The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces
draft-vandesompel-info-uri-04

[Ballot comment]
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.

[Ballot discuss]
A clarity question:

  This document defines the "info" Uniform Resource Identifier (URI)
  scheme for information assets that have identifiers in public
  namespaces but are not part of the URI allocation. 

What does it mean to say that a public namespace is "not part of the URI allocation"?

I am not sure if the IESG is meant to review this allocation against the previous criteria document, but if we are...

I don't understand the demonstrable utility of this mechanism.  Why would it be preferable to allocate the "info:" URI to NISO instead of having IANA directly assign URIs for the items that are listed in this document (such as the Dewey Decimal System), as appropriate?  Is there some inherent value in having a two-level naming scheme? 

I am concerned that each of the items that NISO has listed would need to be treated separately by applications in order to be useful, so I don't see why grouping them under one "info:" URI would simplify application development...  In fact, it might complicate application development to allow these types of sub-allocations, because applications would need to keep track of which URIs are sub-allocated and which ones are not.

I also think that "info:" fails to meet the criteria that we not use names that are too global and far-reaching in scope.  If there is some utility in subregistering these things, perhaps they could be allocated a more specific URI like "niso-info-assets:"?

[Ballot discuss]
I am not sure if the IESG is meant to review this allocation against the previous criteria document, but if we are...

I don't understand the demonstrable utility of this mechanism.  Why would it be preferable to allocate the "info:" URI to NISO instead of having IANA directly assign URIs for the items that are listed in this document (such as the Dewey Decimal System) as appropriate?  Is there some inherent value in having a two-level naming scheme? 

I am concerned that each of the items that NISO has listed would need to be treated separately by applications in order to be useful, so I don't see why grouping them under one "info:" URI would simplify application development...  In fact, it might complicate application development to allow these types of sub-allocations, because applications would need to keep track of which URIs are sub-allocated and which ones are not.

I also think that "info:" fails to meet the criteria that we not use names that are too global and far-reaching in scope.  If there is some utility in subregistering these things, perhaps they could be allocated a more specific URI like "niso-info-assets:"?

[Ballot comment]
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.

[Ballot discuss]
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.

[Ballot discuss]
I will clear this DISCUSS if draft-hansen-2717bis-2718bis-uri-guidelines
is approved. The reference to RFC 2718 should be updated accordingly.

--------------

Picking up Harald's DISCUSS until someone convinces me it's wrong:

https://datatracker.ietf.org/cgi-bin/idtracker.cgi?loginid=43&command=view_comment&id=28653

[Ballot comment]
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.

[Ballot discuss]
There are many, many ways to represent the same resource.  I assume that
  there are situations where client software will compare two info URIs.
  Since the same resource can be represented by several different octet
  strings, some guidance on comparison is needed.  I think that comparison
  rules (like the ones added to draft-duerst-iri) are needed.  Perhaps this
  can be handled by a reference.

[Ballot discuss]
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.)

[Ballot discuss]
My understanding from the logs is that this is intended to use new
review procuders not the old review procedures.  Presumably this means
there is a URI review.  I don't see comments from that review.

The new procedures suggest that informational rfcs should be used only
for widely used URI schemes and that standards track RFCs should be
used for other permanent registrations.  AS such this should be a
standards track RFC and should recieve appropriate review.


I believe that the argument of utility needs more justification.  It
would be nice to describe sample applications of this URI scheme in
addition to describing resources that could be identified.

I find the argument that this scheme should not be a URN weak.  I
would be happy to defer to one of the apps ADs or to the URI community
if they believe this argument is justified.


I don't believe that this scheme is sufficiently well specified to
implement.  Section 5 contemplates sub-scheme-specific normalization
rules an a set of attributes that an application comparing info: URIs
needs to retrieve from the registry.  A normative reference to
protocol and schema for retreiving these requirements seems like it is
necessary to implement the normalization steps in section 5  .  I
actually recommend a different approach similar to normalization rules
for LDAP directory strings.  Accept that you will not be able to
specify all application (or in this case sub-scheme) specific
normalization rules.  Comparing the URI may sometimes indicate that
two URIs are different when  they end up being the same at the
application level.  This approach is much easier to implement although
it does have security implications that would need to be discussed in
the security considerations section. 

I suspect there are internationalization and character set
considerations that need to be discussed for this scheme.

The security considerations section needs to discuss the implications
of the normalization rules.

There are significant problems with the use of requirements language.
For example : When referencing an information asset by means of its
"info" ----:%% URI, the asset SHALL be considered a "resource" as
defined in RFC 2396 [RFC2396] and SHALL enjoy the same common
syntactic, semantic and shared language benefits that the URI
presentation confers.

It looks like there was a search and replace on the original document
to replace lower case requirements terms with upper case versions.
Requirements language should only be used to describe implementation
imperatives.

Finally I have some questions about the basic premis behind the
document.  Is it in the best interest of the Internet community to
turn registration of subschemes over to a registry that will act
according to its own business rules?  Why isn't an IANA registry with
expert review for subschemes appropriate?  How will we make sure that
this registry does not become an end-run around our URI registration
procedures?  How will we respond if someone wants to register the
info2: scheme because the info registry's business rules do not work
for them or because they believe the info registry is too US-centric?

[Ballot discuss]
Section 5 is titled "Normalization and Comparison of "info" URIs", but it only talks about normalization.  Some text needs to be added to describe comparison rules.

[Ballot discuss]
My understanding from the logs is that this is intended to use new
review procuders not the old review procedures.  Presumably this means
there is a URI review.  I don't see comments from that review.

The new procedures suggest that informational rfcs should be used only
for widely used URI schemes and that standards track RFCs should be
used for other permanent registrations.  AS such this should be a
standards track RFC and should recieve appropriate review.


I believe that the argument of utility needs more justification.  It
would be nice to describe sample applications of this URI scheme in
addition to describing resources that could be identified.

I find the argument that this scheme should not be a URN weak.  I
would be happy to defer to one of the apps ADs or to the URI community
if they believe this argument is justified.


I don't believe that this scheme is sufficiently well specified to
implement.  Section 5 contemplates sub-scheme-specific normalization
rules an a set of attributes that an application comparing info: URIs
needs to retrieve from the registry.  A normative reference to
protocol and schema for retreiving these requirements seems like it is
necessary to implement the normalization steps in section 5  .  I
actually recommend a different approach similar to normalization rules
for LDAP directory strings.  Accept that you will not be able to
specify all application (or in this case sub-scheme) specific
normalization rules.  Comparing the URI may sometimes indicate that
two URIs are different when  they end up being the same at the
application level.  This approach is much easier to implement although
it does have security implications that would need to be discussed in
the security considerations section. 

I suspect there are internationalization and character set
considerations that need to be discussed for this scheme.

The security considerations section needs to discuss the implications
of the normalization rules.

Finally I have some questions about the basic premis behind the
document.  Is it in the best interest of the Internet community to
turn registration of subschemes over to a registry that will act
according to its own business rules?  Why isn't an IANA registry with
expert review for subschemes appropriate?  How will we make sure that
this registry does not become an end-run around our URI registration
procedures?  How will we respond if someone wants to register the
info2: scheme because the info registry's business rules do not work
for them or because they believe the info registry is too US-centric?

[Ballot discuss]
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.)