Subject: [Ecrit] I3, I4, I8

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 May 2005 10:20:47 -0400

I3: Multi-stage resolution

The mapping protocol MUST be able to resolve a location to a URL  
incrementally, i.e., provide a URL that represents a larger  
geographic area, where another invocation of the mapping protocol  
then provides a more fine-grained resolution.

Motivation: In some cases, an initial mapping may provide a single  
URL for a large geographic area. The ESRP identified by that URL then  
re-invokes the mapping protocol on a different database to obtain  
another URL for an ESRP or PSAP covering a smaller area.

I4: Return multiple PSAPs

The mapping protocol MUST be able to return multiple URLs for  
different PSAPs that cover the same area.

The mapping protocol MUST provide additional information that allows  
the querying entity to determine relevant properties of the URL.

Motivation: In some cases, the same geographic area is served by  
several PSAPs, for example, a corporate campus might be served by  
both a corporate security department and the municipal PSAP. The  
mapping protocol should then return URLs for both, with information  
allowing the querying entity to choose one or the other. The choice  
would typically be made by an ESRP based on local policy, not by a  
human user.

I8: Resilience against server failure

A client MUST be able to fail over to another replica of the mapping  
server, so that a failure of a server does not endanger the ability  
to perform the mapping.

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

---

From: Andrew Newton <[email-masked]>
Date: Tue, 24 May 2005 20:04:32 -0400

Henning, comments in-line:

On May 18, 2005, at 10:20 AM, Henning Schulzrinne wrote:

> incrementally, i.e., provide a URL that represents a larger geographic 
> area, where another invocation of the mapping protocol then provides a 
> more fine-grained resolution.

I'm not exactly sure what you mean by this.  "The mapping protocol" is 
a specification for bits on the wire and not any particular actor in 
the system.  How does it take the action of "resolution"?  Which actors 
in the system are doing the resolution?

> Motivation: In some cases, an initial mapping may provide a single URL 
> for a large geographic area. The ESRP identified by that URL then 

I've not seen ESRP defined in the document (unless I missed it).  
Google tells me it means "Eldora Special Recreation Program"... which 
is interesting but not particularly useful.

> several PSAPs, for example, a corporate campus might be served by both 
> a corporate security department and the municipal PSAP. The mapping 
> protocol should then return URLs for both, with information allowing 
> the querying entity to choose one or the other. The choice would 
> typically be made by an ESRP based on local policy, not by a human 
> user.

Again, ESRP is not defined.  And I keep getting caught up on the 
"allows" wording in the second sentence. Perhaps "for the purpose of 
using".  It's a small hair to split.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 May 2005 21:47:26 -0400

Andrew Newton wrote:
> I'm not exactly sure what you mean by this.  "The mapping protocol" is a 
> specification for bits on the wire and not any particular actor in the 
> system.  How does it take the action of "resolution"?  Which actors in 
> the system are doing the resolution?

We need to agree on terminology. The mapping server, maybe?

> I've not seen ESRP defined in the document (unless I missed it).  Google 
> tells me it means "Eldora Special Recreation Program"... which is 
> interesting but not particularly useful.

I thought we agreed at the interim that this Emergency Services Routing 
Proxy was to be added to the definition list, but maybe I misremember.

>> typically be made by an ESRP based on local policy, not by a human user.
> 
>

---

From: Andrew Newton <[email-masked]>
Date: Wed, 25 May 2005 22:13:41 -0400

On May 25, 2005, at 9:47 PM, Henning Schulzrinne wrote:

>> I'm not exactly sure what you mean by this.  "The mapping protocol" 
>> is a specification for bits on the wire and not any particular actor 
>> in the system.  How does it take the action of "resolution"?  Which 
>> actors in the system are doing the resolution?
>

I don't think this is a terminology issue.  The statement should be 
about some high level function that the protocol MUST/SHOULD support, 
and I doubt that high-level function is incremental URL resolution.  If 
the requirement is that the a mapping server for a large geographic 
area should be able to refer clients to mapping servers responsible for 
subsets of the geographic area, then let's say that.  However, a 
statement that speaks of passing around URL's so that they may be 
reiteratively invoked seems to be speaking to a solution and not a 
functional requirement.

>>> URL for a large geographic area. The ESRP identified by that URL 
>>> then re-invokes the mapping protocol on a different database to 
>>> obtain another URL for an ESRP or PSAP covering a smaller area.
> I thought we agreed at the interim that this Emergency Services 
> Routing Proxy was to be added to the definition list, but maybe I 
> misremember.

Its possible we did agree on that, and I just zoned it out.  What 
exactly is it suppose to do and which protocol is related to?  Is it to 
speak the same language as the mapping protocol or is it more specific 
to a using protocol? What are the properties associated with its proxy 
function?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 May 2005 22:36:23 -0400

Andrew Newton wrote:

> the requirement is that the a mapping server for a large geographic area 
> should be able to refer clients to mapping servers responsible for 

Works for me.

> to a using protocol? What are the properties associated with its proxy 

It's the logical entity that routes call signaling and is one of the 
logical entities invoking the mapping protocol as well as an entity that 
would be identified (by URL, presumably) as the output of the mapping 
protocol.

In SIP terms: it's a proxy server. Could be the proxy server for a whole 
emergency services region (county, country, state) or for a single PSAP.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 26 May 2005 16:08:01 -0700

At 10:36 PM -0400 5/25/05, Henning Schulzrinne wrote:
>logical entities invoking the mapping protocol as well as an entity 
>that would be identified (by URL, presumably) as the output of the 
>mapping protocol.
>
>In SIP terms: it's a proxy server. Could be the proxy server for a 
>whole emergency services region (county, country, state) or for a 
>single PSAP.
>

So this might be used in any protocol that appears in a contact URI
that might be returned by the mapping server?  It might be worth 
capturing that.

The example I'm thinking of is one in which the user experiencing the
emergency constructs a special-purpose indicator that tells the next-upstream
network element that it had not yet done the mapping and that it needed
the mapping done for it.  So a SIP URI with a target like sos:fire, or an
XMMP URI with a similar target.  But the ESRP you reach by each contact
method is likely to be distinct.

It seems like almost everything about the ESRPs will need to be passed
back to the protocol-specfic groups, though.
				regards,
					Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 May 2005 11:46:44 -0400

At least in the SIP case, I don't see how this would be needed. To make 
this concrete, a fictitious example:

- Caller uses ECRIT mapping protocol to translate "123 Main Street, 
Anytown, Jefferson County, NY, USA" to sip:[email-masked], 
the NY state emergency services ESRP.

- Routes calls to sip:[email-masked] (ESRP), using standard 
SIP mechanisms.

- ESRP at sip:[email-masked] takes address and converts (via 
mapping protocol, but a different "private" database) this to 
sip:[email-masked]. Call gets routed there by standard SIP 
mechanisms.

- ESRP at sip:[email-masked] repeats process and gets 
sip:[email-masked], the PSAP.

Quite a few emergency services folks have asked for this type of 
iterative resolution.

Thus, no resolution indicators are needed. It's obvious from the SIP 
request URL. Adding one would simply add a failure case, namely 
contradiction between apparent and claimed resolution.