The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces
Note: This ballot was opened for revision 04 and is now closed.
(Harald Alvestrand) (was Yes) Discuss
Discuss (2004-12-02 for -)
I believe this document does not satisfy the criteria of RFC 2717/2718 for registration of a new top level scheme. It also does not satisfy the criteria for "permanent" registration in draft-hansen-2717bis; it satisfies the "preliminary" registration criteria, since these are just about nonexistent, but that's not what the proponents are asking, I believe. Review from Joel Halpern, Gen-ART: I believe that this document should not be published in the current form as an Informational RFC. It is possible that the questions below can be answered in a fashion that makes publication suitable. However, if so, the explanations should appear more clearly in the rationale section. Question: Should this URI Schemes be defined in Informational RFCs? According to RFC 2717, Informational should only be used for schemes which are already in wide usage. This may be a case of what RFC 2717 calls "Alternative Trees", but the syntax and structure does not match that required for alternative trees. Question: This document seems to create a registry (the info: registry) that does almost the same thing as the URL scheme registry. It would seem that the ddc and lccn namespaces (used in the examples) could just as easily be URL schemes in their own right. Is this true? If so, is there an advantage to the indirection? Should this instead explicitly use the "alternative trees" approach and syntax from 2717, and explain why that is being used? Question: Reading RFC 2718 and the rationale section of this document, it appears that what is being defined is not a "locator" but rather a "name" that the definers have chosen to define in a way that is not a syntactically valid URN. Presumably, the community had a good reason for introducing the distinction between a URN and a URL. Should this scheme blur the lines this badly. Lesser Question: Is it known whether any / many / some of the information sources listed in the document would wish to use this mechanism? If not, this becomes close to group A defining something about group B, without B's participation. (I think the answer is probably yes because those folks are members of NISO, but the question does need to be answered explicitly.)
(Brian Carpenter) (was Discuss) No Objection
(Margaret Cullen) (was Discuss, Abstain, Discuss, No Objection) No Objection
This document seems to set-up a registry and give control of it to a specific organization (NISO). I'm not sure what criteria we should use to decide whether that is a reasonable thing to do. I don't know anything about NISO or their qualifications to run a registry, and nothing in this document seems to address those sorts of issues.
(Bill Fenner) No Objection
Comment (2004-12-16 for -)
Other documents reference ABNF that they want to incorporate; this one copies. The copied rules do look the same, so it's probably not the worst thing in the world.
(Scott Hollenbeck) (was Discuss) No Objection
(Russ Housley) (was Discuss) No Objection
(David Kessens) No Objection
(Sam Hartman) (was Discuss) Abstain
I am not sure this document meets the guidelines for registration as a permanent URI scheme. i will accept an argument that the determination I'm making is one that should be made by the expert reviewer and not (except in cases of appeal) by the IESG. However if it is reasonable for the IESG to consider this issue, I don't think this scheme name is appropriate for a permanent registration. Consider the following guideline: Avoid using names that are either very general purpose or associated in the community with some other application or protocol. Avoid scheme names that are overly general or grandiose in scope (e.g., that allude to their "universal" or "standard" nature when the described namespace is not.) Organizations that desire a private name space for URI scheme names are encouraged to use a prefix based on their domain name, expressed in reverse order. For example, a URI scheme name of com-example-info might be registered by the vendor that owns the example.com domain name. We've decided to ignore this issue for now; the general question of whether the IESG should consider the URI guidelines when uri registrations are in documents it reviews is still open.