Subject: [urn] naming and the necessity of resolution

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 Jan 2012 16:29:03 -0700

<hat type='individual'/>

On 12/22/11 3:17 AM, Juha Hakala wrote:

> URNs and resolution services are parts of the URN system. Without
> services URN assignment would not make sense. 

This is the core of my worry: you assume that URNs are worthless if they
cannot be resolved. Yet the text you proposed includes these sentences:

   Resources identified with URNs may be abstract (e.g. works such as
   Shakespeare's Hamlet) or embodied in some physical form (PDF/A
   version of the Finnish translation of Hamlet). An abstract entity
   may have 0-n digital manifestations in the Internet (and other kind
   of manifestations in the physical world).

To my mind, an abstract resource with zero manifestations is not the
kind of thing that needs to be resolved. Examples might include:

* the UUID C1A95067-9ECF-4983-9675-2B9CAA70BB11, which has a name of
urn:uuid:C1A95067-9ECF-4983-9675-2B9CAA70BB11

* the SIEVE extension for a personal addressbook, which has a name of
urn:ietf:params:sieve:addrbook:personal

* the XML namespace used to advertise support for ZRTP by XMPP clients,
which has a name of urn:xmpp:jingle:apps:rtp:zrtp:1

As far as I can see, these URNs do not need to be resolved, yet they are
perfectly useful in the relevant applications.

Indeed, I ask you to look at the IANA registry for formal URN namespaces
at http://www.iana.org/assignments/urn-namespaces/ to see that many of
these NIDs are used to assign URNs that name abstract resources with
zero manifestations. Those URNs are just as valid and useful as URNs
that name abstract resources with 1+ manifestations.

I realize that resolution is important for the applications you care
about, but those are not the only applications of interest to people who
have minted URNs.

Peter

-- 
Peter Saint-Andre
http://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 Jan 2012 16:35:15 -0700

<hat type='AD'/>

On 12/22/11 3:17 AM, Juha Hakala wrote:

> Peter Saint-Andre wrote:
>> Juha Hakala wrote:
>>> In chapter 2 <query> is discussed in the bottom of page 9 & top of the
>>> page 10. We should refer here to RFC2483 (which specifies the resolution
>>> services) and use an example which is based on an existing service. The
>>> current example is a bit puzzling; for the time being it is not possible
>>> to specify the type of metadata wanted because no such service exists.
>>
>> Could you clarify whether your statement refers to that particular
>> example or to resolution services as such?
> 
> I refer to the example in 2141bis. But my comment also makes the point
> that we should revise the URN services in such a way that the user can
> specify the type of metadata desired (the point made above in parenthesis).
>>
>>> A note should be added, saying that the services nailed down in RFC2483
>>> are not sufficient. For instance, it is not possible to specify what
>>> type of metadata is needed (descriptive / administrative / structural)
>>> and in which format (there are plenty of formats for descriptive
>>> metadata, such as MARC21 or Dublin Core). RFC2483 refers to URC (Uniform
>>> Resource Characteristics) which was never implemented in practice. (As
>>> an aside, there are plenty of other reasons for updating that RFC.)
>>
>> Isn't that a matter for RFC 2483 (or 2483bis), not the core URN spec?
>> There is no necessary connection between URNs and resolution, I think.
> 
> There is no need to add the note if revision of RFC 2483 is added to the
> charter of the URNBIS WG ;-). 

As long as I'm the Area Director (which is only through IETF 83), this
WG will not add any new items to its charter because it is already
behind schedule on delivering the work for which it was chartered.

Peter

-- 
Peter Saint-Andre
http://stpeter.im/

---

From: Juha Hakala <[email-masked]>
Date: Thu, 12 Jan 2012 09:08:27 +0200

Hello Peter; all,

>    of manifestations in the physical world).

In the library community, if there are no (digital) manifestations of 
the work, URNs should still be actionable. A user will not get the 
resource itself, but a surrogate such as descriptive metadata, which may 
include location of a physical copy.
> perfectly useful in the relevant applications.

If non-resolvable URNs indeed do have meaningful functions, fine. But 
the IETF community should know or be able to find out what these 
functions are. Otherwise people may conclude that the URN system is not 
functioning properly. In order to make sure that the users do not have 
wrong expectations, the namespace registration should be informative as 
regards these functions.

Anyway, based on this discussion, I'll change RFC2483bis draft. It 
currently requires that at least one resolution service is supported. 
The new version will say that some URN namespaces may not support any of 
the formally registered resolution services (the service registration 
mechanism is specified in RFC 2483bis). Instead they may provide some 
internal resolution services (outlined in the namespace registration), 
or none at all.

RFC2483bis will also state that if zero resolution services are 
supported, the purpose of expressing the identifiers in question as URNs 
should be specified in sufficient detail in the namespace registration. 
Then the reviewers can decide if the proposed additional functionality 
is suitable from the URN system point of view. Such review should 
consider both the usefulness of the suggested functionality and the 
persistence of it.

> that name abstract resources with 1+ manifestations.

I have looked at them, albeit only briefly. The number of manifestations 
is not a critical issue from the resolution point of view, since a 
surrogate such as metadata record describing the resource can be 
supplied. If there are zero surrogates there should be a specific 
application context which renders the URN meaningful. What does bother 
me is that I am not familiar with these contexts and there is no way to 
find out about them from the current documentation. As a result it is 
impossible to know how some namespaces are expected to serve the 
Internet users. Any URN namespace may be valid and useful, but I am 
afraid that in the long run some will be more valid and useful than 
others.

> about, but those are not the only applications of interest to people who

I agree, but in order to know the overall role of URNs in the Internet 
we should perhaps know more about out what kind of applications and 
functions people have had in mind. That may have an impact on 3406bis.

Best regards,

Juha

-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email [email-masked], tel +358 50 382 7678

---

From: "Svensson, Lars" <[email-masked]>
Date: Thu, 12 Jan 2012 18:30:06 +0000

Juha, Peter, all,

Juha wrote
> internal resolution services (outlined in the namespace registration),

+1

> consider both the usefulness of the suggested functionality and the

-1 

The requirement that a namespace registrant explicitly need to defend, why the proposed namespace doesn't need a resolution service seems a bit unfair to me. If we do that, we would also need a section where a registrant who wants to have resolvable (or "actionable") URNs need to explain, why http-URIs don't work for him (the keyword being "persistence").

Since we're looking at the complete family of URN RFCs, I suggest the following:

RFC 2141bis simply states what URNs are for and what they look like (syntax). It possibly mentions that URNs can be resolvable, but that they don't have to.
RFC 3406bis states that when you register a namespace you must decide if it needs resolution services or not. If it needs resolution services, there is a mandatory section where you describe if you will provide services according to rfc2483bis or other services (which).

If there is agreement on this, I shall supply some text suggestions next week (or possibly the week after).

I also volunteer to supply some text to 2483bis (outside of the WG), since we need something to refer to in 3406bis.

> afraid that in the long run some will be more valid and useful than

I fear that it is inevitable that some things turn out to be more valid and useful than others. A phlogiston made much sense in the 17th century but it doesn't any more (except to people interested in the history of philosophy, but to them it might still be very important). What I'm trying to say is that it is terribly hard to predict what will make sense in the future and thus we should be very careful not to exclude namespaces just because we don't believe they will be useful in the future. We definitely need some criteria (who will maintain the namespace/resolution service; do they have a plan what will happen, when the organization goes out of business), but also must be able to measure each criterion objectively.

> functions people have had in mind. That may have an impact on 3406bis.

To me it seems that some people really only think of naming (like info-URIs, RFC4452), whereas others think of naming _and_ services. We need to cater for both, and that's why it makes sense (to me) to differ between generic syntax and services. The two aspects come together when someone registers a namespace needing a resolution service. If it doesn't they shouldn't need to care about 3406bis.

All the best,

Lars

  **** Bitte beachten Sie die neue Internet- und E-Mail-Adresse. ****
  **** Please note my new internet- and email-address. ****

-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek / Informationstechnik
http://www.dnb.de/
[email-masked]

---

From: Juha Hakala <[email-masked]>
Date: Fri, 13 Jan 2012 10:33:29 +0200

Hello Lars; all,

> RFC 2141bis simply states what URNs are for and what they look like (syntax). It possibly mentions that URNs can be resolvable, but that they don't have to.

OK.

> RFC 3406bis states that when you register a namespace you must decide if it needs resolution services or not. If it needs resolution services, there is a mandatory section where you describe if you…

OK. Please note that RFC2483bis does not try to list all possible 
services (since that is not possible). Instead there should be an IANA 
registry for formal and informal services, and a possibility to create 
experimental resolution services as well.
> If there is agreement on this, I shall supply some text suggestions next week (or possibly the week after).

Great!
> I also volunteer to supply some text to 2483bis (outside of the WG), since we need something to refer to in 3406bis.

Not only do we need something to refer to in 3406bis; 3406bis and 
2483bis must be in synch.

You are most welcome to revise the 2483bis (which will then become a 
joint  venture between you, Alfred and me). I'll send the latest version 
of the document to you separately later today.

> I fear that it is inevitable that some things turn out to be more valid and useful than others. A phlogiston made much sense in the 17th century but it doesn't any more (except to people interested…

Come to think of it, there is probably nothing much to be afraid of. 
What we need is a flexible system where we have formal, informal & 
experimental namespaces and, independently, formal, informal and 
experimental services. Any combination of a namespace & related services 
is valid, and since it is possible to register the services as needed 
the registrants can indicate precisely what their intentions are. The 
only thing that may be harmful to the URN system as a whole is a 
namespace registration request which fails to provide complete / correct 
information about the namespace.

Best regards,

Juha
-- 

  Juha Hakala

---

From: "Svensson, Lars" <[email-masked]>
Date: Thu, 19 Jan 2012 12:10:35 +0000

Alfred,

thanks for moving this forward. I have added some inline comments, below.

Alfred wrote on October 31, 2011

> So, in order to bring forward the discussion on the draft, please
> currently focus on the other open issues tagged in (editorial) Notes
> inside the draft, which have not received much comments so far.
> In particular, we should hopefully be able to close the NID syntax
> issues discussed in section 2.1 soon, with your help!

Sec 2.1 says:

[[
Note for discussion:
      The above definition is taken from RFC 2141 and changed to reflect
      requirements from RFC 3406[bis].  RFC 3406[bis] contains further
      syntax restrictions on NID strings.
      Should this be further restricted, e.g., to avoid possible
      confusion caused by multiple adjacent hyphens and NIDs looking
      like a numerical value or a numerical range?
      Does the WG opt to move the more restrictive NID syntax details
      from the rfc3406bis draft to this section?
      Such restrictions would be fully backward compatible because no
      NIDs have been defined so far that would violate these
      restrictions.  Hyphens have been used only in the naming pattern
      for "Informal Namespace IDs" per RFC 3406[bis].

   Namespace Identifiers are case-insensitive, so that for instance
   "ISBN" and "isbn" refer to the same namespace.

   To avoid confusion with the URI Scheme name "urn", the NID "urn" is
   permanently reserved by this RFC and MUST NOT be used or registered.

   Note for discussion:
      This reservation is carried over unchanged from RFC 2141, for
      historical reasons.  Further possible reservations and/or details
      are out of scope for this document, but within the scope of the
      rfc3406bis draft!
]]

If we say that 2141bis reserves the NID 'urn' but that all other reserved NIDs are specified by 3406bis, 3406bis should be the master document for all restrictions/requirements on NID syntax. That way we'd have all in one place which makes it easier for implementers (they only need to look at 3406bis when registering a namespace).

Some further comments:

The document does not give a complete ABNF for the URN syntax. If we supply that, it would be fairly straightforward to implement a URN validation service and possibly a service to check for lexical equivalence.

Regarding NSS Syntax: Is it possible to give an ABNF rule that makes it clear that some characters MUST be percent-encoded? I'm not that deep into ABNF, but I guess that there are experts on this list.

And a final thought about Lexical Equivalence (out of scope for 2141bis, but relevant to 3406bis):
If I have a namspace that allows characters which I must percent-encode in a URN (like 'ÅÄÖåäö'), how can I specify that the NSS 'ÅÄÖ' is lexically equivalent to 'åäö'?

> I plan to submit another revision of this draft during the IETF 82
> week, once draft submission is open again.

I could not find a newer revision than 01, so my comments refer to that one. If there is a new revision, please accept my apologies and point me to the newest one and I will have a look ASAP.

All the best,

Lars

---

From: Alfred Hönes <[email-masked]>
Date: Thu, 19 Jan 2012 18:01:48 +0100 (MEZ)

[[ speaking as the draft author ]]

> thanks for moving this forward. I have added some inline comments,

Lars,
Thanks for taking the time to review the draft.
I have been eagerly waiting for comments.

> If we say that 2141bis reserves the NID 'urn' but that all other
> reserved NIDs are specified by 3406bis, 3406bis should be the master
> document for all restrictions/requirements on NID syntax. That way
> we'd have all in one place which makes it easier for implementers
> (they only need to look at 3406bis when registering a namespace).

The main reason for the current placement in the drafts of the
reservation for the NID string 'urn' is that -- as already pointed out
in the 2nd 'Note for discussion' quoted above -- it was in RFC 2141
(last paragraph of section 2.1, at the bottom of page 2 of RFC 2141).

IMO, this placement is justified because it seems to be an essential
detail to disambiguate the leading part of a URN string (whether it
is written as the full URN or as the -- not recommended -- colloquial
abbreviated form comprised of only the NID and subsequent components).

The other exclusions under consideration are more like for
convenience of human users, and need only be respected during
the process of registration of a URN namespace;
hence, the placement in rfc3406bis seems appropriate to me.
Nevertheless, for clarity, the banning of 'urn' as an NSS string
is repeated in rfc3406bis (as a quote from rfc2141bis), in the same
way it has been in RFC 3406 vs. RFC 2141.

However, that implementers on *generic* URN parsers need to follow
rfc2141bis; since this is the document entitled "URN syntax".
Implementations that want/need to go the NID-specifics can
(and should) always derive the current set of registered NISs
from the IANA registry -- i.e. the result of the application of
RFC 3406 / rfc3406bis, not these documents themselves -- and obtain
the NID-specific additional syntax rules from the registration
documents proper.
IMO, generic tools do not need to be aware of NID-specific syntax
details, only URN resolver systems need to do that -- to the extent
of the NIDs they specifically support.

So, in a nutshell, the exclusion specified in rfc2141bis is intended
to provide disambiguation in the general case, ensuring that a
single (leading) instance of "urn" will always be the URI scheme
and never be an NID.

Following other voices, I conclude that the WG does _not_ desire
further formal restrictions in the NID syntax in rfc2141bis,
because the common sense of prospective registrants (likely
seeking for short, expressive, mnemonical, NID strings) and of
the janitors of the IANA registry (a.k.a. IETF experts, and in
the case of dispute, the IESG) will prevent the registration
of confusing/dangerous/abusive NIDs.

If you don't share this conclusion, please state your opinion
and arguments NOW, on the urn list; thanks!

> Some further comments:
>
> The document does not give a complete ABNF for the URN syntax.
> If we supply that, it would be fairly straightforward to implement
> a URN validation service and possibly a service to check for lexical
> equivalence.

It's important, but a bit tricky to avoid overspecification
(with the impending danger of inconsistencies).
Therefore, the rfc2141bis draft follows the IETF tradition of
including other ABNF rules by reference; this seems to be proper
in this case because RFC 5234 (ABNF) and RFC 3986 (URI Syntax)
are the only sources of ABNF rules referred to, and knowledge of
these documents seems to be essential for all implementers of
rfc2141bis.

Further, the *informative* Appendix B of the current rfc2141bis draft
contains the fully expanded version of all the ABNF rules that are
referred to in the normative part of the draft, so that -- assuming
that Appendix B is precisely quoting RFCs 3986 and 5234 -- readers
of rfc2141bis can have the full picture of all ABNF syntax details.

> Regarding NSS Syntax: Is it possible to give an ABNF rule that
> makes it clear that some characters MUST be percent-encoded?
> I'm not that deep into ABNF, but I guess that there are experts
> on this list.

Answer to the question:  Essentially, NO !
(At least it would be huge, onerous, unreadable, and confusing.)

The deeper reason likely is that what you would like to have relates
to the _semantics_ of <pct-encoded>, which cannot be given in ABNF.

Note that the ABNF standard (RFC 5234) points out that textual
explanations can place additional restrictions on ABNF rules that
cannot be formulated in ABNF proper, and that such explanations
are at the same normative level as the formal, directly machine-
parseable, ABNF rules.

> If I have a namspace that allows characters which I must percent-
> encode in a URN (like 'ÅÄÖåäö'), how can I specify that the NSS
> 'ÅÄÖ' is lexically equivalent to 'åäö'?

A namespace that needs/wants to incorporate non-ASCII characters
(which will be first UTF-8 encoded and then percent-encoded for
inclusion in URNs) needs to determine its appropriate rules.
In case of roman characters with accents, the case mapping
properties and normalization rules/forms specified by the
Unicode Standard might be good candidates to draw from.

In general and ultimately, any equivalence not easily expressible
in syntax rules will need to be instantiated by the registration /
resolution systems for a specific namespace, and the methods for
implementation are strictly a "local" matter for the maintainers
of the registration system(s).

A similar problem is well-known for domain names, where it is
well-known that, in particular for non-roman scripts,
"human-friendly" equivalence for identifiers is impossible to
be specified on an "absolute base" and achieved in a distributed
manner because human-perceived equivalence is frequently culture
and context dependent; hence, in the context of the DNS, only
the name registration system and the authoritative servers for a
domain can implement and enforce the non-ASCII equivalence rules
intended for that particular domain.

So, in your example above, the respective namespace document could
specify a "normal form" of the NSS for that namespace and the rules
to achieve it (e.g., Unicode NFxx normalization and case mapping to
lower-case), or it could simply state that any appropriate
equivalence will be deliverd by the resolution system.

Therefore, and in fact, for some namespaces, _lexical_ equivalence
of URNs (i.e., what a client system can determine) might become
less important than _semantical_ equivalence (implemented in the
registration / resolution services).

> I could not find a newer revision than 01, so my comments refer
> to that one. If there is a new revision, please accept my apologies
> and point me to the newest one and I will have a look ASAP.

Indeed, -01 is still current; I've been waiting for more review
comments (like your message!) to address before preparing the next
draft version, but there haven't been much so far.

>  ...

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+