Subject: Re: [urn] Feedback on draft-ietf-urnbis-semantics-clarif-03

From: Sean Leonard <[email-masked]>
Date: Wed, 4 May 2016 09:26:54 -0700

Quick question on this feedback:

> On Apr 27, 2016, at 8:02 AM, Julian Reschke <[email-masked]> wrote:
> 
> Hi there,
> 
> I was asked off-list to review the current drafts, given my interest in RFC 3986 in the past.
> 
[...]

> Appendix A.  Background on the URN - URI relationship
> 
>   The Internet community now has many years of experience with both
>   name-type identifiers and location-based identifiers (or "references"
>   for those who are sensitive to the term "identifier" such as many
>   members of the library and information science communities..  The
> 
> s/.././
> 
>   primary examples of these two categories are Uniform Resource Names
>   (URNs [RFC2141] [RFC2141bis]) and Uniform Resource Locators (URLs)
>   [RFC1738]).  That experience leads to the conclusion that it is
>   impractical to constrain URNs to the high-level semantics of URLs.
>   The generic syntax for URIs [RFC3986] is adequately flexible to
>   accommodate the perceived needs of URNs, but the specific semantics
>   associated with the URI syntax definition -- what particular
>   constructions "mean" and how and where they are interpreted -- appear
>   to not be.  Generalization from URLs to generic Uniform Resource
>   Identifiers (URIs) [RFC3986], especially to name-based, high-
>   stability, long-persistence, identifiers such as many URNs, has
>   failed because the assumed similarities do not adequately extend to
>   all forms of URNs.  Ultimately, locators, which typically depend on
>   particular accessing protocols and a specification relative to some
>   physical space or network topology, are simply different creatures
>   from long-persistence, location-independent, object identifiers.  The
>   syntax and semantic constraints that are appropriate for locators are
>   either irrelevant to or interfere with the needs of resource names as
>   a class.  That was tolerable as long as the URN system didn't need
>   additional capabilities (over those specified in RFC 2141) but
>   experience since RFC 2141 was published has shown that they are, in
>   fact, needed.
> 
> I don't believe this appendix is way too vague to be helpful.

I am confused by this sentence. Is that a typo? Are you saying that this Appendix is too vague to be helpful, and therefore should be removed? Or are you saying it is not too vague; it is helpful; therefore, keep it in the draft?

Sean

---

From: Julian Reschke <[email-masked]>
Date: Wed, 4 May 2016 19:40:53 +0200

> I am confused by this sentence. Is that a typo? Are you saying that this Appendix is too vague to be helpful, and therefore should be removed? Or are you saying it is not too vague; it is helpful;…

Sorry.

I *believe* it is too vague to be helpful.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 15 May 2016 14:48:22 +0200

Hi there,

I haven't seen any substantial feedback on what I wrote two weeks ago. 
Thus here's my attempt to rephrase this in order to get more people to 
think about it.

On draft-ietf-urnbis-semantics-clarif-03:

This currently updates RFC 3986. Of course we can do this, but RFC 3986 
is a full standard, and thus this draft needs to be crystal clear about 
what exactly is being updated. I don't think it currently does that; it 
does some hand-waving with respect to what fragments and queries are 
(without saying exactly what's wrong in RFC 3986). It does *not* talk 
about changes to equivalence and relative resolution, although 
draft-ietf-urnbis-rfc2141bis-urn-16 seems to attempt to change them.

Furthermore, it currently contains stuff that has nothing to do at all 
with the relation to RFC 3986, namely the introduction of new elements 
that are only relevant to the URN spec; these should be moved over to 
the other draft.

On draft-ietf-urnbis-rfc2141bis-urn-16:

This draft seems to rely on draft-ietf-urnbis-semantics-clarif-03, but 
does not reference it normatively.

Furthermore, it appears to redefine relative resolution and equivalence. 
This is problematic in several ways:

It's totally unclear what the intended effect of these redefinitions 
will be on existing code. Is existing, non-URN-specific code supposed to 
be changed? If yes, what's the strategy to make this happen? If no (thus 
it's for URN-specific code only), what's the point in attempting to 
change the generic framework defined in RFC 3986? Wouldn't it be much 
much simpler just to

- define the new URN-scheme-specific equivalence as such (as described 
in <https://greenbytes.de/tech/webdav/rfc3986.html#normalize-scheme>), and

- define the URN-specific reference resolution as something URN-specific 
tools can do, but not to pretend that existing URI processors will 
implement this?

Best regards, Julian

On 2016-04-27 17:02, Julian Reschke wrote:
> I was first confused about 2141bis seemingly making changes to 3986, but
> then realized that there's draft-ietf-urnbis-semantics-clarif-03 as
> well. I believe 2141bis needs to *normatively* reference this one.
>
> That said, I appreciate that these two are separated, because it's
> easier to understand what's going on with relation to 3986. However, the
> separation may need more work; this document IMHO contains stuff that
> should be in 2141bis, while there's stuff in 2141bis which would need to
> be here.
>
> Other than that see below comments inline (sorry for the format).
>
> Best regards, Julian
>
> -- snip --
>
> Uniform Resource Names (urnbis)                               J. Klensin
> Internet-Draft                                          February 5, 2016
> Updates: 3986 (if approved)
> Intended status: Standards Track
> Expires: August 8, 2016
>
>
>                       URN Semantics Clarification
>                draft-ietf-urnbis-semantics-clarif-03.txt
>
> Abstract
>
>    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 Information Science 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) in RFC 3986, updating that
>
> Lack of clarity: this is intended to be standards track document
> updating a full internet standard. I don't think that what people
> believe about that spec is relevant; we should be able to agree upon
> what it says and what it doesn't say.
>
>    document accordingly.  The syntax of URNs is still constrained to
>    that of RFC 3986, so generic URI parsers are unaffected by this
>    change.
>
> ...that depends on whether resolution of a relative reference against a
> base URI is part of what a URI parser does (do we have a definiton of
> what a "URI parser" does?)
>
>
> 1.  Introduction
>
>    The Generic URI Syntax specification [RFC3986] covers both locators
>    and names and mixtures of the two (See its Section 1.1.3) and
>    describes Uniform Resource Locators (URLs) -- first documented in the
>    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] and its
>    successors [RFC2141bis] (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 understand that historical context is useful, but do we really need
> half a paragraph to say: "this is about URIs using the 'urn' scheme"?
>
>    Experience with URNs since the publication of RFC 3986 has identified
>    several ways in which their inclusion under the 3986 scope has
>    hampered understanding, adoption, and especially extension
>    (specifically extensions of types that were anticipated, but not
>    defined, in RFC 2141).  The need for extensions to the URN concept is
>    now being felt in some communities, especially those that include
>    libraries, museums, publishers, and other information scientists.
>
>    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 and the various syntax
>    forms and interpretations it allows for <hier-part>.  This
>
> Agreed for "fragment", not sure about "query". Could you elaborate a bit?
>
>    specification excludes URNs from those definitions of meaning and
>    interpretation so that RFC 3986 applies to their syntax only.  The
>    meaning --and any more specific syntax rules-- for those fields for
>    URNs are now defined in a URN-specific document [RFC2141bis].  URNs
>    remain members of the URI family and parsers for generic URI syntax
>    are not affected by this specification although parsers that make
>    assumptions based on other URI schemes obviously might be.
>
> I don't get the last sentence. If a parser makes assumptions on *other*
> schemes, how would it affect processing of "urn" URIs?
>
>    Neither this specification nor the successor to RFC 2141 [RFC2141bis]
>    discusses DDDS [RFC3401] resolution or conversion to (and
>    interpretation of) URCs [RFC2483] or, with the exception of providing
>    some syntax to cover some specific cases, URN "resolution" more
>    generally.  Any of those topics that do need to be addressed should
>    be covered in other documents.  The document also does not discuss
>    alternatives to URNs, either those that might use a different scheme
>    name within the RFC 3986 URI framework or those that might use a
>    different framework entirely.  In particular, some externally-defined
>    content or object identification systems could be represented either
>    by a URN namespace or through separate URI schemes.  This
>    specification does not offer advice on that choice other than to
>    suggest that the two options not be confused (or both used in a way
>    that would be confusing).
>
> (matter of taste: I think that long text about what spec does *not* do
> really distracts from what it is about; maybe it would be good to things
> like this (and the text about URN's history) to an appendix?)
>
>    This document updates RFC 3986 to make the distinction between syntax
>    and semantics clear for URNs and to isolate URNs from presumed URI
>    semantic requiremnts.  It is important to note that some readers of
>
> s/requiremnts/requirements/
>
>    RFC 3986 are convinced that the separation is clear in that
>    specification and therefore that no changes to that document are
>    needed.  For them, this specification is only a confirming
>    clarification.
>
> I understand that this is well-intended, but it is certainly very very
> confusing.
>
>    In the long term, as the expanded syntax and uses of URNs become
>    commonplace and RFC 3986 is updated, this specification is likely to
>    become of historical interest only, providing an extended rationale
>    for decisions made and adjustment of the boundary between URN
>    specifications and generic URI ones.
>
> ...
>
> 3.  The role of queries and fragments in URNs
>
>    Part of the concern that led to this document was a desire to
>    accommodate URN components that would be analogous to the query and
>    fragment components of generalized URNs but that might have different
>    properties.  For many cases, the analogy cannot be exact.  For
>    example, RFC 3986 ties the interpretation of fragments to media
>    types.  Since media type is a function of specific content, URNs that
>    are never resolved cannot have an associated media type, nor can URNs
>    that resolve to, for example, other URIs that may then not be
>
> FTR, RFC 3986 says: "If no such representation exists, then the
> semantics of the fragment are considered unknown and are effectively
> unconstrained. Fragment identifier semantics are independent of the URI
> scheme and thus cannot be redefined by scheme specifications."
>
>    resolved further.  Similarly, while the RFC 3986 syntax for queries
>    (and fragments) may be entirely appropriate for URN use, terminology
>    like "Service Request" (see Appendix B of the predecessor "URNs are
>    not..." draft [ServiceRequests] for additional discussion) may be
>    more suitable to the URN context than "query" (if, indeed, the
>    portion of the URN that is syntactically equivalent to a URI query is
>    where those requests belong).
>
> RFC 3986: "The query component contains non-hierarchical data that,
> along with data in the path component (Section 3.3), serves to identify
> a resource within the scope of the URI's scheme and naming authority (if
> any)." -- so what *exactly* does this specification try to change? Just
> the name of the component??
>
> 4.  Changes to RFC 3986
>
>    This specification removes URN semantics from the scope of RFC 3896.
>
> s/3896/3986/
>
>    It makes no changes to the generic URI syntax.  That syntax still
>    applies to URNs as well as to other URI types.  Even as regard to
>    semantics, it has no practical effect for URNs defined in strict
>    conformance to the prior URN specification [RFC2141] or the
>    associated registration specification [RFC3406].
>
> So what other effect *does* it have?
>
>    In particular (but without altering RFC 3986 in any way), the generic
>    URI syntax for "queries" (strings starting with "?" and continuing to
>    the end of the URI or to a "#"), and for "fragments" (strings
>    starting with "#" and continuing to the end of the URI) is unchanged.
>    For URNs, additional syntax is introduced to divide the URI "query"
>    into two parts, referred to as "q-components" and "r-components".
>
> ...I'd argue that this URN-specific syntax shouldn't be discussed in
> *this* specification.
>
>    The syntax and general semantics of "fragments" (specified in RFC
>    3986 as scheme-independent) are unchanged, but a somewhat liberal
>    interpretation may be needed in the context of URNs, so a fragment is
>    referred to as an "f-component" as a term of convenience to highlight
>    that distinction.  [RFC2141bis].
>
> From this paragraph it's entirely unclear what the actual change is.
>
> 5.  Actions Occurring in Parallel with this Specification
>
>    The basic URN syntax specification [RFC2141] was published well
>    before RFC 3986 and therefore does not depend on it.  The successor
>    to that specification [RFC2141bis], fully spells out, or references
>    documents that spell out, the semantics and any required within-field
>    syntax of URNs.  It uses great care about generic or implicit
>    reference to any URI specification and delegates further details to
>    specific namespaces.
>
>    [[CREF1: Note in Draft: Perhaps this section can be dropped
>    entirely.]]
>
> Actually, no. <draft-ietf-urnbis-rfc2141bis-urn-16#section-4.3>
> essentially updates <https://tools.ietf.org/html/rfc3986#section-5.2>.
> This specification needs to be clear about that, because that is
> actually the biggest change to RFC 3986, and it's not even mentioned here.
>
> So if there *was* agreement on that change (which is a separate,
> complex, discussion), it really really would need to be mentioned here.
>
>
> ....
>
> 8.  IANA Considerations
>
>    [[CREF2: RFC Editor: Please remove the first paragraph below before
>    publication.]]
>
>    This memo is not believed to require any action on IANA's part.
>
>    There is an existing (i.e. prior to the publication of this document)
>    registry for "Uniform Resource Identifier (URI) Schemes" that already
>    includes the "urn" scheme itself and a separate existing URN
>    Namespace registry.  None of those registrations have any specific
>    dependencies on generic URI specifications.
>
> Actually, the second paragraph could go as well...
>
> 9.  Security Considerations
>
>    This specification changes the semantics of URNs to make them self-
>    contained (as specified in other documents), relying on the generic
>    URI syntax specification for syntax only.  It should have no effect
>    on Internet security unless the use of a definition, syntax, and
>    semantics that are more clear reduces the potential for confusion and
>    consequent vulnerabilities.
>
> It seems that it's RFC 2142bis which defines these changes, no?
>
> 10.2.  Informative References
>
>    [DeterministicURI]
>               Mazahir, O., Thaler, D., and G. Montenegro, "Deterministic
>               URI Encoding", February 2014, <http://www.ietf.org/id/
>               draft-montenegro-httpbis-uri-encoding-00.txt>.
>
>               This is an expired document, cited for historical context
>               only.
>
> This reference doesn't seem to be used.
>
> ...
>
>    [URN-transition]
>               Klensin, J. and J. Hakala, "Uniform Resource Name (URN)
>               Namespace Registration Transition", Feburary 2016,
>               <https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-
>               reg-transition/>.
>
> This reference doesn't seem to be used.
>
>
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn
>

---

From: John C Klensin <[email-masked]>
Date: Sun, 15 May 2016 11:44:03 -0400

--On Sunday, May 15, 2016 14:48 +0200 Julian Reschke
<[email-masked]> wrote:

> Hi there,
> 
> I haven't seen any substantial feedback on what I wrote two
> weeks ago. Thus here's my attempt to rephrase this in order to
> get more people to think about it.

I have been waiting for the co-chairs to take a position on
whether you are reopening an old topic and will continue to
wait.  The difference between this topic and those to which I
have been responding (to at least a subset) is that, while I
believe we discussed those others and move on, my recollection
is that Andy made a formal consensus call and closed this one.
If we start revisiting old topics without substantial new
information, it very nearly guarantees that we will never get
finished.

Reluctantly and against my better judgment, but in the interests
of saving time, a clarification below.

> This currently updates RFC 3986. Of course we can do this, but
> RFC 3986 is a full standard, and thus this draft needs to be
> crystal clear about what exactly is being updated. I don't
> think it currently does that; it does some hand-waving with
> respect to what fragments and queries are (without saying
> exactly what's wrong in RFC 3986). It does *not* talk about
> changes to equivalence and relative resolution, although

The update to 3986 is to remove URNs from the scope of URNs
except with regard to URI syntax.  3986 says, effectively, that
URNs are just like any other URIs; the "update" is that they
they are not.  The informal description of
draft-ietf-urnbis-semantics-clarif as "syntax only" is
consistent with that.

That particular "syntax only" decision has some fairly sweeping
implications, which were discussed at the time.  In particular,
it makes the definitions in 3986 --either whatever precise ones
appear or whatever oral tradition they have accumulated in other
forums -- irrelevant: they are not syntax.  So one can argue,
for example, that the way draft-ietf-urnbis-semantics-clarif
uses the term "resource" or distinctions it attempts to make
about it are undesirable, but one cannot appeal to inconsistency
with 3986 to support that view.   In addition, to the degree to
which the WG has already closed out this issue, an argument
about inappropriateness is presumably out of order unless it
includes fundamentally new arguments.  However, again, that
requires a judgment by the co-chairs.

Some of Juha's recent comments highlight another reason for
making the "syntax only" distinction and drawing a hard line
with it: the usage (I'm reluctant to say "definition") of the
term "identifier" in 3986 is incompatible with the meaning and
use of that term in the library and information sciences
community.  Making progress on URNs requires, at least IMO, not
trying to resolve that incompatibility but does require that the
terminology of 3986 not be treated as authoritative for URNs.

As to what should be in which document, the status of
draft-ietf-urnbis-semantics-clarif has, for a long time, been
"decide whether to fold all or part of this into 2141bis when
the WG has consensus about the substantive content of the
latter".   I've been reluctant to do a major merge because of
concern about introducing mistakes in the process, but am happy
to try to do whatever the WG actually wants. 

Finally, the "syntax only" separation is intended to remove the
implication that URNs (at least of the "urn:" scheme, but that
was deliberately left ambigious) are separate from all other
URIs (if one believes that the language of 3986 creates a
dichotomy, "all other URIs" == "URLs") and therefore that
questions like "how does this affect URL processors?" have a
uniform answer of "not at all, because even 3986 says that URNs
are not URLs".

    best,
      john

---

From: Andrew Newton <[email-masked]>
Date: Tue, 17 May 2016 11:38:42 -0400

> requires a judgment by the co-chairs.

Which hasn't changed. The group previously decided to go down the
"syntax only" path. This has been discussed in documents and several
working group sessions. And I don't think we should reopen the issue
as it was a pivotal decision that has been a prerequisite for the
progress made so far.

> to try to do whatever the WG actually wants.

What content is in which document is up to the discretion of the
document authors. Such things are often a very subjective judgement
where no right answer exists.

-andy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 May 2016 18:10:10 +0200

> as it was a pivotal decision that has been a prerequisite for the

WG consensus isn't IETF consensus. If this WG wants to update a 
standards track document, it will have to be able to answer the 
questions that I asked.

I hear from you and John: "RFC 3986 syntax, but not semantics", as if 
there was agreement about what parts of RFC 3986 are which (or is there?).

So, once again, if we say "updates: 3986" we need to be able to explain 
*precisely* which parts of RFC 3986 are affected (and why, fwiw).

Best regards, Julian

---

From: Sean Leonard <[email-masked]>
Date: Sat, 28 May 2016 07:41:04 -0700

On 5/17/2016 9:10 AM, Julian Reschke wrote:
> So, once again, if we say "updates: 3986" we need to be able to 
> explain *precisely* which parts of RFC 3986 are affected (and why, fwiw).

I agree with Julian that these sorts of questions need to be answered.

Given the low & declining engagement on this list, we need a place to 
record WG decisions that newcomers or people who only have a time budget 
to participate occasionally, can get up to speed and (re-)engaged. The 
document(s) itself/themselves have not been a useful guide to the 
proceedings of this WG.

I strongly advocate that we use some new tools to track and record WG 
decisions that the co-chairs and ADs have declared to be the rough 
consensus (or going-forward) positions. Specifically, I recommend that 
we use the IETF urnbis wiki. I have already created a basic wiki page 
for this purpose:

https://tools.ietf.org/wg/urnbis/trac/wiki/WGDecisions

We have some people saying "oh, the WG decided that, I'm not going to 
re-open that issue", when there is material technical disagreement about 
whether some decision is doable, or there is historical disagreement 
about what decision was actually made.

Two examples:
(1) I recall specifically that this WG decided that URN syntax shall 
conform to RFC 3986 URI syntax. (I cannot find a specific e-mail 
reference for it.) That much I can work with. There is material 
disagreement about whether, and to what extent, URN "semantics" either 
need to--or must not--conform to RFC 3986 URI "semantics". I have 
searched and can find no record of decision on this point. A lot of 
recent objections / elliptical decisions on things like "what is a 
resource?" and so on, have been fueled because people are throwing up 
arguments about what has been decided, when the semantics issue has 
(apparently) not been decided.

My take on this, is that URN syntax === URI syntax. Whether and to what 
extent URN semantics == URI semantics, is not a decided WG issue. 
Therefore saying "oh, the WG decided syntax but not semantics" is 
inaccurate.

Actually the semantics issue has been misunderstood. RFC 3986 pretty 
much says that a "resource" is anything that can be identified by a URI, 
so it's a circular definition. If you can name it, you can claim it. The 
end. An RFC 3986 "representation", in contrast, is an actual concrete 
computable thing, and could be (for example) a content with a media 
type. This really is a debate about nomenclature in the documents. This 
WG can repurpose the term "resource" in a URN to mean something other 
than RFC 3986, but it's confusing if we are not updating RFC 3986.

(I do recall specifically that a chair or AD stepped in a couple of 
years back and declared updates to RFC 3986 to be out of scope of this 
WG. I cannot find the reference.)

(2) RFC 2141 says that NSS is UTF-8 encoded. RFC 5198 (NETUNICODE) says 
that updated stuff SHOULD use Unicode/UTF-8. This WG is technically 
constrained to follow UTF-8 percent-encoding for NSS, and SHOULD nail 
down UTF-8 for the other parts in its purview (i.e., the query 
production). I do not believe that this WG finally made a decision on 
the point; however, the predecessor WG obviously made a decision, so we 
should consider that pretty weighty in terms of what to follow, clearly 
decide if there is a need to deviate, and be done with it.

I have set up the wiki so that existing participants and newcomers alike 
can adhere to the decisions made, with documented evidence. I hope that 
we can use this tool, or a similar tool like it.

Regards,

Sean

---

From: Andrew Newton <[email-masked]>
Date: Tue, 31 May 2016 15:31:35 +0200

Let me address a couple of points with one message:

>> *precisely* which parts of RFC 3986 are affected (and why, fwiw).

Just for my sanity, I reread
draft-ietf-urnbis-semantics-clarif-03.txt. It seems to me that this
draft does exactly the thing you have requested.

If you have found an issue with this draft in the context of updating
3986 (or any other issue), can you please start a separate thread so
we may address the issue?

> Two examples:
> (1) I recall specifically that this WG decided that URN syntax shall conform
> to RFC 3986 URI syntax. (I cannot find a specific e-mail reference for it.)
> That much I can work with. There is material disagreement about whether, and
> to what extent, URN "semantics" either need to--or must not--conform to RFC
> 3986 URI "semantics". I have searched and can find no record of decision on
> this point. A lot of recent objections / elliptical decisions on things like
> "what is a resource?" and so on, have been fueled because people are
> throwing up arguments about what has been decided, when the semantics issue
> has (apparently) not been decided.

Again, see the draft mentioned above. And note that it is a working
group document.

> (I do recall specifically that a chair or AD stepped in a couple of years
> back and declared updates to RFC 3986 to be out of scope of this WG. I
> cannot find the reference.)

I think it was stated at one of our few wg meetings. But to clarify,
we are not re-writing 3986 and tackling that entire URI space. That is
very out-of-scope.

-andy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 31 May 2016 15:39:40 +0200

> draft does exactly the thing you have requested.

It might *intend* to do it, but (a) it's very unclear what the actual 
change is, (b) whether it is needed, and (c) whether that it tries to 
change actually is consistent with what the URN spec attempts to do.

Best regards, Julian

---

From: John C Klensin <[email-masked]>
Date: Tue, 31 May 2016 11:48:23 -0400

--On Tuesday, May 31, 2016 15:39 +0200 Julian Reschke
<[email-masked]> wrote:

>> draft-ietf-urnbis-semantics-clarif-03.txt. It seems to me
>> that this draft does exactly the thing you have requested.
>> ...
> 
> It might *intend* to do it, but (a) it's very unclear what the
> actual change is, (b) whether it is needed, and (c) whether
> that it tries to change actually is consistent with what the
> URN spec attempts to do.

Julian (and Andrew), 

Just so you know (and to repeat what I've at least hinted at),
I've been looking at  draft-ietf-urnbis-semantics-clarif since
Julian's first posting on the issue to see if I could find thing
that could reasonably be improved.  I've found several [1] and
put new text into a working draft for -04 but have not posted it
pending input and direction from the co-Chairs [2].  

I don't believe those changes will satisfy Julian's concerns.
The reasons are connected to why I've been looking for
instructions from the co-chairs and summarized in Andy's note.
>From my point of view, this document updates 3986 _for URNs
only_, it is not an attempt at a general update (that should
have been quite clear from the first sentence of Section 4; -04
will be even more clear on the subject).  In principle, we could
do a paragraph by paragraph review of what portions of 3986 are
affected by that, but it would be a lot of work, it would make
this document longer and more complicated, and I don't believe
that anyone would read it except for the purpose of finding
things to quibble and pick nits about.  I see that as
potentially a huge source of further delay and not particularly
useful; if you disagree, please work with Andy to convince the
WG.  

Similar comments apply to "whether it is needed".  Before the
decisions that led, first to the "URNs are not URIs" proposal
and then to this document, the WG spent seemingly-endless months
bogged down in discussions about whether a particular mechanism
or usage was consistent with, or permitted by, 3986.  For each
case, some people argued that it was, others argued with equal
passion, that it was not.  We were not converging on subjects
that were arguably outside the WG's scope, such as whether 3986
needed work or was clear enough.   While there are technical
arguments having to do with differing layering abstractions that
I believe justify the separation, my impression of the WG's
conclusion was that we simply needed to separate ourselves from
those arguments if we were to make progress.   So, if the
question is "whether this is needed to make URN work proceed"
the answer is that the WG decided "yes" and Section 2 of 
draft-ietf-urnbis-semantics-clarif (at least -02 and later) is
intended to say that.  If the question were, instead, "can the
WG prove to the satisfaction of all readers and interpreters of
3986 than it is impossible to develop a functional URN model
that meets the needs of the communities the WG has identified
without some separation from 3986", that answer to that question
is probably "no", or at least "no within the level of energy
that exists", but I hope the WG doesn't need to do that.

best,
   john

p.s. Sean, the two typos that you spotted were repaired in the
working draft for -04 in February or earlier.  I don't remember
whether someone pointed them out to me (on or off list) or
whether I just spotted them and fixed them.  Unless directed
otherwise by WG Chairs, I generally don't post new drafts just
to fix obviously typographic and other trivial editorial errors.
But thanks for spotting them again and having me go back and
confirm the repairs.

[1]  Not a surprise.  I don't think I've ever looked, months or
years later, at a document I had finished or put aside for a
while and not found areas of possible improvement.  

[2] I believe I did say on-list that I was going to wait.

---

From: Andrew Newton <[email-masked]>
Date: Tue, 31 May 2016 19:26:28 +0200

> pending input and direction from the co-Chairs [2].

Yes, please publish it.

> useful; if you disagree, please work with Andy to convince the

Agreed.

> that exists", but I hope the WG doesn't need to do that.

Again, agreed.

-andy

---

From: John C Klensin <[email-masked]>
Date: Tue, 31 May 2016 13:48:05 -0400

--On Tuesday, May 31, 2016 19:26 +0200 Andrew Newton
<[email-masked]> wrote:

>> Julian's first posting on the issue to see if I could find
>> thing that could reasonably be improved.  I've found several
>> [1] and put new text into a working draft for -04 but have
>> not posted it pending input and direction from the co-Chairs
>> [2].
>> 
> 
> Yes, please publish it.

Ok.  As I have warned in other contexts, this is a very bad week
for me, starting later this afternoon.   I'll try to find time
to get it together and posted, but it might not be until the end
of the weekend.

thanks.
    john