Subject: RE: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes

From: "Roger Marshall" <[email-masked]>
Date: Wed, 7 Dec 2005 16:45:37 -0800

Based on Ted's response (ref. below thread) ...

I propose to insert the following new (Ma5x) requirement in order to try
to address the issue of same scheme avoidance when it comes to multiple
URIs returned:

NEW (PROPOSED) REQUIREMENT:

Ma5x.  When multiple URIs are returned, the mapping protocol 
SHOULD differentiate multiple URIs by use of different URI 
schemes.

Motivation: There may be two URIs returned, both an SMS URI 
and a SIP URI, which the client can select by choice, based 
on it's capability and/or preference setting.

Are the other (existing) requirements sufficient to address use cases
where same schemas might be returned if unavoidable? 

Please comment if objectionable.

Thanks.

Roger Marshall

>-----Original Message-----
>From: Ted Hardie [mailto:[email-masked]] 
>Sent: Wednesday, December 07, 2005 10:07 AM
>To: Roger Marshall; James M. Polk; Marc Linsner; 
>[email-masked]; [email-masked]
>Subject: RE: [Ecrit] Issue 28: NENA Comments on 
>draft-ietf-ecrit-requirements-00 -Alternate Routes
>
>At 5:24 PM -0800 12/6/05, Roger Marshall wrote:
>>I'm glad you brought this up, since we currently DON'T yet have the 
>>"with at most one per scheme" qualification.  I think we 
>should, but we 
>>need to be careful, since there are a number of multiple uri 
>scenarios 
>>mentioned.  Here are the four:
>
>I believe it was Henning who brought this up initially.  His 
>logic, if I remember correctly, was that we didn't want the 
>client to have to order multiple responses for the same URI 
>scheme; the service should return the best/correct answer for 
>that scheme and any forwarding or redirection that occurred 
>should take place in the protocol processing for the scheme.  
>In the SIP example, the processing would return something like 
>"sips:[email-masked]"; if that psap were not 
>available, it would be the SIP mechanisms, not the mapping 
>protocol, that handle the traffic moving to 
>sips:[email-masked] .
>
>I personally agree with this logic, and I hope others do as well.
>
>
>>1. The mapping server returns two solutions for a given request and 
>>location...
>>
>>Mapping Client: A Mapping Client interacts with the Mapping Server to 
>>learn one or multiple URIs for a given location.
>>
>>2. Though I'm not sure this is Id2's original intent, since there are 
>>various service types are mentioned, could this take the form of 
>>sip:[email-masked] vs. [email-masked] vs.
>>[email-masked] (or some other combi) that could be provided 
>>from a mapping server?
>>
>>Id2.  Universal Identifier Resolution: Where multiple 
>emergency service 
>>types exist, it MUST be possible to treat each emergency identifier 
>>separately, based on the specific type of emergency help requested.
>>
>>3. The following requirement says nothing of scheme limits.
>>
>>Ma5.  The mapping protocol MUST allow a response to carry 
>multiple URIs.
>
>I would add it here, as "It SHOULD return at most one URI for 
>each scheme it supports, in order to avoid shifting the burden 
>of discovery back to the client".
>
>I think SHOULD is the right level here, just to allow for 
>special cases where multiple URIs are unavoidable or where the 
>scheme has no provision for forwarding/redirection.  That 
>might, though, cause us to say whether a return set containing 
>multiple URIs in a single scheme is ordered or
>unordered.   I also would have no real heartburn if we said MUST,
>and let people draw the conclusion that anything that has no 
>redirection/ redundancy/forwarding might be a bad choice for this use.
>
>				regards,
>					Ted Hardie
>

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

---

From: Ted Hardie <[email-masked]>
Date: Wed, 7 Dec 2005 17:00:40 -0800

>SHOULD differentiate multiple URIs by use of different URI

Sorry, but I think this doesn't quite capture it.  This sounds like
a server wanting to return multiple URIs should differentiate
them by scheme (e.g. assign one to sip and one to sips), where
what we want to say is that servers may return multiple URIs
when the PSAP supports multiple contact protocols, but should
return only one per protocol, to avoid the client getting muddled. 
Proposed replacement text:

Ma5x.  The mapping protocol MAY return multiple URIs.  It SHOULD
return only one URI per scheme, so that clients are not required
to select among different targets for the same contact protocol.

Motivation:  There may be two or more URIs returned when
multiple contact protocols are available (e.g. SIP and SMS).
The client may select among multiple contact protocols based
on its capabilities, preference settings, or availability.

Does this replacement text work  for you?
			regards,
				Ted

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 07 Dec 2005 20:34:13 -0600

This text is good