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

From: Julian Reschke <[email-masked]>
Date: Sat, 7 Jan 2017 18:42:58 +0100

Reviewing my own feedback from 7 months ago and reposting those parts 
that still seem to apply...:

On 2016-04-27 20:11, Julian Reschke wrote:
>
>       rq-components =  ( "?="  q-component
>                           [ "?+" r-component ] ) /
>                        ( "?+" r-component
>                           [ "?="  q-component ] )
>       q-component   = pchar *( pchar / "/" / "?" )
>       r-component   = pchar *( pchar / "/" / "?" )
>       f-component   = fragment
>
> These come as a surprise to anybody not already familiar to what led to
> the spec.
>
> Either introduce them later, or insert some prose explaining where they
> come from.
 >
> Also, it would be good if there was a discussion about compatibility
> with existing use of queries, as these essentially reserve certain
> variants of queries for generic use.

> ...
>    For the sake of consistency with RFC 3986, neither the general syntax
>    nor the semantics of q-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.
>
> I agree that this is the right thing to do, but I'm not sure what this
> has to do with 3986.  3986 allows a scheme to mandate a specific syntax,
> no?
> ...

> ...
>    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/
>
>    Section 5.2 of [RFC3986] describes an algorithm for converting a URI
>    reference that might be relative to a given base URI into "parsed
>    components" of the target of that reference, which can then be
>    recomposed per RFC 3986 Section 5.3 into a target URI.  This
>
> s/RFC3986//
> ...

Best regards, Julian

---

From: John C Klensin <[email-masked]>
Date: Sat, 07 Jan 2017 16:44:51 -0500

Julian,

My belief is that these issues have already been dealt with in
-19 or earlier.   If you disagree and consider the issues
substantive enough to meet the criteria Barry laid out, please
explain.  Some comments below.

--On Saturday, January 7, 2017 18:42 +0100 Julian Reschke
<[email-masked]> wrote:

> Reviewing my own feedback from 7 months ago and reposting
> those parts that still seem to apply...:
> 
>> These come as a surprise to anybody not already familiar to
>> what led to the spec.

>> Either introduce them later, or insert some prose explaining
>> where they come from.

The paragraph immediately above the syntax in Section 2 ("The
basic syntax for a URN is defined...") now contains explicit
forward pointers to the relevant defining sections.  If you
think more is needed, please explain and propose text.  Whether
one soul supply syntax before or after the explanation of what
the elements are about is a matter of taste; when I've done it
one way in a proposed RFC, I'm been attached and when I've done
it the other way, I've been attacked too, so, speaking
personally and as co-editor, I'm no longer interested in the
discussion.

>> Also, it would be good if there was a discussion about
>> compatibility with existing use of queries, as these
>> essentially reserve certain variants of queries for generic
>> use.

I believe there is now fairly extensive discussion on that
topic.  Again, if you think more is needed, please explain and,
ideally, supply text.  Note, however, that there is no "existing
use of queries" within the URN scheme as defined in RFC 2141.
Going very much further than 2141bis goes now (which is, IIR,
further than -16 did) is ultimately not about the "urn:" scheme
but interpretation of 3986 including both what it says and what
it omits.  

Some of those issues have been discussed fairly extensively on
the mailing list but, at least IMO, if the WG has neither
mandate nor authorization to update or otherwise modify 3986,
then the inevitable corollary is that 3986 needs to stand on its
own.  The new comments about potentially-conflicting terminology
or language was motivated precisely by WG discussions of related
issues.

>> ...
>>    For the sake of consistency with RFC 3986, neither the
>>    general syntax nor the semantics of q-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.
>> 
>> I agree that this is the right thing to do, but I'm not sure
>> what this has to do with 3986.  3986 allows a scheme to
>> mandate a specific syntax, no?

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.

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

best,
   john

---

From: Julian Reschke <[email-masked]>
Date: Sat, 7 Jan 2017 22:57:32 +0100

> explain.  Some comments below.

Well, I checked -19 before sending the mail. Feedback is feedback.

> personally and as co-editor, I'm no longer interested in the

It probably would be sufficient to move the overview in front of the ABNF.

> think this is important and want to propose alternate text,

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

> the sort of thing the RFC Editor is really good at catching and

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

---

From: John C Klensin <[email-masked]>
Date: Sun, 08 Jan 2017 01:41:43 -0500

> Well, I checked -19 before sending the mail. Feedback is

Just my opinion: See Barry's note.  The difficulty with
"feedback is feedback" is that we can quibble endlessly about
small matters of phrasing, organization, etc., and that, if we
are ever going to finish this work, that needs to stop at some
point.   I'll leave determining the point up to the co-chairs
but, again in my opinion, we are past it.

>> think more is needed, please explain and propose text.
>> Whether one soul supply syntax before or after the
>> explanation of what the elements are about is a matter of
>> taste; when I've done it one way in a proposed RFC, I'm been
>> attached and when I've done it the other way, I've been
>> attacked too, so, speaking personally and as co-editor, I'm
>> no longer interested in the discussion.
> 

See above.  Barry?

>>>>    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.
>>>> 
>> 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 don't know if we do or not.  Some things I know are that I've
spent too many weeks of my life reading and rereading 3986,
trying to understand how it bears and should bear on URNs and
that the WG has spent years circling around the issue.  Another
thing I know is that 3986 is quire clear that it updates and
replaces some URL documents and that, while it includes some
sentences about URNs, it does not identify itself as updating or
replacing RFC 2141 or, for that matter, 3406 or any other
URN-specific document.  Since the WG has no mandate or authority
to update or otherwise modify or clarify 3986, it is equally or
more reasonable that it start from prior URN materials as a
basis as it is that it treat 3986 as definitive.

> I think the right
> conclusion is to strip the prose wrt RFC 3986. Just say:
> 
> 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."

I think that change is probably harmless, but would like to hear
from others before I make the change.  In particular, in either
version, whether the sentence(s) are meaningful at all depends
on the distinction between what are "general syntax" and
"[general ?] semantics" versus "specifics of syntax and
semantics".  The previous form tied that distinction to 3986,
even though it is not clear to me that it made the distinction
clear either.   Perhaps it is just late at night but, with the
3986 references removed, I just don't see a clear boundary.

>>>>    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
>> the sort of thing the RFC Editor is really good at catching
>> and fixing.

> ...I prefer to process documents with known problems fixed.

So do I, which is why the fix has been applied.  I was just
trying to suggest that, had this fallen through the cracks, it
almost certainly would have been caught in final editing.

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

If that implies that you expect a complete rewrite as the result
of IETF LC, noted.

best,
    john

---

From: Julian Reschke <[email-masked]>
Date: Sun, 8 Jan 2017 08:28:41 +0100

> If that implies that you expect a complete rewrite as the result

No, I don't expect that, nor do I think it's needed. What I said is 
we'll very likely have one more draft after WGLC and one more after IETF 
LC and IESG discussions.

Best regards, Julian

---

From: "Hakala, Juha E" <[email-masked]>
Date: Tue, 10 Jan 2017 06:28:29 +0000

Hello, 

A comment below. 

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of Julian Reschke
> Sent: 7. tammikuuta 2017 23:58
> To: John C Klensin <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [urn] Feedback on draft-ietf-urnbis-rfc2141bis-urn-16
> 

> > claims that 3986 does not obviously allow a scheme to delegate the
> > syntax to other (non-scheme) parts of the URI (specifically
> > personally prefer sentences to the effect of "no matter what you think
> > 3986 says, URNs works this way...", but I don't think that
> > 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

> > 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.
> 
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Jan 2017 08:11:53 +0100

> 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…

My proposal was just to remove the (IMHO) confusing and unnecessary 
mention of RFC 3986... Yes, there may be other things to change -- this 
is why we're doing a Last Call, right?

Best regards, Julian

---

From: "Svensson, Lars" <[email-masked]>
Date: Wed, 11 Jan 2017 08:42:08 +0000

Julian, all

> course may depend on a particular namespace or even a particular

Since the q-component is always passed directly to the resource representation returned by the URN resolver, I'd say that any syntactical and semantic constraints of the q-component depends _entirely_ on that resource representation. My suggestion would be to strip references to the URN namespace, too:

[[
Neither the general syntax, nor the semantics of q-components are defined or dependent on the namespace of the URN. Specifics of syntax and semantics, e. g., which keywords or terms are meaningful, depend entirely on the particular resource representation.
]]

Best,

Lars