Subject: [urn] Wording draft-ietf-urnbis-semantics-clarif-00.txt

From: [email-masked] (Dale R. Worley)
Date: Fri, 5 Sep 2014 16:52:22 -0400

I've been looking at draft-ietf-urnbis-semantics-clarif-00, and it
seems to be a practical place to start.  I think its wording could be
improved in some places.

The Abstract says:

   ... this specification separates URNs from the semantic constraints
   that many people believe are part of the specification for Uniform
   Resource Identifiers (URIs) specified in RFC 3986, updating that
   document accordingly.

Section 1 (Introduction) says:

   This specification is concerned only about URNs of the variety
   described in RFC 2141 [RFC2141] (i.e., those that use the "urn"
   scheme).  URLs, other types of names, and any URI types that may
   not fall into one of the above categories are out of its scope and
   unaffected by it.

I'm sure that the text in section 1 is what we intend, but it doesn't
match what is in the Abstract; the Abstract claims to cover all URNs,
not just things with the scheme "urn".

This goes back to the fact that we've been sloppy about the
distinction between "URN" (per RFC 3986, things that have the "name"
properties, that is, "identifiers" in Juha's terminology), and things
with the scheme "urn".

   In particular, the Generic URI Syntax specification goes beyond
   syntax to specify the meaning and interpretation of various fields,
   especially the "query" and "fragment" ones.

It would help the reader who is not already neck-deep in the
discussion to consistently use one name for each document.  Most
references in this draft use the RFC number, but some references use
the document title.

(Amusingly, both of the above issues involve the use of names:  The
first is distinguishing the set of all possible URNs from the set URIs
with scheme "urn", which contains all existing URNs.  The second
emphasizes the usefulness of using a unique name for each particular
resource.)

In section 2 (Pragmatic Goals) is this item:

   1.  Try to accommodate all of those who think URNs are necessary,
       i.e., that they can and should be usefully distinguished in
       certain respects from other URIs, at least those that have been
       defined prior to this document.  In particular, provide a
       foundation for extensions to the URN syntax allowed by and
       defined in RFC 2141 to support requirements encountered by some
       of those communities.

The first clause of the item doesn't fit with what follows.  One can
consider "URNs are necessary" without thinking "they can and should be
usefully distinguished in certain respects from other URIs".  (One can
consider a thing necessary without requiring it to be contained in a
distinguished category from certain other things.)  I think what is
meant "those who think that a specific category for URNs is
necessary".  But I think the meaning can be more simply conveyed by
removing that clause, starting the item with "Try to accommodate all
of those who think that URNs can and should be usefully
distinguished...".

Dale

---

From: John C Klensin <[email-masked]>
Date: Sat, 06 Sep 2014 02:37:07 -0400

--On Friday, September 05, 2014 16:52 -0400 "Dale R. Worley"
<[email-masked]> wrote:

> I've been looking at draft-ietf-urnbis-semantics-clarif-00,
> and it seems to be a practical place to start.  I think its
> wording could be improved in some places.
> 
> The Abstract says:
> 
>    ... this specification separates URNs from the semantic
> constraints    that many people believe are part of the
> specification for Uniform    Resource Identifiers (URIs)
> specified in RFC 3986, updating that    document accordingly.
> 
>    This specification is concerned only about URNs of the
> variety    described in RFC 2141 [RFC2141] (i.e., those that
> use the "urn"    scheme).  URLs, other types of names, and any
> URI types that may    not fall into one of the above
> categories are out of its scope and    unaffected by it.
> 
> I'm sure that the text in section 1 is what we intend, but it
> doesn't match what is in the Abstract; the Abstract claims to
> cover all URNs, not just things with the scheme "urn".

Please see my conversation with Leslie from 3 - 5 September
(http://www.ietf.org/mail-archive/web/urn/current/maillist.html).
In particular, the conclusion in Toronto, Andy's instructions,
and that thread all argue that, unless it actually causes
confusion in our conversations, it is not a good use of time to
fine-tune the text of this document until we decide what we are
going to do substantively and then decide whether to keep the
document.

So, yes, if we are going to keep and publish the document, the
abstract needs work.  If we are not, please concentrate on
substance or explain why the current text is getting in the way
of a discussion. 

> distinction between "URN" (per RFC 3986, things that have the
> "name" properties, that is, "identifiers" in Juha's
> terminology), and things with the scheme "urn".

This issue was also addressed in that earlier thread, although
less directly so.  I intentionally did not include it in Section
6 and left out precisely because it relates to what this
document says (relevant only if we are going to publish it)
rather than the core substance of the WG's work.  As illustrated
by the thread Leslie started, both she and I (and, I believe
from earlier threads and discussions) believe that the language
of 3986 that says there are URNs that don't follow the "urn:"
scheme is undesirable and has little value unless the goal is to
create confusion.  At least in retrospect, it probably should
have said something more like "there are names and naming system
that may be URIs but are not URNs".   The WG needs to decide
whether it wants to address that topic, whether it wants to
address it in a successor to this document and, if so, what it
wants to say.   The current draft intended to sidestep the
issue.  Another alternative would be to "update" it out of 3986
but it is hard to do that without formally criticizing 3986.
Such criticisms seem to be painful out of proportion to their
value in moving the present URN work forward.   Then we can make
any documents we intend to publish consistent with that decision.

>    In particular, the Generic URI Syntax specification goes
> beyond    syntax to specify the meaning and interpretation of
> various fields,    especially the "query" and "fragment" ones.
> 
> discussion to consistently use one name for each document.
> Most references in this draft use the RFC number, but some
> references use the document title.

Until and unless we decide we intend to publish this document,
its audience it precisely those people who are neck-deep in the
discussion.   Until that time, it is an instrument to aid WG
discussion, not an introduction to the WG's work.   Bluntly and
IMnvHO, a far worse problem than the inconsistencies you cite in
the working draft is people expressing opinions in the WG who
are not familiar with the issues, mailing list discussions, and
relevant documents.

> (Amusingly, both of the above issues involve the use of names:
> The first is distinguishing the set of all possible URNs from
> the set URIs with scheme "urn", which contains all existing
> URNs.  The second emphasizes the usefulness of using a unique
> name for each particular resource.)

As others have observed, the difference between a thing, the
name of the thing, and the names by which it is called have
often been a source of confusion in our conversations.  I do not
believe that the text of this document adds to that confusion
for someone who has been following the work of the WG.  If you
disagree, send text.

>    1.  Try to accommodate all of those who think URNs are
> necessary,        i.e., that they can and should be usefully
> distinguished in        certain respects from other URIs, at
> least those that have been        defined prior to this
> document.  In particular, provide a        foundation for
> extensions to the URN syntax allowed by and        defined in
> RFC 2141 to support requirements encountered by some        of
> those communities.
> 
> The first clause of the item doesn't fit with what follows.
> One can consider "URNs are necessary" without thinking "they
> can and should be usefully distinguished in certain respects
> from other URIs".  (One can consider a thing necessary without
> requiring it to be contained in a distinguished category from
> certain other things.)

That is why the word "and" was used, and used in its Boolean
sense.  If that is sufficiently unclear to be confusing, please
see below and suggest text.

>  I think what is meant "those who think
> that a specific category for URNs is necessary".  But I think
> the meaning can be more simply conveyed by removing that
> clause, starting the item with "Try to accommodate all of
> those who think that URNs can and should be usefully
> distinguished...".

If the current text isn't clear, that isn't the fix because part
of the point is that the argument has been made that URNs (at
least "urn:" scheme ones, fall somewhere on the scale between
completely irrelevant and a bad mistake.  For someone who holds
that belief, their relationship to [other] URIs is of no
importance or, put differently, worthy of discussion among the
angels dancing on the head of some particular pin.

Sorry.  I do appreciate the careful reading.  I'm just hoping to
do what the document was written to do, which is to focus the WG
on critical-path substantive questions rather than editorial and
philosophical debates.

best,
    john