Re: [urn] Document status and related issues - semantics clarification (replacing urns-are-not-uris)

["Leslie Daigle (TCE)" <[e-mail]>]

[Re-sending from the address that is actually subscribed to the list...]

Hi,

Thank you for updating the document, and in such short order after the 
WG meeting!

I read through it, and I feel I am being a little dense, or maybe caught 
between a couple of known edit disconnects.

Reading through it, it seems to me that there are 2 problems to solve:

+ identify, agree and articulate how the URN syntax relates to URI 
syntax, as captured in RFC3986.  This is Section 6 in the document.

+ ensure that there are persistent identifiers, presumably URIs, that
"meet the needs of the Library, Museum, Publisher, and Informational 
Sciences communities and other users".   Some of the requirements for 
this are captured in the Appendices.


The first ought to happen, no matter what, and is in fact the focus of 
this WG's charter.  It could actually happen without addressing the 
second problem, at least from a strictly logical perspective.

I realize that would not be very satisfying -- as the latter was what 
provided the motivation for the working group in the first place, and 
I'm not actually suggesting we do that.

In fact, I thought where we landed in Toronto was that we should first 
focus on figuring out how to address those issues -- ensure URI 
persistent identifiers that meet the requirements and _then_ see whether 
such persistent URIs were, or could be, URNs as defined by the IETF 
(i.e., solving the first problem by applying the results of the discussion).


In terms of the document, here are a couple of the things that make me 
wonder about disconnects:

1/ The abstract addresses the second problem, but couches it in terms of 
the first:

    "Experience has shown that identifiers associated with persistent
    names have properties and requirements that may be somewhat different
    from identifiers associated with the locations of objects.  This is
    especially true when such names are expected to be stable for a very
    long time or when they identify large and complex entities.  In order
    to allow Uniform Resource Names (URNs) to evolve to meet the needs of
    the Library, Museum, Publisher, and Informational Sciences
    communities and other users, 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.  The syntax of URNs is
    still constrained to that of RFC 3986, so generic URI parsers are
    unaffected by this change.

For a different document (one addressing the persistent identifier 
issue), I might write the abstract very slightly differently:

    Experience has shown that identifiers associated with persistent
    names have properties and requirements that may be somewhat different
    from identifiers associated with the locations of objects.  This is
    especially true when such names are expected to be stable for a very
    long time or when they identify large and complex entities.  In order
    to allow Uniform Resource Identifiers (URIs) to meet the needs of
    the Library, Museum, Publisher, and Informational Sciences
    communities and other users, this specification outlines the
    specification of a persistent identifier scheme which is separate
    from the semantic constraints that many people believe are part of
    the specification for Uniform Resource Identifiers (URIs) specified
    in RFC 3986.  The syntax of these identifiers is still constrained
    to that of RFC 3986, so generic URI parsers are unaffected by this
    change.


2/ For historic reasons, I have a lot of heartburn with this para:

    IETF in RFC 1738 [RFC1738] -- as an embodiment of the locator concept
    and Uniform Resource Names (URNs), specifically those using the "urn"
    scheme [RFC2141], as an embodiment of the names that do not directly
    provide for resource location.  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.

RFC2141 defines the syntax for URNs, period.  Not "the URN: URI scheme". 
  For URNs.    I don't take exception to people hating that approach to 
URNs :-)  but insofar as the IETF defines standards, it defined the 
standard for URNs once.

There can be (and already are) any number of other approaches to 
persistent identifiers that are more or less URN-like, but they are 
persistent identifiers, Persistent Resource Names, Uniform Persistent 
Identifiers, whatever.

If the IETF starts talking about multiple possible specifications for 
URNs, we're in trouble, IMO.

Leslie.

On 8/25/14 8:08 PM, John C Klensin wrote:
> Hi.
>
> I've posted the replacement for
> draft-ietf-urnbis-urns-are-not-uris-01 as
> draft-ietf-urnbis-semantics-clarif-00.  It is now awaiting
> Andy's approval which I thought was given shortly after Toronto.
>
> Some of you know that my intention was to immediately follow it
> with a trimmed-down -01 because -00 contains a lot of material
> we probably won't want long-term.  As a preview, exclusive of
> references (some of them cited from the appendices) and
> appendices, -00 is only 8 pages long; with them, twice that.
> I've deferred trying to get -01 out both because -00 took much
> longer than expected and because I continued to review both the
> post-Toronto mailing list comments and a number of private
> communications and concluded that the current draft may not be
> stable enough to start pulling text out of.  I'd also like to
> have a better idea of what Peter expected to do with 2141bis (or
> what the WG wants him to do).
>
> I'm aware that some text is redundant, especially the repeated
> comments about zero effect on generic URI parsing systems.  That
> is partially intentional (to be sure those statements didn't get
> lost when we start removing sections) and partially just
> temporarily running out of energy.
>
> Note too that this draft contains, in Section 6, my cut at the
> list Andy requested of alternatives with which the WG will need
> to deal.
>
> In the spirit of the discussions in Toronto, this document  is
> intended more as the basis for focusing discussions than as a
> final piece to be published.  To paraphrase what Andy said
> there, we need to make decisions about what we want to do and
> only then figure out how much of this, if any, is worth having
> in an officially-permanent document.
>
> While some of the discussion in this -00 draft gets fairly far
> into "how to do this", I personally concur with something Andy,
> Henry, and several others have said in different ways: in the
> short run, we are much more likely to end up with the results we
> want if we can talk about functionality and not where to put it
> or what syntax to use.  While the I-D uses "query" and
> "fragment" terminology, it may even be useful to thinks of parts
> of the URI syntax as "path-stuff", "?-stuff", and "#-stuff",
> remembering that the connotations of words like "query" and
> "fragment" are themselves semantics.  I expect that we will
> return to URI terminology before the version of 2141bis that
> reflects these issues is posted but, for thinking right now it
> again may be useful to break loose from historical concepts.
>
> Some of the above has almost certainly influenced what I've
> written and how I've written it.  That doesn't mean the text is
> right, but I hope we can be clear about what we are talking
> about before we get into trouble.
>
> Happy reading,
>      john
>
>
>
> _______________________________________________
> urn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/urn
>

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[e-mail]
-------------------------------------------------------------------