Using Universal Content Identifier (UCI) as Uniform Resource Names (URN)
Note: This ballot was opened for revision 02 and is now closed.
(Harald Alvestrand) (was No Objection, Yes) Discuss
Discuss (2004-12-09 for -)
I am assured that normal procedure for URN review has been followed. However, the following issue discovered by Leslie Daigle should be addressed. draft-sangug-uci-urn-00.txt says: > The Namespace specific string of all URNs assigned by NCA conforms > to the syntax defined in section 2.2. of RFC2141, "URN Syntax". and, > UCI = prefix "-" instance *1(":" qualifier) > > prefix = 1*(alphaDigit) *1(":" 1*(alphaDigit)) > *1("+" 1*(alphaDigit)) > instance = 1*(trans / "%" HEXDIG HEXDIG) > qualifier = head 1*(alphaDigit) *2("-" head 1*(alphaDigit)) > trans = alphaDigit / other / reserved > alphaDigit = ALPHA / DIGIT > head = "C" / "R" / "F" > other = "(" / ")" / "+" / "," / "-" / "." / "=" / "@" / > ";" / "$" / "_" / "!" / "*" / "'" > reserved = "%" / "/" / "?" / "#" while the URN syntax document, RFC2141, says: > 2.3.2 The other reserved characters > > RFC 1630  reserves the characters "/", "?", and "#" for particular > purposes. The URN-WG has not yet debated the applicability and > precise semantics of those purposes as applied to URNs. Therefore, > these characters are RESERVED for future developments. Namespace > developers SHOULD NOT use these characters in unencoded form, but > rather use the appropriate %-encoding for each character. I *think* what you're trying to do is express that the UCI URN will support "/", "?", and "#" in whatever fashion the URN specification eventually determines. However, I also think that, the way it is expressed in your syntax, it would be very easy to believe the characters could appear as valid characters (in unescaped form) in a UCI URN, and that would be a mistake. Therefore, I think it would be better to either remove them from the list of characters that can appear in a UCI URN, or refer the reader directly, at that line of syntax, to the URN syntax definition for use and meaning.
Comment (2004-12-01 for -)
Reviewed by Scott Brim, Gen-ART His review: Technically it's acceptable although idnits wants the boilerplate fixed. This is an individual draft, destined to be informational. It's out of my area, but I don't know of any conflicts with specific IETF work.
(Scott Hollenbeck) (was Discuss, No Objection) Yes
(Brian Carpenter) No Objection
Comment (2005-03-18 for -)
Removing Harald's discuss - he and Leslie are satisfied that the new version resolves the concern Leslie had.