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 >
