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