[email protected]
[Top] [All Lists]

Re: [Ecrit] NENA requirement: contact URI for resolving errorsindatabase

Subject: Re: [Ecrit] NENA requirement: contact URI for resolving errorsindatabase
From: Henning Schulzrinne
Date: Mon, 9 Jul 2007 15:35:27 -0400
It's hard to know what exactly the nena URN is supposed to do, but in general I share Ted's concern. I see no reason for urn:service to be the new playground for all non-document URNs.

The slippery slope is that once you have urn:service:nena, it's hard to say no to urn:service:amazon and urn:service:google.

As far as I can tell, even LoST doesn't really care that the URN starts with urn:service as opposed to urn:foobar, although we probably need to open up the language a bit if that's a concern.


On Jul 9, 2007, at 1:50 PM, Ted Hardie wrote:

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 [3] 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
by IANA).

Having a separate NID is easier, in my opinion.


Ecrit mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>