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

Larry Masinter <masinter@parc.xerox.com> Wed, 02 April 1997 23:26 UTC

Received: from cnri by ietf.org id aa04350; 2 Apr 97 18:26 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa21513; 2 Apr 97 18:26 EST
Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id RAA00281 for uri-out; Wed, 2 Apr 1997 17:59:20 -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 RAA00273 for <uri@services.bunyip.com>; Wed, 2 Apr 1997 17:59:14 -0500 (EST)
Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23006 (mail destined for uri@services.bunyip.com); Wed, 2 Apr 97 17:58:42 -0500
Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <17612(1)>; Wed, 2 Apr 1997 14:58:17 PST
Received: from bronze.parc.xerox.com ([13.1.102.194]) by casablanca.parc.xerox.com with SMTP id <72025>; Wed, 2 Apr 1997 14:58:00 PST
Message-Id: <3342E477.5FD9@parc.xerox.com>
Date: Wed, 02 Apr 1997 14: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: <334153DD.7495@parc.xerox.com> <v0300781daf687ef07cea@[206.245.192.34]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-uri@bunyip.com
Precedence: bulk

In my personal judgement, there was significant controversy
about adding to a Draft Standard document additional constraints
that were not part of the Proposed Standard and are not
implemented in at least two interoperable implementations.

As I said, I edited the document to contain those changes that
I thought were non-controversial.

>   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.
>   URL creation mechanisms that generate the URL from a source which
>   is restricted to a single character->octet encoding should use UTF-8
>   exclusively.  If the source encoding is not UTF-8, then a mapping
>   between the source encoding and UTF-8 should be used.
>
This is an additional requirement that does not correspond,
as far as I can tell, to any kind of "implementation experience".
I know of no URL creation mechanisms that actually do this.

Further, I think that the complaints that there is a certain
amount of ambiguity in practice over exactly how one goes
about doing this are legitimate, and that not only is there
no "running code", there is not "rough consensus".

> I'm surprised, too. I thought we had this worked out, and that
> there was no significant objection or controversy.

I hope that the domain name from which you post ("newbie.net")
isn't some kind of joke. If you insist, I will forward you
the three hundred or so email messages discussing the controversy
around the proposed additions.

Regards,

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