RFC 3935 responsibility

[JFC Morfin]

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:

- IETF?
- Unicode?
- IANA?
- ISO?
- WIPO? WTO?
- ASWIG? or other enhenced cooperation on a per language basis (we 
call "Ledgers" in the ML-DNS exploration)
- national standardisation bodies?
- Governments?
- UNESCO or MAAYA or accademics?
- Registries?
- users?

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.

jfc

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
>has?
>
>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
>variants? Or?
>
>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:
>Dear All,
>
>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 
>file: TATWEEL-2.jpg):
>         ãËÇá    vs    ãËÜÇá   vs    ãÜËÜÇá
>
>3- It is not a letter or a digit (conflict with LDH concept)
>         http://en.wikipedia.org/wiki/Tatweel
>
>4- do we really want to see these type of labels as domains (see 
>file: TATWEEL-4.jpg):
>         ÜÜÜÜÜ    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
>
>Thanks ..