RFC 3935 responsibility
jefsey at jefsey.com
Tue Mar 24 11:54:02 CET 2009
The different mails below and my TATWEEL DISALLOW NO position seem to
show there is some confusion about the matter being really discussed.
The matter is not the TATWEEL codepoint. Considering the impact on
IRI, Semantic Addressing, Semiotics, WTO and WIPO rules, etc.. etc...
the matter is: who is to assume the RFC 3935 responsibility
concerning the digital alphabet being authorized to the world:
- WIPO? WTO?
- ASWIG? or other enhenced cooperation on a per language basis (we
call "Ledgers" in the ML-DNS exploration)
- national standardisation bodies?
- UNESCO or MAAYA or accademics?
I have no problem this being decided by IETF, however it must be
accepted by all the others. This is why:
- I think advisable this results from a formal IETF consensus. I am
afraid that today there is no text in the Draft to claim this
responsibility that a consensus may accept to support. For years I
have proposed that at least that responsibility be assumed by Unicode
which has experts and ties with other SSDOs in this domain. This is
has always been opposed.
- I do not think, I may be wrong, this belongs to the current
WG-IDNABIS Charter. Otherwise, why was the ASWIG created?
- I do not feel such a responsibility would be accepted by the IETF
and the accademic, regalian, civil, private societies without at
least an IETF entity to review the DISALLOW claims, such as the ccTAG Reviewer.
This being said, I have no objection (but I feel some may have
objections within and outside the IETF) to a scheme where:
- every language should have an ASWIG or Francophonie equivalent,
showing close ties with every concerned community and trade.
- the IETF documents a procedure where-by these entitities may
reflect their decisions in IDNA IANA tables
Otherwise, I am afraid this IDNA proposition loses international
credibility and will be opposed in WG-LC, IETF-LC, international
implementation with an other decade delay.
Please, let stay within our charter. And be sure that at the end of
the day what will prevail is what the users will want. We only can
either delay and confuse it or speed it up after so many years.
At 02:00 24/03/2009, Andrew Sullivan wrote:
>On Mon, Mar 23, 2009 at 05:34:03PM -0700, Mark Davis wrote:
> > Look back at the email archives; this character is used in many languages,
> > in many surnames.
>I was afraid you'd say that. Surely that some things are hard to
>encode if we don't include someone's favourite code point is not what
>we want to do, right? That puts us back into the
>character-by-character business. The counter-arguments are also in
>the archives, I think.
At 02:09 24/03/2009, Patrik Fältström wrote:
>Then I must ask myself, why does it have the properties in Unicode it
>I.e. I really do not like having the IETF "overriding" various
>definitions Unicode Consortium has decided upon, because there must be
>a reason why the codepoint has the classification it has. If it is
>"used as a letter in a name", then it should be one of the letter
>I am just trying to understand, and will of course given consensus in
>this wg change (potentially) exceptions accordingly.
>Where does this slippery slope end?
At 05:29 24/03/2009, Sarmad Hussain wrote:
> > Based on the on-line exchanges, it appears to me that the general
> > consensus is to ban TATWEEL by exception (ie. make it DISALLOWED).
> > Please respond with:
> > YES (ie make it DISALLOWED)
>YES, should be DISALLOWED at protocol.
At 06:47 24/03/2009, Raed Al-Fayez wrote:
>As a native Arabic speaker I strongly vote for
> YES (ie make it DISALLOWED)
>for the following reasons:
>1- It is so similar to the hyphen (see file: TATWEEL-1.jpg):
> ÃÜÁ vs Ã-Á
>2- It will add more help domain fishing and user confusion (see
> ãËÇá vs ãËÜÇá vs ãÜËÜÇá
>3- It is not a letter or a digit (conflict with LDH concept)
>4- do we really want to see these type of labels as domains (see
> ÜÜÜÜÜ vs Ü vs ÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜ vs Ü-Ü-Ü-Ü-Ü (the
> last one is composed of TATWEEL + Hyphen)
>5- If someone feels that all registries are capable of fixing
>problems in all the languages than why not enabling all code points
>and simplify the IDNA protocol!!!!!!
> I believe that we need to simplify the registry operations
> by keeping them focused on the core functions and not adding extra
> work/load on the script problems/issues
More information about the Idna-update