Re: Apology -- didn't read the critical section (was I18N)

Larry -

On Wed, 19 Feb 1997, you wrote:

> First, this doesn't have much to do with "Internationalization". 
> It's just a recommendation for theuse of character encodings. 

Don't understand what you are saying here. Character encodings
are one of the basic concerns of what's usually called software
internationalization.

> It isn't binding, it is just advice. And this specification is not
> a place for a commentary about the status of character encoding
> choices in other Internet protocols. We're just recommending what
> you should do with URL schemes, in the cases where it is appropriate.
> 
> So what about this:

I greatly admire the elegance of your prose, and am happy if
we can work together finding the best wording.

However, there are several factual differences between your
proposal and mine, and in many cases, these are important.


> =================
> Use of Character Encodings
> 
> When describing new URL schemes in which the elements of

You have already commented on "NEW". The draft as a whole,
formally speaking, is about new URL schemes indeed. This is
said in the introduction. After that, the word "new" turns
up here and there, seamingly without much significance.

I would explicitly like to request you to take it out here,
for the following reasons:

- Formally speaking, it's irrelevant.
- The draft is also a good guideline for URL scheme revisions
	and updates, and will be used as such. The use of
	UTF-8 might also, in some way or another, be appropriate
	for existing schemes, and the elimination of the word "new"
	in this sentence would not let readers to believe otherwise.
- Many protocols and mechanisms are undergoing revisions, in
	particular in the area of character encoding. Whereas
	the associated schemes are not new in the sence that
	they have a new label, they are new in the sence that
	they extend their workings. It would be strange if
	the current draft, as an example, mandated strict
	conformance in some issue for new schemes, whereas
	older schemes, even if they conformed up to now,
	could deviate from this conformance in a revision
	just because they are not "new". (This is of course
	different in cases where existing schemes already
	deviate.)
- Because the conformance with UTF-8 is a suggestion, and not
	mandative, there is no harm if the text should be
	understood to apply to existing URLs too.

> 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]

The note on RFC 2044 that I had in my proposal should not be left
out here.

> and then subsequently using the %HH encoding
> for unsafe characters is recommended.

The rest of this paragraph looks very nice.


> Avoiding Variants
> 
> If a protocol allows multiple ways to access the same resource,
> e.g., multiple alternative character encodings or byte sequences needed
> to access a particular resource, it is preferable for the URL scheme
> to reduce the variability, even at the cost of introducing a translation
> when mapping from URL to protocol. This will reduce the number
> of alternative URLs for the same resource, and encourage consistency.
> In particular, if a protocol supports multiple charset representations
> for strings and those representations include UTF-8, it would be
> preferable to use UTF-8 uniformly in the URL scheme than to allow all 
> protocol-compatible variants.

This is certainly a good point, but it is currently not relevant.
To my knowledge, there is no protocol currently using various
character encodings in a controlled way to access the same
resource.

I have proposed, in my introductory mail, that servers showing
such behaviour might be a solution for some upgrading problems,
but this would be done in order to move towards UTF-8, and doesn't
exist currently, other than scripts trying to guess the encoding
of the query part.

Also, the phrase "and those representations include UTF-8" is
misleading. UTF-8, where it can be introduced, is a step
forward for protocols with single and with multiple character
encodings, and whether the later include UTF-8 or not.

As an example, let's take the IMAP protocol. In RFC 2060, it
introduces folder names using characters from the whole UCS.
Due to the specific situation of IMAP, it uses a modified
UTF-7 encoding. I have discussed this in a small group with
Mark Crispin, and I agree that this modified UTF-7 is a
good solution for IMAP. On the other hand, there was also
agreement that when there is a solution for encoding UCS
characters in URLs, the necessary mapping should be applied
(i.e. that IMAP URLs should be in UTF-8 (+%HH, of course),
and that the URL->IMAP code in a client would be responsible
for the appropriate conversion).

So the part "Avoiding Variants" could probably just be
left out, but has to be replaced by language that says that
even if a protocol/mechanism uses something else than UTF-8,
this should, if possible, be translated into UTF-8 for
URLs. Also, the possibility that a protocol doesn't have
well-defined character encodings, but that it converges
to UTF-8 (such as currently FTP) should be mentionned.
For detailed language, see my original proposal.


What is completely missing in your proposed text, and what,
based on experience, think is very important, is the requirements
on documentation (the last paragraph of my proposal). For
me, this is a MUST requirement. Otherwise, the danger is too
big that people constructing new URLs just forget it.
Note that this is a MUST in terms of process, not in terms
of content. This is similar to the now generally accepted
requirements for documentation on security. It's possible
to write an RFC with a security section listing several
security problems. But it is not possible to write an RFC
and ignore security issues and leave them undocumented.


In some of your comments, you suggested that some of the
aspects dealt with in the text I proposed for the process
draft are actually the business of the syntax draft. Once
we get a little farther here, I may have to reexamine my
proposals for the syntax draft and maybe make some additions.


Regards,	Martin.