headers
Steve Dyer | 1 Nov 10:40
Favicon

Re: Re: idn-uri document

At 23:40 31/10/2002 +0100, Erik Nordmark wrote:
> > >The defined syntax rules for declare certain ASCII domain names illegal
> > >(such as *.example.org). Where is the check for illedgal names assumed to
> > >be performed? For IDNA it probably makes sense to only apply this types
> > >of checks (setting the UseSTD3ASCIIRules flag) when verifying domain name
> > >registrations and not do such checks in the clients.
> >
> > This is an IDNA question, not a idn-uri question. As far as I remember,
> > the idea was to have the checks done on the clients, too (with some
> > leeway for unassigned characters to stay forward-compatible with
> > new character assignements). The reason for this was to create
> > pressure on registries to follow the rules.

Hi,
I am surprised that you indicate that certain ASCII domains will be 
illegal. I can see why unix people may be unhappy about "*.example.org".
I trust that most high ASCII will be allowed - "é" (e-acute) for example 
since software such as BIND9 handles them.

I am also concerned that a group discussing a protocol is suggesting that 
the protocol is designed to "create pressure on registries". A protocol is 
a stand-alone technical facility, not an instrument of policy.

Regards

Steve Dyer
CentralNic Ltd
Permalink | Reply | 0 comments |
headers
Harald Tveit Alvestrand | 1 Nov 13:03
Picon

RE: UTF-8 in Internet Drafts (was Re: I-D ACTION:draft-jsen g-idn-admin-01.txt)


--On 31. oktober 2002 16:06 -0500 John C Klensin <klensin <at> jck.com> wrote:

>> I-Ds can be submitted in PostScript format if that helps,
>> though a text version (that can be different due to issues
>> with figures and non-ASCII characters) is still required to
>> have both published.
>
> Assuming, obviously incorrectly, that the same "simultaneous
> posting in text and PS or PDF" principle applied to I-Ds as
> well as RFCs, this one was sent to the I-D administrator in
> text and pdf formats.  The latter was discarded.   If we would
> like a PDF alternative, I think that is a small matter of the
> IESG expanding the rules.

There are currently quite a few PDF files in the internet-drafts 
direcories, and I don't think they got there by accident.

I'm checking with the secretariat to figure out whether they think it was 
lost through clerical error on their side or on the sender's side.

               Harald
Permalink | Reply | 0 comments |
headers
Harald Tveit Alvestrand | 1 Nov 13:08
Picon

Representing codepoints (RE: UTF-8 in Internet Drafts)


--On 31. oktober 2002 16:06 -0500 John C Klensin <klensin <at> jck.com> wrote:

> James and
> the rest of the JET team have been discussing (at my request)
> ways to present the characters in ASCII text that would make
> the document more comprehensible than the code points alone
> for those reading the document in ASCII text.

advertising someone else's code, and only tangentially relevant to this 
list.....

there's a Perl package out on CPAN called "unidecode", maintained by Sean 
Burke. It can be used to generate ASCII strings from any sequence of 
Unicode codepoints; in some cases, these ASCII strings can remind people 
what the characters were supposed to mean.

For Chinese, for instance, it spits out something resembling Pinyin 
(probably *is* Pinyin, but I don't know enough to guarantee that).

Health warning: I've only played with it....

                    Harald
Permalink | Reply | 0 comments |
headers
Martin Duerst | 3 Nov 07:49
Picon
Favicon

Re: Re: idn-uri document

At 23:40 02/10/31 +0100, Erik Nordmark wrote:
> > Ah, I see, of course the resolvers pass things through and then
> > pass the negative result back, so they don't actually reject it.
> > So now the sentence reads:
> >
> > However, such syntax should never be used, and will never be
> > resolved because no such domains will be registered.
>
>ok
>
>
> > >The defined syntax rules for declare certain ASCII domain names illegal
> > >(such as *.example.org). Where is the check for illedgal names assumed to
> > >be performed? For IDNA it probably makes sense to only apply this types
> > >of checks (setting the UseSTD3ASCIIRules flag) when verifying domain name
> > >registrations and not do such checks in the clients.
> >
> > This is an IDNA question, not a idn-uri question. As far as I remember,
> > the idea was to have the checks done on the clients, too (with some
> > leeway for unassigned characters to stay forward-compatible with
> > new character assignements). The reason for this was to create
> > pressure on registries to follow the rules.
>
>My point is that the idn-uri document is more restrictive in its
>syntax than the IDNA document. I don't know if this is a good idea
>or a bad idea, and we need to understand which type of idea it is.

URIs [RFC 2396] uses the same restrictions as STD3. I think it
therefore makes sense to also use these restrictions in this
upgrade.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Duerst | 3 Nov 03:47
Picon
Favicon

Re: Re: idn-uri document

Hello Steve,

In an URI, *.example.org (e.g. http://*.example.org) is very
clearly illegal.

Also, I don't think it's a bad idea that a group that decides on the
syntax of a new protocol element give some thoughts about where the
rules should be checked, and where not, in order to assure consistent
deployment. The restrictions on domain names given by IDNA/nameprep/
stringprep are not in any sense policy issues, they are very clearly
technical issues.

Regards,    Martin.

At 09:40 02/11/01 +0000, Steve Dyer wrote:
>At 23:40 31/10/2002 +0100, Erik Nordmark wrote:
>> > >The defined syntax rules for declare certain ASCII domain names illegal
>> > >(such as *.example.org). Where is the check for illedgal names assumed to
>> > >be performed? For IDNA it probably makes sense to only apply this types
>> > >of checks (setting the UseSTD3ASCIIRules flag) when verifying domain name
>> > >registrations and not do such checks in the clients.
>> >
>> > This is an IDNA question, not a idn-uri question. As far as I remember,
>> > the idea was to have the checks done on the clients, too (with some
>> > leeway for unassigned characters to stay forward-compatible with
>> > new character assignements). The reason for this was to create
>> > pressure on registries to follow the rules.
>
>Hi,
>I am surprised that you indicate that certain ASCII domains will be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rick Wesson | 4 Nov 00:48

punnycode in java


anyone know of a punycode implementation in java source?

thanks,

-rick
Permalink | Reply | 0 comments |
headers
Erik Nordmark | 3 Nov 20:07
Picon

Re: Re: idn-uri document

> URIs [RFC 2396] uses the same restrictions as STD3. I think it
> therefore makes sense to also use these restrictions in this
> upgrade.
> 
> On the other hand, while URI syntax contains these checks, URI
> implementations are supposed to not check (because they would need
> scheme-specific knowledge to do so, which would restrict
> deployment of new schemes (even more than it's currently restricted)).

Hmm, is this captured in some specification?

Clearly(?) URI parsers will have to enforce some syntax
checks e.g. in order to tell which part of a URI is
a domain name.

  Erik
Permalink | Reply | 0 comments |
headers
Simon Josefsson | 5 Nov 11:29

Sample test vectors?

Has anyone developed test vectors for stringprep and/or IDNA?

I think such a document would be useful, to test implementations.

A'la enumerating results like the following, together with details on
the profile used:

STRINGPREP("foo\xC2\xADbar") => "foobar"
STRINGPREP("\xC2\xB5") => "\xCE\xBC"
STRINGPREP("\xC2\xAA") => "\x61"
<snip>
Permalink | Reply | 0 comments |
headers
John C Klensin | 5 Nov 19:23

Re: Re: idn-uri document

--On Thursday, 31 October, 2002 23:40 +0100 Erik Nordmark
<Erik.Nordmark <at> sun.com> wrote:

>> If IDNA says that their preparation of ascii-only labels is
>> the identity operation, then we recommend that you apply that
>> (i.e. do nothing), and not something else. If you see a way
>> to make this clearer, please tell me.
> 
> It is the identity operation for ASCII-only labels (plus some
> checks that will reject certain labels).
> 
> If you want to do that part, but not apply the Punycode step
> then I think you need to explicitly state that one should
> apply ToASCII without the punycode step (and other steps that
> don't make sense if there are any).

Erik,

I tried to raise this argument in some of my remarks about IDNA,
but, as with many other things, it was apparently ignored by the
IESG.  Let me repeat it, in a different way, in this context.
One of the things that many of us feel is key to the success of
the Internet protocol suite is a minimum of profiling and
options for variations within a protocol.  That is obviously a
principle, not a hard rule: the stringprep-nameprep separation
arose as the better choice relative to having different
protocols make up their own mapping variations.  But, even in
that case, we haven't permitted profile variations _within_
IDNA: a user, site, or registry cannot select a different
stringprep profile, and that is a Good, probably necessary,
(Continue reading)

Permalink | Reply | 13 comments |
headers
JFC (Jefsey) Morfin | 6 Nov 00:44

Re: Re: idn-uri document

I came in here just to say two things as a "user"
- the punycode thing seems OK but the DNS aspects are
   inadequate"
- the text you produced is not easily understandable.
I was said to be a troll for the second point. May be
could we also look at the second one?

At 19:23 05/11/02, John C Klensin wrote:
>--On Thursday, 31 October, 2002 23:40 +0100 Erik Nordmark

>But, even in that case, we haven't permitted profile variations _within_ 
>IDNA: a user, site, or registry cannot select a different stringprep 
>profile, and that is a Good, probably necessary, thing.

"probably" necessary ???
At this date, this rises a lot of question.
All I found was a very early commitment to that in the process.
I did not read everythng yet.
Any reason why it is "certainly" necessary?
(a part from obvious non technical reasons)

  But much the same argument applies to the type of use Martin
>contemplates.   IDNA, as written, is _one_ protocol.  It is not
>a toolkit for building other protocols, nor is it a a set of
>profiles that other protocols can adopt.  Those two may be much
>the same thing in practice.  As soon as we say "you should use
>that operation from IDNA, but without some particular step" we
>head down a slippery slope.  That is especially true because
>IDNA contains (or appears to contain) a good deal of normative
>text outside the particular of, e.g., ToASCII.  It is not clear
(Continue reading)

Permalink | Reply | 0 comments |

Gmane