Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Proposeeliminatingrelaysbyrequiring PSAP to support all reasonable modes

From: "Roger Marshall" <[email-masked]>
Date: Fri, 30 Dec 2005 10:11:09 -0800

Based on this discussion, I agree that the requirement (Re7) around
Relays is at it's foundation, architectural, and not really part of the
mapping function per se.  Also, this original requirement discussed
conveyance of data through (or maybe despite) a Relay's presence, which
doesn't really seem to me to be a mapping protocol function. 

So, I have replaced Re7 (existence of Relays), with what seems to be the
better discussion, that of initiating mapping from anywhere, anytime.  

Change FROM:
Re7.  DirectRelay Services: It SHOULD be possible to involve 
relay services in the call for translation between different modes.

Motivation: It should be possible to connect the relay service so that 
the direct flow of media to the emergency service is maintained.  In 
addition, it should be possible to convey telemetry data, such as data 
from automobile crash sensors.

Change TO:
Re7.  Ubiquiteous Triggering: It MUST be possible to invoke 
the mapping protocol at any time, from any location, by any 
client which supports the mapping protocol.

Motivation: While end devices are the typical initiators of 
mapping service requests, it is also expected that other 
mapping clients, such as relays, 3rd party devices, PSAPs, 
etc. may also trigger a mapping request.

(Also, since I'm not thrilled with my own choice of the tag, "Ubiquitous
Triggering", I'm accepting offers for a better one.)

Roger Marshall

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Henning
>Sent: Thursday, December 29, 2005 12:20 PM
>To: [email-masked]; [email-masked]
>Subject: Re: [Ecrit] RE: [issue21] Re7 (Relays): 
>Proposeeliminatingrelaysbyrequiring PSAP to support all 
>reasonable modes
>
>While there may be administrative and policy reasons that a 
>particular server will not answer queries from a particular 
>region or querier, it seems to be rather difficult to 
>anticipate these in a protocol design. Thus, from a protocol 
>design perspective, the protocol should make it possible to 
>allow queries from anywhere. It is easy to picture scenarios 
>where this is needed, for example when delayed location 
>availability causes the call to be routed to some default 
>location and that call center then needs to lookup the right 
>PSAP when the location information shows up later. The number 
>of such places is essentially unbounded, as it could be one 
>for each VSP (including corporations).
>
>Therefore, I think there is a need to state as a protocol 
>design objective that queries can indeed come from anywhere.
>
>
>----- Original Message ----- 
>From: "Brian Rosen" <[email-masked]>
>To: "'Henning'" <[email-masked]>; "'Winterbottom, James'" 
><[email-masked]>; "'Roger Marshall'" 
><[email-masked]>; <[email-masked]>; "'Rohan Mahy'" 
><[email-masked]>
>Sent: Thursday, December 29, 2005 3:12 PM
>Subject: RE: [Ecrit] RE: [issue21] Re7 (Relays): Propose 
>eliminatingrelaysbyrequiring PSAP to support all reasonable modes
>
>
>>I have just looked through the current draft.  No where is there a
>> requirement that mapping can be done by any entity, using 
>anyone's notion 
>> of
>> location.
>>
>> While I believe any entity along a path from a caller to the 
>PSAP must be
>> able to map, it's not absolutely necessary to broaden that 
>to any entity 
>> at
>> all.  Similarly, location can come from the caller (directly or 
>> indirectly)
>> or from an authorized third party (as in a telematics call), 
>but it isn't
>> necessary that it come from just any entity.
>>
>> If you want to make the requirements broad, by saying explicitly that
>> mapping can be accomplished by any entity regardless of 
>their relationship
>> to an emergency caller, and that any location can be used 
>for mapping, 
>> then
>> that would cover the relay and other 3rd party call 
>originatos.  However,
>> the requirements, as currently expressed in the draft, are 
>insufficient.
>>
>> You could have some problems with very broad language 
>because it could 
>> open
>> the door to more abuse.
>>
>> Lack of an overall architecture is again causing problems.
>>
>> Brian
>>
>
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ecrit
>

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