Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs

From: Juha Hakala <[email-masked]>
Date: Mon, 05 Jan 2015 13:23:20 +0200

Hello,

On 25.12.2014 8:28, John C Klensin wrote:
> The first part of Section 7, "Defining a URN Namespace",
> outlines broad requirements.  Under item (2), it seems
> worthwhile to clarify that the status of *-components be
> specified here (it is explained in more detail in Section 7.2,
> as promised).
>
> Suggestion:
>
> Old:
> 	2.  The syntax of URNs assigned within the namespace.
>
> New:
> 	2.  The syntax of URNs assigned within the namespace,
> 	including whether p-, q-, and/or f-components are
> 	allowed.

+ 1.

The downside of this is that people creating registration requests must 
find out what the implications of these components are for their 
identifier systems. But it should be easy both to supply this 
information, and to check if the information provided in the 
registration request is OK.

Namespaces which do not intend to support resolution services should not 
allow q-component. Namespaces which deal with digital manifestations may 
be able to support f-component.

The namespaces I am familiar with will at least for the time being not 
use the p component even if it were technically possible to do so.

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

-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. +358 9 191 44293
  Mobile +358 50 3827678

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 06 Jan 2015 12:03:10 +0900

> be able to support f-component.

We should make sure we write so in the draft.

Regards,   Martin.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 12 Jan 2015 18:39:58 -0900

> We should make sure we write so in the draft.

If nobody has any issues with this, we'll consider it closed.  The
resolution is that the draft will include John's "New" text along with
some text along the lines of what Juha specified.

Melinda

---

From: "Svensson, Lars" <[email-masked]>
Date: Tue, 13 Jan 2015 08:21:47 +0000

> some text along the lines of what Juha specified.

Looks good to me.

Best,

Lars

---

From: Sean Leonard <[email-masked]>
Date: Tue, 13 Jan 2015 01:31:39 -0800

> some text along the lines of what Juha specified.

Ehhhhhhhhhhh...........I have some issues with this.

"Namespaces which deal with digital manifestations may be able to 
support f-component."

Does this imply that namespaces which deal with digital manifestations 
must describe how the f-component is used, in order to be syntactically 
valid or otherwise usable? (What are the consequences of tacking on an 
f-component anyway?)

Does this imply that namespaces which do not deal with digital 
manifestations, do not support f-component?

Consider f-components for urn:oid and urn:uuid. OIDs are assigned to 
arbitrary objects, including documents, standards, and the like. UUIDs 
are assigned to arbitrary objects as well, including (especially) 
specific instances of digital data.

In my organization, every document gets at least one OID (actually 
multiple OIDs, depending on the version of the document). In some 
standards organizations (e.g., ISO, ITU-T), standards get an OID or OID arc.

Thus, in the abstract, urn:oid:1.0.4217#EUR could well refer to the Euro 
currency. (ISO 4217 is the standard for currency identifiers.)

Thus, concretely, urn:uuid:62f2ac03-9422-43b6-a599-c712be931d4a#tabs 
refers to the Microsoft Answers forum thread started January 6, 2015, 
with the subject "Weather module on my Home Page doesn't remember my 
location". It is served at 
<http://answers.microsoft.com/en-us/ie/forum/ie11-iewindows8_1/weather-module-on-my-home-page-doesnt-remember-my/62f2ac03-9422-43b6-a599-c712be931d4a#tabs> 
as Content-Type: text/html, and has an anchor "tabs" in the HTML. To my 
knowledge (extended by Google, heh), nobody else in the universe is 
using 62f2ac03-9422-43b6-a599-c712be931d4a for any other purpose.

Make sense?

Overall I do not believe that these use cases of URNs (in urn:oid and 
urn:uuid) should be foreclosed. Even if the URN NID registration does 
not envision the use of f-components, an application (e.g., a database 
or content management system) should be able to use f-components for its 
purposes when it knows some specific stuff about the identifier. This is 
especially important for generic NID registrations like oid and uuid, 
where the identifier can identify pretty much any arbitrary thing.

I have nothing good to say about q-components, and therefore have no 
comment on that production.

Sean

---

From: Melinda Shore <[email-masked]>
Date: Tue, 13 Jan 2015 20:52:23 -0900

We haven't seen any responses to Sean's comments and I'm not
sure whether to read that as agreement, disagreement, or "meh."
Thoughts?

Melinda

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 14 Jan 2015 19:20:54 +0900

Hello Melinda,

> sure whether to read that as agreement, disagreement, or "meh."

I started to write an answer yesterday, but got stuck. I agree with 
Sean. While there will be some correlation between URN namespaces and 
fragment identifiers (f-components for those who prefer that term), as 
Sean says, fragment identifiers and their interpretation is defined by 
the MIME media type of a resource obtained when resolving an URI, and 
therefore any mention in a namespace registration document can and 
should only be advisory, if at all.

Regards,   Martin.

---

From: Juha Hakala <[email-masked]>
Date: Thu, 15 Jan 2015 14:53:33 +0200

Hello Sean,

Some thoughts below.

>> valid or otherwise usable? (What are the consequences of tacking on an

IMO it is not really necessary to describe how the f-component is used. 
F-component and q-components are not part of the NSS and have no role in 
identification, so any guidelines the community may have about the use 
of the identifier can exclude these components.

On the other hand, using the f-component is easy and works in the same 
way in each namespace which deals with manifestations of digital 
resources: if the identified resource has fragments, a user can attach 
the f-component to the URN. It will have zero impact to the resolution 
of the URN; the identified resource will be retrieved, and the client 
will apply the fragment to it.

>> manifestations, do not support f-component?

I don't see how they  could. Of course that depends on how we define 
manifestation. My definition is fairly exhaustive. Be that as it may, 
people who register namespaces should know if f-component is applicable 
or not. For instance, it cannot be used in a meaningful way in e.g. ISSN 
namespace, since ISSNs identifies the entire serial, not its individual 
volumes / issues / articles.
>> specific instances of digital data.

OK. I assume that some of these objects will support fragments, some 
won't. In this respect OID and UUID are no different from ISBN. There is 
no requirement that all manifestations which are within the scope of the 
identifier will support f-component. In fact, it is unlikely that there 
are namespaces out there which would guarantee f-component support for 
each identified resource. That is not a problem; f-component is an 
add-on which provides some additional functionality on the client side 
but has zero impact on e.g. URN resolution (or identification).

>> using 62f2ac03-9422-43b6-a599-c712be931d4a for any other purpose.
Yes, of course, although I am afraid that the URN identifying that 
discussion will not remain actionable for long.

>> where the identifier can identify pretty much any arbitrary thing.
Yes, if the scope of the namespace is very broad, it is likely that 
there are at least some resources which may support fragments.

>> comment on that production.

I hope that in the future you'll find some uses for q-components as well.

All the best,

Juha

-- 

  Juha Hakala
  Senior advisor

---

From: "Svensson, Lars" <[email-masked]>
Date: Mon, 19 Jan 2015 14:30:52 +0000

Hello Juha and Sean,

> Some thoughts below.
[...]
> >> valid or otherwise usable? (What are the consequences of tacking on an
 
I think the operative word is "may": " Namespaces which deal with digital manifestations may be able to support f-component." I don't read anything that *only* namespaces that deal with digital manifestations may use f-components, nor that all such namespaces *must* support it.

> of the identifier can exclude these components.

Yup.

> will apply the fragment to it.

I think this depends on how your resolution service works. It's true for http-based resolvers (which probably will be the most common ones for the next future). I don't think it would be the same for an ftp-based resolver, since to my knowledge ftp-URIs are not aware of fragment identifiers (rfc 959 precedes 3986...).

> but has zero impact on e.g. URN resolution (or identification).

I guess there will be namespaces that definitely will not support f-components, some that definitely will and some that will leave the question open (e. g. OID and UUID). If the namespace does not intend to support resolution, it really will not matter.

> >> <http://answers.microsoft.com/en-us/ie/forum/ie11-
> iewindows8_1/weather-module-on-my-home-page-doesnt-remember-
> my/62f2ac03-9422-43b6-a599-c712be931d4a#tabs>

Yes. And this discussion shows me, that the issue probably is trickier than I had thought and that we must try to provide as much guidance as we can to future namespace registrants.

Best,

Lars

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 20 Jan 2015 14:10:07 +0900

> I think this depends on how your resolution service works. It's true for http-based resolvers (which probably will be the most common ones for the next future). I don't think it would be the same f…

Resolution of the fragment identifier depends on the (MIME) media type 
of what you get back, not on the protocol. The problem with ftp may be 
that it doesn't have a way to indicated the content type. But if a 
browser guesses the content type as HTML, it would definitely apply the 
fragment identifier to that document.

Regards,    Martin.

---

From: John C Klensin <[email-masked]>
Date: Wed, 21 Jan 2015 13:55:40 -0500

--On Wednesday, January 14, 2015 19:20 +0900 "\"Martin J.
Dürst\"" <[email-masked]> wrote:

>> sure whether to read that as agreement, disagreement, or
>> "meh." Thoughts?
> 
> I started to write an answer yesterday, but got stuck. I agree
> with Sean. While there will be some correlation between URN
> namespaces and fragment identifiers (f-components for those
> who prefer that term), as Sean says, fragment identifiers and
> their interpretation is defined by the MIME media type of a
> resource obtained when resolving an URI, and therefore any
> mention in a namespace registration document can and should
> only be advisory, if at all.

I don't have a really strong opinion about what should happen
with URN fragments, although I'd encourage those who want to
engage in this discussion to read through the thread about 3986
and "file"-scheme fragments on the apps-discuss list.  However,
we've had extended discussions, starting at the Toronto meeting,
and at least one very clear consensus statement from Andy about
the syntax-only binding between URNs and 3986.   If the binding
is syntax-only, then claims about what this WG is required to do
because of relationships between f-components (whether they
appear to be "fragment identifiers" or not) and MIME media types
ought to be out of scope.  We can, of course, open the
"syntax-only" topic again, but, in the interest of progress, I
hope we can avoid doing so unless someone has compelling new
arguments.  Absent reopening it, comments that contradict that
conclusion should not have any further standing in WG
discussions.

I may have a little more to say directly to Sean's comment when
I have been able to think about this more.  However, it appears
to me that we have a substantive disagreement that we will need
to figure out either how to resolve or how to push off into
namespace definitions and ignore.  While Sean has "nothing good
to say about q-components", urn:oid:1.0.4217?code=EUR makes far
more sense to me than urn:oid:1.0.4217#EUR.   In either case,
the decision between those options must be made by the OID
registration authority or similar entity who can speak for and
commit the whole namespace because having one interpretation in
one arc and another in a different one could cause a mess of
epic proportions.  

I _think_ that part of my problem is that I'm concerned about
URNs that are not interpreted or resolved at all, URNs that may
be interpreted but not resolved, and the kind of URNs that seem
to underlie at least parts of Sean's note, i.e., those that
provide a location-independent identifier that resolves into a
conventional URL and for which the purpose of f-components (and
maybe q-components) is just to provide a string that is passed
through into the URL without processing as part of the URN.  I
think that, if we make a scheme-wide decision about that sort of
pass-through model, we'd better make it very carefully and
better be sure we have at least some things that don't pass
through (which drags the whole discussion about whether some
values in a q-component/ query can be dependent on the
resolution, others can actually specify the resolution
service/mechanism, and still others may be independent of
whether resolution occurs at all.

    john