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

["Svensson, Lars" <[e-mail]>]

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.

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").

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.

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.

I'm not deep enough into the gory details to be able to answer any of Keith's comments, but I look forward to the discussion.

Best,

Lars

*** Lesen. Hören. Wissen. Deutsche Nationalbibliothek *** 
-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek
Informationsinfrastruktur und Bestanderhaltung
Adickesallee 1
D-60322 Frankfurt am Main
Telefon: [phone]
Telefax: [phone]
mailto:[e-mail] 
http://www.dnb.de


> -----Original Message-----
> From: urn [mailto:[e-mail]] On Behalf Of Hakala, Juha E
> Sent: Wednesday, July 01, 2015 12:19 PM
> To: Melinda Shore; [e-mail]
> Cc: Tobias Weigel; [e-mail]; [e-mail]
> Subject: Re: [urn] Fwd: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt
> 
> 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.
> 
> Best regards,
> 
> Juha
> 
> -----
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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. 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.
> 
> 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.
> 
> 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.
> 
> 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".
> 
> 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. This question could be the second one asked.
> 
> 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). Identifiers
> with statuses "other" and "local usage" should usually have informal than
> formal namespaces registered for them. 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.).
> 
> 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.
> 
> 
> > -----Original Message-----
> > From: urn [mailto:[e-mail]] On Behalf Of Melinda Shore
> > Sent: 20. kesäkuuta 2015 5:17
> > To: [e-mail]
> > Subject: [urn] Fwd: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt
> >
> > This is a reminder to take a look at draft-ietf-urnbis-rfc2141bis-urn-12
> > with an eye towards what, if anything, needs to be resolved before going to
> > working group last call.
> >
> > Many thanks, and have an excellent weekend.
> >
> > Melinda
> >
> >
> > -------- Forwarded Message --------
> > Subject: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt
> > Date: Tue, 16 Jun 2015 07:28:05 -0800
> > From: Melinda Shore <[e-mail]>
> > To: [e-mail] <[e-mail]>
> >
> > As you've probably seen, the -12 version of the 2141bis draft was uploaded
> > yesterday.  We're planning on taking the -13 version to working group last
> > call, and we really need some careful review to make sure that problems
> with
> > the document have been identified and addressed.
> >
> > This morning John sent out a list of issues that he's identified and that need
> > sign-off from the working group.
> > Some of his questions are somewhat open-ended and we need to avoid rat-
> > holing, so please be very specific and provide concrete examples where
> > possible.
> >
> > The immediate questions are:
> >
> > . Are the current versions of the registration templates
> >   and descriptions complete and clear?
> > . Are the r-component and q-component examples correct?
> > . Can someone provide clarifying text about where r-component
> >   and q-component queries go?
> >
> > He also raised some broader questions which need discussion but which
> > perhaps can wait until we've got some level of agreement on what needs to
> > be done for wglc.
> >
> > (John's email is here:
> > https://mailarchive.ietf.org/arch/msg/urn/H2lkeRkYhPhbqF_zMs555ARCp6g)
> >
> > Thanks,
> >
> > Melinda
> >
> > -------- Forwarded Message --------
> > Subject: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt
> > Date: Mon, 15 Jun 2015 16:25:26 -0700
> > From: [e-mail]
> > Reply-To: [e-mail]
> > To: [e-mail]
> > CC: [e-mail]
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >  This draft is a work item of the Uniform Resource Names, Revised Working
> > Group of the IETF.
> >
> >         Title           : Uniform Resource Names (URNs)
> >         Authors         : Peter Saint-Andre
> >                           John C Klensin
> > 	Filename        : draft-ietf-urnbis-rfc2141bis-urn-12.txt
> > 	Pages           : 30
> > 	Date            : 2015-06-15
> >
> > Abstract:
> >    A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI)
> >    that is assigned under the "urn" scheme and a particular URN
> >    namespace, with the intent that the URN will be either a persistent,
> >    location-independent resource identifier or in some cases an abstract
> >    designator that is persistent but that does not identify a resource.
> >    With regard to URN syntax, this document defines the canonical syntax
> >    for URNs (in a way that is consistent with URI syntax), specifies
> >    methods for determining URN equivalence, and discusses URI
> >    conformance.  With regard to URN namespaces, this document specifies
> >    a method for defining a URN namespace and associating it with a
> >    namespace identifier, and describes procedures for registering
> >    namespace identifiers with the Internet Assigned Numbers Authority
> >    (IANA).  This document obsoletes both RFC 2141 and RFC 3406.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/
> >
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-12
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-12
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> >
> >
> > _______________________________________________
> > urn mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/urn
> 
> _______________________________________________
> urn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/urn