3492bis

[JFC Morfin]

Frank,
would you have a text to propose? It would make easier to understand 
what it represents.
Why would you not introduce it as an RFC 3492bis private submission 
with Adam Costello?

I am sure that Adam could review the text upon the experience of some 
discusions he shared, like for mail addresses.  This could lead to an 
extended punycode that could be tested. It should provide full 
backward compatibility, so this WG would not have to consider it, but 
the Community could have a more powerfull tool that might 
consistently address needs IDNA does not support (such those that 
lead ".su" to adopt its position, that many other ccTLD will probably 
adopt). This way it would be a network stability factor.
jfc

At 21:13 19/06/2008, Frank Ellermann wrote:

>John C Klensin wrote:
>
> > My preference would be to finish IDNA2008
>
>That would be fine, when somebody asked what "A-label"
>is supposed to mean in the IDN test TLD (2606bis) I-D
>he had a *big* point.
>
> > _then_ go back and look at Stringprep/3942 (and
> > SASLPrep, etc.) and ask, not just "what is in the
> > errata" and "can we move this forward procedurally"
> > but, "what did we learn with IDNA that should be
> > applied here".
>
>"Nobody is going to invent a new encoding" is in the
>WG Charter, I take that as given.  But I forgot the
>(in essence ready) 3492bis draft in the discussion
>about a "todo" list.  IIRC we talked about it on the
>EAI list more than a year ago.
>
>I stumbled about it while trying to reconstruct how
>the old IDN WG starting with UTF-5 arrived at 3492 -
>meanwhile I found some of the missing pieces, e.g.,
>in <http://www.inter-locale.com/IUC22.pdf>, or in
><http://www.nicemice.net/idn/ace-eval.gz>.  I've
>now added a 3492bis link to the Punycode article:
>http://en.wikipedia.org/wiki/Punycode#External_links
>
> > "yes, but we need to add the Unicode 5.1 diffs
> > and cycles at Proposed"
>
>Likely.  From my POV RFC 3492 is just an algorithm
>with input = a sequence of whole numbers between 0
>and 0x10FFFF, and output = string of US-ASCII LDH
>characters (not necessarily related to any IDNAbis
>purposes).  In theory this could be registered as
>charset, or rather, the technical reasons why such
>an attempt would be rejected are not obvious.
>
> > that this is just not the right time to ask it.
>
>"Couldn't they find a less obscure algorithm" is
>apparently the most FAQ in IDN discussions, now
>after "why is it bound to an old Unicode version"
>will be soon obsolete.
>
>  Frank
>
>_______________________________________________
>Idna-update mailing list
>Idna-update at alvestrand.no
>http://www.alvestrand.no/mailman/listinfo/idna-update