Subject: [urn] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16

From: [email-masked] (Henry S. Thompson)
Date: Tue, 03 May 2016 18:14:58 +0100

Section 2 BNF

 This has probably been done to death, so wrt the "0*30(ldh)" in the NID
 production I merely register my general dismay at the inclusion of
 _any_ arbitrary numerical field widths in grammars such as this

Section 2.3.1, para 1

 (requested) service

 "The q-component is intended for passing parameters to either the
  named resource or a system that can supply the requested service, for
  interpretation by that resource or system."

 This is the first use of the word 'service' since section 1.1, which
 reads to me as only defining _resolution_ services, which are
 explicitly ruled out in this case by the immediately following
 parenthesis.

 Aside from the case of "services associated with the namespace" which
 occurs in 6.4.1 item 5, all other uses of the word 'service' in the
 spec either clearly (and usually explicitly) refer to resolution
 services, or are about non-URN-related services altogether.

 In contexts I'm familiar with, the 'Resource' in 'URI' covers anything
 and everything that might be identifiable, from the easy (what TimBL
 calls "information resources") to the ineffable (the weather in
 Oaxaca), the imaginery (unicorns) and the abstract (democracy), and
 certainly including services.  So I'm unsure what the distinction is
 that you're trying to get at here.  Particularly as in practice any
 actual response to the use of a URN comes from some system, so making a
 distinction between passing a parameter to a resource vs. to a service
 seems to me a distinction without a difference.

 The following, from 2.3.2:

  "(By contrast, passing parameters to the resources
   identified by a URN, or to applications that manage such resources,
   is handled by q-components as described in the previous section.)"

 is by contrast exactly what I would expect to see.

Section 3.1 [also signalled earlier at 2.3.1 para 5]

  "For various purposes such as caching, it is often desirable to
   determine if two URNs are 'the same'."

   ...

  "If a q-component, r-component, or f-component (or any combination
   thereof) are included in a URN, they MUST be ignored for purposes of
   determining equivalence."

These two seem in contradiction to one another, at least insofar as q-
and probably r-components are concerned.  Surely for caching purposes
distinct q-components must mean inequality?  Otherwise asking for my
booking to Amsterdam might get me your booking for New York, if I made
the request via a URN for a flight-booking service including surname and
booking ID via q-parameters, sent to a service that does the
q-conversion and URL-fetching itself. . .
 
But I realise there's been a _very_ long discussion history about this
issue, and thus it not be one you want to re-open.  At the very least,
however, I think you need to call out the downside wrt caching, in
some kind of "your gun, your foot, your bullet" note.

Section 4

  [No issues, this is a good compromise wrt previous disputes, IMO]

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: Sean Leonard <[email-masked]>
Date: Tue, 3 May 2016 12:36:53 -0700

Hello,

>   _any_ arbitrary numerical field widths in grammars such as this

I disagree with this on the premise stated, so -1. If there is a limit 
on a field width, it should be expressed in the grammar however 
possible. If the grammar is normative (and I ascribe to the view that 
ABNF is fully normative), the grammar and the prose ought to be in exact 
alignment.

However, I agree with the premise that field widths should not be limited.

The limit of 30 characters for NID does not have much justification. If 
someone wants to register 
someextremelylongNIDbecausetheyfeellikeitandsoforth, who cares? It's not 
a resource exhaustion issue.

(Note: the limit of 32 characters is in RFC 2141. If that is the 
justification--compatibility with prior spec--then I accept it, but that 
should be mentioned in the text IMO.)

>   is by contrast exactly what I would expect to see.

+1. The draft needs to take a strong stand on the definitions of 
"service" and "resource" per Henry's comments above. I believe that 
"resource" should mean exactly what RFC 3986 says, to avoid confusion 
with that spec. However, this is in contrast to prior voices in this WG 
that have tried to change what "resource" means in the URN context. I 
would appreciate those voices speaking up, because this WG has been 
dragging on with fewer and fewer participants, and Henry's feedback 
shows exactly what happens when "resource" is not the same between IETF 
documents.

In particular: a URI without a fragment identifies some primary resource 
(which RFC 3986 says is anything that can be identified by URI, so it's 
pretty reflexive); with a fragment, it identifies some secondary 
resource that is part of the primary resource, and is reachable with 
knowledge of the media type of the primary resource(s). The actual 
representation that is returned during the dereferencing operation, can 
vary based on ambient conditions (network topology, servers online, 
redirects, blah blah blah). Other things (such as web server, URN 
resolvers, proxies, DNS servers, Tor, IP addresses, warp holes, blah 
blah blah) are resources in the generic sense of the term, but *not* 
resources in the way that RFC 3986 refers to resources.

> distinct q-components must mean inequality?
+1, I agree.

>    Otherwise asking for my

+1, I agree. That part "MUST be ignored for purposes of determining 
equivalence", need to be something like:
"MUST be ignored for purposes of determining name equivalence" or some 
other magical term. The point is that urn:nid1:obj2 and 
urn:nid1:OBJ2?foo#baz identify the same Uniform Named Thing (if nid1 
namespace says case-insensitive), but they may well not return the same 
representations when URI-dereferenced. "Equivalence" in URIs also 
depends on what you mean by equivalence, i.e., how deep you are looking. 
There are multiple kinds of equivalence.

Sean

---

From: Sean Leonard <[email-masked]>
Date: Tue, 3 May 2016 12:46:52 -0700

On 5/3/2016 12:36 PM, Sean Leonard wrote:
> namespace says case-insensitive), but they may well not return the 
> same representations when URI-dereferenced. "Equivalence" in URIs also 
> depends on what you mean by equivalence, i.e., how deep you are 
> looking. There are multiple kinds of equivalence.

Let me provide specific text. The term I shall use is "name the same thing".

3.  Equivalence: URNs That Name the Same Thing

3.1.  Procedure

    It is often desirable to
    determine if two URNs are "the same".
    The generic URI specification [RFC3986] is very flexible about
    equality comparisons, putting the focus on allowing false negatives
    and avoiding false positives.  If comparisons are made in a scheme-
    independent way, i.e., as URI comparisons only, URNs that this
    section considers equal would be rejected.  The discussion
    below applies when the URIs involved are known to be URNs.
    This "Name the Same Thing" procedure is a form of scheme-based
    normalization (Section 6.2.3 of [RFC3986]).

    Two URNs Name the Same Thing if their <assigned-name>
    portions are octet-
    by-octet equal after applying case normalization (as specified in
    Section 6.2.2.1 of [RFC3986]) to the following constructs:

    1.  the URI scheme "urn", by conversion to lower case

    2.  the NID, by conversion to lower case
[[
    3.  any percent-encoded characters in the NSS (that is, all character
        triplets that match the <pct-encoding> production found in
        Section 2.1 of the base URI specification [RFC3986]), by
        conversion to upper case for the digits A-F.

    Percent-encoded characters MUST NOT be decoded, i.e., percent-
    encoding normalization (as specified in Section 6.2.2.2 of [RFC3986])
    MUST NOT be applied as part of the comparison process.
]]
    If a q-component, r-component, or f-component (or any combination
    thereof) are included in a URN, they MUST be ignored for purposes of
    determining whether to URNs Name the Same Thing.

    URN namespace definitions MAY include additional rules for
    equivalence, such as case-insensitivity of the NSS (or parts
    thereof).  Such rules MUST always have the effect of eliminating some
    of the false negatives obtained by the procedure above and MUST NOT
    result in treating two URNs as not equivalent if the procedure here
    says they are equivalent.  For related considerations with regard to
    NID registration, see below.

**

I disagree with the text in between [[ ]], because I believe that NSS is 
in UTF-8; therefore, ill-formed UTF-8 sequences such as %FF cannot Name 
the Same Thing, even if both urn: URIs have them. That issue, however, 
is a different topic.

Sean

---

From: John C Klensin <[email-masked]>
Date: Tue, 03 May 2016 18:06:00 -0400

--On Tuesday, May 03, 2016 12:36 -0700 Sean Leonard
<[email-masked]> wrote:

>...
> The limit of 30 characters for NID does not have much
> justification. If someone wants to register
> someextremelylongNIDbecausetheyfeellikeitandsoforth, who
> cares? It's not a resource exhaustion issue.

Actually, one of the things I learned when I was working with
human factors psychologists in a prior life is that there is a
reason, having to do with the ability of humans to distinguish
between things (like strings) based on quick inspection.    As
an example, look quickly at
someextremely1ongNIDbecausetheyfee11ikeitandsoforth and,
pretending this isn't a test to which I've alerted you, tell me
if the two supposed identifiers are the same.  A truly random
string or a hash, which might also have been used in your
example, would be worse/harder because there would be no
expectation of a concatenated set of words.  Easy for computers
but, insofar as we expect to rely on humans, bad for them.  The
Stevens limit seems or apply to reliable human recognition as
well as short-term memory.

> (Note: the limit of 32 characters is in RFC 2141. If that is
> the justification--compatibility with prior spec--then I
> accept it, but that should be mentioned in the text IMO.)

Right now, 2141bis lists substantive differences from 2141.  Are
you also suggesting that it list everything that has not
changed?  Or, if there is a dividing line for those things that
are unchanged from 2141 that should be called out, how would you
define it?

> +1. The draft needs to take a strong stand on the definitions
> of "service" and "resource" per Henry's comments above. I
> believe that "resource" should mean exactly what RFC 3986
> says, to avoid confusion with that spec. However, this is in
> contrast to prior voices in this WG that have tried to change
> what "resource" means in the URN context. I would appreciate
> those voices speaking up, because this WG has been dragging on
> with fewer and fewer participants, and Henry's feedback shows
> exactly what happens when "resource" is not the same between
> IETF documents.

See my response to Henry but also note that what 3986 appears to
say (and how he interprets it if I correctly understood his
note) is that "resource" can refer to very nearly anything.
Meaning exactly what 3986 says would require that 3986 be a
great deal more specific than the entirely circular definition
of 3986 which reads "This specification does not limit the scope
of what might be a resource; rather, the term "resource" is used
in a general sense for whatever might be identified by a URI."
followed by some examples and general comments. 

> In particular: a URI without a fragment identifies some
> primary resource (which RFC 3986 says is anything that can be
> identified by URI, so it's pretty reflexive); with a fragment,
> it identifies some secondary resource that is part of the
> primary resource, and is reachable with knowledge of the media
> type of the primary resource(s). The actual representation
> that is returned during the dereferencing operation, can vary
> based on ambient conditions (network topology, servers online,
> redirects, blah blah blah). Other things (such as web server,
> URN resolvers, proxies, DNS servers, Tor, IP addresses, warp
> holes, blah blah blah) are resources in the generic sense of
> the term, but *not* resources in the way that RFC 3986 refers
> to resources.

And the status of an abstract designator is still unclear.

>...
>> But I realise there's been a _very_ long discussion history
>> about this issue, and thus it not be one you want to re-open.
>> At the very least, however, I think you need to call out the
>> downside wrt caching, in some kind of "your gun, your foot,
>> your bullet" note.
> 
> +1, I agree. That part "MUST be ignored for purposes of
> determining equivalence", need to be something like:
> "MUST be ignored for purposes of determining name equivalence"
> or some other magical term. The point is that urn:nid1:obj2
> and urn:nid1:OBJ2?foo#baz identify the same Uniform Named
> Thing (if nid1 namespace says case-insensitive), but they may
> well not return the same representations when
> URI-dereferenced. "Equivalence" in URIs also depends on what
> you mean by equivalence, i.e., how deep you are looking. There
> are multiple kinds of equivalence.

Need advice from the WG Chairs on whether or not this topic
should be reopened.  I have no strong preference about what the
spec should say other than that we not go around in circles
about it for more months.

best,
    john

---

From: John C Klensin <[email-masked]>
Date: Tue, 03 May 2016 18:07:08 -0400

--On Tuesday, May 03, 2016 18:14 +0100 "Henry S. Thompson"
<[email-masked]> wrote:

> Section 2 BNF
> 
>  This has probably been done to death, so wrt the "0*30(ldh)"
> in the NID  production I merely register my general dismay at
> the inclusion of  _any_ arbitrary numerical field widths in
> grammars such as this

That is not a "field width" in the usual sense.  It is the name
of the namespace.   Names get placed in tables, etc., and having
a nominal upper limit on their length helps a lot.    FWIW, in
my many years of (admittedly strange) experience, the only time
I've seen human beings voluntarily select a 32 character
identifier/name, much less a longer one, has been when they are
trying to prove a point or be deliberately obscure.   I don't
see a need to support either of those uses, but perhaps others
do.

Note that there is no protocol-imposed limit on the actual data
fields: NSS, q-component, r-component, or f-component.  I would
probably share you objection to a limit on them.

> Section 2.3.1, para 1
> 
>  (requested) service
> 
>  "The q-component is intended for passing parameters to either
> the   named resource or a system that can supply the requested
> service, for   interpretation by that resource or system."
> 
>  This is the first use of the word 'service' since section
> 1.1, which  reads to me as only defining _resolution_
> services, which are  explicitly ruled out in this case by the
> immediately following  parenthesis.
> 
>  Aside from the case of "services associated with the
> namespace" which  occurs in 6.4.1 item 5, all other uses of
> the word 'service' in the  spec either clearly (and usually
> explicitly) refer to resolution  services, or are about
> non-URN-related services altogether.
> 
>  In contexts I'm familiar with, the 'Resource' in 'URI' covers
> anything  and everything that might be identifiable, from the
> easy (what TimBL  calls "information resources") to the
> ineffable (the weather in  Oaxaca), the imaginery (unicorns)
> and the abstract (democracy), and  certainly including
> services.  So I'm unsure what the distinction is  that you're
> trying to get at here.  Particularly as in practice any
>  actual response to the use of a URN comes from some system,
> so making a  distinction between passing a parameter to a
> resource vs. to a service  seems to me a distinction without a
> difference.

The addition went in because the use of "resource" seemed to set
off arguments, particularly about whether abstract designators
were actually required to designate something, such as a
whatever-a-resource-is.  Note that we do not, at least so far,
have a restriction on q-components being associated with
abstract designators.  My reading of 3986 suggests that one
cannot have a fragment with an abstract designator because
fragments require no only that one retrieve and interpret a
resource (or, more specifically, a "potentially retrieved
representation"), but that the resource have a media type.  If
you think that distinction needs clarification, please suggest
text.  And, unless you can convince the WG that "service" should
be dropped, I'm certainly open to other choices of wording.

>    identified by a URN, or to applications that manage such
> resources,    is handled by q-components as described in the
> previous section.)"
> 
>   "For various purposes such as caching, it is often desirable
> to    determine if two URNs are 'the same'."
> 
>    ...
> 
>   "If a q-component, r-component, or f-component (or any
> combination    thereof) are included in a URN, they MUST be
> ignored for purposes of    determining equivalence."
> 
> These two seem in contradiction to one another, at least
> insofar as q- and probably r-components are concerned.  Surely
> for caching purposes distinct q-components must mean
> inequality?  Otherwise asking for my booking to Amsterdam
> might get me your booking for New York, if I made the request
> via a URN for a flight-booking service including surname and

Text would be welcome.  Personally, I can argue either way for
including (or excluding) q-components and/or r-components from
equality comparisons, but, as you note, the WG has been around
that loop several times.  I'll leave it up to the WG Co-Chairs
whether reopening it is reasonable.  One way or the other please
note that 2141bis inherits two equality-testing problem from
3986: until one understands the details of the resource (sic)
and, in the URN case, the namespace, one cannot prove equality
(or, for that matter, inequality).   As far as I can tell,
Section 6 of 3986 does not discuss the application of queries in
comparisons even though it explicitly excludes fragments.  One
can only demonstrate that equality or inequality is not
disproven.   I recommend a careful reading of section 6,
particularly 6.2, of 3986 to anyone who wants to venture into
this swamp.

>   [No issues, this is a good compromise wrt previous disputes,

thanks.

best,
   john

---

From: Sean Leonard <[email-masked]>
Date: Tue, 3 May 2016 17:36:48 -0700

> are unchanged from 2141 that should be called out, how would you

I am calling this out specifically because it was called out by someone 
else. It's not general advice.

The problem with RFC 2141 in that regard, is simply that it doesn't say 
anything about length limits in the prose. It's only in the ABNF. The 
length limit is "material" in the sense that it's a part of the NID 
definition. Therefore, I would modify the text to say:

      2.1
      <https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-16#section-2.1>.
      Namespace Identifier (NID)

    Namespace Identifiers (NIDs) are case insensitive, limited
    to 32 characters, and MUST NOT begin or end with a hyphen.

You could also modify the text in 5.1 to say something, but I would 
recommend putting the limitation in the prose in Section 2.1. Notably, 
5.1 says quite a bit about NIDs but nothing about the length limit in 
particular. I take it that 5.1 is a limit on *formal namespace 
registrations*, not NIDs as a whole. Therefore, the NID <xn--foobar> is 
syntactically valid and a URN parser is supposed to accept it; it just 
can't be registered under the current rules. A URN parser ought to 
reject a URN-like string that contains a really long NID, in contrast.

Overall it's obvious that a NID is supposed to be compatible with the 
DNS. Not sure if this should be called out more than it already is 
(subpoint 5 in Section 5.1), but I assume that RFC 2141's length 
limitation has at least something peripherally to do with that.

[Note: going to deal with "resource" in another e-mail.]
> about it for more months.

I have no problems with the current text in terms of how the comparison 
procedurally operates. I do share Henry's concern about the cavalier use 
of the term "equivalence". Make up a different term, fit the term into 
the RFC 3986 framework, and stick with it. I have proposed a term 
already: Name the Same Thing. (Not a joke.) It's concise and gets across 
exactly what's going on.

Sean

---

From: Julian Reschke <[email-masked]>
Date: Wed, 4 May 2016 08:18:24 +0200

>  seems to me a distinction without a difference.

Actually, the abstract conflicts with that view as well:

    A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI)
    that is assigned under the "urn" scheme and a particular URN
    namespace, with the intent that the URN will be either a persistent,
    location-independent resource identifier or in some cases an abstract
    designator that is persistent but that does not identify a resource.

So that implies that there are URNs that do not identify anything. I'm 
not sure what the point of this claim is; is there are concrete example 
of this class of URNs we could discuss?

Best regards, Julian

---

From: Sean Leonard <[email-masked]>
Date: Tue, 3 May 2016 23:47:14 -0700

On "resources":

> followed by some examples and general comments.

"Resource" is not defined by what the thing is. It is defined by the 
speaker's relationship to the thing, namely, to draw upon it.

The Random House Dictionary says: resource: "a source of supply, 
support, or aid, especially one that can be readily drawn upon when needed."

The 3986 definition might sound a bit circular, *but* it is also 
perfectly precise for our purposes. A resource is that which might be 
identified by a URI. 3986 Section 3.5 further clarifies primary vs. 
secondary resource. The stuff before # identifies a resource (also known 
as absolute-URI).

The dictionary definition is "source of supply...*that can be readily 
drawn upon when needed*". I.e., a key function of URIs, as distinct from 
other forms of identification, is that you can draw upon it (i.e., 
*dereference* it) when needed. URNs are not specific to any particular 
location on the network...therefore the name part of URN is not 
dependent on network topology/state.

So, what's not a resource? For one thing, URN resolvers and other 
network components that assist in the dereferencing process of a URI are 
*not* resources (in the RFC 3986 sense). They are services.

:80 (port 80) is some network element. It is a resource in the generic 
sense, but not in the RFC 3986 sense when it appears in 
<http://example.com:80/foo>. Similarly, example.com is also not a 
resource in the RFC 3986 sense in this example. It is an identifier for 
a server (service) that is used in the dereferencing process, that 
ultimately gives resource(s) back when <http://example.com:80/foo> is 
dereferenced. When people say that <http://example.com:80/foo> is a 
resource, they mean that <http://example.com:80/foo> is the identifier 
that a URI dereferencer can dereference to get that (named) resource(s).

dns:example.com?claSS=IN;tYpE=A is an identifier for the example.com DNS 
IPv4 address records. The records are the resource(s). But when people 
refer to "example.com" in the generic sense, they are probably not 
referring to the IP address records specifically, but rather to the 
(web) server(s) that are pointed to by the DNS IP address (and other) 
records.

Clear?

> And the status of an abstract designator is still unclear.

The term "abstract designator" was introduced in draft-13, and was 
useful at the time. I believe its utility has ended. My vote is to 
remove the distinction from rfc2141bis.

The reason is because all URNs can potentially get resolved (i.e., 
turned into resources by software processes), even if a namespace author 
doesn't intend it.

A namespace registrant can say: ok, I am creating <urn:klingon> and 
there is this "abstract designator" <urn:klingon:Qu'vatlh>. Then 
someone, somewhere in the Universe, creates a URN resolver that accepts 
<urn:klingon:Qu'vatlh> and returns an image/jpeg of an angry Worf.

Now <urn:klingon:Qu'vatlh> is no longer so abstract. So the namespace 
registrant gets upset: "hey, you weren't supposed to do that! You made 
my namespace more useful! Stop!" That is silly. People will do what they 
want.

Practically, people want to use URNs to resolve to resources. Otherwise, 
why would they be shoehorning abstract identifiers into URI protocol slots?

Sean

---

From: [email-masked] (Henry S. Thompson)
Date: Wed, 04 May 2016 12:23:27 +0100

John C Klensin writes:

> reason . . .

I guess my view is this kind of limit is the wrong response to that kind
of issue.  My preference is not to try too hard to protect people from
themselves, particularly if doing so puts hard barriers in place which
some unforeseen downstream users may have good reason to be frustrated
by.

I also note that it would be entirely appropriate for the Expert
Reviewer to recommend reconsideration of egregiously unmemorable or
difficult to distinguish NIDs in their reviews, and a _recommendation_
in favour of short and distinctive NIDs in the spec would be a good
thing.

But, I did classify this as minor, and I certainly won't lie down in the
road over it.

ht

---

From: [email-masked] (Henry S. Thompson)
Date: Wed, 04 May 2016 14:19:05 +0100

John C Klensin writes:

>> anything and everything that might be identifiable, from the easy
>> (what TimBL calls "information resources") to the ineffable (the
>> weather in Oaxaca), the imaginery (unicorns) and the abstract
>> (democracy), and certainly including services.  So I'm unsure what
>> the distinction is that you're trying to get at here.  Particularly
>> as in practice any actual response to the use of a URN comes from
>> some system, so making a distinction between passing a parameter to a

And John also wrote, on Tue, 03 May 2016 18:06:00 -0400 in reply to Sean

> See my response to Henry but also note that what 3986 appears to say
> (and how he interprets it if I correctly understood his note) is that
> "resource" can refer to very nearly anything.  Meaning exactly what
> 3986 says would require that 3986 be a great deal more specific than
> the entirely circular definition of 3986 which reads "This
> specification does not limit the scope of what might be a resource;
> rather, the term "resource" is used in a general sense for whatever
> might be identified by a URI."  followed by some examples and general
> comments.

I think there's a misunderstanding here about the word 'resource' as
used in 3986 and other writings (e.g. the W3C TAG'S AWWW [1]).  It
cannot be understood as naming a pre-existing natural kind, some
sub-category of all the possible categories, some node in a universal
complete taxonomy.  There is no set of tests which can be performed on
some candidate for membership in the set of resources _in terms of
properties local to said candidate_ which will determine whether or not
it is in fact a resource.

The point of the above-quoted definition from 3986 is to establish
'resource' as a convenience term of art, a shorthand for "that which is
identified by [this/some] URI".  In a previous century we would have
used _identificandum_.

The ordinary language word 'referent' is an illuminating non-technical
parallel case: no examination of an object will allow you to tell
whether it is a referent or not: truthfully labelling something a
referent simply requires that some word or expression has been used to
refer to it.

(It's perhaps worth noting a further parallel: Contesting such a
labelling requires appealing to the person who produced the referring
word or expression: when you said such-and-such, what did you mean to
refer to?  And as far as 3986 is concerned, the same is true for URIs:
the ultimate authority for questions about what is identified by a URI
is, and can only be, the minter of that URI.)

It follows, I think, that urnbis can use 'resource' in exactly the way
it is used in 3986, referencing 3986 for that purpose in section 1.1.

Indeed it _should_ do so, because otherwise it does what it accuses 3986
of doing, only more so, by using both 'resource' and 'service' without
defining them, or explaining how to tell which of the two is identified
by a URN.

ht

[1] https://www.w3.org/TR/webarch/

PS  The fact that 3986 doesn't come particularly clean about how one
might in principle answer questions of the form "What is identified by
this URI" or "Can I use this URI to identify [...]" is arguably a bug.

urnbis is in a particularly good position to fix this for URNs.

Something to address such questions for URNs should, I suggest, be added
to the list of requirements on namespace definers.
-- 
       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: Wed, 04 May 2016 14:42:19 +0100

John C Klensin writes:

> My reading of 3986 suggests that one cannot have a fragment with an
> abstract designator because fragments require no[t] only that one
> retrieve and interpret a resource (or, more specifically, a
> "potentially retrieved representation"), but that the resource have a
> media type.  If you think that distinction needs clarification, please
> suggest text.

A different reading is widely shared, and heavily relied on by a
substantial part of the Semantic Web.  Indeed I think 3986 explicitly
contradicts what you say:

  "The semantics of a fragment identifier are defined by the set of
   representations that _might_ result from a retrieval action on the
   primary resource.  The fragment's format and resolution is therefore
   dependent on the media type [RFC2046] of a _potentially_ retrieved
   representation, even though such a retrieval is only performed if the
   URI is dereferenced.  If _no such representation exists_, then the
   semantics of the fragment are considered unknown and are effectively
   unconstrained."  [1], emphasis added

Note further that 3986, for better or worse, is careful to distinguish
representations from resources: resources are what a URI identifies,
representations are what you can retrieve using a URI.  They are not the
same.  Resources don't have media types, representations do.

I read the above quote from 3986 as studiously _allowing_ precisely what
I understand you to want, namely, that for abstract designators (that
is, URNs for which no resolution service is provided or envisaged) the
interpretation of a fragment identifier is unconstrained _by 3986_.

Having said all that, I'm not sure this has any bearing on the point at
issue, which was the 'resource'/'service' distinction.

ht

[1] https://tools.ietf.org/html/rfc3986#section-3.5

---

From: Sean Leonard <[email-masked]>
Date: Wed, 4 May 2016 07:07:23 -0700

On 5/4/2016 6:19 AM, Henry S. Thompson wrote:
> [...]

+1. This.

> urnbis is in a particularly good position to fix this for URNs.

Yes.

Sean

---

From: [email-masked] (Henry S. Thompson)
Date: Wed, 04 May 2016 15:43:00 +0100

> (or, for that matter, inequality).

Indeed, and 3986 explicitly acknowledges the impossibility of such
proof.  It accordinly goes on to establish the goal of section 6.2 [2]
as analysing the trade-off between false-negative rates (for
string-based tests) and computational effort, on the basis that e.g. for
caching it's false negatives that are wasteful, and therefore worth
_some_ effort to avoid.

Note further that 6.1 [1] includes a claim that the methods defined in
6.2 "strictly avoid... false positives", which I believe is in fact the
case.

> As far as I can tell, Section 6 of 3986 does not discuss the
> application of queries in comparisons even though it explicitly
> excludes fragments.

The exclusion of fragments makes sense (in the stated context of
(potential) retrieval), because e.g. HTTP mandates that frag-ids are
stripped before GET requests are issued (consistent with their retrieved
media-type dependence).  I read the _absence_ of any _other_ exclusion
as pretty definitively _including_ the query-string in the comparison,
since we're talking about URI comparison, and the production for URI
includes the query-string.  And the desire to avoid false positives, per
my example above, seems like a likely explanation for that.

Also note the following:

  "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)." [3], emphasis added

So queries are part of a URI's identification function, and it follows
that syntax-distinct queries _may_ identify different URIs, so for the
avoidance of false positives they must be included in any comparison.

All of which leaves me perplexed as to why the WG has declined to treat
the q-component as part of the identifying function of a URN, but, as
you said, it's up to the co-chairs to re-open this if they choose.

I note that _with respect to 3986_, the q-component _is_ a query (as is
the r-component, if it comes first), and so any _generic_ URI processor
will include it in its comparison algorithms.  I'm not sure whether this
is obliquely recognised by the following in the first para of 3.1:

  If comparisons are made in a scheme- independent way, i.e., as URI
  comparisons only, URNs that this specification considers equal would
  be rejected.

That is, for my air-travel example, 3986-compliant web browsers that
follow the example in 3986 and pick Syntax-Based Normalization [4] to
determine link-colouring would _not_ colour a link to
urn:example_airtix:booking?=surname=Thompson&id=xyzzy differently
before/after a visit to
urn:example_airtix:booking?=surname=Klensin&id=zyxxz, whereas per urnbis
as it stands a urn:-aware tool, which chose Scheme-Based Normalization [5],
_would_ do so.

>> [Suggested edits] would be welcome

 Replace the existing final two sentences of para. 1 of section 3.1
 (the one quoted above and the one following) with:

  If comparisons are made in a scheme-independent way, that is, using
  the Simple String Comparison or Syntax-Based Normalization steps on
  the Comparison Ladder defined in section 6.2 of [3986], URNs that this
  specification considers equal will compare as not equal.

  Although such an approach may be appropriate for generic URI-level
  processing, as for example when a browser checks its history to color
  link text or a cache is probed for a locally-available retrieval
  response, for URN-specific tasks such as [fill in some credible
  example here, I can't think of one], a stronger equality standard is
  desirable.  Accordingly there follows below a specification of what
  [3986] calls Scheme-Based Normalization, which may be the preferred
  comparison approach when the URIs involved are known to be URNs.

ht

[1] https://tools.ietf.org/html/rfc3986#section-6.1
[2] https://tools.ietf.org/html/rfc3986#section-6.2
[3] https://tools.ietf.org/html/rfc3986#section-3.4
[4] https://tools.ietf.org/html/rfc3986#section--6.2.2
[5] https://tools.ietf.org/html/rfc3986#section--6.2.3
-- 
       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: Sean Leonard <[email-masked]>
Date: Wed, 4 May 2016 09:32:52 -0700

> On May 3, 2016, at 3:06 PM, John C Klensin <[email-masked]> wrote:
> 
>> ...

Just call it something else. Other than naked “equivalence”. Calling it “equivalence” without calling it something else or adding some qualifier to say what kind of equivalence the document is talking about, is confusing.

Henry and I already independently pointed out that it is a kind of Scheme-Based Normalization (see <mid:[email-masked]>).

Sean

---

From: "Hakala, Juha E" <[email-masked]>
Date: Wed, 11 May 2016 04:53:57 +0000

Hello, 

some comments below 

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of Sean Leonard
> Sent: 4. toukokuuta 2016 17:07
> To: [email-masked]
> Subject: Re: [urn] Minor comments on draft-ietf-urnbis-rfc2141bis-urn-16
> 

It is not this simple in the URN environment. Assignment of URNs is a managed process, and the agency which is responsible of the namespace provides the rules for what can be identified by URNs in that namespace. So an organization - for instance, a publisher - which mints a URN from urn:isbn namespace is not an authority, but just applying its narrow mandate to identify its own books. The authority is limited to saying that this urn:isbn identifies this book. And if the publisher makes a mistake - such as a typo in isbn, or re-assignment of isbn that has already been used, etc. - the national ISBN center will correct the problem. 

Assignment of URIs is very seldom a managed process in any sense that communities using persistent identifiers would use in the context. 
  
> > Indeed it _should_ do so, because otherwise it does what it accuses
> > 3986 of doing, only more so, by using both 'resource' and 'service'
> > without defining them, or explaining how to tell which of the two is
> > identified by a URN.

Each URN namespace has its own view of which resources can be identified. Scopes of namespaces will overlap, and some namespaces may have much broader scopes than others, but namespace registrations and possibly some additional documentation will still describe what kind of resources are identifiable. Since there are these descriptions of what identifiable resources are, IMO URN syntax document does not need to give a generic definition of what a resource is. On the other hand, we do not know the scopes of future namespaces, and therefore it would only be possible to give a very generic definition, like URI 3986 does.  

According to RFC 3986 resource can be anything, from - literally - zero to infinity. I am not sure how useful that kind of "definition" is when we talk about resource identification in any proper sense of the word. Broad definition creates an impression that assigning URIs to these resources cannot even in principle be a managed process. According to RFC 3986 anyone can identify anything and somehow this does not result in a mess. In the light of practical experience of e.g. URI longevity this seems optimistic. 

> > this URI" or "Can I use this URI to identify [...]" is arguably a bug.

It is not possible to always answer these questions unless URI assignment in its entirety is a well managed process, which it is not, either now or in the future. I mean, it may be possible to manage URIs in small, controlled environments such as W3C web server, but in the Web scale it seems to be impossible to achieve sufficient control, in spite of efforts to provide guidelines on how to create URIs and keep them alive. 
 
> > urnbis is in a particularly good position to fix this for URNs.

Yes, provided that namespaces are properly managed. This does not need to be the case, if IETF approves namespace registrations which are not solid enough. 

Best regards, 

Juha

> 
> Yes.
> 
> Sean
> 
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn