Re: [urn] Fwd: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt

[Peter Saint-Andre - &yet <[e-mail]>]

Hi Juha, thank you for reviewing the document and providing detailed
feedback. Comments inline.

On 7/1/15 4:19 AM, Hakala, Juha E wrote:
> Hello Melinda; all,
>
> I have only a few, mostly minor comments to the latest RFC2141bis
> draft. As far as I am concerned, our work is almost done. With this
> syntax the library community will be able to do everything we wanted
> initially to do, and then some more - we did not anticipate the
> possibility to send resolution requests not only to the URN
> resolvers, but also to the identified resources themselves or to the
> applications managing them. Since resources are getting more complex
> - research data sets are an example of this -, this kind of enriched
> functionality may become very useful in the long run.

It's good to hear that the needs of the library community seem to have 
been met.

> In the second paragraph of chapter 3.3 we say that unless defined for
> a particular namespace, use of q-, r- and f-components is
> disallowed.
>
> This is OK for q- and r-components, but I am not sure if such
> limitation is required for F-component, since it has no impact on URN
> resolution. Moreover, F-component is not namespace specific but
> depends on file format. It can be added to the URN:ISBN if the
> identified book is e.g. a PDF document, but not to every URN:ISBN
> (even if the ISBN identifies an e-book; printed books certainly do
> not have URI fragments). So it is likely that f-component can never
> be applied to all URNs in a certain namespace, but it may be possible
> to apply it to some URNs in most (actionable) namespaces.

As I recall, the purpose of the text you have cited was to maintain 
strict compatibilty with RFC 2141 for all existing namespaces; only if a 
namespace explicitly allows q-, r-, and f-components after 2141bis is 
published should it allow and use those components. This is an "opt-in" 
model, if you will, and seems like the safest approach (i.e., do not 
assume that it's OK to add an f-component to an "old", 2141-compatible 
namespace just because 2141bis says that f-components are now allowed). 
This is a form of Postel's Law, I think.

> The example in the last paragraph of chapter 3.3.1 uses a real ISBN
> but in wrong (urn:example) namespace. It is better to replace the
> ISBN with a random NSS such as "bar", because the URN is not
> actionable and even if it were, the fragment would not be
> applicable.

Yes, we'll fix that to prevent confusion.

> Although libraries' primary intention was to use q-component for
> passing resolution related information to URN resolvers, I see no
> problem in using r-component instead to this purpose. IMO it is good
> design to make a difference between requests to resolvers
> (r-component) and requests to resources themselves or applications
> managing them (q-component). Identified resources will become
> increasingly large and complex (scientific data sets are a good
> example of this)  and it may be necessary to perform various
> operations before the resource is ready to be sent to the user.

Do you think that the text or example in Section 3.3.1 needs to change 
in order to make that clear?

> In 3.3.3 we say that f-component need not be semantically equivalent
> to the URI fragment (component). IMO URN f-component is never
> semantically equivalent with URI fragment since f-component does not
> have a role in identification. We avoid making this difference
> explicit by saying that f-component is intended to "distinguish
> integral parts of resources", which is OK to me in spite of being
> somewhat vague.

I think that "constituent parts" might be clearer.

> If we want to be more specific we could say that what
> is being distinguished are physical (encoded) parts of resources.
> F-component cannot be applied to logical parts of resources unless
> they coincide with physical ones. It might be a good idea to be more
> specific about what f-component does because there is an increasing
> need within my community (libraries, archives and museums) to
> identify component parts of resources. If and when we start
> developing a new standard identifier for logical components of
> resources (or if we extend existing systems such as NBN in such a way
> that they do the job) it is important to know precisely what the role
> of f-component is. The present wording does not make that very
> clear.

I am not well versed in information science, so I am sure how the 
distinction between logical and physical parts is applied in that field. 
However, from my own limited perspective I hesitate to say that 
f-components are necessarily tied to physical representation because 
even though the "preface" and "chapter 3" and "afterword" might be 
constituent parts of a book, in an electronic book those parts are not 
represented physically as they would be in a paper book.

> The example in the last paragraph of chapter 3.3.3 uses a real ISBN
> but in wrong (urn:example) namespace. It is better to replace the
> ISBN with a random NSS such as "bar". URN:ISBN is actionable (as
> http://urn.fi/URN:ISBN:978-952-10-7060-0) but urn:example is not. In
> both cases fragment is not applicable.

Yes, we will fix that too.

> In chapter 6 (top of page 14) the draft states that "uniqueness
> constraint means that an identifier within the namespace is never
> assigned to more than one resource and never reassigned to a
> different resource". We might consider saying "one resource (as
> defined in the namespace)".  Every journal article published in e.g.
> Scientific American has the same ISSN, since in the URN:ISSN
> namespace "resources" are serials. In SICI (Serial Item and
> Contribution Identifier) namespace resources are journal issues and
> articles. URN:NBN could be used for identification of still images
> within these articles.

I see your point. How about this?

    The "uniqueness" constraint means that an identifier within the
    namespace is never assigned to more than one resource and never
    reassigned to a different resource (for the kind of "resource"
    identified by URNs assigned within the namespace).

> In chapter 6.1, the last paragraph of page 16 the draft requires that
> particular attention should be paid to strings that might imply
> association with well-known trademarks. More exhaustive formulation
> would be "... well-known identifier systems and trademarks". In this
> context we need to be even more concerned about NID strings like
> "handle" and "doi" than "pepsi".

Good point.

> In 7.3.1 (Purpose of the URN registration) it is IMO necessary to
> provide information whether resolution services are or will be
> available, and if so, what the existing / anticipated services.
> Registrants might even be able to provide examples for q- and
> r-component semantics and syntax, even if they are registered
> elsewhere later.

That seems fine.

> It might be a good idea to ask the registrants to clarify formal
> status of the identifier (de jure standard / de facto standard /
> other) and current / anticipated extent of its use (international /
> national / local usage).

In my experience and (see RFC 6648) the experience of the Internet 
community, it is not especially helpful to draw a distinction between 
standardized and unstandardized identifiers, because unstandardized 
identifiers have a tendency to leak into the space of standardized 
identifiers.

> Identifiers with statuses "other" and "local
> usage" should usually have informal than formal namespaces registered
> for them.

Here again, see RFC 6648.

> The current scope question (number 4 on the list) is a
> little bit of a mixed bag as it covers both geographical and
> organizational issues; it might be better to target scope on various
> organizational issues only (public / private sector, book trade /
> libraries, military / civilian use etc.).

It's not fully clear to me why some of those dimensions are relevant, 
but in any case I think the answers would emerge from asking about the 
community of use. Thus I propose:

        The scope and applicability of the URNs assigned within the
        namespace; this might include information about the community of
        use (e.g., a particular nation, industry, technology, or
        organization), whether the assigned URNs will be used on public
        networks or private networks, etc.

> As regards the current second (later perhaps third) question on the
> list, I would drop the request for telling why it is preferable to
> use URN rather than some other technology. IETF does not need to know
> this. Also asking the registrant to explain why existing URN
> namespaces are not a good fit sounds a bit negative. I would ask the
> registrant to describe how the namespace to be registered relates to
> existing URN namespaces and how the new namespace complements them.

I like that more positive focus. How is this?

       How the namespace relates to and complements existing URN
       namespaces, URI schemes, and identifier systems.

Thanks again for the review.

Peter