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

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 31 Aug 2015 19:27:36 -0600

Hi Lars, thanks for the feedback and my continued apologies for the
delayed reply.

On 7/5/15 1:37 PM, Svensson, Lars wrote:
> Melinda et al.;
>
> My comments are even more minor than Juha's:
>
> 1) Introduction The first paragraph discusses the difference between
> resource identifiers and abstract designators. In order to avoid
> confusion we should make it clear that "resource" is meant as
> "internet resource", since also abstract designators do identify
> resources (but not internet resources). This comment also applies to
> the document's abstract.

I'm not sure. RFC 3986 says that "a resource is not necessarily 
accessible via the Internet", so limiting the scope of resources in the 
URN context to Internet resources seems perhaps incorrect. On the other 
hand, RFC 1737 does say that a URN is an "Internet resource identifier". 
I would slightly favor leaving the text as-is for now.

> 2) Terminology The first paragraph mentions that important terms are
> taken from RFC 3986. I think it would help the interpretation if we
> could list exactly what terms are to be interpreted in the RFC 3986
> fashion (e. g. "resource").

That's a good point. I might suggest...

OLD

    Several important terms used in this document, including some
    "normalization" operations that are not part of the Unicode Standard
    [UNICODE], are defined in the URI specification [RFC3986].

NEW

    Because this document attempts to harmonize the definition of URNs
    with that of URIs, it borrows a number of important rules (such as
    "normalization" operations that are not part of the Unicode Standard
    [UNICODE]) from the URI specification [RFC3986], and also uses
    several key terms (such as "resource" and "identifier") in
    effectively the sense as the URI specification.

I don't exactly want to say that some of these key terms are "defined" 
in RFC 3986 because I don't consider ostensive definition to be 
sufficient for protocol specifications.

> 3) URN syntax The third paragraph discusses "rules not defined here"
> and mentions "path-absolute" and "query", but I cannot find that
> those two rules are used in the ABNF.

Good catch. Those were used in a previous version, but are no longer used.

> 4) Appendix A, §A.6 This section says that the use of p-components is
> not allowed unless the registration explicitly says how. There are no
> p-components any more.

Correct. Will fix.

Peter

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 31 Aug 2015 20:38:58 -0600

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

---

From: Keith Moore <[email-masked]>
Date: Mon, 31 Aug 2015 23:34:36 -0400

On 08/31/2015 10:38 PM, Peter Saint-Andre - &yet wrote:
> 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. 

I think this is not only wrong for several technical reasons that I've 
already described, but also unnecessary for compatibility, since the use 
of q-, r- and/or f-components doesn't affect the "assigned portion" of 
the URN.

The whole point of URNs is to permit uniform handling by software of 
names from different namespaces.    This continued insistence on making 
components namespace-specific is trying to break that.

Keith

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 31 Aug 2015 21:48:04 -0600

On 8/31/15 9:34 PM, Keith Moore wrote:
> already described,

Sorry, I haven't yet had time to reply to your large review. I'll start 
to do that soon, breaking it down into smaller chunks.

> but also unnecessary for compatibility, since the use

This is true.

> names from different namespaces.

I don't think that uniformity is the whole point (because IMHO that 
would primarily encompass something about defining a space of 
"persistent, location-independent resource identifiers"), but it is one 
desirable quality.

> This continued insistence on making

In this case, we're trying to be careful about introducing new features 
or assuming that those new features have any meaning in the context of 
names that were defined before those new features were created. The 
*intent* of this caution has not been to break uniformity, although that 
might have been an unintentional byproduct.

Although I'm open to discussing the tradeoffs and adjusting the text so 
that we don't break the principle of uniformity, inflammatory statements 
about the bad intent of the editors does not conduce to a constructive 
dialogue.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Keith Moore <[email-masked]>
Date: Tue, 1 Sep 2015 00:00:10 -0400

On 08/31/2015 11:48 PM, Peter Saint-Andre - &yet wrote:
> In this case, we're trying to be careful about introducing new 
> features or assuming that those new features have any meaning in the 
> context of names that were defined before those new features were 
> created. The *intent* of this caution has not been to break 
> uniformity, although that might have been an unintentional byproduct.
>
> Although I'm open to discussing the tradeoffs and adjusting the text 
> so that we don't break the principle of uniformity, inflammatory 
> statements about the bad intent of the editors does not conduce to a 
> constructive dialogue.

I should have worded things slightly differently.   I don't think the 
editors are "trying" to break uniformity, in the sense that this is 
their intent.  I do think that trying to make components 
namespace-specific has the effect of breaking uniformity.   And I 
believe that this further degrades the value of URNs in several ways.

To me this seems obvious because (long ago) I've written URN resolution 
systems and modified browsers so that URNs were "clickable".  As soon as 
we start talking about components being namespace-specific, I 
immediately see how this makes the browser more complex (and the 
complexity increases without bound) and blurs the layering between the 
namespace and the publisher (with very unfortunate implications).

Keith