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