Internationalized Domain Name (idn)

Paul Hoffman / IMC | 9 Oct 22:21

Picon

draft-hoffman-rfc3454bis

	Title		: Preparation of Internationalized Strings
			  ('stringprep')
	Author(s)	: P. Hoffman, M. Blanchet
	Filename	: draft-hoffman-rfc3454bis-01.txt
	Pages		: 69
	Date		: 2003-10-9

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hoffman-rfc3454bis-01.txt

-----

 From the draft:

This document is a revision of RFC 3454. None of the changes affect the
protocol described in RFC 3454; that is, all implementations of RFC 3454
will be identical with implementations of the specification in this
document. The items that have changed RFC 3454 document are:

- Made clearer in section 2 and section 7 where the check for
   unassigned characters should be done, namely in step 3.

- In section 7, there was a paragraph about the goal of the requirements
   in the section. That paragraph was removed because it didn't describe
   the goal and could be misleading.

- In the last paragraph of section 7.1, "provide" was changed to
   "provides".

- Fixed the capitalization in the headings in Appendixes A, C, and D.

(Continue reading)

Paul Hoffman / IMC | 9 Oct 22:21

Picon

Moving the IDN RFCs from Proposed to Draft Standards

Greetings again. Patrik, Adam, Marc and I have made editorial 
revisions to the RFCs in a new series of Internet drafts. The 
announcements for those drafts came out recently; the following four 
messages include a summary of the announcements plus the list from 
each Internet Draft about what changes it makes to the corresponding 
RFC. Note that none of the protocols were changed: all the document 
changes were for clarification based on comments we have received 
over the past six months, plus a few minor editorial changes. That 
is, an implementation of the old RFC should work the same under the 
new RFC.

Comments on the individual drafts are appreciated.

BTW, the second part of moving RFCs from Proposed to Draft Standard 
involves finding two or more independent interoperable 
implementations of the standard. We believe that we found many during 
the IDNConnect event (see <http://www.idnconnect.jdna.jp>) a few 
weeks ago, and we'll be making a full report on this soon.

--Paul Hoffman, Director
--Internet Mail Consortium

Paul Hoffman / IMC | 9 Oct 22:21

Picon

draft-hoffman-rfc3491bis

	Title		: Nameprep: A Stringprep Profile for 
Internationalized Domain Names (IDN)
	Author(s)	: P. Hoffman, M. Blanchet
	Filename	: draft-hoffman-rfc3491bis-00.txt
	Pages		: 0
	Date		: 2003-10-7

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hoffman-rfc3491bis-00.txt

-----

 From the draft:

This document is a revision of RFC 3491. None of the changes affect the
protocol described in RFC 3491; that is, all implementations of RFC 3491
will be identical with implementations of the specification in this
document. The items that have changed RFC 3491 document are:

- In section 1.1, a sentence was added to the end of the first paragraph
   to make it clear that implementations must follow the same steps in
   Stringprep, not just use the tables from Stringprep. The numbered list
   added as well.

- In section 5, removed "This profile MUST be used with the IDNA
   protocol" because it is expected that other protocols might use this
   profile as well.

--Paul Hoffman, Director
--Internet Mail Consortium

(Continue reading)

Paul Hoffman / IMC | 9 Oct 22:21

Picon

draft-hoffman-rfc3490bis

	Title		: Internationalizing Domain Names in 
Applications (IDNA)
	Author(s)	: P. Faltstrom, P. Hoffman, A. Costello
	Filename	: draft-hoffman-rfc3490bis-00.txt
	Pages		: 0
	Date		: 2003-10-7

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hoffman-rfc3490bis-00.txt

-----

 From the draft:

This document is a revision of RFC 3490. None of the changes affect the
protocol described in RFC 3490; that is, all implementations of RFC 3490
will be identical with implementations of the specification in this
document. The items that have changed RFC 3490 document are:

- The last line of section 1 has a grammatical fix (user's -> users').

- In section 3.1 rule 3, fixed spelling of "unintelligle" to
   "unintelligible".

- In step 8 of section 4.1, added "(0 is excluded)" to clarify.

- In section 4.2, the first sentence of the third paragraph was
   incorrect. It has been replaced with a sentence that is both
   correct and more descriptive.

(Continue reading)

Paul Hoffman / IMC | 9 Oct 22:21

Picon

draft-costello-rfc3492bis

	Title		: Punycode: A Bootstring encoding of Unicode for
			  Internationalized Domain Names in Applications (IDNA)
	Author(s)	: A. Costello
	Filename	: draft-costello-rfc3492bis-00.txt
	Pages		: 0
	Date		: 2003-10-6

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-costello-rfc3492bis-00.txt

-----

 From the draft:

This document is a revision of RFC 3492.  None of the changes alter
the protocol; that is, any correct implementation of RFC 3492 is
a correct implementation of this document, and vice-versa.  The
changes are as follows:

At the end of section 2 "Terminology", added a statement of
the assumption that all values from zero through maxint can be
represented.  RFC 3492 relied on this assumption without stating it.

In section 5 "Parameter values for Punycode", in the paragraph
following the first list of parameter values, fixed the remark about
code points D800..DFFF, which RFC 3492 claimed were not code points
at all.  Technically they are code points, but they do not occur in
any valid Unicode string.  In the same section, in the paragraph
discussing uppercase and lowercase, clarified that the restrictions
on encoder output apply only to the non-literal portion of the

(Continue reading)

Paul Hoffman / IMC | 15 Oct 05:01

Picon

Interoperable IDNA implementations.

Greetings again. As part of the effort to move the IDNA documents 
from Proposed Standard to Draft Standard, we need to show at least 
two independent interoperable implementations of IDNA (talk about 
alliteration!). Of course, IDNA is not a client-server specification, 
so showing interoperability is not simply a case of creating a client 
and a server.

Instead, as part of the work performed at the IDNConnect event last 
month, I created what I hope to be a very complete test suite for 
IDNA. This includes testing every part of the IDNA spec, every part 
of the Nameprep spec, and every part of the Punycode spec (where 
"every part" means all the protocol steps, not just the MUSTs and 
SHOULDs). The full set of tests is described at 
<http://idnconnect.jdna.jp/Description.txt>. (IDNConnect and the 
continuing development of the testbed are funded by the Japanese 
Domain Names Association.)

The actual tests were created using the original set of tools that I 
created in Perl during the creation of the IDNA specs. During the 
event, implementers from around the world tested their code against 
the tests; we did not run the tests in a central environment, and 
results of the test were not kept. Most test participants reported 
that they found bugs in the software and have fixed them.

Subsequent to the event, I have validated one (unnamed, pre-release) 
IDNA system passes all the tests that it should pass, and fails all 
the test that should fail, as specified in the test description. This 
may be sufficient for two independent interoperable implementations: 
the creation of the UTF-8 and Punycode strings, and the system that 
interpreted each of them. I have been told by some developers that

(Continue reading)

Paul Hoffman / IMC | 16 Oct 19:05

Picon

NUDGE: Moving the IDN RFCs from Proposed to Draft Standards

Just a quick reality check. I sent this message with the four 
follow-ons a week ago. We haven't heard anything on the list (or off 
the list, for that matter). Maybe our proposed changes are perfect 
and beyond comment...

>Greetings again. Patrik, Adam, Marc and I have made editorial 
>revisions to the RFCs in a new series of Internet drafts. The 
>announcements for those drafts came out recently; the following four 
>messages include a summary of the announcements plus the list from 
>each Internet Draft about what changes it makes to the corresponding 
>RFC. Note that none of the protocols were changed: all the document 
>changes were for clarification based on comments we have received 
>over the past six months, plus a few minor editorial changes. That 
>is, an implementation of the old RFC should work the same under the 
>new RFC.
>
>Comments on the individual drafts are appreciated.
>
>BTW, the second part of moving RFCs from Proposed to Draft Standard 
>involves finding two or more independent interoperable 
>implementations of the standard. We believe that we found many 
>during the IDNConnect event (see <http://www.idnconnect.jdna.jp>) a 
>few weeks ago, and we'll be making a full report on this soon.

--Paul Hoffman, Director
--Internet Mail Consortium

Martin v. Löwis | 17 Oct 00:03

Picon

Re: draft-costello-rfc3492bis

Paul Hoffman / IMC <phoffman <at> imc.org> writes:

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-costello-rfc3492bis-00.txt

I just looked at it, and have these comments:

> In sections 6.2 "Decoding procedure" and 6.3 "Encoding procedure",
> added statements to emphasize that overflow handling is REQUIRED,
> NOT OPTIONAL.

"NOT OPTIONAL" is not a keyword of RFC2119. "OPTIONAL" is, and it is a
synonym of "MAY". The usage of "NOT OPTIONAL" is redundant with the
"MUST".

It's not immediately obvious why some operations (e.g. inside adapt)
don't perform overflow checking, but (without further review) I assume
there is some guarantee that it can't overflow.

Regards,
Martin

Adam M. Costello | 17 Oct 10:42

Re: draft-costello-rfc3492bis

"Martin v. Löwis" <martin <at> v.loewis.de> wrote:

> > http://www.ietf.org/internet-drafts/draft-costello-rfc3492bis-00.txt
>
> "NOT OPTIONAL" is not a keyword of RFC2119. "OPTIONAL" is, and it is a
> synonym of "MAY".  The usage of "NOT OPTIONAL" is redundant with the
> "MUST".

Maybe I got carried away with the emphasis.  I wouldn't mind removing
all instances of "NOT OPTIONAL", leaving just "MUST" and "REQUIRED".

> It's not immediately obvious why some operations (e.g. inside adapt)
> don't perform overflow checking, but (without further review) I assume
> there is some guarantee that it can't overflow.

You raise an interesting question.

In the main encoding and decoding functions, for any values of maxint
and the constants (base, tmin, tmax, etc), you can make overflow happen
by providing a long enough input.

In adapt(), on the other hand, the possibility of overflow can be ruled
out regardless of the input, if the constants aren't too extreme.

adapt() cannot overflow if

    (base - tmin + 1) * ((base - tmin) * tmax) div 2) <= maxint

and

(Continue reading)

Patrik Fältström | 26 Oct 20:55

Picon

FYI: BOF on Internationalized Email Addresses (IEA)


At the IETF in Minneapolis, there will be a BOF on Internationalized 
Email Addresses (IEA).

It is *preliminary* on the agenda on Monday, November 10, 2003 at 
1530-1730.

Chairs:  Pete Resnick, Patrik Fältström
Mailing list:imaa <at> imc.org (other salient lists include uri <at> w3.org)
Agenda:

Agenda Bashing (Chairs)                5 min.
Topic Introduction (Chairs)           10 min.
Proposals
   IDNA-Based (Paul Hoffman)           15 min.
   Infrastructure-Based (John Klensin) 15 min.
   IRI-Based (Michel Suignard)         15 min.

Discussion                            60 min.

Topics for discussion:

   Are there other solutions which have been specified?

   The solutions present the problem at different scopes;

      Where should the IETF tackle it?

      Are some short-term, and other long-term?

(Continue reading)

Group

gmane.ietf.idn.

Search Archive

Page

1 | 2 | 3 | 4 | 5 | 6 | 7

Articles in period: 60

October 2003

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

Revised IDN Guidelines Open for Public Comments (21 Sep 02:43)
IDN Implementation Status Update (22 Jul 18:12)
(14 Jul 11:44)
a way toward homograph resolution ? (was "improving WG operation") (11 May 16:21)
homographs in TrueType fonts (5 May 23:34)
Mac OS X Safari and IDN spoofing (28 Mar 19:15)
Mac OS X Safari and IDN spoofing (22 Mar 22:19)
list: productive discussion (18 Mar 19:39)
IDNA section 3.1 requirement 3 (16 Mar 23:13)
stability (16 Mar 19:40)
stability (16 Mar 19:11)
stability (16 Mar 17:37)
character tables (3 Mar 10:03)
character tables (3 Mar 08:13)
mailing list (25 Feb 03:08)
gTLD Registry Constituency's statement (25 Feb 02:43)
punctuation (24 Feb 20:55)
homographs of the delimiters aka syntax chars (23 Feb 22:43)
another BIDI/ASCII representation problem on w3.org (23 Feb 19:35)
another BIDI/ASCII representation problem on w3.org (23 Feb 09:29)
nameprep, IDN spoofing and the registries (22 Feb 22:59)

Archives

1	March 2008
1	February 2008
1	February 2006
1	September 2005
2	July 2005
6	May 2005
4	April 2005
88	March 2005
271	February 2005
1	November 2004
8	September 2004
23	August 2004
6	July 2004
4	June 2004
2	May 2004
1	April 2004
3	March 2004
2	February 2004
19	January 2004
1	December 2003
4	November 2003
60	October 2003
1	September 2003
4	August 2003
2	July 2003
2	June 2003
13	May 2003
27	April 2003
98	March 2003
16	February 2003
22	January 2003
31	December 2002
65	November 2002
97	October 2002
207	September 2002
24	August 2002
60	July 2002
211	June 2002
206	May 2002
51	April 2002

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template