Subject: [urn] 2141bis Section 6 Conformance consensus

From: Andrew Newton <[email-masked]>
Date: Mon, 17 Nov 2014 09:16:22 -1000

All,

Since there was a great deal of discussion around URI conformance and
specifically the relative resolution process, I'd like to ask the
group if they have any issues with Section 6 of 2141bis. So, have you
read the draft, in particular section 6? And if so, do you have any
changes you'd like to see to the text? If so, why?

-andy,
co-chair

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Nov 2014 08:21:47 +0100

> changes you'd like to see to the text? If so, why?

Is this a question about 
<https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-08#section-5>? 
In which case:

> 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 makes sense in practice to place a URN

maybe s/makes sense/always makes sense/

>    in a given URI protocol slot; in particular, because a URN does not
>    specify the location of a resource, it is not 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]).

It's not clear to me why it would be wrong to use a URN in a/@href.

>    Despite the fact that URNs are not hierarchical and are not
>    appropriate for use as a base URI (see Section 5.1 of [RFC3986]), the
>    relative resolution algorithm specified in Section 5.2 of [RFC3986]
>    still applies to the "urn" URI scheme; implementers need to be aware,
>    however, that running the algorithm against URNs can lead to results
>    that are unexpected or not useful.

+1

> ...

Best regards, Julian

---

From: Andrew Newton <[email-masked]>
Date: Tue, 18 Nov 2014 08:40:24 -0500

> <https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-08#section-5>?

Yes, section 6. Sorry for the confusion.

-andy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Nov 2014 14:46:10 +0100

> Yes, section 6. Sorry for the confusion.

Five :-)

---

From: Andrew Newton <[email-masked]>
Date: Tue, 18 Nov 2014 08:50:47 -0500

Coffee, now!

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 19 Nov 2014 19:34:36 +0900

I just changed the subject to align it with the content :-).

Regards,   Martin.

On 2014/11/18 22:50, Andrew Newton wrote:
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn
>

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 20 Nov 2014 14:33:35 +0000

> maybe s/makes sense/always makes sense/

Yes, this is very important.

> It's not clear to me why it would be wrong to use a URN in a/@href.

In fact, it's clear to me that it will often make sense to use URNs in
a/@href and even image/@src, and it will become increasingly common to
do so, if implementation of registerProtocolHandler [1] becomes
widespread.  I note that 'urn' is already specified as a whitelisted
(i.e. open to have a handler registered).

Just as I expect the DOI folks to provide support for doi: URIs via a
(misnamed, I agree) 'protocol' handler, so the ISBN folks could
register a handler for 'urn' URIs, (and start a turf war, until the
WebApps WG allows registration of handlers for specific URN
namespaces).

See the sub-thread starting with Mark Baker's mention of
registerProtocolHandler [2] for further examples.

ht

[1] http://www.w3.org/TR/html5/webappapis.html#dom-navigator-registerprotocolhandler
[2] http://www.ietf.org/mail-archive/web/urn/current/msg02232.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]