Subject: [Ecrit] draft-polk-dhc-uri-00: mixed goals

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 14 Sep 2005 19:31:13 -0500

To put this into perspective, I like the idea of this draft - I can see how this would be beneficial, but I have a few questions.

From a high level, when you look at the abstract, the draft talks about URIs - no specific topic.  So this draft has the potential to cover a wide array of URI-type configuration information.  All present URIs are mapping or emergency based, obviously driven by need.

Is this draft intended to be a container for future URI-type configuration information?

If this is going to be a container, why then use up numbers so rapidly with primary and secondary options?  Why not provide a list in each option, similar to the way that RFC 3361 and RFC 3397 provide a list of domain names?  That would enable the provision of more than two fallback values if necessary - keeping in mind Michael's point that we already have means of fallback at other layers.

The rest of my comments are more specific to the contents of the document...

The "provided-by" URI is probably better than the structure in PIDF-LO, but how do you envisage this working?  The <provided-by> element is currently underspecified, so an example might be useful here.  Is this URI something that is included in the PIDF-LO directly?  If so, do you want to register a URN and schema for the <provided-by> contents?  OR is the intent of this URI that the endpoint dereferences the URI and retrieves an XML fragment containing the <provided-by> contents?  In which case do you expect that application/xml is sufficient as a MIME-type?

I think that from a user perspective the ESRP and PSAP should appear to be the same entity.  This is really a question of degree: do I want the SIP URI for an individual PSAP operator?  For instance, [email-masked] should be enough - I don't care what is done beyond this point.  I assume that contacting [email-masked] will get me help.

Distinguishing between an ESGW and ESRP is even less useful - I would hope that they all appear the same to the end user.

I think that we should also mandate that a mapping service use a PIDF-LO as input, therefore distinguishing between a civic and geo mapping service does not add any value.  The capabilities of the mapping service (the ability to accept civic or geo input) are metadata.

Cheers,
Martin 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Andrew Newton <[email-masked]>
Date: Thu, 15 Sep 2005 08:51:13 -0400

On Sep 14, 2005, at 8:31 PM, Thomson, Martin wrote:

> I think that we should also mandate that a mapping service use a  
> PIDF-LO as input, therefore distinguishing between a civic and geo  
> mapping service does not add any value.  The capabilities of the  
> mapping service (the ability to accept civic or geo input) are  
> metadata.

Martin,

I'm not sure all of PIDF-LO should be a requirement, but certainly  
the location elements seem appropriate.  As of my last reading of the  
requirements document, neither were required.

The intent of separating out the two types of URIs was not to suggest  
that they have different inputs, but only to tell the client when  
LCMS is needed and when the direct PSAP URIs can be used.  For  
instance, if the client is provided PSAP URIs and geo-LCMS URIs (and  
not civic-LCMS URIs), it can know not to invoke LCMS for civic cases  
and instead use the PSAP URIs.

-andy