Document: draft-evain-ebu-urn-01.txt
Reviewer: David L. Black
Review Date: 15 November 2007
IETF LC End Date: 10 December 2007

Summary:

This draft is on the right track, but has open issues, described in the review.

Comments:

There is one minor open issue, but it does cause syntactic ambiguity, and hence needs to be fixed:

   Declaration of structure:

      URNs assigned by EBU will have the following hierarchical
      structure based on the organisational structure of the EBU
      resources:

         urn:tva:{category}:{string}

      where "{category}" and "{string}" are US-ASCII strings that
      conforms to URN Syntax requirements ([RFC2141]).

The issue is that the use of the colon character (":") in {category} needs to be prohibited in order to protect the colon used as a delimiter between {category} and {string}.  In addition, it may also be appropriate to prohibit use of some or all additional  <other> characters defined in Section 2.2 of RFC 2141 in {category} beyond prohibiting the colon character - such a prohibition would apply the same syntax  rules rules to {category} as apply to the Namespace ID ("ebu").

Nits:

(1)

   Declared registrant of the namespace:

      Name:           jean-Pierre Evan

Should "jean" be capitalized?
Is there an "i" missing in "Evan"?

(2)

   Declaration of structure:

      URNs assigned by EBU will have the following hierarchical
      structure based on the organisational structure of the EBU
      resources:

         urn:tva:{category}:{string}

"tva" --> "ebu"

(3)

3.  Examples

   The following examples are not guaranteed to be real. They are
   presented for pedagogical reasons only.

      urn:ebu:metadata:pmeta:2007
      urn:ebu:metadata:cs:EscortCS:2007
      urn:other:anytype:version

The third example ("urn:other:anytype:version") should be removed.

(4)

idnits 2.05.01 found a possible boilerplate problem:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC
4748:
 
------------------------------------------------------------------------
----

  ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC
4748)
     Disclaimer -- however, there's a paragraph with a matching beginning.
     Boilerplate error?