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/