Subject: [urn] Alissa Cooper's Discuss on draft-ietf-urnbis-rfc2141bis-urn-21: (with DISCUSS and COMMENT)

From: Alissa Cooper <[email-masked]>
Date: Wed, 01 Mar 2017 07:11:18 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-urnbis-rfc2141bis-urn-21: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

What is the motivation behind specifying the r-component syntax at this
point and then recommending against its use until further standardization
is complete? Why not specify the syntax when those future standards get
written? The current approach just seems like an invitation for people to
start including r-components in URNs without independent implementations
understanding their semantics.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

= General =

I agree with Stephen that this spec seems unnecessarily long. There are a
bunch of instances of repeated text in different sections that reference
each other. I realize this doc was a negotiated outcome but if doing a
streamlining pass is a possibility, it wouldn't hurt IMO.

= Section 4.4 =

"Further, all URN-aware applications MUST
   offer the option of displaying URNs in this canonical form to allow
   for direct transcription (for example by copy-and-paste
techniques)."

I know this was in 2141, but it seems needlessly constraining on
applications and I would be surprised if every application that is aware
of URNs actually does this. 

In general I think it would be preferable to avoid specifying normative
requirements about what applications are to display, including the other
requirements added to this section that were not in 2141.

= Section 8 =

Agree with Stephen's comment here.

= Appendix C =

"Truly experimental usages MAY, of course, employ
       the 'example' namespace [RFC6963]."

It seems inappropriate to have normative language in this appendix.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 1 Mar 2017 18:21:37 -0700

Hi Alissa, thanks for your input.

> https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/

My perspective is that we don't have the right people involved at the
IETF (esp. many more members of the information sciences community) to
undertake work on URN resolution, so it will happen elsewhere (perhaps
ISO TC 46). However, this was probably our one and only chance to update
the URN syntax so that others can work on URN resolution, which is why
we defined the r-component syntax now. Naturally this is less than
ideal, but we play the hand we're dealt.

> I agree with Stephen that this spec seems unnecessarily long.

I see a few areas where the main portion of this specification (~11500
words) is significantly longer than the combination of RFC 2141 and RFC
3406 (~7100 words):

1. Design tradeoffs; this could be moved to an appendix.

2. Terminology; given the wrangling over concepts, this was important.

3. URI syntax; more precision was needed and r-components were added.
(Yes, there is some repeated text here, but it was extremely confusing
to read when an earlier version tried to combine sections.)

4. URN equivalence; this now includes more examples and associated
explanations, which seem helpful.

5. URI conformance; this was necessary because RFC 3986 was published
since RFC 2141.

6. URN namespace registration; this was expanded because registrants
often found the old text confusing.

IMHO the new specification is *unnecessarily* long.

> There are a

Specific suggestions are welcome, and we'll take another look as well.

> requirements added to this section that were not in 2141.

I have no objections to softening that language.

> Agree with Stephen's comment here.

I'll reply separately to Stephen on this point.

> It seems inappropriate to have normative language in this appendix.

I suggest changing MAY to can.

Peter

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Mar 2017 21:18:36 -0500

--On Wednesday, March 1, 2017 07:11 -0800 Alissa Cooper
<[email-masked]> wrote:

>....

> -------- DISCUSS: --------
> 
> What is the motivation behind specifying the r-component
> syntax at this point and then recommending against its use
> until further standardization is complete? Why not specify the
> syntax when those future standards get written? The current
> approach just seems like an invitation for people to start
> including r-components in URNs without independent
> implementations understanding their semantics.

Commenting at this time on this one issue only and speaking for
myself (if it is relevant, Barry or Alexey will need to comment
on whether I've captured WG consensus).

One of the important properties of URNs (more or less since they
were first conceived of) is that they were location-independent
(and, for things more like books than web pages,
particular-copy-independent) abstract identifiers that would
"resolve" into something more location and/or copy-dependent.
While some early documents assumed that URNs would be resolved
to locator-type URIs, that is not and never has been a
requirement: URNs can resolve into other sorts of things or not
resolve at all.  

When the "opportunity" came up to revise URNs, there were
several different communities who wanted extended capabilities
beyond those that can be supported under a strict interpretation
of RFC 2141.   The library community was important among them
and needed the capability to both identify an object (or
object-abstraction) and pass information to it.  An initial view
in the WG was to simple add a 3986-like query component to the
URN syntax and be done with it.  However, discussion on that
point rapidly led to the realization that there were at least
two different types of qualifying information: information that
was needed to resolve or dereference the URN and information
that was needed to work with, interpret, or get information from
the object.  That, in turn, led to the conclusion that the
distinction between the r-component and q-component was
necessary, even (or especially) if the WG didn't feel ready to
precisely define the syntax and semantics of r-component (it may
be worth noting that there was one proposal to do just that, but
the WG decided to be conservative about untried solutions to a
problem that was not itself, understood explicitly and in
detail).    It was, and is, still necessary, to define basic
syntax for r-component, both to distinguish it from q-component
and to address a more basic problem.

That problem is that the predecessors of RFC 3986 established a
generic, and quite prescriptive, syntax for URLs.  RFC 3986
expanded that to cover all URIs, arguably including URNs without
fully understanding the implications of that expansion.  The
result is that almost anything one puts in a URI either means
something, is part of some specific component, or both.  

The WG was told that there are generic URI parsers that isolate
those components according to the rules of 3986 and that the WG
could not reasonably do anything that would foul up such
parsers.  The result is that, if one is going to separate the
"part of URN processing" material that the document calls
r-components from the "something the URN is expected to make
available to the resolution object or equivalent if there is
one" material the document calls q-components, then it is
necessary to assign distinguishing syntax to both of them so it
is clear how to tell them apart.   That can be done without
specifying parsing of the substring that the spec assigns to
r-components, and, after a good deal of discussion about
options, that is what the WG told the editors to do.  But it
cannot be done without defining that distinguishing syntax -- if
that were done, if all that were defined now was the q-component
(or the RFC 3986 <query>) then it would be impossible to add the
r-component functionality later without complaints that some
potential use of q-component or functionality of some real of
hypothetical generic parser was being messed up.

The discussion above is the answer to another question, or maybe
another set of them.  The URNBIS effort was driven by demands
from several communities who had URNs in general use for
functionality beyond that allowed by RFC 2141, even though 2141
and its predecessors discussed some of it and reserved syntax
for future use.  At least one of those communities, whose
members include experts from several important repository
libraries, have national and international standards-defining
bodies of their own and a lead on the IETF in terms of thinking
about persistent identifiers of at least a few hundred years.
They could have simply gone off and defined and standardized
their own extended URN format.  Instead, they were, at least
IMO, far more adult and responsible than many of the SDOs we
deal with and preferred to bring requirements to us, ask us to
figure out what would work best with URNs, and then participated
in the process.   

Had the goal of the WG been simply to update and make minor
adjustments to RFC 2141 and possibly to combine the registration
issues of 3406 with it, the result would almost certainly have
been a shorter document than the sum of the page count of those
two.  When the requirement because to expand functionality in
ways  that changed syntax while remaining compatible with prior
practice and 3986 syntax and, necessarily, to address some of
the subtle issues above, the explanations and the document got
appreciably longer.  

Could it be streamlined?  Yes, probably.   Some of the issues
you identified are the result of pulling text out (including
some internal syntax for r-components and a longer discussion of
f-components/fragments) over the last year.  But, speaking from
experience, it isn't easy -- virtually every non-trivial
document change seems to stimulate someone in the WG who wants
to revisit an old issue.  Unless there are substantive issues, I
recommend just letting things go with a plan to sort those
issues out when URNs are progressed to full standard.   With
luck and some effort on the IESG's part, perhaps we will, by
then, have a revised and clarified 3986bis to work with,
something that would almost certainly make this document far
simpler.  On the other hand, if you object to a normative
statement in the registration template because we make an
arbitrary decision to put it in an appendix when 3406/3406bis
was moved in, I think that template could be turned into a
section of the main document (or a subsection of IANA
Considerations) by applying a very small effort to the XML
source.

Again, my personal perspective with which some people in the WG
might disagree.  

best,
   john

---

From: Julian Reschke <[email-masked]>
Date: Thu, 2 Mar 2017 08:07:19 +0100

On 2017-03-02 03:18, John C Klensin wrote:
> ...
> ...

Actually, that happened with RFC 2396 in August 1998.

> ...

Best regards, Julian

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 2 Mar 2017 09:04:41 -0500

> On Mar 1, 2017, at 8:21 PM, Peter Saint-Andre <[email-masked]> wrote:
> 

Ok. This also seems to be part of the argument John made in his mail, and I get it.

Given the expectations that you state, however, I’m wondering if the expression of the normative requirements might be more prudent if it were phrased more along these lines:

---

OLD
Thus r-components SHOULD NOT be used for actual
   URNs until additional development and standardization work is
   complete, including specification of any necessary registration
   mechanisms.

NEW
Thus r-components SHOULD NOT be used for URNs before their semantics have been standardized.

---

Since the expectation is that the future standardization efforts will take place elsewhere, it doesn’t seem justified to try to constrain those efforts by normatively recommending registry mechanisms or imposing an undefined notion of what it means for future standards to be “complete.” Better to be clear that all this document is doing is specifying syntax and therefore cannot constrain how people decide to use r-components in the future. I also was not sure what an “actual” URN is. 

Thanks,
Alissa

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Mar 2017 09:11:01 -0500

Because there have been a few comments on the length of this
document and internal redundancy, an explicit tradeoff may be
worth a brief comment.

While the document contains a good deal of theoretical and
contextual material that the WG concluded was important, we (the
editors and, I believe, the WG) also concluded that many readers
who were trying to understand what was involved in registering a
namespace and the procedure to be followed would read it looking
for that information.  There are, in essence, three separate
procedures.  They use reflecting different cases but depend on
the same template.  

We decided to make each case and procedure as self-contained as
possible for easy reading (or even skimming/ checking) but
someone trying to work out a registration.  Because the
procedures are still similar, that resulted in considerable
redundancy.   The other alternative would have been to try to
define a single procedure with lots of alternate cases and/or a
web of cross-references.  That would have created a much shorter
document but one that would have been harder to use and that
might have increased the odds of errors or omissions.

Speaking personally, I hope the IESG doesn't feel a need to
second-guess that set of document organization decisions.

    john

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Mar 2017 11:18:26 -0500

Hi (IESG, other than Alexey, Alissa, and Stephen, not copied to
save them clutter),

The IESG just tentatively signed off on this draft, pending a
revised document (don't start celebrating yet).  That means only
editorial corrections and changes already agreed.

I'd like to get that draft posted within the next 24 hours so
that the IESG can issue an approval notice and we can get this
behind us (modulo RFC Editor changes and AUTH48).

As far as I know, the following changes are in the queue:

(1) Alissa's suggestion about r-component below.  The more
complex text was trying to make a slightly different and
stronger point, but I don't think it is worth fighting about and
her text is definitely simpler and shorter.

(2) Stephen's pending text on privacy.  I expect this to be
minimal and clarifying.

(3) Review of Alissa's other suggestions.  Absent strong (and
immediate) comments/objections from the WG, I expect to resolve
them as follows (for more details on some of these, see her
DISCUSS and NO OBJECTION postings to the list):

(3.1) = Section 4.4 =

> 	"Further, all URN-aware applications MUST offer the
> 	option of displaying URNs in this canonical form to
> 	allow for direct transcription (for example by
> 	copy-and-paste techniques)."

> I know this was in 2141, but it seems needlessly constraining
> > on applications and I would be surprised if every
> application that is aware of URNs actually does this. 
>...

I am very reluctant to tamper with this at this point -- it
would, IMO, need WG discussion.  In addition, questions about
what "every application" does and does not do seem as or more
appropriate when we come back to this for full standard.

3.2 = Appendix C =

> It seems inappropriate to have normative language in this

The text appears to me to be more of a comment than a normative
requirement, so I'm simply going to change "MAY" to "may" and
hope that lets us move on.

(4) That is everything on my list.  If anyone has other things,
or I've missed an important note, please speak up _very_ soon.

    john

--On Thursday, March 2, 2017 09:04 -0500 Alissa Cooper
<[email-masked]> wrote:

>    URNs until additional development and standardization work
> is    complete, including specification of any necessary
> registration    mechanisms.
> 
> NEW