[URN] comments on "URN Namespace Definition Mechanisms draft

[Ron Daniel <[e-mail]>]

Hi all,

Some draft-ietf-urn-nid-req-03.txt, aka "URN Namespace Definition
Mechanisms"

In general, having an IANA-like body register namespaces is the
way to go.


> 3.0 URN Namespace Definition Template

The sections of the template look OK, we will learn more about these
over time but they are a very good start.


> 5.0 Example

> Declaration of structure:
>
>        The identifier structure is as follows:
>        
>
>        FQDN:<assigned string>

I suggest that the urn:inet: prefix should also appear in the request.

>        where FQDN is a fully-qualified domain name, and the
>        assigned string is conformant to URN syntax requirements.

Oh, one other field to add to the template is a listing of any RFCs that
govern the syntax of the namespace or fields in the names. In this case,
some of the basic domain names specs should be cited to let people know
what is and is not a legal FQDN. Also, this example should cite the
relevant RFCs.

>Identifier uniqueness considerations:
>        
>        Uniqueness is guaranteed as long as the assigned
>        string is never reassigned for a given FQDN.    

If we were reviewing the INET proposal as an RFC-track document, I would
regard this section on considerations as inadequate. FQDNs are not
unique
over time. In fact the guarantee is pretty much that if you don't keep
paying your bills, your domain name will be sold out from under you.
Given
that, the INET namespace needs additional information to prevent
collisions.

>Identifier persistence considerations:
>
>        Persistence of identifiers is dependent upon suitable
>        delegation of resolution at the level of "FQDN"s.

Here again, this is an inadequate discussion. First, it is not clear
just
what is meant by this statement (though I can guess, I should not have
to).
Second, given that FQDNs are not necessarily unique over time, something
needs to talk about what to do when a new organization gets another's
old
domain. 

> Rules for Lexical Equivalence:
>
>        Nothing in particular.

Nope. The "urn", "inet", and "FQDN" fields are case-insensitive.
information after the "FQDN" field should be regarded as case-
sensitive.


>Conformance with URN Syntax:
>
>        No special considerations.

I'd like to see more information on limits on what is a legal name that
can be assigned by the holder of the FQDN. At a minimum there needs to
be
a citation to the URN syntax RFC.

>Validation mechanism:
>
>        None specified.

Hmmm.

>Scope:
>        
>        Global.