At 1:22 PM -0400 7/9/07, Brian Rosen wrote:
>The downside is only that it wouldn't meet the wording in the service urn
>RFC. I don't think it has any practical problem.
>I fail to see why IETF can't allocate urn:service:nena based on a RFC and
>then let NENA create subservices (urn:service:nena.address-error-report).
>There is certainly no uniqueness problem with that.
If you want this to work, I think you have to convince folks
to pull draft-ietf-ecrit-service-urn-06.txt before it becomes a BCP.
It sets out a registration mechanism according to RFC 3406 that's
a fairly standard NID. As it stands, the document says;
Services and sub-services are identified by labels managed by IANA,
according to the processes outlined in  in a new registry called
"Service URN Labels". Thus, creating a new service requires IANA
action. The policy for adding top-level service labels is 'Standards
Action'. (This document defines the top-level service 'sos' and
'counseling'.) The policy for assigning labels to sub-services may
differ for each top-level service designation and MUST be defined by
the document describing the top-level service.
This says that sub-services are managed by IANA; if you want
to define a mechanism where the sub-services may be managed
by someone else, I think that is in conflict with what
the document currently says. I also think the folks who
have been thinking about NIDs for a long time will have
a problem with it. The urn:service:sos mechanism is one
type of registration (where a class of services is identified
at the second level of the syntax) and urn:service:nena is
pretty different (the same place in the syntax has the semantic
of sub-registrant). Sub-registrants where the primary registrant
is IANA needs some real discussion with IANA, as IANA will
have to coordinate them (presuming we keep all of the publication
Having a separate NID is easier, in my opinion.
Ecrit mailing list