--- 1/draft-ietf-sipcore-location-conveyance-07.txt 2011-05-18 23:15:41.000000000 +0200 +++ 2/draft-ietf-sipcore-location-conveyance-08.txt 2011-05-18 23:15:41.000000000 +0200 @@ -1,20 +1,20 @@ Network Working Group James Polk Internet Draft Cisco Systems -Expires: Nov 4, 2011 Brian Rosen +Expires: Nov 18, 2011 Brian Rosen Intended Status: Standards Track (PS) Jon Peterson NeuStar - May 4, 2011 + May 18, 2011 Location Conveyance for the Session Initiation Protocol - draft-ietf-sipcore-location-conveyance-07.txt + draft-ietf-sipcore-location-conveyance-08.txt Abstract This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of the Location Target. @@ -32,21 +32,21 @@ months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on Nov 4, 2011. + This Internet-Draft will expire on Nov 18, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -481,24 +481,23 @@ The only defined values for the Geolocation-Routing header field are "yes" or "no". When the value is "yes", the locationValue can be used for routing decisions along the downstream signaling path by intermediaries. Values other than "yes" or "no" are permitted for future extensions. Implementations not aware of an extension MUST treat any other received value the same as "no". If no Geolocation-Routing header field is present in a SIP request, a SIP intermediary MAY insert this header. Without knowledge from a Rulemaker, the SIP intermediary inserting this header-value SHOULD - NOT set the value to "yes", as this could allow the Target's - location to be forwarded to third parties without the Target's - explicit permission. An easy way around this is to have the Target - always insert this header-value as "no". + NOT set the value to "yes", as this may be more permissive than the + originating party intends. An easy way around this is to have the + Target always insert this header-value as "no". When this Geolocation-Routing header-value is set to "no", this means no locationValue (inserted by the originating UAC or any intermediary along the signaling path) can be used by any SIP intermediary to make routing decisions. Intermediaries that attempt to use the location information for routing purposes in spite of this counter indication could end up routing the request improperly as a result. Section 4.4 describes the details on what a routing intermediary does if it determines it needs to use the location in the SIP request in order to process the message further. The @@ -669,22 +667,22 @@ As discussed in Section 4.3, more granular error notifications specific to location errors within a received request are required if the location inserting entity is to know what was wrong within the original request. The Geolocation-Error header field is used for this purpose. The Geolocation-Error header field is used to convey location-specific errors within a response. The Geolocation-Error header field has the following ABNF [RFC5234]: - message-header /= Geolocation-Error ; - (message-header from 3261) + message-header /= Geolocation-Error + ; (message-header from 3261) Geolocation-Error = "Geolocation-Error" HCOLON locationErrorValue locationErrorValue = location-error-code *(SEMI location-error-params) location-error-code = 1*3DIGIT location-error-params = location-error-code-text / generic-param ; from RFC3261 location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 HCOLON, SEMI, and EQUAL are defined in RFC3261 [RFC3261]. DIGIT is @@ -1160,27 +1158,44 @@ 1. Update the Header Fields registry with Registry: Header Name compact Reference ----------------- ------- --------- Geolocation-Routing [this doc] 8.3 IANA Registration for Location Profiles This document defines two new SIP option tags: "geolocation-sip" and - "geolocation-http." with the definition and rule in Section 4.6 of - this document, to be added to the IANA sip-parameters Options Tags - registry. + "geolocation-http" to be added to the IANA sip-parameters Options + Tags registry. - Name Valid Scheme(S) Reference - geolocation-sip See 4.6 [this doc] - geolocation-http See 4.6 [this doc] +Name Description Reference +----------- ------------------------------------------ --------- +geolocation-sip The "geolocation-sip" option tag signals [this doc] + support for acquiring location information + via the presence event package of SIP + (RFC 3856). A location recipient who + supports this option can send a SUBSCRIBE + request and parse a resulting NOTIFY + containing a PIDF-LO object. The URI + schemes supported by this option include + "sip", "sips" and "pres". + +geolocation-http The "geolocation-http" option tag signals [this doc] + support for acquiring location information + via an HTTP ([RFC2616]). A location + recipient who supports this option can + request location with an HTTP GET and + parse a resulting 200 response containing + a PIDF-LO object. The URI schemes + supported by this option include "http" + and "https". The names of profiles are SIP option-tags, and the guidance in this document does not supersede the option-tag assignment guidance in [RFC3261] (which requires a Standards Action for the assignment of a new option tag). This document does however stipulate that option-tags included to convey the name of a location profile per this definition MUST begin with the string "geolocation" followed by a dash. All such option tags should describe protocols used to acquire location by reference: these tags have no relevance to location carried in SIP requests by value, which use standard MIME @@ -1214,60 +1229,63 @@ Header Name compact Reference ----------------- ------- --------- Geolocation-Error [this doc] 2. In the portion titled "Header Field Parameters and Parameter Values", add Predefined Header Field Parameter Name Values Reference ----------------- ------------------- ---------- --------- - Geolocation-Error code= yes [this doc] + Geolocation-Error code yes [this doc] 8.6 IANA Registration for the SIP Geolocation-Error Codes - New location specific Geolocation-Error codes are created by this - document, and registered in a new table in the IANA sip-parameters - registry. Details of these error codes are in Section 4.4 of this - document. + This document creates a new registry for SIP, called + "Geolocation-Error Codes." Geolocation-Error codes provide reason + for the error discovered by Location Recipients, categorized by + action to be taken by error recipient. The initial values for this + registry are shown below. - Geolocation-Error codes - ----------------------- - Geolocation-Error codes provide reason for the error discovered by - Location Recipients, categorized by action to be taken by error - recipient. + Registry Name: Geolocation-Error Codes + Reference: [this doc] + Registration Procedures: Specification Required Code Default Reason Phrase Reference ---- --------------------------------------------------- --------- 100 "Cannot Process Location" [this doc] 200 "Permission To Use Location Information" [this doc] 201 "Permission To Retransmit Location Information to a Third Party" [this doc] 202 "Permission to Route based on Location Information" [this doc] 300 "Dereference Failure" [this doc] + Details of these error codes are in Section 4.4 of this + document. + 9. Acknowledgements To Dave Oran for helping to shape this idea. To Dean Willis for guidance of the effort. To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard - Barnes, Dan Wing, Matt Lepinski, John Elwell, Thomas Stach and - Jacqueline Lee for constructive feedback and nits checking. + Barnes, Dan Wing, Matt Lepinski, John Elwell, Thomas Stach, + Jacqueline Lee and Adam Roach for constructive feedback and nits + checking. Special thanks to Paul Kyzivat for his help with the ABNF in this document and to Robert Sparks for many helpful comments and the proper construction of the Geolocation-Error header field. And finally, to Spencer Dawkins for giving this doc a good scrubbing to make it more readable. 10. References @@ -1321,35 +1339,35 @@ [RFC4483] E. Berger, "A Mechanism for Content Indirection in SIP", RFC 4483, May 2006 [RFC5491] J. Winterbottom, M. Thomson, H. Tschofenig, "GEOPRIV PIDF-LO Usage Clarification, Considerations, and Recommendations ", RFC 5491, March 2009 [RFC5870] A. Mayrhofer, C. Spanring, "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", RFC 5870, June 2010 - [RFC5606] J. Peterson, T. Hardie, J. Morris, "Implications of - 'retransmission-allowed' for SIP Location Conveyance", - RFC5606, Oct 2008 - [RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, June 1999 10.2 Informative References [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, "Geopriv Requirements", RFC 3693, February 2004 [RFC2818] E. Rescorla, "HTTP Over TLS", RFC 2818, May 2000 + [RFC5606] J. Peterson, T. Hardie, J. Morris, "Implications of + 'retransmission-allowed' for SIP Location Conveyance", + RFC5606, Oct 2008 + [ID-GEO-FILTERS] R. Mahy, B. Rosen, H. Tschofenig, "Filtering Location Notifications in SIP", draft-ietf-geopriv-loc-filters, "work in progress", March 2010 [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. Thomson, M. Dawson, "A Location Dereferencing Protocol Using HELD", "work in progress", December 2010 [ID-GEO-ARCH] R. Barnes, M. Lepinski, A. Cooper, J, Morris, H. Tschofenig, H. Schulzrinne, "An Architecture for Location