Subject: Re: [urn] Terminology issue: 'URL'

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 2 Dec 2016 12:17:19 -0700

On 11/17/16 8:31 AM, Henry S. Thompson wrote:
> TL;DR: Replace 'resolve to a URL' with 'resolve to a Locator'
> throughout

I have no deep objections to this. See below on a few points.

> The current draft (correcly, IMO) defines 'URN' as "A name that is a
> member of a URN namespace", that is, a name of the form urn:nid:...
>
> It doesn't list 'URL' as a term, but does say, towards the end of
> section 1.2 *Terminology*
>
>   this document uses the term Uniform Resource Locator (URL), rather
>   than the generic term Uniform Resource Identifier (URI), to refer to
>   locators; see also Section 1.1.3 of [RFC3986].
>
> I think this either partakes of, or at least encourages, a confusion
> between properties of URI schemes and properties of individual URIs,
> thereby missing the key point of the referenced section of 3986:
>
>   An individual scheme does not have to be classified as being just
>   one of "name" or "locator".  Instances of URIs from any given scheme
>   may have the characteristics of names or locators or both... [1]
>
> That is, although many http: URIs are locators, some are names (and
> some are both), and although all urn: URIs are names, some may be
> locators as well.
>
> A URI is a locator if it can be dereferenced, if, for example "[there
> are] services related to the identified resource, such as
> ... delivering a document object from a convenient source" [2].
> That's not a property of the URI as such, but of its context of use
> and the services available therefrom.  As that quote indicates, some
> URNs may have that property in some circumstances.
>
> On the other hand, just because a resolution service provides you with
> an http: URI when invoked on a URN does not mean you are now on your
> way to a document object, because that http: URI may itself be a name
> and not a locator.
>
> So, I'd suggest that you add a new term to the term list in section
> 1.2, as follows:
>
>    Locator: A retrieval-enabled URI
>
> and use that term in most of the places where 'URL' is currently used.

RFC 3986 §1.1.3 says:

    The
    term "Uniform Resource Locator" (URL) refers to the subset of URIs
    that, in addition to identifying a resource, provide a means of
    locating the resource by describing its primary access mechanism
    (e.g., its network "location").

And §1.2.2 says:

    When URIs are used within information retrieval systems to identify
    sources of information, the most common form of URI dereference is
    "retrieval": making use of a URI in order to retrieve a
    representation of its associated resource.

I'm wondering if we want to use slightly more general terminology than 
your proposal of "a retrieval-enabled URI", because perhaps "access" is 
the more general term (cf. also in §1.2.2 "URI 'resolution' is the 
process of determining an access mechanism").

Also, do we want to define locators in terms of URIs, given that we 
don't define names in terms of URIs or URNs?

Perhaps:

Locator: an identifier that provides a means a locating a resource

> The penultimate paragraph of section 1.2 would then need to read
> something along these lines:
>
>    This document uses the terms "resolution" and "resolver" in roughly
>    the sense in which they were used in the original discussion of
>    architectural principles for URNs [RFC2276], i.e., "resolution" is
>    the act of supplying services related to the identified resource,
>    such as translating the persistent URN into one or more current
>    Locators for the resource, delivering metadata about the resource
>    in an appropriate format, or even delivering a document object from
>    a convenient source without requiring further intermediaries.  At
>    the time of this writing, resolution services are described in
>    [RFC2483].
>
>    Section 1.1.3 of [RFC3986] helpfully observes that "A URI can be
>    ... classified as a locator, a name, or both" and goes on to define
>    locators as URIs which "provide a means of locating the resource
>    [which they identify] by describing its primary access mechanism
>    (e.g., its network 'location')".  This is what we mean by
>    'retrieval-enabled' above, and we use the term 'Locator' to refer
>    to the class of individual URIs which have this property.

Something along those lines, yet.

> A few places where 'URL' is effectively used as shorthand for
> "non-urn-scheme-URI' will require some more explicit rewriting, e.g.
>
>   The URN r-component has no syntactic counterpart in URLs
>
>  -->
>
>   The URN r-component has no syntactic counterpart in any other URI
>   scheme that we are aware of

Yes.

> The overall point here is that RFCs are meant for the entire
> community, and it's at best misleading for an RFC to redefine a widely
> used term to have a meaning other than the one already in wide (and
> documented) use.  I do of course understand that there exists a
> sub-community within which this distinct meaning is understood and
> intended, but this spec can and should reach out more widely.  So note
> that I'm _not_ proposing that the spec should use 'URL' as defined in
> 3986, but rather use 'URN' to mean urn:nid:..., as it does already, to
> use 'URI' as the generic, and _not to use 'URL' at all_.

I do agree that "locator" is better here, for sure.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 2 Dec 2016 12:20:08 -0700

> Locator: an identifier that provides a means a locating a resource

Sorry, I meant...

    Locator: an identifier that provides a means of accessing a resource

My apologies for trying to do two things at once here...

Peter

---

From: John C Klensin <[email-masked]>
Date: Sat, 03 Dec 2016 13:31:50 -0500

Without thinking about it a lot, I think I am ok with these
changes and think they probably improve things.  However, it is
worth keeping in mind that RFC 3986 is not completely clear
about some of the distinctions we are now trying to make (even
if a number of people read it the same way) and that at least
one of its authors has a very negative attitude toward URNs.
Especially since I think we have general agreement that this WG
should not try to update or otherwise formally clarify 3986, I
hope that future changes along these lines can be explicitly
justified in terms of their importance to finishing our URN
specs.

    john

--On Friday, December 02, 2016 12:17 -0700 Peter Saint-Andre
<[email-masked]> wrote:

>> The current draft (correcly, IMO) defines 'URN' as "A name
>> that is a member of a URN namespace", that is, a name of the
>> form urn:nid:...
>> 
>> It doesn't list 'URL' as a term, but does say, towards the
>> end of section 1.2 *Terminology*
>> 
>>   this document uses the term Uniform Resource Locator (URL),
>>   rather than the generic term Uniform Resource Identifier
>>   (URI), to refer to locators; see also Section 1.1.3 of
>>   [RFC3986].
>> 
>> I think this either partakes of, or at least encourages, a
>> confusion between properties of URI schemes and properties of
>> individual URIs, thereby missing the key point of the
>> referenced section of 3986:
>> 
>>   An individual scheme does not have to be classified as
>>   being just one of "name" or "locator".  Instances of URIs
>>   from any given scheme may have the characteristics of names
>>   or locators or both... [1]
>> 
>> That is, although many http: URIs are locators, some are
>> names (and some are both), and although all urn: URIs are
>> names, some may be locators as well.
>> 
>> A URI is a locator if it can be dereferenced, if, for example
>> "[there are] services related to the identified resource,
>> such as ... delivering a document object from a convenient
>> source" [2]. That's not a property of the URI as such, but of
>> its context of use and the services available therefrom.  As
>> that quote indicates, some URNs may have that property in
>> some circumstances.
>> 
>> On the other hand, just because a resolution service provides
>> you with an http: URI when invoked on a URN does not mean you
>> are now on your way to a document object, because that http:
>> URI may itself be a name and not a locator.
>> 
>> So, I'd suggest that you add a new term to the term list in
>> section 1.2, as follows:
>> 
> I'm wondering if we want to use slightly more general
> terminology than your proposal of "a retrieval-enabled URI",
> because perhaps "access" is the more general term (cf. also in
> §1.2.2 "URI 'resolution' is the process of determining an
> access mechanism").
> 
> Also, do we want to define locators in terms of URIs, given
> that we don't define names in terms of URIs or URNs?
> 
> Perhaps:
> 
>> The penultimate paragraph of section 1.2 would then need to
>> read something along these lines:
>> 
>>    This document uses the terms "resolution" and "resolver"
>>    in roughly the sense in which they were used in the
>>    original discussion of architectural principles for URNs
>>    [RFC2276], i.e., "resolution" is the act of supplying
>>    services related to the identified resource, such as
>>    translating the persistent URN into one or more current
>>    Locators for the resource, delivering metadata about the
>>    resource in an appropriate format, or even delivering a
>>    document object from a convenient source without requiring
>>    further intermediaries.  At the time of this writing,
>>    resolution services are described in [RFC2483].
>> 
>>    Section 1.1.3 of [RFC3986] helpfully observes that "A URI
>>    can be ... classified as a locator, a name, or both" and
>>    goes on to define locators as URIs which "provide a means
>>    of locating the resource [which they identify] by
>>    describing its primary access mechanism (e.g., its network
>>    'location')".  This is what we mean by 'retrieval-enabled'
>>    above, and we use the term 'Locator' to refer to the class
>>    of individual URIs which have this property.
> 
>>   The URN r-component has no syntactic counterpart in any
>>   other URI scheme that we are aware of
> 
> Yes.
> 
>> community, and it's at best misleading for an RFC to redefine
>> a widely used term to have a meaning other than the one
>> already in wide (and documented) use.  I do of course
>> understand that there exists a sub-community within which
>> this distinct meaning is understood and intended, but this
>> spec can and should reach out more widely.  So note that I'm
>> _not_ proposing that the spec should use 'URL' as defined in
>> 3986, but rather use 'URN' to mean urn:nid:..., as it does
>> already, to use 'URI' as the generic, and _not to use 'URL'
>> at all_.
> 
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: [email-masked] (Henry S. Thompson)
Date: Sun, 04 Dec 2016 14:07:29 +0000

Peter Saint-Andre writes:

> your proposal of "a retrieval-enabled URI", because perhaps "access"
> is the more general term (cf. also in §1.2.2 "URI 'resolution' is the

OK.

> Perhaps:
>
> Locator: an identifier that provides a means [of accessing] a resource

OK.

Thanks, and yes, John, I do think this "contributes to finishing our URN
specs", because it will I hope forestall another round of argument.

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: Peter Saint-Andre <[email-masked]>
Date: Mon, 5 Dec 2016 22:59:38 -0800

Hi Henry, thanks for the continued reviews and feedback. Comments inline.

On 11/17/16 5:22 AM, Henry S. Thompson wrote:
> There are two parts to this
>
>   External: the current use of these terms is incompatible with the
>             3986
>
>   Internal: The definitions and uses of 'abstract designator' are
>             inconsistent
>
> TL;DR:
>
>  1) 3986 distinguishes between 'resource' and 'representation', and so
>     should we;
>
>  2) The term 'abstract designator' should be dropped.
>
> Part 1 -- 3986 incompatibility
>
> URNs are URIs, that is, Uniform Resource Identifiers.  Every URI
> identifies something, as the name implies, and 3986 uses the term
> 'resource' as the cover term for _anything_ that is identified by a
> URI.  It explicitly places _no_ constraint on what a URI can identify.
> In other words, anything can be a resource: real, imaginary, abstract,
> concrete, individual, set (finite or infinite), ...
>
> The current draft does not define the term 'resource'.  It often uses
> it in ways which are consistent with 3986's definition, for example in
> phrases such as "resource identifier" (lower case in original),
> "identified resource", "The kinds of resources identified by URNs" and
> "persistent identification of resources".  This longer exposition is
> also pretty much compatible with 3986:
>
>   URNs (either individually or entire URN namespaces as defined below)
>   that do not resolve to URLs at all or that resolve to metadata or
>   non-Internet objects are among URN use cases explicitly permitted by
>   this specification; each leaves the concept of "resolution" somewhat
>   more abstract and difficult than the simple case of resolution to a
>   URL. [1.1, 2nd para]
>
> But the current draft also uses 'resource' in many ways which are
> clearly incompatible with 3986.  3986 is very careful to distinguish
> between the resource _identified_ by a URI on the one hand, and
> _representations_ of that resource and _metadata_ about it on the
> other.  The latter are much more concrete, and the kind of thing you
> can get your hands on/interact with (see section 1.2.2 of 3986 [1]).
> Some examples of where the current draft is incompatible with this
> position:
>
>   "A URN [may] be ... an abstract designator that is persistent but
>   that does not identify a resource" [Abstract, Introduction]
>   Per 3986, _all_ URIs identify something, which it calls a resource.

Good catch.

>   "media type of those resources" [2.3.3, next-to-last para]
>   Per 3986, resources do not in general have media types,
>   _representations_, e.g. as returned in messages, have media types.
>
> I don't think this will be hard to fix -- there's already a
> distinction between what is identified and the outcome of a resolution
> attempt, as well as between resolution and retrieval, and the wording
> around these just needs to be tightened up a bit, with the word
> 'resource' used a bit less.  Whether the idea behind 3986's word
> 'representation' needs to be imported, along with the word, will I
> think be an editorial decision to be made in the course of the
> tightening-up effort.

Yes, that all seems right.

> Part 2 -- 'abstract designator'

As a bit of background, I would say that we introduced the term 
'abstract designator' to describe names that purely identify resources; 
that is, the intent is that such a name will never be resolved (i.e., 
there is no access mechanism associated with the name) and, more 
specifically, that at no time will it be possible to retrieve a 
representation of the identified resource.

> Here are some examples of the use of this term which taken together
> leave me confused as to what is meant:
>
>   A URN [may] be ... an abstract designator that is persistent but
>   that does not identify a resource [Abstract, Introduction]

As you pointed out, this is wrong: every URI identifies a resource.

>   If there are or will be resolution services available for a URN,
>   this document calls the URN a "resource identifier" in roughly the
>   sense that term is used in [RFC3986].  If there is no intention to
>   provide any resolution services, and the distinction is important,
>   this document calls the URN an "abstract designator". [1.2, near the
>   end]

This suffers from the same problem you have pointed out regarding 
resource identification.

>   If the URN does not resolve to a URL (i.e., is an abstract
>   designator) or if it resolves directly to an object or a non-URL
>   resource designator [2.3.2, 3rd para] [note that this is the only
>   use of the phrase 'resource designator' in the draft]
>
>   If the URN does not resolve to a URL (e.g., is an abstract
>   designator) [2.3.3, 2nd para]
>
>   because a URN might not specify the location of a resource or even
>   point indirectly to one [4.1, 2nd para]
>
>   (e.g., URNs within some URN namespaces are intended to act as
>   abstract designators and thus are not intended to be resolved)
>   [6.4.6 1st para]
>
>   Clarified that there can be URNs that neither resolve to URLs nor
>   are abstract designators. [F.8., 6th bullet.  I _think_ this refers
>   to the quote above from section 2.3.2]
>
> It is often argued that 3986 implies that there are two in-principle
> possibilities for any URI (including URNs) as far as resolution is
> concerned (where the possibility that resolution may involve more than
> one step is assumed):
>
>   1) Resolution services are or could be provided, but the results of
>      resolution necessarily consist only of metadata about the
>      identified resource, that is, no _representation_ of that
>      resource is or could be available;

I'd like to understand more about what 'metadata' means here.

RFC 3986 says the following in Section 1.2.2:

    A "representation" is a
    sequence of octets, along with representation metadata describing
    those octets, that constitutes a record of the state of the resource
    at the time when the representation is generated.

Here, 'metadata' mean metadata about the representation. If there is no 
representation, there can be no representation metadata.

However, later in the same paragraph we find this:

    Depending on the protocols used to perform the retrieval,
    additional information might be supplied about the resource (resource
    metadata) and its relation to other resources.

This might indicate that RFC 3986 envisions a distinction between 
representation metadata (metadata describing the octets, as in MIME, see 
Section 5.1.2) and resource metadata (metadata describing the resource 
itself - perhaps an example would be Dublin Core information about 
authors, publishers, licenses, and the like). However, even the notion 
of resource metadata here seems to be tied to retrieval.

>   2) Resolution services are or could be provided, and the results of
>      resolution may in practice and could in principle include one or
>      more representations.
>
> However I think the above quotes from the current draft taken together
> provide evidence that it considers there to be a
> _threefold_ distinction, adding
>
>   3) No resolution services of any kind are provided or envisaged;

Yes.

> However the quotes also demonstrate that no consistent interpretation
> for the term 'abstract designator', e.g. as (1) or (3) (or their union),
> is possible.

Impossible is a strong word. :-)

I agree that the current text is not fully consistent with RFC 3986 
(e.g., with regard to all URIs identifying resources), and perhaps is 
not internally consistent. That doesn't necessarily imply that no 
consistent intepretation of the term 'abstract designator' is possible.

As noted, we coined this term to refer to precisely your (3).

The examples that I personally had in mind were XML namespaces, such as 
"urn:ietf:params:xml:ns:xmpp-sasl" in RFC 6120. Although I suppose one 
could make the argument that a "representation" of an XML namespace 
could take the form of a W3 XML Schema or a RELAX NG schema, that seems 
like a stretch to me.

An even more abstract example is feature advertisement of the kind we 
use in XMPP:

<feature var='urn:xmpp:hash-function-text-names:sha-256'/>

(See http://xmpp.org/extensions/xep-0300.html for details.)

I suppose you could say that the foregoing URN identifies a "resource" 
of supporting the specified hash function. Here it's even clearer to me 
that there is no representation and that no resolution is ever intended.

The service names defined in RFC 5031 and RFC 7462 seem similar - they 
are just identifiers of features that an endpoint can support.

> Although at first it may seem that the most likely intended meaning
> for the term is (3), in fact I don't think this makes any sense.  An
> identifier about which _no_ information is provided is useless, or
> rather, it makes no sense to make it available, as no-one when
> encountering it will be able to make anything of it.  Registering a
> URN namespace must surely imply the intent of providing _some_
> information about the resources identified by URNs which use it, even
> if that is only metadata to the effect that all interesting
> information about such resources is available offline in such-and-such
> a way.

For the examples adduced above, the URNs most definitely have meaning, 
and that meaning is specified in the relevant protocol specification. 
Are you suggesting that the appropriate metadata here is a pointer to 
the specification in which the meaning of the URN is defined?

> Or, more simply, the difference between (1) and (3) is surely a
> contingent one, bearing in mind the timescales over which we expect
> URNs to persist.  It would be an odd namespace indeed for which the
> defining documents mandated that no-one could ever implement a
> resolution service providing useful metadata!

Well, it seems to me that the arrow of meaning for such namespaces 
points in the other direction. To my mind, immersed as it is in the 
practicalities of deploying running code for communication systems, it 
would be an odd resolution service indeed that attempts to "resolve" 
urn:xmpp:hash-function-text-names:sha-256 to XEP-0300 or to "resolve" 
urn:alert:service:call-waiting to RFC 7462. Instead, these URNs are used 
as, well, abstract designators of potentially supported features in XMPP 
or SIP; i.e., XMPP or SIP user agents and servers know exactly what 
these URNs mean (because the software developers have read the relevant 
specifications), but I see no reason for some generic URN parser to 
resolve them. Not that anyone could stop them from implementing such 
resolution, but there's no good reason to do so as far as I can see. 
Call that "contingent" if you would like.

> What I think is the key distinction being implicitly appealed to is
> the _representability_ of resources in a namespace.  The draft appears
> to use the acronym 'URL' to _mean_ a URI which is (at least in
> principle) resolvable to a representation.

To your point in another thread, that would be "locator".

> But I'd much prefer if the
> difference between (2) vs (1) union (3) were _not_ equated with
> "resolve(s) to a URL", because
>
>   a) For 3986 and many users of URLs (understanding 'URL' to mean
>      'non-URN URI'), many URLs identify resources for which no
>      representations are possible;
>
>   b) There are perfectly good ways which are _not_ mediated by URLs at
>      all to access representations for resources.

Agreeing to all of that, it still seems to me that abstract designators 
are useful and that the concept captures something that is different 
from your (1) and (2).

> So in summary I'm arguing that the only non-contingent property worth
> naming with 'abstract' or something like it is a property of
> _resources_, not of URNs.  As such it's not really relevant to this
> specification.
>
> My most-preferred outcome: just remove the term 'abstract designator'
> altogether, and only discuss briefly the contingent nature of
> resolution, as sometimes yielding metadata, and sometimes (perhaps
> indirectly) access to representations.

I'm probably being obtuse, but I still don't see what the resource 
metadata is for urn:xmpp:hash-function-text-names:sha-256 or 
urn:alert:service:call-waiting. Is it all and only the specification in 
which the name is defined?

Peter

---

From: "Hakala, Juha E" <[email-masked]>
Date: Wed, 7 Dec 2016 09:09:06 +0000

Hello, 

a few comments inline below. 

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
> Sent: 6. joulukuuta 2016 9:00
> To: Henry S. Thompson <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [urn] Terminology -- 'resource' and 'abstract designator'
> 

You say below that resources do not in general have media types. If that is the case, then there is a constraint on what a URI can identify if identification of representations (which do have a media type) is not covered in the URI syntax as well. More about this below.  

Whatever general reservations I may have about RFC 3986, I have no problem with using the RFC 3986 terminology in RFC2141bis. Communities using URNs will in any case map the URN terminology from the URN syntax specification and other IETF documents to whatever terms they are using internally. Such terminological mappings may be a bit awkward, but that should have no impact on the URN usage within these domains. 

Just to give you an example, library community does not use and will not use terms "resource" and "representation". We have works, expressions, manifestations and items. I assume (for now) that "resource" covers the first three of these, and representation equals item. Works are immaterial (Hamlet, the original text in English) and so are expressions which are for instance translations of works. Manifestations are physical or digital embodiments of works and expressions. 

There are international standard identifiers for all of these resources. We have also standard identifiers for metadata records describing these resources, and it is fine with me to say that these metadata records are resources as well. And there are standard identifiers for authors like Shakespeare, and publishers (and all the other organizations out there). Calling these natural and legal persons resources within this particular context is confusing, but we can deal with it. There are also identifiers for subject headings (literature - Medieval - English) and place names (Stratford-Upon-Avon) and OK, we can think that they (and definitely metadata records describing them) are resources as well.

One area where RFC 3986 is a bit restrictive is that we have standard identifiers for representations as well. We can identify items, that is, individual copies of a (printed) book. It is also possible and sometimes necessary to give different persistent identifiers to, say, PDF version of Hamlet in English, available from different sources (publisher, legal deposit collection in the national library, open repository at the university, and so on).       

So in order to be flexible enough for libraries, RFC 3986 and RFC2141bis should talk about both resource identifiers and representation identifiers. But we can do without the latter in 2141bis. From our point of view the terminology used in RFC 3986 (resources and representations) is far too simple, but using it in URN context should not be a problem, as long as libraries can still use their own, more fine grained terminology in namespace registration requests. For instance, it would not be meaningful to say that ISBNs are for book resources (in RFC 3986 sense), they are for manifestations of books.  
 
> >   more abstract and difficult than the simple case of resolution to a

It is important to say that URN resolution may not always produce the identified resource itself, but related resources such as bibliographic metadata record describing the resource (or metadata record describing rights information about the resource).  The result can be URL, but not a URL of the identified resource, but of something else.   

> > can get your hands on/interact with (see section 1.2.2 of 3986 [1]).

What exactly do you mean by "getting your hands on"? If we assume for a moment that the PDF version of a book is a resource, then is a particular copy of that book on e.g. the national library of Finland's legal deposit collection a representation? And a back-up copy in a dark archive another one? Our PDF copy might have URN:NBN assigned by the library, while a publisher might have a DOI for another representation of  the same resource on the publisher's server. So are these copies then different resources, or is RFC 3986 just plain wrong?  

And if the PDF version of a book is a representation, how can we extend URN scope to identification of not only representations, but also to copies of those representations in different locations? 

> >   Per 3986, _all_ URIs identify something, which it calls a resource.

+ 1, from RFC2141bis point of view. 

> >   _representations_, e.g. as returned in messages, have media types.

Standard identifiers the library community has been using for decades identify things that do have a media type, such as books in PDF, or audio in MP3. Media type is important, since usually different representations (PDF, ODF, HTML versions of a book) do get different identifiers. 

The only resources (in the RFC 3986 sense) which the libraries deal with are what we call works and expressions, which are immaterial and do not have a media type. But since we deal more with manifestations it would be totally impossible for libraries to accept a specification which does not allow identification of things which do have a media type.   

> Yes, that all seems right.

As far as I am concerned, RFC3986 does have some issues with resources and representations which seem to become more apparent when we apply these terms in the real world (at least as libraries see them). But my suggestion is to not to dig too deep in possible problems in the URI syntax problems, just assume that all is well, talk about resources only in the URN syntax specification and let communities use whatever terms they are used to and identify whatever they need to identify in their own namespaces. 
  
Best regards, 

Juha 

> As a bit of background, I would say that we introduced the term 'abstract
> designator' to describe names that purely identify resources; that is, the
> intent is that such a name will never be resolved (i.e., there is no access
> mechanism associated with the name) and, more specifically, that at no time
> will it be possible to retrieve a representation of the identified resource.
> 
> This suffers from the same problem you have pointed out regarding resource
> identification.
> 
> itself - perhaps an example would be Dublin Core information about authors,
> publishers, licenses, and the like). However, even the notion of resource
> metadata here seems to be tied to retrieval.
> 
> > provide evidence that it considers there to be a _threefold_
> > distinction, adding
> >
> > for the term 'abstract designator', e.g. as (1) or (3) (or their
> > union), is possible.
> 
> I agree that the current text is not fully consistent with RFC 3986 (e.g., with
> regard to all URIs identifying resources), and perhaps is not internally
> consistent. That doesn't necessarily imply that no consistent intepretation of
> the term 'abstract designator' is possible.
> 
> An even more abstract example is feature advertisement of the kind we use
> in XMPP:
> 
> of supporting the specified hash function. Here it's even clearer to me that
> there is no representation and that no resolution is ever intended.
> 
> The service names defined in RFC 5031 and RFC 7462 seem similar - they are
> just identifiers of features that an endpoint can support.
> 
> Are you suggesting that the appropriate metadata here is a pointer to the
> specification in which the meaning of the URN is defined?
> 
> Well, it seems to me that the arrow of meaning for such namespaces points
> in the other direction. To my mind, immersed as it is in the practicalities of
> deploying running code for communication systems, it would be an odd
> resolution service indeed that attempts to "resolve"
> urn:alert:service:call-waiting to RFC 7462. Instead, these URNs are used as,
> well, abstract designators of potentially supported features in XMPP or SIP;
> i.e., XMPP or SIP user agents and servers know exactly what these URNs
> mean (because the software developers have read the relevant
> specifications), but I see no reason for some generic URN parser to resolve
> them. Not that anyone could stop them from implementing such resolution,
> but there's no good reason to do so as far as I can see.
> Agreeing to all of that, it still seems to me that abstract designators are useful
> and that the concept captures something that is different from your (1) and
> (2).
> 
> I'm probably being obtuse, but I still don't see what the resource metadata is
> for urn:xmpp:hash-function-text-names:sha-256 or urn:alert:service:call-
> waiting. Is it all and only the specification in which the name is defined?
> 
> Peter
> 
>

---

From: [email-masked] (Henry S. Thompson)
Date: Wed, 07 Dec 2016 12:15:53 +0000

[Prolog: I've been avoiding FRBR [1] terminology, with which I am familiar,
because although as you say the information science community knows it
very well, the web community does not.

And there's an interesting intellectual discussion to be had about which
of FRBR's 'manifestation' or 'item' is closer to 3986's
'representation', but I think we can bring urnbis to completion without
engaging further with that question and the many interesting issues
which surround it.]

[Disclaimer: The above notwithstanding, and with respect, I don't think
any of what follows actually impacts on the discussion of what, if
anything, needs to change in urnbis -- for that, see my forthcoming
reply to Peter.]

Hakala, Juha E writes:

> [Peter Saint-Andre wrote]
> You say below that resources do not in general have media types. If
> that is the case, then there is a constraint on what a URI can
> identify if identification of representations (which do have a media
> type) is not covered in the URI syntax as well. More about this below.

You're right, of course -- 'in general' doesn't mean 'always'.  It is
however actually quite rare in practice for a representation as such to
have a distinct URI: from the 3986 perspective a representation is what
you get in a message, the outcome of a retrieval request for a URI for a
resource that _has_ a representation.

Even in the (apparently) simple case of, say, the particular online item
corresponding to the PDF manifestation of the FRBR report [1] on some
IFLA server somewhere, 3986 would call what [1] identifies a resource,
more-or-less corresponding to the 2008 English expression of the work.
The manifestation has what you might call a 'native' media type
(application/pdf in this case), which is reproduced as representation
metadata in any successful HTTP Response message in reply to an HTTP GET
Request to that server for that URI. [Note: this does _not_ claim to be
a definitive answer to the question of how to deploy FRBR in the case of
web-hosted artefacts, see disclaimer above.  I believe the point
relevant to urnbis here is independent of exactly which FRBR-defined
terms should be applied to which 3986-defined terms]

Berners-Lee has used the term *information resource* (see AWWW [2]) for
resources like this, that is, resources "all of [whose] essential
characteristics can be conveyed in a message."

There's nothing in 3986 or elsewhere to rule _out_ creating a URI for a
resource which one might describe as "the particular byte-sequence
conforming to the application/pdf media type and corresponding to the
2008 edition of the FRBR report which was transmitted from 178.18.86.42
to 129.215.25.32 beginning at 2016-12-07 11:26:55 GMT in response to a
retrieval request for
http://www.ifla.org/files/assets/cataloguing/frbr/frbr_2008.pdf".

You could then make assertions about that particular representation as
identified by such a URI (for example that it consisted of 1336355
bytes, was expressed using PDF-1.4, that it had not been compressed for
transmission, that it took 2.1 seconds to be transmitted, etc.), some,
but not (necessarily) all of which would also be true of the item on the
server.  But it _would_ (again quoting 3986) be "a record of the state
of [that] resource at the time when [that] representation [was]
generated".

> Just to give you an example, library community does not use and will
> not use terms "resource" and "representation". We have works,
> expressions, manifestations and items. I assume (for now) that
> "resource" covers the first three of these, and representation equals
> item. Works are immaterial (Hamlet, the original text in English) and
> so are expressions which are for instance translations of
> works. Manifestations are physical or digital embodiments of works and
> expressions.

That's one possible version of the mapping, I agree, although not quite
the same as what I outlined above.

> One area where RFC 3986 is a bit restrictive is that we have standard
> identifiers for representations as well. We can identify items, that
> is, individual copies of a (printed) book. It is also possible and
> sometimes necessary to give different persistent identifiers to, say,
> PDF version of Hamlet in English, available from different sources
> (publisher, legal deposit collection in the national library, open
> repository at the university, and so on).

As I hope is clear from the extended example above, no problem with
that.  It's just that 3986 doesn't call those things representations,
they are resources too.

> So in order to be flexible enough for libraries, RFC 3986 and
> RFC2141bis should talk about both resource identifiers and
> representation identifiers.

Indeed, since they can all have URIs, they are all resources.

>  But we can do without the latter in 2141bis. From our point of view
> the terminology used in RFC 3986 (resources and representations) is
> far too simple, but using it in URN context should not be a problem,
> as long as libraries can still use their own, more fine grained
> terminology in namespace registration requests. For instance, it would
> not be meaningful to say that ISBNs are for book resources (in RFC
> 3986 sense), they are for manifestations of books.

Just fine.

> It is important to say that URN resolution may not always produce the
> identified resource itself, but related resources such as
> bibliographic metadata record describing the resource (or metadata
> record describing rights information about the resource).  The result
> can be URL, but not a URL of the identified resource, but of something
> else.

>From the 3986 perspective, _no_ resolution _ever_ produces the
identified resource.  Resolution by definition produces a
representation.  Whether it's a representation _of the (state of the)
resource_, or of resource metadata, is a contingent question.
Berners-Lee would say that the former (a representation of the resource)
is _only_ possible for *information resources*.

> What exactly do you mean by "getting your hands on"? If we assume for
> a moment that the PDF version of a book is a resource, then is a
> particular copy of that book on e.g. the national library of Finland's
> legal deposit collection a representation? 

No, a resource.

> And a back-up copy in a dark archive another one? 

No, a resource.

> Our PDF copy might have URN:NBN assigned by the library, while a
> publisher might have a DOI for another representation of the same
> resource on the publisher's server. So are these copies then different
> resources, or is RFC 3986 just plain wrong?

Different resources.

> And if the PDF version of a book is a representation, how can we
> extend URN scope to identification of not only representations, but
> also to copies of those representations in different locations?

Not a representation, so not a problem.

> Standard identifiers the library community has been using for decades
> identify things that do have a media type, such as books in PDF, or
> audio in MP3. Media type is important, since usually different
> representations (PDF, ODF, HTML versions of a book) do get different
> identifiers.

Agreed, but not a problem, see above.

> The only resources (in the RFC 3986 sense) which the libraries deal
> with are what we call works and expressions, which are immaterial and
> do not have a media type. But since we deal more with manifestations
> it would be totally impossible for libraries to accept a specification
> which does not allow identification of things which do have a media
> type.

Agreed, but not a problem, see above.

> As far as I am concerned, RFC3986 does have some issues with resources
> and representations which seem to become more apparent when we apply
> these terms in the real world (at least as libraries see them).

Quite likely, but I hope the above has helped clarify that some of the
problems you thought were there are not actually there.

> But my suggestion is to not to dig too deep in possible problems in
> the URI syntax problems, just assume that all is well, talk about
> resources only in the URN syntax specification and let communities use
> whatever terms they are used to and identify whatever they need to
> identify in their own namespaces.

Works for me.  3986's use of 'representation' is _very_ narrow, and
doesn't correspond well to ordinary language use.  As I said in the
original ("whether ... 'representation' needs to be imported" ...), I
don't assume it needs to appear in urnbis at all.

Thanks for your detailed and thoughtful reply,

ht

[1] http://www.ifla.org/files/assets/cataloguing/frbr/frbr_2008.pdf
[2] https://www.w3.org/TR/webarch/
-- 
       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: [email-masked] (Henry S. Thompson)
Date: Mon, 12 Dec 2016 14:27:00 +0000

Peter Saint-Andre writes:

>> ...

> 'abstract designator' to describe names that purely identify
> resources; that is, the intent is that such a name will never be
> resolved (i.e., there is no access mechanism associated with the name)
> and, more specifically, that at no time will it be possible to
> retrieve a representation of the identified resource.

Understood.

>> ...
> Here, 'metadata' mean metadata about the representation. If there is
> no representation, there can be no representation metadata.

Right -- as in my reply to Juha, this is an example of 3986's very
_narrow_ use of 'representation'.  And yes, 3986 is careful to
distinguish between representation metadata, which will always be
strictly defined by the protocol by which the representation is
delivered, and resource metadata, which is unconstrained by 3986.

> representation metadata (metadata describing the octets, as in MIME,
> see Section 5.1.2)

and also protocol-related information, such as cacheability,
time-to-live, etc.

> and resource metadata (metadata describing the resource itself

Yes.

> - perhaps an example would be Dublin Core information
> about authors, publishers, licenses, and the like). 

For example, yes.  But much further than that in the case of
non-representable resources (non-information resources, to use
Berners-Lee's term, see my reply to Juha) -- more on this below.

> However, even the notion of resource metadata here seems to be tied to
> retrieval.

Yes, I _think_ the '_additional_ information might be _supplied_'
[emphasis added] is a reference to on the one hand offers of other
formats (MIME and/or translations), and on the other hand (where
'alternative' would be more accurate than 'additional') when no
representation is supplied but other information is (again, see below).

> consistent intepretation of the term 'abstract designator' is possible.

Indeed.

> As noted, we coined this term to refer to precisely your (3).

Right -- it's now clear that we disagree about the _possibility_ of such
identifiers.

> The examples that I personally had in mind were XML namespaces, such
> as "urn:ietf:params:xml:ns:xmpp-sasl" in RFC 6120. Although I suppose
> one could make the argument that a "representation" of an XML
> namespace could take the form of a W3 XML Schema or a RELAX NG schema,
> that seems like a stretch to me.

Indeed.  Stipulate that no representation is possible.  XML namespaces
are not, in Berners-Lee's terms, information resources.

A brief *digression* is necessary before we proceed.  In your reply to my
other message, you preferred 'access' to 'retrieve', and I accepted that
in my follow-up.  I _assumed_ you preferred the more general term
because you didn't want to distinguish in the relevant contexts between
my cases (1) and (2) above, that is, that it counts as 'accessing' a
resource if you can get resource metadata about it, even though you
can't get a representation == 'retrieve'. 

Back to the namespace example, which proves empirically opportune.  If
you issue an HTTP GET request for the XML Schema namespace URI, that is,
http://www.w3.org/2001/XMLSchema, or for the XML encryption namespace
(http://www.w3.org/2009/xmlenc11), the response you get is not a
representation _of_ the resource, rather it gives you information
_about_ the resource: strictly speacking it represents a different
resource which gives a bit of prose description and pointers to the
relevant standards.  That's a good example of resource metadata.

> of supporting the specified hash function. Here it's even clearer to
> me that there is no representation and that no resolution is ever
> intended.
>

I'm happy to stipulate that none of these identify information resources
either: they all denote some documented point in some enumerated type.
But that doesn't mean someone might not find it useful to provide a
resolution service for those enumerated types which, as for the
namespace examples above, provide human-readable resource metadata.

>From which the next bit of my message follows, I hope:

> and that meaning is specified in the relevant protocol
> specification. Are you suggesting that the appropriate metadata here
> is a pointer to the specification in which the meaning of the URN is
> defined?

Precisely.

> urn:alert:service:call-waiting to RFC 7462. Instead, these URNs are
> used as, well, abstract designators of potentially supported features
> in XMPP or SIP; i.e., XMPP or SIP user agents and servers know exactly
> what these URNs mean (because the software developers have read the
> relevant specifications), but I see no reason for some generic URN
> parser to resolve them. Not that anyone could stop them from
> implementing such resolution, but there's no good reason to do so as
> far as I can see. Call that "contingent" if you would like.

Reasonable persons might differ, I submit.  There's a line of argument,
expressed in the folkloric argument for why the Web works: "because you
can write URIs on the side of a bus, follow your nose and view source"
[1].  The "follow your nose" point is more formally worked through in
the TAG finding "The Self-Describing Web" [2].  On this account, part of
the practical value of using URNs instead of any other form of managed
name is precisely that the overhead involved in supplying online access
to useful information is low because some much of the necessary
infrastructure is already in place.

More controversially, there is the expectation/vision/hope/dream of the
Semantic Web, that is, of _machine-interpretable_ metadata, where, for
example, one might hope to find a set of axioms, expressed in RDF, which
would actually support an automatic operationalisation of e.g. the
various XEP-0300 hash functionalities.

> To your point in another thread, that would be "locator".

Well, no longer -- see the *digression* above -- that is what I meant
originally, but in response to your suggestion I agreed to widening,
shall we say, from "_retrieval_-enabled" to "_access_-enabled", where
the former is restricted to representations but the latter extends to
(resource) metadata.

> Agreeing to all of that, it still seems to me that abstract
> designators are useful and that the concept captures something that is
> different from your (1) and (2).

Given your examples and discussion that I'm replying to here, I think
the point now is that I see no difference between what it turns our you
mean by 'abstract designator' and my (1): identifiers of resources for
which no representation (in the strict 3986 sense) is possible.  That
certainly fits with the _word_ 'abstract': of necessity although we can
talk _about_ abstractions, even define them, they are not themselves the
same as that talk or those definitions.

>> _resources_, not of URNs.  As such it's not really relevant to this

In the context of the foregoing I should acknowledge that if a URN
namespace _by construction_ provides names only for
abtract/imaginary/hypothetical entities, then all names in that
namespace fall into my class (1).

> urn:alert:service:call-waiting. Is it all and only the specification
> in which the name is defined?

I hope the above has clarified that it's not by any means that narrow.

One last example.  Consider the space of (registered) Media Types.  They
are certainly not representable as such, they definitely fall into the
category of an enumerated type with externally-specified semantics.

As such we might well think there _should_ be a URN namespace for them.
Suppose there were, e.g. urn:ietf:mediatype:.  If so, then it would be
_very_ useful if resolution of urn:ietf:mediatype:application/xml would
redirect to (the appropriate table row of)
http://www.iana.org/assignments/media-types/media-types.xhtml, thus
enabling a very useful instance of 'follow your nose'.

ht

[Those for whom the jargon phrase "http-range-14" rings a bell will know
that I've glossed over the HTTP-level details of the representation
vs. metadata point -- I don't believe the above discussion stands or
falls on the resolution (or lack of it) of that issue]

[1] http://www.ltg.ed.ac.uk/~ht/persistence.html
[2] https://www.w3.org/2001/tag/doc/selfDescribingDocuments.html
-- 
       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: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Dec 2016 21:06:32 -0700

Henry, thanks for your enlightening message. I shall ponder these 
matters a bit further before replying in depth.

One comment below.

On 12/12/16 7:27 AM, Henry S. Thompson wrote:

<snip/>

> enabling a very useful instance of 'follow your nose'.

In fact, a few years ago I started defining a URN namespace for IANA 
registry entries:

https://www.ietf.org/archive/id/draft-saintandre-iana-urn-01.txt

Although that work got lost in the shuffle during the recently-completed 
IANA transition, the fact that you mention IANA registry entries as an 
example of "enumerated types with externally-specified semantics" 
encourages me to think that we have a shared understanding of the 
entities under discussion here.

More soon.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Dec 2016 21:04:50 -0700

Hi Henry & WG,

After pondering this and your follow-up message, I have a few more 
comments and I would like to propose some textual changes. See inline.

>>  1) 3986 distinguishes between 'resource' and 'representation', and so

Agreed.

>>  2) The term 'abstract designator' should be dropped.

I now think this is the right thing to do. Specifically, this term 
wasn't doing any work for us because it was used sparingly to no great 
effect. Better to remove it and reduce the potential for confusion.

>>   Per 3986, _all_ URIs identify something, which it calls a resource.

In both cases, I suggest that we remove the phrase "or in some cases an 
abstract designator that is persistent but that does not identify a 
resource".

> Yes, that all seems right.

Here is proposed text...

OLD
    The f-component is primarily intended to distinguish the constituent
    parts of resources named by URNs.  Thus, for URNs that resolve to
    URLs of the named resources, the semantics of an f-component are
    defined by the media type of those resources, not by the URN
    namespace.

NEW
    The f-component is primarily intended to distinguish the constituent
    parts of resources named by URNs.  Thus, for URNs that resolve to
    locator URIs of the named resources, the semantics of an f-component
    are defined by the media type of the representations into which those
    locator URIs are dereferenced, not by the URN namespace.

(See below for the paragraph where I introduce the unfamiliar term 
"locator URI".)

> As you pointed out, this is wrong: every URI identifies a resource.

Fixed (see above).

> This suffers from the same problem you have pointed out regarding

My suggestion is to remove that paragraph in its entirety.

>>   to the quote above from section 2.3.2]

In line with your previous message on URL vs. locator, I suggest that we 
modify the terminology in those snippets. You can get a feeling for how 
I propose to change things by reading the following paragraph:

OLD
    The URN q-component has the same syntax as the URI query component,
    but is introduced by "?=", not "?" alone.  For URNs that may be
    resolved to a URL, the semantics of the q-component are identical to
    those for the query component of that URL.  Thus URN resolvers
    returning a URL for a URN with a q-component do this by copying the
    q-component from the URN to the query component of the URL.  If the
    URN does not resolve to a URL, the interpretation of the q-component
    is undefined by this specification.  An example of the copying
    operation appears below.

NEW
    The URN q-component has the same syntax as the query component in URI
    schemes for locators, but is introduced by "?=", not "?" alone.  For
    URNs that may be resolved to a locator URI, the semantics of the
    q-component are identical to those for the query component of that
    URI.  Thus URN resolvers returning a locator URI for a URN with a
    q-component do this by copying the q-component from the URN to the
    query component of the locator URI.  If the URN does not resolve to a
    locator URI, the interpretation of the q-component is undefined by
    this specification.  An example of the copying operation appears
    below.

>>   3) No resolution services of any kind are provided or envisaged;

Although I am not 100% sure that we still need category (3), I _think_ 
it remains useful.

To (I hope) clarify these issues, I propose the following text change in 
Section 1.1:

OLD
    Among these general issues, one that is specific to URNs is the
    fairly abstract topic of "resolution", discussed in Section 1.2,
    Section 2.3.1, and elsewhere below.  It is possible to define the
    relationships quite precisely for a URN that resolves to a URL, where
    that URL in turn resolves to (or locates) a single target document or
    similar resource; however, that is only one special case (albeit an
    important one).  URNs (either individually or entire URN namespaces
    as defined below) that do not resolve to URLs at all or that resolve
    to metadata or non-Internet objects are among URN use cases
    explicitly permitted by this specification; each leaves the concept
    of "resolution" somewhat more abstract and difficult than the simple
    case of resolution to a URL.

NEW
    Among these general issues, one that is specific to URNs is the
    fairly difficult topic of "resolution", discussed in Section 1.2,
    Section 2.3.1, Section 6.4.6, and elsewhere below.  By contrast,
    resolution is relatively straightforward for traditional Uniform
    Resource Locators (URLs), or at least for most URI schemes for
    locators, because resolution is used to determine an access mechanism
    which in turn is used to dereference the locator by (typically)
    retrieving a representation of the associated resource (see
    Section 1.2.2 of [RFC3986]).  Consequently, it is possible to define
    the relevant relationships quite precisely for URNs that resolve to
    locators (such as URLs) which in turn are dereferenced to a
    representation (such as a target document); however, that is only one
    particular case, albeit an important one.  This specification permits
    several other kinds of URNs, either individually or (as defined
    below) collectively for entire URN namespaces.  In particular, some
    URNs might resolve to locators which in turn are dereferenced only to
    metadata about the resource, not to a representation of that
    resource; an example might be a URN namespace for cataloging of
    information resources.  Furthermore, some URNs might not be intended
    to resolve to locators at all; examples might include URNs
    identifying XML namespace names (e.g., the 'dgiwg' URN namespace
    specified by [RFC6288]), URNs identifying application features that
    can be supported within a communications protocol (e.g., the 'alert'
    URN namespace specified by [RFC7462]), and URNs identifying
    enumerated types such as values in a registry (e.g., a URN namespace
    could be used to individually identify the values in all IANA
    registries, as provisionally proposed in [I-D.saintandre-iana-urn]).
    These types of URNs leave the concept of "resolution" somewhat more
    difficult than the straightforward case of resolution to a locator
    that is dereferenced to a representation.  (On the distinction
    between names and locators, see Section 1.1.3 of [RFC3986]; on the
    distinction between representations and metadata, see Section 1.2.2
    of [RFC3986].)

As you can see, that text adds some examples and makes more careful 
distinctions, which I think are helpful (even absent the potentially 
confusing term "abstract designator").

Comments are welcome.

Peter

P.S. Please note that I have not yet talked with my co-author about 
these proposed changes, so all errors are mine.

P.P.S. If you like source control, you can see the work-in-progress 
changes here: 
https://github.com/stpeter/urnbis/commits/master/draft-ietf-urnbis-rfc2141bis-urn.xml 
(naturally, these are only provisional, and I'd prefer to keep 
discussion on this list instead of at GitHub).

---

From: "Hakala, Juha E" <[email-masked]>
Date: Thu, 15 Dec 2016 05:40:14 +0000

Hi Peter, 

I approve the changes you have made, including the removal of abstract designator. I was never a great fan of that concept. 

One point we need to make very clear is that the terms "resource" and "identify" are used throughout RFC2141bis as specified in URI syntax, unless otherwise said. And that the RFC 3986 definitions of those terms may differ a lot from those traditionally used in some domains which are involved with resource identification. Any librarian will have a problem with "every URI identifies a resource" unless he knows how RFC 3986 defines these concepts (and how people understand what RFC 3986 stipulations). 

Henry has already clarified the meaning of resource in RFC 3986. As regards identification, URI syntax says that 

Our use of the terms "identify" and "identifying"
      refer to this purpose of distinguishing one resource from all
      other resources, regardless of how that purpose is accomplished
      (e.g., by name, address, or context).  These terms should not be
      mistaken as an assumption that an identifier defines or embodies
      the identity of what is referenced, though that may be the case
      for some identifiers.

And because of this, my email address identifies me according to RFC 3986. Whether email addresses are good (note that the RFC 3986 definition does not require persistence) identifiers even from the liberal RFC 3986 point of view is a different issue which does not need to be discussed here. 

Juha 

> Sent: 15. joulukuuta 2016 6:05
> I now think this is the right thing to do. Specifically, this term wasn't doing any
> work for us because it was used sparingly to no great effect. Better to
> remove it and reduce the potential for confusion.
> 
> >> In other words, anything can be a resource: real, imaginary,
> >> abstract, concrete, individual, set (finite or infinite), ...
> >>
> >> it in ways which are consistent with 3986's definition, for example
> >> in phrases such as "resource identifier" (lower case in original),
> >> "identified resource", "The kinds of resources identified by URNs"
> >> and "persistent identification of resources".  This longer exposition
> >> is also pretty much compatible with 3986:
> >>
> abstract designator that is persistent but that does not identify a resource".
> 
> >> distinction between what is identified and the outcome of a
> >> resolution attempt, as well as between resolution and retrieval, and
> >> the wording around these just needs to be tightened up a bit, with
> >> the word 'resource' used a bit less.  Whether the idea behind 3986's
> >> word 'representation' needs to be imported, along with the word, will
> >> I think be an editorial decision to be made in the course of the
> >> tightening-up effort.
> >
> (See below for the paragraph where I introduce the unfamiliar term "locator
> URI".)
> 
> modify the terminology in those snippets. You can get a feeling for how I
> propose to change things by reading the following paragraph:
> 
> OLD
> >> concerned (where the possibility that resolution may involve more
> >> than one step is assumed):
> >>
> > see Section 5.1.2) and resource metadata (metadata describing the
> > resource itself - perhaps an example would be Dublin Core information
> > about authors, publishers, licenses, and the like). However, even the
> > notion of resource metadata here seems to be tied to retrieval.
> >
> >> However I think the above quotes from the current draft taken
> >> together provide evidence that it considers there to be a _threefold_
> >> distinction, adding
> >>
> Although I am not 100% sure that we still need category (3), I _think_ it
> remains useful.
> 
> To (I hope) clarify these issues, I propose the following text change in Section
> 1.1:
> 
> OLD
> distinctions, which I think are helpful (even absent the potentially confusing
> term "abstract designator").
> 
> Comments are welcome.
> 
> Peter
> 
> P.S. Please note that I have not yet talked with my co-author about these
> proposed changes, so all errors are mine.
> 
> P.P.S. If you like source control, you can see the work-in-progress changes
> here:
> (naturally, these are only provisional, and I'd prefer to keep discussion on this
> list instead of at GitHub).
> 
>

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 15 Dec 2016 08:55:51 +0000

Hakala, Juha E writes:

> I approve the changes you have made, including the removal of abstract
> designator. I was never a great fan of that concept.

And I'm happy with all those changes as well.

> One point we need to make very clear is that the terms "resource" and
> "identify" are used throughout RFC2141bis as specified in URI syntax,
> unless otherwise said. And that the RFC 3986 definitions of those
> terms may differ a lot from those traditionally used in some domains
> which are involved with resource identification. Any librarian will
> have a problem with "every URI identifies a resource" unless he knows
> how RFC 3986 defines these concepts (and how people understand what
> RFC 3986 stipulations).
>
> Henry has already clarified the meaning of resource in RFC 3986. As
> regards identification, URI syntax says that
>
>       Our use of the terms "identify" and "identifying" refer to this
>       purpose of distinguishing one resource from all other resources,
>       regardless of how that purpose is accomplished (e.g., by name,
>       address, or context).  These terms should not be mistaken as an
>       assumption that an identifier defines or embodies the identity
>       of what is referenced, though that may be the case for some
>       identifiers.

Quoting, paraphrasing and/or referencing this would be a sensible thing
to do, I agree.

ht

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 18 Dec 2016 11:33:31 -0700

> And I'm happy with all those changes as well.

Great! Thanks to you both for reviewing the proposed text.

> Quoting, paraphrasing and/or referencing this would be a sensible thing

Pointing to it seems like the right thing to do. I suggest that we add 
the following sentence to Section 1.2:

    This document uses the terms "resource", "identifier", "identify",
    "dereference", "representation", and "metadata" as defined in the URI
    specification [RFC3986].

Peter

---

From: John C Klensin <[email-masked]>
Date: Sun, 18 Dec 2016 13:40:51 -0500

--On Sunday, December 18, 2016 11:33 -0700 Peter Saint-Andre
<[email-masked]> wrote:

>> Quoting, paraphrasing and/or referencing this would be a
>> sensible thing to do, I agree.
> 
> Pointing to it seems like the right thing to do. I suggest
> that we add the following sentence to Section 1.2:
> 

I think the principle is correct.  However, unless there is a
great deal more consensus about what 3986 says and what the
words mean than I'm seeing, please be very careful about this.
More follows as soon as I get my desktop machine rebuilt
(getting close).

    john

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 18 Dec 2016 11:42:29 -0700

> words mean than I'm seeing, please be very careful about this.

Yes, we have been careful about that with other terms:

    This document uses the terms "resolution" and "resolver" in roughly
    the sense in which they were used in the original discussion of
    architectural principles for URNs [RFC2276]

We could provide similar text here.

Peter

---

From: "Svensson, Lars" <[email-masked]>
Date: Wed, 21 Dec 2016 11:26:57 +0000

Peter, WG,

> abstract designator that is persistent but that does not identify a

This change is fine with me.

[...]
>     locator URIs are dereferenced, not by the URN namespace.

This is fine with me, too.

> >> Part 2 -- 'abstract designator'

[...]
 
>     this specification.  An example of the copying operation appears

Here I don't quite agree with "The URN q-component has the same syntax as the query component in URI schemes for locators". That text implies that URI schemes that are not for locators have a different query component syntax. My suggestion would be to accept Peter's new version but keep the first sentence unchanged:

[[
The URN q-component has the same syntax as the URI query component, but is introduced by "?=", not "?" alone.  For     URNs that may be resolved to a locator URI, the semantics of the q-component are identical to those for the query component of that URI.  Thus URN resolvers returning a locator URI for a URN with a q-component do this by copying the q-component from the URN to the query component of the locator URI.  If the URN does not resolve to a locator URI, the interpretation of the q-component is undefined by this specification.  An example of the copying operation appears below.
]]
[...]
> confusing term "abstract designator").

Yes, thank you! This is much clearer than before.

Best,

Lars

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 22 Dec 2016 11:56:23 -0700

Hi Lars, thank you very much for your feedback.

On 12/21/16 4:26 AM, Svensson, Lars wrote:
> Peter, WG,
>
> On Thursday, December 15, 2016 5:05 AM, urn
> [mailto:[email-masked]] On Behalf Of Peter Saint-Andre wrote:

<snip/>

>> OLD The URN q-component has the same syntax as the URI query
>> component, but is introduced by "?=", not "?" alone.  For URNs that
>> may be resolved to a URL, the semantics of the q-component are
>> identical to those for the query component of that URL.  Thus URN
>> resolvers returning a URL for a URN with a q-component do this by
>> copying the q-component from the URN to the query component of the
>> URL.  If the URN does not resolve to a URL, the interpretation of
>> the q-component is undefined by this specification.  An example of
>> the copying operation appears below.
>>
>> NEW The URN q-component has the same syntax as the query component
>> in URI schemes for locators, but is introduced by "?=", not "?"
>> alone.  For URNs that may be resolved to a locator URI, the
>> semantics of the q-component are identical to those for the query
>> component of that URI.  Thus URN resolvers returning a locator URI
>> for a URN with a q-component do this by copying the q-component
>> from the URN to the query component of the locator URI.  If the URN
>> does not resolve to a locator URI, the interpretation of the
>> q-component is undefined by this specification.  An example of the
>> copying operation appears below.
>>
>
> Here I don't quite agree with "The URN q-component has the same
> syntax as the query component in URI schemes for locators". That text
> implies that URI schemes that are not for locators have a different
> query component syntax. My suggestion would be to accept Peter's new
> version but keep the first sentence unchanged:
>
> [[ The URN q-component has the same syntax as the URI query
> component, but is introduced by "?=", not "?" alone.  For     URNs
> that may be resolved to a locator URI, the semantics of the
> below. ]] [...]

You are right - thanks for pointing out this problem.

Peter

---

From: John C Klensin <[email-masked]>
Date: Tue, 27 Dec 2016 18:14:07 -0500

--On Thursday, December 22, 2016 11:56 AM -0700 Peter

>> Here I don't quite agree with "The URN q-component has the
>> same syntax as the query component in URI schemes for
>> locators". That text implies that URI schemes that are not
>> for locators have a different query component syntax. My
>> suggestion would be to accept Peter's new version but keep
>> the first sentence unchanged:
>> 
>> component, but is introduced by "?=", not "?" alone.  For
>> URNs that may be resolved to a locator URI, the semantics of
>> the q-component are identical to those for the query
>> component of that URI.  Thus URN resolvers returning a
>> locator URI for a URN with a q-component do this by copying
>> the q-component from the URN to the query component of the
>> locator URI.  If the URN does not resolve to a locator URI,
>> the interpretation of the q-component is undefined by this
>> specification.  An example of the copying operation appears
>> below. ]] [...]

> You are right - thanks for pointing out this problem.

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".   I still don't fully
understand why we have dropped "URL" in favor of "locator URI"s
and similar unnatural constructions, but, if we are going to do
so, "locator URI" is in need of a clear definition in Section
1.1.  When I go back and reread Section 1.1.3 of RFC 3986, I
think that any plausible definition takes us back to "URL"
unless the intent is to get at the "both" case, but maybe I'm
missing something. 

best,
   john

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Dec 2016 18:37:16 -0700

> unless the intent is to get at the "both" case, but maybe I'm

If we follow Henry's suggestion to use the term "locator" instead of 
"URL" in most instances, then we need a term to refer to locators that 
are identified by URIs, since there could be non-URI locators. This is 
why I coined the neologism "locator URI", which is the same as a "URI 
for a locator" but less wordy. I'm open to better suggestions!

Peter