Re: revised "generic syntax" and "data:" internet drafts

Larry Masinter <masinter@parc.xerox.com> Sat, 05 April 1997 00:24 UTC

Received: from cnri by ietf.org id aa02063; 4 Apr 97 19:24 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa22066; 4 Apr 97 19:24 EST
Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id SAA04575 for uri-out; Fri, 4 Apr 1997 18:58:41 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id SAA04567 for <uri@services.bunyip.com>; Fri, 4 Apr 1997 18:58:34 -0500 (EST)
Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02731 (mail destined for uri@services.bunyip.com); Fri, 4 Apr 97 18:58:32 -0500
Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <16308(6)>; Fri, 4 Apr 1997 15:58:19 PST
Received: from bronze.parc.xerox.com ([13.1.100.114]) by casablanca.parc.xerox.com with SMTP id <72070>; Fri, 4 Apr 1997 15:57:59 PST
Message-Id: <33459587.2FD0@parc.xerox.com>
Date: Fri, 04 Apr 1997 15:57:59 -0800
From: Larry Masinter <masinter@parc.xerox.com>
Reply-To: masinter@parc.xerox.com
Organization: PARC
X-Mailer: Mozilla 3.01Gold (Win95; I)
Mime-Version: 1.0
To: Edward Cherlin <cherlin@newbie.net>
Cc: uri@bunyip.com
Subject: Re: revised "generic syntax" and "data:" internet drafts
References: <3342E477.5FD9@parc.xerox.com> <v03007805af69d830da5e@[206.245.192.34]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-uri@bunyip.com
Precedence: bulk

I'm surprised I have to spell this out. 

Martin has proposed that we add to the "Draft Standard" the following
wording:

>    URL creation mechanisms that generate the URL from a source which
>    is not restricted to a single character->octet encoding are
>    encouraged, but not required, to transition resource names toward
>    using UTF-8 exclusively.

I will point out that of all of the implementors of all of the software
that I'm aware of that contain "URL creation mechanisms", including
the software products from Alis, Accent, Netscape and Microsoft -- 
even in the latest versions which purport to support UTF-8 in the
representation of text--  I have yet to see any product that is a
"URL creation mechanism" that actually does what Martin is proposing
we encourage them to do ("transition resource names toward using
UTF-8 exclusively"). Not only aren't they transitioning toward
using UTF-8 exclusively, I've yet to see one that actually uses
UTF-8 in resource names at all. When I asked for instances of some
actual
practice, I got sent two examples of URLs on Martin's own site
in which the "URL creation mechanism" was careful hand crafting
of the URLs themselves. Furthermore, none of the implementors
of the "URL creation mechanisms" have stepped forward to endorse
this proposal. The only voices for it are those who are not actually
producing "URL creation mechanisms". Even the most ferverent
believer in UTF-8 would not be so foolish as to create a product
that 'transitioned' toward 'using UTF-8 exclusively'.  Certainly, 99.99%
of the installed "URL creation mechanisms that generate a URL from a
source that is restricted to a single character->octet encoding"
do *NOT* "use UTF-8 exclusively".

It would be irresponsible and ridiculous to insert a recommendation
into a Draft Standard of a practice that not only did not occur
in the Proposed Standard but also is not the result of implementation
experience of the community.

Regards,

Larry
--
http://www.parc.xerox.com/masinter