Subject: Review and URN assignment for draft-seantek-rdf-urn-00

From: Sean Leonard <[email-masked]>
Date: Mon, 10 Nov 2014 14:52:19 -1000

Sean Leonard requests review of draft-seantek-rdf-urn-00, which registers the URN NID “rdf”.

Regards,

Sean

*************

A new version of I-D, draft-seantek-rdf-urn-00.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-rdf-urn
Revision:	00
Title:		A Uniform Resource Name (URN) Namespace for Resource Description Framework (RDF) URI References
Document date:	2014-11-10
Group:		Individual Submission
Pages:		6
URL:            http://www.ietf.org/internet-drafts/draft-seantek-rdf-urn-00.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-rdf-urn/
Htmlized:       http://tools.ietf.org/html/draft-seantek-rdf-urn-00

Abstract:
  The Resource Description Framework contains nodes that are identified
  by URI references.  This document defines a URN specifically for RDF
  URI references.

The IETF Secretariat

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 12 Nov 2014 21:37:40 -0500

(Many of these comments apply to draft-seantek-xmlns-urn-00 as well.)

   1.  Introduction

   The Resource Description Framework [RDF] is a framework for
   representing information in the web.  RDF contains nodes that are
   identified by URI references.  The URI reference is basically an
   opaque string with semantics applied onto it by the RDF standard; RDF
   applications are not required or expected to dereference the URI.

You almost certainly mean "URI" not "URI reference" ("RDF contains
nodes that are identified by URIs.") -- a "URI reference" is an
appearance of a URI in a particular place, in the same way a footnote
in a book is a reference.  There can be many URI references to the
same URI.

(You can see this by expanding the acronym "URI":  "RDF contains nodes
that are identified by Uniform Resource Identifiers." not "RDF
contains nodes that are identified by Uniform Resource Identifier
references.")

   This document defines a URN specifically for identifying RDF URI
   references.

This should read "This document defines a URN namespace identifier [or
alternatively, NID] specifically for use in constructing RDF URIs."

   The abstract resource does not have any particular concrete
   representation (such as a type of content identified by Internet
   media type), although concrete representations may be associated
   with it.

This is true, but you say later that, one or more URIs may be
associated with the URN via the IANA registration.  I believe that
these are an important feature of the NID, and you should probably
discuss them here, as they act somewhat like a representation of the
URN.

   Abstract parts of the abstract resource can be identified with
   fragment identifiers.

How does this statement interact with the fact that RFC 2141 does not
admit fragment identifiers for URNs, and that there is work afoot to
allow fragment identifiers for URNs?

   Declaration of syntactic structures:

   The structure of the Namespace Specific String is any
   valid XML name corresponding to the "Name" production in
   Section 2.3 of [XML] (production 5), with the following restrictions:
      1. The name MUST be at least four characters.
      2. Colons MAY be used as arbitrary intra-name dividers.
      3. Colons MUST NOT appear at the beginning or end of the name.
      4. Consecutive colons are PROHIBITED.
   and the following relaxation:
      5. The first part of the name preceding the first colon MAY
         be a whole decimal number as discussed in
         "Process of identifier assignment".

"PROHIBITED" is not an RFC 2119 word, so it should probably appear in
lower-case.

While it's a convenient mnemonic to compare the NSS syntax to the Name
syntax, it's easier for implementers if the NSS syntax is given
directly and in one place.

It's not clear what item 2 means, as there is no definition of
"divider", and the syntax of Name allows a colon in any position.

The phrasing of 5 is peculiar, since Name allows digits in all
positions except the first -- it would seem that the natural
expression would be "The first character may be a digit".  But if that
is the intended meaning, why was it not stated in that simpler way?

The text suggests that the use of leading digits is only permitted 'as
discussed in "Process of identifier assignment"', suggesting that the
use of leading digits is further restricted in some manner which is
not specified in this section.  Whatever restrictions are placed on
the use of leading digits should be expressed unambiguously in this
section.

The stated syntax does not allow fragment identifiers, but the rest of
the document presumes that a fragment identifier may be present.
Probably this section only intends to define the RDF URN NSS, leaving
implicit the syntax of the full RDF URN.  That should be clarified by
providing an explicit production for <rdf-urn>.

   When encoded in a URN, Unicode code points beyond U+007F
   are encoded as percent-encoded UTF-8. Conveniently, all XML name
   characters in the US-ASCII range are in the [RFC3986] unreserved set.

Describing the syntax of the NSS by specifying a set of Unicode
strings and then an encoding to be applied to that set of strings to
produce the URNs is formally correct but puts a burden on an
implementer.  It would be better if that aspect of the syntax was also
described as a combination of an informal description of the intention
and a complete and correct ABNF.

   Identifier uniqueness considerations:
   Once a name is registered in the IANA registry, it is unique.

   Identifier persistence considerations:
   Once a name is registered in the IANA registry, it is permanent.

These are awkwardly phrased.  It would be better phrased as "The
meaning of an identifier is registered in the registry, and thus is
unique." and "Once an identifier is registered, its meaning cannot be
changed."  (However, if a registration can be withdrawn as is
mentioned in passing later in the draft, can a URN whose previous
registration was withdrawn later be registered again -- with a
different description/registrant/associated URIs?)

   Process of identifier assignment:

   Identifiers are registered with IANA on a First-Come, First-Served
   basis. One-character names and prefixes are RESERVED for further
   use. Two- and three-character names and prefixes are RESERVED
   for language tags and regional codes; however, those names
   have no such semantic content when used in an RDF URN. Whole number
   prefixes are RESERVED for IANA Private Enterprise Numbers.
   Registrants are free to register names with reserved two-character
   and three-character prefixes, such as "au:flag" or "en:us:ca:lax".
   Registrants are also free to register names with reserved whole
   number prefixes, such as "20:10-250".

There are a number of difficulties here.

The word RESERVED is not an RFC 2119 word, and so should probably be
in lower-case.

The second and third sentence describes one-, two-, and three-
character "names".  It's not clear what "name" means here.  By
default, I expect it to be the same as "URN", but of course all URNs
have at least 7 characters.  So perhaps "name" means "NSS".  But the
syntax definition restricts NSSs to have at least 4 characters.

I don't understand what "however, those names have no such semantic
content when used in an RDF URN" means. -- You've just said that such
(syntactically excluded!) "names" are reserved, which presumably means
that they can't be used as NSSs to form URNs that are registered.  But
if they can't be used to form URNs, how could they be "used in an RDF
URN"?  Or is the important consequence based on one-character
"prefixes"?  But every string has a one-character prefix.

When you say, "Whole number prefixes are RESERVED for IANA Private
Enterprise Numbers.", what do you mean by "reserved"?  There is no
obvious semantic correspondence between private enterprise numbers and
URN NSSs.  And by "prefix" to you mean the default meaning of "an
initial substring of characters in a string", or (as I suspect you
mean) "an initial substring of characters in an NSS which is followed
by a colon"?

I suspect what you mean is that any NSS of the form
<digits>:<something> is implicitly associated in some way with the
registrant of the enterprise number <digits>, but you don't say that
explicitly.

And at the end you say "registrants are free to register names with
reserved ... prefixes".  In what manner are prefixes "reserved" if
registrants are free to register them?  (And in particular, if a
registrant can register a URN starting with a private enterprise
number even if it is not the registrant of the private enterprise
number.)

    Process for identifier resolution:

The fact that one or more URIs may attached to an RDF URN's
registration to provide a resolution for the URN is a very important
feature of your definition, and it deserves to be described more
explicitly than just as part of the "Process for identifier
resolution".  Indeed, in practice, it's a fundamental part of the
semantics of an RDF URN as you have described it.

Conversely, since there is (as far as I know) no defined way for a URN
resolver to look up the information associated with *any* IANA
registration, it's not clear how this information can be used in an
implemented resolution software.  More discussion is needed on how a
queryable database of these associations is to be accessed.

Similar considerations apply to "Validation mechanism".

   Fragments (delimited by the # character) are not considered part of
   the namespace-specific string, so a fragment would not affect
   lexical equivalence.

This sentence seems to be part of the rules for lexical equivalence,
but is not in that section of the template.

Assuming that URNs with fragment identifiers are compared in the ways
described in RFC 3986 for generic URIs, the fragment identifiers of
two URNs *are* compared when testing the URNs for equivalence.

    3.  IANA Considerations

These considerations place various burdens on IANA.  Has anyone
checked that IANA is in position to undertake them?  In particular:

   The registration template SHALL be encoded in UTF-8.

Can IANA process registrations containing arbitrary Unicode characters?

   If a registrant attempts to register a name that is confusingly
   similar to other registered names (such as only differing by case, or
   differing by code points but generating the same or confusingly
   similar visual representations), the registrants of the prior names
   are to receive a warning notification of the impending registration.
   However, there is no protest mechanism; the registration will still
   succeed unless withdrawn by the registrant.  IANA SHOULD implement a
   modern algorithm to detect such confusingly similar names.

What is the definition of "confusing"?  Can an RFC apply a SHOULD to
IANA?

   If a registrant attempts to register a name that contains a whole
   number prefix, the registrant of the corresponding IANA Private
   Enterprise Number is to receive a warning notification of the
   impending registration.

Is IANA prepared to undertake this?

Given that there is no protest mechanism, what is the purpose of
these?  As far as I know, there is no non-IETF mechanism that any
registrant could use to oppose such a registration.

There is no defined mechanism for withdrawing any registration that I
know of.  Is there intended to be one for this registry?

Dale

---

From: Sean Leonard <[email-masked]>
Date: Thu, 13 Nov 2014 06:19:13 -1000

Once again thanks for the detailed comments. I will try to focus on a couple of initial, key points.

> in a book is a reference.  There can be many URI references to the

When writing this draft-00 I used the RDF Concepts and Abstract Syntax spec <http://www.w3.org/TR/2004/REC-rdf-concepts-20040210> ~1.0 (from 2004).

In that spec, the term “URI reference” (also “RDF URI reference”) is used prominently. Basically it just means URI in the RFC 3986 sense. Probably the reason why it is called “URI reference” is because in RDF parlance, 

I note that in the newer RDF 1.1 Concepts and Abstract Syntax spec <http://www.w3.org/TR/rdf11-concepts/> (2014), the term “RDF URI reference” has been replaced with “IRI”. For example:
***
1.0:
6.1 RDF Triples

An RDF triple contains three components:

	• the subject, which is an RDF URI reference or a blank node
	• the predicate, which is an RDF URI reference
	• the object, which is an RDF URI reference, a literal or a blank node

1.1:
3.1 Triples

An RDF triple consists of three components:

	• the subject, which is an IRI or a blank node
	• the predicate, which is an IRI
	• the object, which is an IRI, a literal or a blank node

***
The definition in 1.0 is closely aligned with the URN syntax [RFC 2141]:

A URI reference within an RDF graph (an RDF URI reference) is a Unicode string [UNICODE] that:

	• does not contain any control characters ( #x00 - #x1F, #x7F-#x9F)
	• and would produce a valid URI character sequence (per RFC2396 [URI], sections 2.1) representing an absolute URI with optional fragment identifier when subjected to the encoding described below. 
The encoding consists of:

	• encoding the Unicode string as UTF-8 [RFC-2279], giving a sequence of octet values.
	• %-escaping octets that do not correspond to permitted US-ASCII characters.

Compare with 1.1:

An IRI (Internationalized Resource Identifier) within an RDF graph is a Unicode string [UNICODE] that conforms to the syntax defined in RFC 3987 [RFC3987].

IRIs in the RDF abstract syntax must be absolute, and may contain a fragment identifier.

IRI equality: Two IRIs are equal if and only if they are equivalent under Simple String Comparison according to section 5.1 of [RFC3987]. Further normalization must not be performed when comparing IRIs for equality.

***

From what I understand, there is a history of less than goodness with regard to RFC 3987…so I tried to avoid the whole topic by sticking with the RDF 1.0 spec.

I am happy to do what makes the most sense here, however, in light of the history.

> [...]

> […]

These series of concerns relate directly to the UTF-8 encoding issue.

Based on my understanding (which could well be flawed—I seek education on the matter) of URI, IRI, URN, etc., there are many different rules and heuristics that define “equivalence” and “transformation”. For example, “lexical equivalence” of a URN is not the same as “equivalence” of a URI. In fact RFC 3986 defines at least seven different equivalence algorithms in what it calls a “comparison ladder”, and also freely admits that: “We use the terms "different” and "equivalent" to describe the possible outcomes of such comparisons, but there are many application-dependent versions of equivalence.”

My inference is that lexical equivalence of a URN is simply a different kind of equivalence relationship than that described in RFC 3986. It is one of the “application-dependent versions” (if you were to shoehorn it in).

When I wrote these drafts, in my mind (which should have been more explicitly stated), I drew distinctions between:
<<<
the name and the resource: the name is an abstract identifier that is unique etc. in the space of names for a set of resources; the resource is an abstract thingamajig of interest to applications on the Internet
 (I have provided more commentary about this on [email-masked])

the Name, which (in the case of RDF URNs, at least) is a Unicode string that complies mostly with the XML Name production (with the changes discussed in this document)

the NSS, which is the sequence of characters that is syntactically compliant with RFC 2141 (URN Syntax), with an obvious relationship to the Name

the URN, which is the NID + NSS, and has “URN semantics” (whatever that is—basically the stuff about being persistent, unique, and resolvable with a URN resolver)

the urn: URI, which is a RFC 3986-compliant URI that looks like <urn:xmlns:acme:foodlv2#bar>.
<<<

With these distinctions (vaguely) in mind, I felt that the term “lexical equivalence” primarily is relevant to the NSS and URN concepts, not to the urn: URI concept. Thus the urn: URI is a syntactic way to adapt a URN to a URI world, viz.:

urn:<URN>[#REF]

i.e., the fragment is not part of the URN, although it is part of the urn: URI. The fragment depends on the resource, the resource is defined by the preceding part of the URI, and in the case of URNs, the resource is this abstract thingamajig of interest to applications on the Internet.

Furthermore, the URN is only comprised of US-ASCII characters, but the Name is UTF-8. This provides a path to transform or use UTF-8 characters (outside US-ASCII) in the RDF URN…which I guess when not percent-encoded, would make it a RDF IRN (Internationalized Resource Name?) which is compatible with RDF 1.1. That approaches the twilight zone because among other disgruntlements, such an RDF IRN in RDF 1.1 could be transformed back to a RDF URN in RDF 1.0 (for analysis and comparison purposes), but it’s not obvious if a URN/URI/IRI parser needs to treat the percent-encoded characters as irrelevant to lexical equivalence. I just saw all of this and said…”let’s deal with that in a later draft…”.

Consider the homograph problem, such as “é” (e with acute). In UTF-8 there are two code sequences that can produce such a grapheme: U+00E9 and U+0065 U+0301 (e + combining acute). XML says that Names SHOULD use Normalization Form C, but it doesn’t require that. In any event there are plenty of examples of homographs where picking a normalization form doesn’t help.

In a [RFC 2141] URN, the code sequences need to be converted to %E9 and e%CC%81 respectively. The distinction is patently obvious. But when you allow UTF-8 codes directly (as RDF 1.1 makes more explicit, in any event) the distinction is lost on display, and could well be lost in transcription. This is the origin of the IANA registration process that is supposed to look at confusingly similar names in an automated fashion. It is the same problem that plagues IDNA registrations in the DNS.

We could avoid the problem entirely by only using characters in the RESERVED set (which conveniently correspond mostly to the US-ASCII range of XML Name). But then we lose the Unicode goodness. I don’t know which is worse but seeing everything I opted in draft-00 to include non-ASCII support, to start a conversation about it.

Sean

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 13 Nov 2014 12:22:42 -0500

I notice a strong similarity between these two drafts,
draft-seantek-rdf-urn-00 and draft-seantek-xmlns-urn-00, as they
propose two NIDs with the same syntax, registration procedures, and
resolution properties.  The only difference is what the resulting URNs
are intended to be used for.

It would seem to me to provide simplicity and more functionality if
the two drafts were combined to propose a single NID whose URNs could
be used as either XML namespace identifiers or RDF node identifiers --
or for identifying other things.

Combining the drafts would also avoid duplicate discussion of whether
there was enough value in the purpose of the NID:  to provide short,
memorable identifiers that do not depend on (or refer to) domain
registrations.

In regard to the registration of the URIs associated with URNs and the
resolution of the URNs into the associated URIs, let me propose that
this data be be retrievable from some suitable zone of the DNS along
the following lines:

    Some suitable domain name should be chosen, either under
    .IANA.ORG.  or .ARPA.  The information for any particular URN
    would be stored under the name <URN>.<domain-name>.  Or better,
    <NSS>.<domain-name>.  But since IANA assigns names in large
    top-level domains like .COM., it already has the facilities to
    maintain such a zone.

    This scheme does limit the URNs to the maximum DNS label length,
    which is 63 octets.  This seems to me to not be a serious
    restriction, given the goals of the NID definition.  But perhaps
    it would be troublesome for, e.g., NSSs made of CJK characters,
    which generally require 3 octets each in UTF-8, which is encoded
    as 9 characters in URNs.  Perhaps the NSS should be pre-processed
    by converting the %-escapes into the octets they represent?  That
    would allow 21 CJK characters.  Or a scheme can be devised to
    map longer NSSs into more than one level of DNS label.  We'd still
    be limited by the 255 octet limit on DNS names as a whole.

    The information associated with a URN is:  the description, the
    registrant, and the associated URIs.  Assuming that each of these
    data are short enough, they can be stored in DNS RRs with the
    suitable DNS name.  Since there is no shortage of DNS RR types
    (they are 16-bit integers) it would seem suitable to choose three
    new RR types to identify these records.

Dale