In line > So, this text: > > In this document, we frequently refer to the "emergency case". This > refers to a specific, important use of sip location conveyance where > the location of the caller is used to determine which Public Safety > Answering Point (PSAP) should receive an emergency call request for > help (e.g. a call to 1-1-2 or 9-1-1). This is an example of > location-based routing. The location conveyed is also used by the > PSAP to dispatch first responders to the caller's location. There > are special security considerations which make the emergency case > unique, compared to a normal location conveyance within SIP. We will rewrite this text to say that emergency call routing is a use case for this document. Something like: A specific, important use of sip location conveyance is in emergency calls (citizen to authority, for example a call to 1-1-2 or 9-1-1) where the location of the caller is used to determine which Public Safety Answering Point (PSAP) should receive an emergency call request for help. This is an example of location-based routing. The location conveyed is also used by the PSAP to dispatch first responders to the caller's location. > > > >-- Last sentence of Section 4.3 > > The last sentence of this: > > A location recipient would need to dereference the sips-URI in the > Geolocation header to retrieve Alice's location. If the > atlanta.example.com domain chooses to implement location conveyance > and delivery in this way (i.e. location-by-reference), it is > RECOMMENDED that entities outside this domain be able to reach the > dereferencing LIS server, otherwise this model of implementation is > only viable within the atlanta.example.com domain. This will likely > not suit some services already being considered in the IETF at the > time of this writing, such as emergency calling. I think we should leave this.
> > And section 6, which I talked about in my first message. > > Having reviewed this again, I don't believe that it is appropriate to > remove the text in Section 1, since the emergency use case was and > is an important driver for both location based routing and location > conveyance. Removing that context doesn't help the reader. An > additional pointer there to the ECRIT documents and a statement > that the full context is in them might be valuable as a way of pointing > out that the location-conveyance draft will not provide that. > > I think much the same is true for the last sentence in 4.3; replacing > it with a statement like "For special considerations relevant to > dereferencing location in emergency call situations, see [CITATION]" > would be better. I'd rather not have a normative reference to ecrit documents hold up this document. > > I believe the issues in Section 6 could be covered in the ECRIT phonebcp > document, but I continue to believe that they will need to be re-written > to fit into that document. Yes, of course > > I assume that any change to this text will require an update to the > Security Considerations, which currently have this: > > UAC implementations MUST make such capabilities > conditional on explicit user permission, and SHOULD alert a user > that location is being conveyed. Emergency calls have their own > rules in this regard, as detailed in Section 6. Proxies inserting > location for location-based routing are unable to meet this > requirement, and such use is NOT RECOMMENDED. Proxies conveying > location using this extension MUST have the permission of the target > to do so. Yes, a rewrite of this text is in order _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
