Please discuss the proposed text, not "belief in Unicode"

Larry Masinter <[email protected]>
Newsgroups gmane.ietf.url
Organization Xerox PARC
Message-ID <[email protected]>
There is no point in continuing the Unicode debate
here -- we've had it forever everywhere. I suggest
ignoring discussion that is about anything other than
the proposed text, since responding to irrelevant
flames just generates more of them.

I proposed:

> =================
> Use of Character Encodings
> 
> When describing new URL schemes in which the elements of
> the URL are actually representations of sequences of characters,
> care should be taken not to introduce unnecessary variety in the 
> ways in which characters are encoded into octets and then into 
> URL characters. Unless there is some compelling reason for a 
> particular scheme to do otherwise, translating character sequences
> into UTF-8 [RFC 2044] and then subsequently using the %HH encoding
> for unsafe characters is recommended.

Since this is a document about the procedure and criteria
for NEW URL schemes, the comment that "this is incompatible
with current practice" is irrelevant, since any NEW URL scheme
is of course incompatible with current practice. That is
why it is a NEW scheme. 

The comment that "this is unacceptable" is merely repeating
an opinion. Of course many things are unacceptable to
some and not to others. I don't think we need to pay any
attention to opinions without justification.

The comment "Use of %HH must be mandatory." is misplaced.
The issue of unsafe characters in URLs is expanded at
great length in the generic syntax document. This document,
the process and criteria for new URL schemes, does not
change the generic syntax of URLs, it only is a set of
guidelines for new ones.

# The only safe recommendation to be compaible with existing
# practice is to use ISO 2022.

This section is not about "safety" or even "compatible with
existing practice". We're making a recommendation for new
URL schemes. Certainly, compatibility with current practice 
could be a "compelling reason" for not following the
recommendation, but the case would have to be made based
on the practice.

In addition, I think there was some misunderstanding of the
precondition:

> When describing new URL schemes in which the elements of
> the URL are actually representations of sequences of characters,

since it applies only in the case where there are three
levels of interpretation:
   sequence of characters -> octet -> URL characters

and of course, the only safe characters in "URL characters"
are the subset of ASCII so designated in the generic URL
syntax draft. 

Larry
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.