Subject: Re: [urn] 2141bis questions - (4) Section 5 on URI Conformance

From: John C Klensin <[email-masked]>
Date: Wed, 21 Jan 2015 11:51:08 -0500

--On Tuesday, December 23, 2014 11:49 -0700 Peter Saint-Andre -
&yet <[email-masked]> wrote:

> On 12/23/14, 10:44 AM, John C Klensin wrote:
>> We've had some on-list discussion about the wording of parts
>> of Section 5 of 2141bis.  I think we've reached general
>> agreement about some of the language in the first paragraph
>> or two and Peter or I will post draft text sometime soon to
>> see if it is actually what the WG intends.
>> 
>> However, a careful reading of the rest of that section turns
>> up several related issues.   Before trying to write and
>> circulate draft text, I want to verify that it is the view of
>> the URN WG that precise rules (and constraints and
>> restrictions) for the use of URNs embedded in various
>> contexts is the job of the definitions for those contexts,
>> not 2141bis or other generic URN documents.
>...
>> On particular, while 2141bis can (and probably should) offer
>> general guidance for issues a context/usage designer should
>> think about, decisions about what can, or cannot, appear with
>> href in <a> elements are a matter for HTML, not this
>> specification.
> 
> Very much +1.
> 
>> Is the WG in enough agreement about that to allow us to draft
>> text?
> 
> Yes, please.

Having heard from no one other than Peter, I propose the
following text as the first part of Section 5 on Conformance:

   5.  URI Conformance

   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 may not specify the location of a resource or even point
   indirectly to one, it may 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 URNs, or
   URNs that reference particular namespaces, are the
   responsibility of descriptions of individual URI schemes and
   contexts; this specification cannot possibly anticipate all
   of the relevant cases.

That paragraph incorporates not only the "pointer to somewhere
else" suggested by this question but also contains the
adjustments suggested by Julian and others for the prior "makes
sense" language.

Tuning or other suggestions welcome.

     john

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Sat, 24 Jan 2015 20:17:31 -0700

> adjustments suggested by Julian and others for the prior "makes

That looks good to me. Personally I'd change "may not" to "might not" in 
both instances, but then avoiding lowercased versions of RFC 2119 
keywords is one of my hobbyhorses.

Peter

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

---

From: John C Klensin <[email-masked]>
Date: Sun, 25 Jan 2015 04:38:26 -0500

--On Saturday, January 24, 2015 20:17 -0700 Peter Saint-Andre -
&yet <[email-masked]> wrote:

>>     URN may not specify the location of a resource or even
>>     point indirectly to one, it may 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 URNs, or URNs that reference
>>     particular namespaces, are the responsibility of
>>     descriptions of individual URI schemes and contexts; this
>>     specification cannot possibly anticipate all of the
>>     relevant cases.
>> 
>> adjustments suggested by Julian and others for the prior
>> "makes sense" language.
> 
> That looks good to me. Personally I'd change "may not" to
> "might not" in both instances, but then avoiding lowercased
> versions of RFC 2119 keywords is one of my hobbyhorses.

Both instances changed in my working copy.  Wait until you find
out about my hobbyhorses :-)

   john

---

From: Julian Reschke <[email-masked]>
Date: Sun, 25 Jan 2015 14:04:09 +0100

> Tuning or other suggestions welcome.

I believe I asked this before when a variation of this text was proposed 
before: why wouldn't be appropriate to have a URN in a/@href?

Best regards, Julian

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 26 Jan 2015 13:02:23 +0900

> before: why wouldn't be appropriate to have a URN in a/@href?

I think it might be appropriate for some, but not for others. So I 
suggest to change the text to (including Peter's change) "it might not 
be appropriate to place a certain URN" or some such.

Regards,   Martin.