Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt

["Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>]

"Eric A. Hall" <ehall@ehsco.com> wrote:

> Everything else discussed is irrelevant.  We are there.

Well, just because I'm finally starting to understand your vision
doesn't mean I'm sold on it.  :)

> > At some point, someone needs to perform Stringprep with some
> > profile.  Why can't that entity go ahead and do the whole
> > transformation at the same time (Unicode to ASCII, prepend the
> > prefix)?  What's the advantage of doing only the Stringprep part?
>
> Because EDNS->ACE conversion by some cache in the middle will
> require that the cache have knowledge of the appropriate prefix tag.
> Everytime you roll out a new stringprep profile, you have to tell
> *everything* that *might* do conversion what the prefix is.

What I'm suggesting is that whenever you apply Stringprep, you also
apply Punycode and prepend the prefix.  It's not really any extra
effort.  Whenever you roll out a new Stringprep profile, the things that
need to get updated to know the new profile are exactly the same things
that need to get updated to know the new prefix.

Of course, my suggestion implies that there is no prepared-UTF-8 format,
there's unprepared-UTF-8 and prepared-ACE.  I don't see the point of
using prepared-UTF-8 as an interchange format, when ACE works just as
well, requires essentially the same effort from applications, and has
the added benefit of backward compatibility.

AMC