Subject: [urn] URI contexts (CREF9)

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 11 Mar 2015 20:13:35 -0600

Section 5 states:

    Because a URN is, syntactically, a URI under the "urn" scheme, in
    theory a URN can be placed in any protocol slot that allows for a URI
    (e.g., an XML namespace name [XML-NAMES]).  However, this does not
    imply that, semantically, it always makes sense in practice to place
    a URN in a given URI protocol slot; in particular, because a URN
    might not specify the location of a resource or even point indirectly
    to one, it might not be appropriate to place a URN in a URI protocol
    slot that points to a resource (examples include the 'href' and 'src'
    attributes and the <base/> element in HTML, as well as the 'xml:base'
    attribute in XML [XML-BASE]).  Ultimately, specifications of where it
    is appropriate to use URNs, or URNs created within particular URN
    namespaces, are the responsibility of descriptions of individual URI
    schemes and their expected uses; this specification cannot possibly
    anticipate all of the relevant cases.

Ted suggested "individual URI contexts" instead of "individual URI 
schemes". (CREF9) I wholeheartedly agree, and I thought that I had 
already made a similar change but I see that I had not.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 19 Mar 2015 11:14:50 +0000

> already made a similar change but I see that I had not.

I disagree.  What's a "URI context"?  It's not defined, or even used
earlier in the document.  If it means "context of use", how can that
make sense here?  Suppose we adopted Ted's wording: the result would
read:

    specifications of where it is appropriate to use URNs, or URNs
    created within particular URN namespaces, are the responsibility
    of descriptions of individual URI contexts.

Who is now expected to provide such specifications?  The HTML5
specification, when it talks about the 'href' attribute?  Elsevier, in
some document about authoring guidelines for journal landing pages?
Surely the right place for guidelines about the use of
urn:mynid:... is in the NID definition for 'mynid'.

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 - &yet <[email-masked]>
Date: Thu, 19 Mar 2015 07:19:38 -0600

On 3/19/15 5:14 AM, Henry S. Thompson wrote:
> I disagree.  What's a "URI context"?

I would think of it as the equivalent of a "protocol slot" from IDNA2008 
and PRECIS: a place where a URI can be used.

> It's not defined,

Yes, let's do that.

> or even used
> earlier in the document.

Only by example in that paragraph.

> If it means "context of use", how can that
> specification, when it talks about the 'href' attribute?

Yes.

> Elsevier, in

But this is true of all URNs and is not namespace-specific.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 19 Mar 2015 17:24:31 +0000

Peter Saint-Andre - &yet writes:

>>>     ... Ultimately, specifications of where it is appropriate to
>>>     use URNs, or URNs created within particular URN namespaces,
>>>     are the responsibility of descriptions of individual URI
>>>     schemes and their expected uses; this specification cannot
>>>     possibly anticipate all of the relevant cases.
>>>
> I would think of it as the equivalent of a "protocol slot" from
> IDNA2008 and PRECIS: a place where a URI can be used.
>
>> It's not defined,
>
> Yes, let's do that.
>
>> or even used earlier in the document.
>
>> Elsevier, in some document about authoring guidelines for journal
>> landing pages?  Surely the right place for guidelines about the use
>> of urn:mynid:... is in the NID definition for 'mynid'.
>

I'm confused.  The text quoted above from (5) says "where it is
appropriate to use URNs, or URNs created within a particular URN
namespace".  That _makes_ this, at least to some extent,
namespace-specific, doesn't it?  And so, I think, it should.

I have been assuming this para. is here to address concerns about the
appropriateness of e.g. constitutionally unresolvable URNs appearing
in retrieval-expected slots.  Being constitutionally unresolvable is a
property of URNs from URN namespaces whose constitution makes that a
requirement.  Surely it follows that the right place for advice about
appropriate contexts of use then is in that constitution, where you
can say "So, don't use these in contexts that imply retrieval,
e.g. HTTP GET or anywhere that might result in HTTP GET".

It feels impractical to the point of inviting consternation from our
readers to suggest, as I think I understand your reply above, that
_every possible_ context of use of should note that you shouldn't put
constitutionally-unresolvable URNs there.

ht

---

From: John C Klensin <[email-masked]>
Date: Thu, 19 Mar 2015 14:42:00 -0400

--On Thursday, March 19, 2015 17:24 +0000 "Henry S. Thompson"
<[email-masked]> wrote:

> I have been assuming this para. is here to address concerns
> about the appropriateness of e.g. constitutionally
> unresolvable URNs appearing in retrieval-expected slots.
> Being constitutionally unresolvable is a property of URNs from
> URN namespaces whose constitution makes that a requirement.
> Surely it follows that the right place for advice about
> appropriate contexts of use then is in that constitution,
> where you can say "So, don't use these in contexts that imply
> retrieval, e.g. HTTP GET or anywhere that might result in HTTP
> GET".
> 
> It feels impractical to the point of inviting consternation
> from our readers to suggest, as I think I understand your
> reply above, that _every possible_ context of use of should
> note that you shouldn't put constitutionally-unresolvable URNs
> there.

My response, not Peter's (I have no idea whether we agree on the
details at this level or note):

I agree with the above, but there is another side of this, which
is that there should not be statements in docs that define URI
references that say, e.g., "every URI is usable in the context
of <a href...>".  The statements in those places really need to
either be a little more equivocal or to confine themselves to
URIs where they know what they are talking about.

At least IMO, suggestions for text that would say that, together
with what the document now says and your observation about
"constitutional unresolvability" in a way that would be clear
would be most welcome.

That said, "constitutionally-unresolvable" is not the only issue
that concerned me.  As has been discussed on this list in the
past, there is a great deal of potential for URNs that do
resolve but whose resolution is a multi-step process that might
involve either external information (e.g., knowing the network
location of the client application requesting resolution
obtaining a URL that was appropriate to that location and then
resolving the URL) or analysis or one or more of p-components,
q-components, or f-components (but most likely q-components) to
determine, to invoke a first-generation library computer
automation joke, whether a URN associated with a namespace for
cat information should, on resolution, return pictures of cats,
descriptions of cats, or sample cats in designated states of
repair [2].

Both of those hypothetical URNs resolve, so there is no
"constitutional unresolvability".   Whether they are appropriate
for use in an HTTP <a href> context (or any similar context in
any other format that might be associated with invocation of
URIs) really should not -- can not-- be the responsibility of
URN specifications, even per-namespace ones, to specify.  On the
other hand, we should be sure that namespace specifications and
registrations are adequate for systems in those various contexts
to make appropriate determinations and I really hope we can do
that without creating a formal typology of URN namespaces.

best,
    john

[1] Capitalized if you like, but here we get into issues about
what URN specs can demand of specs like HMTL(n).

[2] And, no, I don't want to touch the question of a fragment
identifier in that context, especially wrt separation of the
cat-fragment from the cat.  :-(

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 23 Mar 2015 20:59:28 -0600

On 3/19/15 12:42 PM, John C Klensin wrote:
> I agree with the above,

Probably the clause "or URNs created within particular URN namespaces" 
is confusing. I don't want to forestall the use of URNs from some 
particular (perhaps future) URN namespace from being appropriate for use 
in individual URI protocol slots, but it's likely best to leave out such 
future-proofing text at this time.

> but there is another side of this, which

Agreed. It might not be appropriate to put a 'data' or 'iax' or 'info' 
or 'tag' URI in the 'xml:base' attribute, and it's the responsbility of 
the XML-BASE spec to say what's appropriate there.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 23 Mar 2015 21:03:55 -0600

> the XML-BASE spec to say what's appropriate there.

Would the following text be agreeable?

    Because a URN is, syntactically, a URI under the "urn" scheme, in
    theory a URN can be placed in any protocol slot that allows for a URI
    (e.g., the 'href' and 'src' attributes in HTML, the <base/> element
    in HTML, the 'xml:base' attribute in XML [XML-BASE], and the 'xmlns'
    attribute in XML for XML namespace names [XML-NAMES]).  However, this
    does not imply that, semantically, it always makes sense in practice
    to place a URN in a given URI protocol slot; in particular, because a
    URN might not specify the location of a resource or even point
    indirectly to one, it might not be appropriate to place a URN in a
    URI protocol slot that points to a resource (e.g., the aforementioned
    'href' and 'src' attributes).  Ultimately, guidelines regarding when
    it is appropriate to use URIs under the "urn" scheme (or any other
    scheme) are the responsibility of specifications for individual URI
    protocol slots (e.g., the specification for the 'xml:base' attribute
    in XML might recommend that it is inappropriate to use URNs in that
    protocol slot).  This specification cannot possibly anticipate all of
    the relevant cases, and it is not the place of this specification to
    legislate usage for individual protocol slots.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: "Svensson, Lars" <[email-masked]>
Date: Wed, 25 Mar 2015 15:39:48 +0000

On Tuesday, March 24, 2015 4:04 AM, Peter wrote:

> To: John C Klensin; Henry S. Thompson
> Cc: [email-masked]
> Subject: Re: [urn] URI contexts (CREF9)
> 

Works for me.

Best,

Lars