Re: [urn] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16

Hello, 

some comments below 

> -----Original Message-----
> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Sean Leonard
> Sent: 4. toukokuuta 2016 17:07
> To: urn@ietf.org
> Subject: Re: [urn] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16
> 
> On 5/4/2016 6:19 AM, Henry S. Thompson wrote:
> > [...]
> > (It's perhaps worth noting a further parallel: Contesting such a
> > labelling requires appealing to the person who produced the referring
> > word or expression: when you said such-and-such, what did you mean to
> > refer to?  And as far as 3986 is concerned, the same is true for URIs:
> > the ultimate authority for questions about what is identified by a URI
> > is, and can only be, the minter of that URI.)

It is not this simple in the URN environment. Assignment of URNs is a managed process, and the agency which is responsible of the namespace provides the rules for what can be identified by URNs in that namespace. So an organization - for instance, a publisher - which mints a URN from urn:isbn namespace is not an authority, but just applying its narrow mandate to identify its own books. The authority is limited to saying that this urn:isbn identifies this book. And if the publisher makes a mistake - such as a typo in isbn, or re-assignment of isbn that has already been used, etc. - the national ISBN center will correct the problem. 

Assignment of URIs is very seldom a managed process in any sense that communities using persistent identifiers would use in the context. 

> >
> > It follows, I think, that urnbis can use 'resource' in exactly the way
> > it is used in 3986, referencing 3986 for that purpose in section 1.1.
> >
> > Indeed it _should_ do so, because otherwise it does what it accuses
> > 3986 of doing, only more so, by using both 'resource' and 'service'
> > without defining them, or explaining how to tell which of the two is
> > identified by a URN.

Each URN namespace has its own view of which resources can be identified. Scopes of namespaces will overlap, and some namespaces may have much broader scopes than others, but namespace registrations and possibly some additional documentation will still describe what kind of resources are identifiable. Since there are these descriptions of what identifiable resources are, IMO URN syntax document does not need to give a generic definition of what a resource is. On the other hand, we do not know the scopes of future namespaces, and therefore it would only be possible to give a very generic definition, like URI 3986 does.  

According to RFC 3986 resource can be anything, from - literally - zero to infinity. I am not sure how useful that kind of "definition" is when we talk about resource identification in any proper sense of the word. Broad definition creates an impression that assigning URIs to these resources cannot even in principle be a managed process. According to RFC 3986 anyone can identify anything and somehow this does not result in a mess. In the light of practical experience of e.g. URI longevity this seems optimistic. 

> > PS  The fact that 3986 doesn't come particularly clean about how one
> > might in principle answer questions of the form "What is identified by
> > this URI" or "Can I use this URI to identify [...]" is arguably a bug.

It is not possible to always answer these questions unless URI assignment in its entirety is a well managed process, which it is not, either now or in the future. I mean, it may be possible to manage URIs in small, controlled environments such as W3C web server, but in the Web scale it seems to be impossible to achieve sufficient control, in spite of efforts to provide guidelines on how to create URIs and keep them alive. 

> >
> > urnbis is in a particularly good position to fix this for URNs.

Yes, provided that namespaces are properly managed. This does not need to be the case, if IETF approves namespace registrations which are not solid enough. 

Best regards, 

Juha

> 
> Yes.
> 
> Sean
> 
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn