Re: draft-fielding-url-syntax-05.txt

Larry Masinter (masinter@parc.xerox.com)
Fri, 2 May 1997 12:14:25 PDT


Message-ID: <336A3D11.73A8@parc.xerox.com>
Date: Fri, 2 May 1997 12:14:25 PDT
From: Larry Masinter <masinter@parc.xerox.com>
To: Chris Newman <Chris.Newman@innosoft.com>
CC: IETF URI list <uri@bunyip.com>
Subject: Re: draft-fielding-url-syntax-05.txt

#I find this much too wishy-washy. 
Not every section of a document can explicitly forbid
everything that is forbidden. In general, standards
documents work best when they say "how do I use this"
rather than listing lots of rules.

# I think we should explicitly forbid the use of 8-bit characters

I think this document is clear that URLs are currently
written with a limited repertoire of characters that
is a subset of US-ASCII. That subset does not include
"8-bit characters" or "9-bit characters" or "38-bit characters".

#  and hex-encoded 8-bit characters

I think it would be incorrect to disallow hex-encoded
8-bit octets that didn't actually correspond to characters,
e.g., in guid schemes, in FTP URLs for FTP servers that
*don't* implement UTF-8, etc. So, no.

# except as defined by the future I18N URL standard.

The future standard will set the standard for the future.
All this document says is that it doesn't set that standard.

# We need to make it very clear that programs sending 8-bit URLs over
# the wire are broken (unless they use UTF8 according to the # future
standard).

The purpose of this document is to define the standard for
how URLs work, and not to 'send a message' about a future
standard. I and Martin have actually started work on the
'message', and if you want to help 'send a message' about UTF8,
I invite you to actually help craft the 'message'.

When we have a standard for UTF8 URLs, we'll have a standard
for UTF8 URLs. But that's the only message that you can
send that will have any meaning.

Larry