Skip to main content

The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces


No Objection

(Brian Carpenter)
(David Kessens)
(Russ Housley)
(Scott Hollenbeck)


Note: This ballot was opened for revision 04 and is now closed.

Harald Alvestrand Former IESG member
(was Yes) Discuss
Discuss [Treat as non-blocking comment] (2004-12-02) Unknown
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.)
Bill Fenner Former IESG member
No Objection
No Objection (2004-12-16) Unknown
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.
Brian Carpenter Former IESG member
(was Discuss) No Objection
No Objection () Unknown

David Kessens Former IESG member
No Objection
No Objection () Unknown

Margaret Cullen Former IESG member
(was Discuss, Abstain, Discuss, No Objection) No Objection
No Objection (2005-10-27) Unknown
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.
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection () Unknown

Scott Hollenbeck Former IESG member
(was Discuss) No Objection
No Objection () Unknown

Sam Hartman Former IESG member
(was Discuss) Abstain
Abstain (2005-10-27) Unknown
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 domain

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.