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

Hello, 

A comment below. 

> -----Original Message-----
> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Julian Reschke
> Sent: 7. tammikuuta 2017 23:58
> To: John C Klensin <john-ietf@jck.com>
> Cc: urn@ietf.org
> Subject: Re: [urn] Feedback on draft-ietf-urnbis-rfc2141bis-urn-16
> 
> On 2017-01-07 22:44, John C Klensin wrote:

> > Yes, at least as I read it.   But, IIR, there have been some
> > claims that 3986 does not obviously allow a scheme to delegate the
> > syntax to other (non-scheme) parts of the URI (specifically
> > a namespace in the urn scheme case).   At this point, I would
> > personally prefer sentences to the effect of "no matter what you think
> > 3986 says, URNs works this way...", but I don't think that
> > a proposal like that would be constructive or helpful.   If you
> > think this is important and want to propose alternate text, please do
> > so.
> > ...
> 
> So we agree on what RFC 3986 says :-). I think the right conclusion is to strip
> the prose wrt RFC 3986. Just say:
> 
> "Neither the general syntax nor the semantics of q-components are defined
> by, or dependent on, the namespace of the URN.  Specifics of syntax and
> semantics, e.g., which keywords or terms are meaningful, of course may
> depend on a particular namespace or even a particular resource."

Yes, different namespaces definitely support different resolution services. In the ISSN namespace it is possible to request metadata about the identified periodical, or locations from which it can be found. But it is usually not possible to request all volumes and issues of a periodical.

Identified resources also have an impact on resolution services. Dublin Core metadata record as an identified resource allows some services (including migration to another metadata format), large research datasets some others, such as extraction of selected variables. 

One aspect which is missing from Julian's suggestion above is that applications with which we manage resources also support different services. There are certain things an integrated library system can do for an electronic book, and then some other services only a digital preservation system can supply for the same book. Taken together, the different system with which organizations manage their digital collections will support a wide variety of services which can be requested using q- and r-components. Syntax and semantics of these components will evolve over time to reflect new functionalities supported by digital asset management systems in production.    

Juha

> >>> ...
> >>>    For the sake of consistency with RFC 3986, neither the
> >>>    general syntax nor the semantics of f-components are
> >>>    defined by, or dependent on, the namespace of the URN.  In
> >>>    parallel with RFC 3896, specifics of syntax and semantics,
> >>>    e.g., which keywords or terms are meaningful, of course
> >>>    may depend on a particular namespace or even a particular
> >>>    resource.
> >>>
> >>> s/3896/3986/
> >
> > I thought we had caught all of those.  Both remaining cases, now
> > corrected in the working draft of -20 (which, unless major issues show
> > up or Barry directs otherwise, will appear only after the informal WG
> > Last Call ends at the end of the month).
> > FWIW, even though it is clearly better to fix it now, this is the sort
> > of thing the RFC Editor is really good at catching and fixing.
> 
> ...I prefer to process documents with known problems fixed. That said,
> there's an IETF LC before that anyway, so whatever the WG submits after
> WG LC is very unlikely what gets to the RFC Editor anyway.
> 
> Best regards, Julian
> 
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn