[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Newbie's questions implementing the [IDNA]
- To: "Soobok Lee" <lsb@postel.co.kr>, "IETF idn working group" <idn@ops.ietf.org>
- Subject: Re: [idn] Newbie's questions implementing the [IDNA]
- From: "William Blackwood" <wblackwo@tampabay.rr.com>
- Date: Thu, 23 Jan 2003 21:52:42 -0500
- References: <3DF3F626.4060709@netpia.com> <20021209024449.GA31524@postel.co.kr> <20021209231828.GA32412@nicemice.net> <20021210000347.GR31524@postel.co.kr> <20021210002946.GD32412@nicemice.net> <20021210005550.GS31524@postel.co.kr>
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 <wblackwo@tampabay.rr.com> 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" <lsb@postel.co.kr>
To: "IETF idn working group" <idn@ops.ietf.org>
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 <lsb@postel.co.kr> 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
>