- From: Felix Sasaki <fsasaki@w3.org>
- Date: Thu, 01 Sep 2005 00:09:17 +0900
- To: iesg@ietf.org, uri@w3.org, tony+urireg@maillennium.att.com, hardie@qualcomm.com, LMM@acm.org
- Cc: "public-i18n-core@w3.org" <public-i18n-core@w3.org>
Dear Tony, Ted, Larry, dear all, With this mail the W3C I18N Core Working Group [1] would like to send you comments on the document "Guidelines and Registration Procedures for new URI Schemes". First let me congratulate you for your work, which is an important part of the Internet architecture. The comments we have are only about a part of the document, naturally mainly concerning internationalization issues. We are looking forward to discuss these comments with you and wish you all the best for the further development of your document. Best regards, Felix Sasaki (team contact of the W3C I18N Core Working Group) Comments: [1] The passage "In particular, the mapping should describe the mechanisms for encoding binary or character strings within valid character sequences in a URI.". There is already a mapping mechanism in rfc 3987, sec. 3.1. It should be made sure in your document that the mechanism you are describing is compatible with the rfc 3987 mechanism. One reason for this is the role of UTF-8, which is handled in the mechanism of rfc 3987. [2] Sec. 2.6 "Internationalization and character encoding": Please don't refer to "section 2.5 of RFC 3986 for guidelines.", but to RFC 3987, or better, to both. [3] Sec. 2.6, you write: "URI scheme definitions SHOULD be compatible with that specification.". It would be good to have a MUST here. [4] Sec. 2.7 "Clear security considerations": Please refer to sec. 8 of rfc 3987. [5] Sec. 5.4 URI Scheme Registration Template: Field "Encoding considerations.". Also title of sec. 2.6 "Internationalization and character encoding". The way you use the terms "character encoding" and "encoding" are maybe unclear. Proposal: You call this section and section 2.6 "Character Encoding Considerations". [6] Sec. 5.4: Please refer to the security considerations in rfc 3987 (see comment [4]).
Received on Wednesday, 31 August 2005 15:09:31 UTC