Subject: [urn] 2141bis - terminology, particularly about locators, names, and URNs

From: John C Klensin <[email-masked]>
Date: Thu, 29 Dec 2016 15:38:04 -0500

Hi.

Peter and I are iterating on -10 and still expect it to be
posted before the end of the week.

I want to alert the WG to some proposed terminology changes.
Requirements for these became clear in carefully checking
through usage of terms in the draft.  In no particular order:

(1) "name" is used all over the place, both within the document,
within 3986, and elsewhere to mean several different things
and/or as a general term, often associated with a certain amount
of handwaving.  The definition in -18, which appears to assume
that the only usage is that in 3986 1.1.3, which uses it as the
name (sic) of one of the two categories of URI, the other one
being "locator".  "name" has been removed from the definition
and replaced by a caution against assuming the term has any
precise meaning.

(ii) Removal of "URL" in favor of "locator" or related
terminology didn't go as smoothly as I (and, I think, Peter)
assumed it would when Henry suggested it.  "locator URI" now
appears in the Terminology section and some other corrections
have been made for consistency, but, unless we believe that
there is a non-trivial possibility that URLs will go out of use
within the lifetime of 2141bis, we may be making a fine
distinction that is more confusing than helpful.  An alternate
strategy, which I think people who care about this should
consider (although I hope we don't need to do the work because
it would be hard to avoid errors), is to use "URL" when we mean
that and "non-URL locators" and "possibly non-URL locators" when
we don't.

(iii) -18 defined "URN" in a way that was not consistent with
usage in the rest of the document and some other places (but
that was closely related to the definition of "name" discussed
above.  The definition has been changed and a caution inserted
about other definitions and definition-less usage.

If any of the above bother people at a conceptual level, please
say so.  Otherwise, consider this an early warning of an area of
-19 that deserves attention as well as some explanation of why I
believe we need to move past the sort of overly-close reading
that causes this sort of work and the resulting questions.

best,
    john

---

From: [email-masked] (Henry S. Thompson)
Date: Fri, 30 Dec 2016 15:31:03 +0000

> and replaced by a caution against assuming the term has any

Good.

> that and "non-URL locators" and "possibly non-URL locators" when

I find the proposed use of "locator URI" quite natural: 3986 says that
some URIs are locators and some are not (independently of their URI
scheme), so it makes sense to talk about the ones that are as locator
URIs.  Juha, Lars and I all responsed positively to this aspect of
Peter's message of 14 December.  I'm not sure I see any specific reason
in the para. above for changing my mind...

ht

[Perhaps the origin of your unease is reflected in what I think is a
misunderstanding in yours of 27 December:

> As another small nit, I'm not sure where a "locator URI" is defined.
> The term certainly is not defined in 2141bis, nor does it appear in
> 3986.  I'm ok with "locator" by itself (which does have origins in
> 3986 and that is defined in Section 1.1 of 2141bis), or "URI for a
> locator".

"URI for a locator" is a pretty rare and unlikely beast, at least as I
unpack it, that is, as an identifier for an identifier.  Would adding a
very short definition in the terminology section, along the lines of

  Locator URI -- "[a URI] that, in addition to identifying a resource,
  provide[s] a means of locating the resource by describing its primary
  access mechanism (e.g., its network 'location')" [ref. 3986 1.1.3]

> I still don't fully understand why we have dropped "URL"

Primarily (IMO) because it confuses people -- common usage (3986
notwithstanding) thinks anything that looks like 'http://...' is always
a URL.

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: John C Klensin <[email-masked]>
Date: Fri, 30 Dec 2016 12:09:01 -0500

--On Friday, December 30, 2016 15:31 +0000 "Henry S. Thompson"
<[email-masked]> wrote:

>...
>> there is a non-trivial possibility that URLs will go out of
>> use within the lifetime of 2141bis, we may be making a fine
>> it would be hard to avoid errors), is to use "URL" when we
>> mean that and "non-URL locators" and "possibly non-URL
>> locators" when we don't.
 
> I find the proposed use of "locator URI" quite natural: 3986
> says that some URIs are locators and some are not
> (independently of their URI scheme), so it makes sense to talk
> about the ones that are as locator URIs.  Juha, Lars and I all
> responsed positively to this aspect of Peter's message of 14
> December.  I'm not sure I see any specific reason in the para.
> above for changing my mind...
>...

> [Perhaps the origin of your unease is reflected in what I
> think is a misunderstanding in yours of 27 December:
> 
>> As another small nit, I'm not sure where a "locator URI" is
>> defined. The term certainly is not defined in 2141bis, nor
>> does it appear in 3986.  I'm ok with "locator" by itself
>> (which does have origins in 3986 and that is defined in
>> Section 1.1 of 2141bis), or "URI for a locator".
> 
> "URI for a locator" is a pretty rare and unlikely beast, at
> least as I unpack it, that is, as an identifier for an
> identifier. 

I wasn't confused (if that be the right term), until I went back
and reread 3096 again, but that is exactly where the terminology
gets tangled up.    If you said "a locator-type URI", I wouldn't
have have a problem.  But "locator URI" sounds like a very
specific term of art that is not, IMO, justified by any obvious
reading of 3986.  I note that we could be using "name URI" in
lieu of URN, or at least the more general interpretation of
"URN" as more than the "urn:' scheme, but we don't do that and,
by removing "name" as a 2141bis definition, we remove what is,
IMO, the last vestige of that concept from 2141bis.   Again, I'm
ok if "lcoator URI" is specifically defined somewhere; the
objection is to expecting readers to figure out what it means
and what its implications are.

> Would adding a very short definition in the
> terminology section, along the lines of
> 
>   Locator URI -- "[a URI] that, in addition to identifying a
> resource,   provide[s] a means of locating the resource by
> describing its primary   access mechanism (e.g., its network
> 'location')" [ref. 3986 1.1.3]

The following appears in the preliminary versions of -19 that
have been going back and forth between Peter and myself:

   "Locator URI: A locator that is conformant to URI syntax and
   other rules of RFC 3986.  That document, at Section 1.1.3,
   appears to identify all such locators as "URLs", but this
   document attempts to be agnostic on that issue."

I don't see much reason to prefer one over the other but, in the
interest of progress, am substituting yours.  Anyone who has a
strong preference for the earlier version (the one quoted
directly above) should speak up, ideally in the next few hours
before I post -19.

> Primarily (IMO) because it confuses people -- common usage
> (3986 notwithstanding) thinks anything that looks like
> 'http://...' is always a URL.

Then, in retrospect, I would have preferred to define "URL" in
2141bis in a way that is completely consistent with 3986 and
warn against alternate definitions and interpretations, at least
within the scope of 2141bis and URNs.  Again, just in retrospect
-- I see the tradeoffs and don't propose to go back.

best,
    john

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 30 Dec 2016 10:57:27 -0700

> directly above) should speak up, ideally in the next few hours

I have a better idea: let's not define "locator URI" as a term of art. 
When we substituted "locator" for "URL" in most cases, there were a few 
places in the text where we talked about URI query components in 
relation to such locators. However, it doesn't make sense to talk about 
URI query components if the locator is not a URI, so when I 
provisionally modified the text I sought a less cumbersome phrase than 
"a URI for a locator", landing on "locator URI" as a proposed phrase 
(*not* a defined term of art). I now think that interim proposal was a 
mistake, and I would prefer that we use the phrase I started with ("a 
URI for a locator") to avoid confusion, even if it is somewhat ugly.

Peter

---

From: John C Klensin <[email-masked]>
Date: Fri, 30 Dec 2016 13:15:04 -0500

--On Friday, December 30, 2016 10:57 -0700 Peter Saint-Andre
<[email-masked]> wrote:

>>>> appears in the Terminology section and some other
>>>> corrections have been made for consistency, but, unless we
>>>> believe that there is a non-trivial possibility that URLs
>>>> will go out of use within the lifetime of 2141bis, we may
>>>> be making a fine distinction that is more confusing than
>>>> helpful.  An alternate strategy, which I think people who
>>>> care about this should consider (although I hope we don't
>>>> need to do the work because it would be hard to avoid
>>>> errors), is to use "URL" when we mean that and "non-URL
>>>> locators" and "possibly non-URL locators" when we don't.
>> 
>>> (independently of their URI scheme), so it makes sense to
>>> talk about the ones that are as locator URIs.  Juha, Lars
>>> and I all responsed positively to this aspect of Peter's
>>> message of 14 December.  I'm not sure I see any specific
>>> reason in the para. above for changing my mind...
>>> ...
>> 
>> I wasn't confused (if that be the right term), until I went
>> back and reread 3096 again, but that is exactly where the
>> terminology gets tangled up.    If you said "a locator-type
>> URI", I wouldn't have have a problem.  But "locator URI"
>> sounds like a very specific term of art that is not, IMO,
>> justified by any obvious reading of 3986.  I note that we
>> could be using "name URI" in lieu of URN, or at least the
>> more general interpretation of "URN" as more than the "urn:'
>> scheme, but we don't do that and, by removing "name" as a
>> 2141bis definition, we remove what is, IMO, the last vestige
>> of that concept from 2141bis.   Again, I'm ok if "lcoator
>> URI" is specifically defined somewhere; the objection is to
>> expecting readers to figure out what it means and what its
>> implications are.
>> 
>>    "Locator URI: A locator that is conformant to URI syntax
>>    and other rules of RFC 3986.  That document, at Section
>>    1.1.3, appears to identify all such locators as "URLs",
>>    but this document attempts to be agnostic on that issue."
>> 
>> I don't see much reason to prefer one over the other but, in
>> the interest of progress, am substituting yours.  Anyone who
>> has a strong preference for the earlier version (the one
>> quoted directly above) should speak up, ideally in the next
>> few hours before I post -19.
> 
> I have a better idea: let's not define "locator URI" as a term
> of art. When we substituted "locator" for "URL" in most cases,
> there were a few places in the text where we talked about URI
> query components in relation to such locators. However, it
> doesn't make sense to talk about URI query components if the
> locator is not a URI, so when I provisionally modified the
> text I sought a less cumbersome phrase than "a URI for a
> locator", landing on "locator URI" as a proposed phrase (*not*
> a defined term of art). I now think that interim proposal was
> a mistake, and I would prefer that we use the phrase I started
> with ("a URI for a locator") to avoid confusion, even if it is
> somewhat ugly.

Wfm, but I note Henry appears to not like "URI for a locator",
or at least some variations on it.   He apparently believes
"locator URI" is obvious and a reference to the "locator" part
of 3986 1.1.3; I don't and see it as acceptable only as a term
of art.

Again, part of my problem is that there are URIs that are not
locators and not names (although not in 3986), URIs that are
both locators and names, and, of course, locators (and names)
that are not URIs.  There are also things whose classifications
require effort outside the scope of URNBIS: Juha, Lars, and
their colleagues would tell us that Dewey Decimal Numbers are a
classification system, perhaps not even a set of identifiers and
definitely not a system with single centralized (or topically
delegated) management.  But there are probably more people in
the world who think of them as locators than there are people
who think that "URI" and "URL" are equivalent terms and/or that
anything that "looks like" 'http:...' is inherently a URL.

So how would you like to proceed?  I'm partway through the draft
of -19 I was going to touch up as needed and post today, but the
only changes I've made so far are to substitute Henry's text for
mine as discussed above and to start removing the CREFs we've
used to discuss issues with each other.  Do you want the pen
back to fix the "locator URI" instances?  If you do that, I'm
probably going to run out of time to do/finish a final review
and post today, but we could delay the posting schedule until
tomorrow or Sunday.  Or I could just post what we have with a
note about fixing that later.

While I think we can still get a draft posted this weekend, I'd
really like the WG to consider how much effort this, and
similar, efforts are worth relative to the value of getting
finished.

best,
    john

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 30 Dec 2016 11:28:56 -0700

On 12/30/16 11:15 AM, John C Klensin wrote:
> of 3986 1.1.3;

When it comes to URIs, nothing is obvious. ;-)

> I don't and see it as acceptable only as a term
> of art.

I would prefer to avoid coining unneeded terminology and potentially 
causing more confusion that we already have in this space. That's why 
I'd prefer "URI for a locator" or "URI that is a locator".

Henry, can you not live with one of those phrases? (cf RFC 7282, §2)

> note about fixing that later.

If you finish your work and send me the source file, I will make these 
few little fixes and post -19 later today or early tomorrow.

> similar, efforts are worth relative to the value of getting

I would like us all to consider -19 as the version that undergoes 
working group last call so that ideally we can finish this work before 
the next IETF meeting in late March.

Peter

---

From: [email-masked] (Henry S. Thompson)
Date: Fri, 30 Dec 2016 19:36:32 +0000

> Henry, can you not live with one of those phrases? (cf RFC 7282, §2)

I can certainly live with "URI that is a locator".

(I have to say that I'm still worried that you seem to think that those
two quoted phrases mean the same thing -- "a URI for a locator" means,
to me, a URI for (some identifier which is itself) a locator, but I
_hope_ that worry doesn't matter if we agree on "URI that is a
locator".)

ht

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 30 Dec 2016 12:57:33 -0700

> I can certainly live with "URI that is a locator".

That's my preferred phrase as well.

> _hope_ that worry doesn't matter if we agree on "URI that is a

I had not picked up on the subtlety you've pointed out, but now that 
you've done so I agree even more strongly that it's best to use the 
phrase "URI that is a locator" (which is the phrasing in the working 
version I've sent to John; he now holds the pen and will be posting it 
in the next 24 hours or so).

Peter