|
|
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.
Brian
> -----Original Message-----
> From: Ted Hardie [mailto:hardie@xxxxxxxxxxxx]
> Sent: Monday, July 09, 2007 1:13 PM
> To: Brian Rosen; 'Henning Schulzrinne'; 'Roger Marshall'
> Cc: 'ECRIT'
> Subject: RE: [Ecrit] NENA requirement: contact URI for resolving
> errorsindatabase
>
> At 8:38 PM -0400 7/6/07, Brian Rosen wrote:
> >
> >Finally, I am planning to write an I-D creating a service:nena namespace,
> >which NENA will administer. Happy to have a generic address location
> error
> >reporting service, and we'll use it, but we're also quite happy to create
> a
> >local service for this purpose if others have a problem.
> >
> >Brian
>
> Hi Brian,
> I assume you mean a urn namespace . If so, the guarantee of
> uniqueness
> rules for URNs make it a bit tricky for the IETF to take part of a
> namespace
> and hand it out to another org; it would be easier to register a URN NID
> for NENA (i.e. urn:nena: , instead of urn:service:nena). What would be
> the downside of using that approach?
> Ted
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|
|