W3C home > Mailing lists > Public > public-iri@w3.org > May 2003

Re: issue idnuri-02: New approach, new text

From: Dan Connolly <connolly@w3.org>
Date: 06 May 2003 16:59:05 -0500
To: "Roy T. Fielding" <fielding@apache.org>
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, Martin Duerst <duerst@w3.org>, public-iri@w3.org, uri@w3.org
Message-Id: <1052258344.11683.405.camel@dirk.dm93.org>

On Tue, 2003-05-06 at 16:49, Roy T. Fielding wrote:
> > These are reasons to change RFC 2396 in a way that allows %-escapes
> > in the hostname component (and probably other components). Has this
> > been considered and refused?
> Yes, it has been considered and refused.

If I'm following correctly, that's documented at...

>   The IETF developed IDNA in
> order to avoid the need for operating system infrastructure to be
> updated en masse prior to deployment of i18n domains.  URI processors
> are part of that infrastructure and the rationale for not changing them
> is the same as that provided for not globally changing the 
> implementations
> of BIND.
> IRIs have to be processed by applications that accept the burden of
> full Unicode processing already.  URIs do not.  Adding punycode
> interpretation to the processing of URIs or gethostbyname simply
> will not happen because that technology is already deployed.  Thus,
> in order to make deployment possible, punycode processing moves up
> a layer and URIs are specified such that it becomes easier for the
> IRI processor to determine where it is needed.

Has anybody got an example to show how this works?

I'm trying to collecte examples/tests, if only to keep
all this stuff straight in my own mind.

> Schemes that use DNS within components other than authority will have
> to provide their own percent-encoding-to-punycode processing, but that's
> no big deal because there are no such schemes deployed that actually
> use the domain name for DNS access (they simply use it for 
> identification,
> which does not require punycode).
> ....Roy

Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Tuesday, 6 May 2003 18:01:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:39:37 UTC