Re: Newbie's questions implementing the [IDNA]

CAN **ANYONE** tell the world when this RFC is going to be published and we
are going to get this IDN **FINALLY** going?

Any estimates even???







> William Blackwood <[email protected]> wrote:
>
> > Do you have any estimate when the RFC is going to be published?
>
> I don't.  It's now in the hands of the RFC editor.  People with more
> IETF experience than I have might be able to guess how long it will
> take.
>
> > How far behind, in terms of calendar months/years is this working
> > group's output according to the original schedule?
>
> I joined the working group after it was already a year old, so I'm not
> sure I ever saw the original schedule.  The only schedule I can find now
> is shown here:
>
> http://www.ietf.org/html.charters/idn-charter.html
>
> It gives 2001-Jun as the goal for working group last call (which
> actually happened in 2002-Jan).  The schedule gives no goals for IESG
> approval (which happened in 2002-Oct) or RFC publication (which has yet
> to happen).
>
> AMC
>
>
>
----- Original Message -----
From: "Soobok Lee" <[email protected]>
To: "IETF idn working group" <[email protected]>
Sent: Monday, December 09, 2002 7:55 PM
Subject: Re: [idn] Newbie's questions implementing the [IDNA]


> On Tue, Dec 10, 2002 at 12:29:46AM +0000, Adam M. Costello wrote:
> > Soobok Lee <[email protected]> wrote:
> >
> > > > The output of ToUnicode can contain unnameprepped, prohibited, and
> > > > unassigned code points.  Simply feed such a string as input to
> > > > ToUnicode, and the string will be output unaltered by ToUnicode.
> > >
> > > right. IDNA states that such outputs should not be displayed as native
> > > ones, but just as ASCII ones as it is. "must not" is meant for that.
> > > I think it is clear enough in drafts.
> >
> > I don't know what you could be referring to.  Suppose X is a string
> > consisting entirely of uppercase Greek letters.  X is not nameprepped,
> > because nameprepped things don't contain uppercase.  X contains no ASCII
> > characters.  ToUnicode(X) equals X, exactly, which means it is perfectly
> > acceptable to display X.
>
> I mean that Punycode(X) [not Punycode(NAMEPREP(X)), not X ] can be
inserted into
>  RFC822 message headers. In that case, ToUnicode(Punycode(X)) should be
> treated differently than ToUnicode(Punycode(Nameprep(X))) .
>
> You are right if X is non-ASCII input, because toUnicode(X)==X.
>
> >
> > AMC
>