< draft-ietf-sip-location-conveyance-12.txt   draft-ietf-sip-location-conveyance-13.txt >
SIP Working Group James Polk SIP Working Group James Polk
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expires: May 19, 2009 Brian Rosen Expires: September 9, 2009 Brian Rosen
Intended Status: Standards Track (PS) NeuStar Intended Status: Standards Track (PS) NeuStar
November 19, 2008 March 9, 2009
Location Conveyance for the Session Initiation Protocol Location Conveyance for the Session Initiation Protocol
draft-ietf-sip-location-conveyance-12.txt draft-ietf-sip-location-conveyance-13.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with
applicable patent or other IPR claims of which he or she is aware the provisions of BCP 78 and BCP 79. This document may contain
have been or will be disclosed, and any of which he or she becomes material from IETF Documents or IETF Contributions published or made
aware will be disclosed, in accordance with Section 6 of BCP 79. publicly available before November 10, 2008. The person(s)
controlling the copyright in some of this material may not have
granted the IETF Trust the right to allow modifications of such
material outside the IETF Standards Process. Without obtaining an
adequate license from the person(s) controlling the copyright in
such materials, this document may not be modified outside the IETF
Standards Process, and derivative works of it may not be created
outside the IETF Standards Process, except to format it for
publication as an RFC or to translate it into languages other than
English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
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 May 19, 2009. This Internet-Draft will expire on September 9, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
Legal
This documents and the information contained therein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
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 extension covers end to end SIP entity to another SIP entity. The extension covers end to end
conveyance as well as location-based routing, where SIP servers conveyance as well as location-based routing, where SIP servers
make routing decisions based on the location of the user agent make routing decisions based on the location of the user agent
clients. clients.
Table of Contents Table of Contents
1. Conventions and Terminology used in this document . . . . . . 2 1. Conventions and Terminology used in this document . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 5 3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 6
4. SIP Modifications for Geolocation Conveyance . . . . . . . . 7 4. SIP Modifications for Geolocation Conveyance . . . . . . . . 7
4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 7 4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 7
4.2 424 (Bad Location Information) Response Code . . . . . . 10 4.2 424 (Bad Location Information) Response Code . . . . . . 11
4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 11 4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 11
4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . . 19 4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . . 20
4.5 Using sip/sips/pres as a Dereference Scheme . . . . . . . 19 4.5 Using sip/sips/pres as a Dereference Scheme . . . . . . . 20
5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 21 5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 21
5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 21 5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 22
5.2 Location-by-reference . . . . . . . . . . . . . . . . . . 23 5.2 Location-by-reference . . . . . . . . . . . . . . . . . . 23
6. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 23 6. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 24
6.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 24 6.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 25
6.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 27 6.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 28
6.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 32 6.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 33
7. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 35 7. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 36
8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38
9.1 IANA Registration for New SIP Geolocation Header . . . . 38 9.1 IANA Registration for New SIP Geolocation Header . . . . 38
9.2 IANA Registration for New SIP 'geolocation' Option Tag . 38 9.2 IANA Registration for New SIP 'geolocation' Option Tag . 39
9.3 IANA Registration for New 424 Response Code . . . . . . . 38 9.3 IANA Registration for New 424 Response Code . . . . . . . 39
9.4 IANA Registration for New SIP Geolocation-Error Header . 38 9.4 IANA Registration for New SIP Geolocation-Error Header . 39
9.5 IANA Registration for New SIP Geolocation-Error Codes . . 38 9.5 IANA Registration for New SIP Geolocation-Error Codes . . 39
9.6 IANA Registration of LbyR Schemes . . . . . . . . . . . 39 9.6 IANA Registration of LbyR Schemes . . . . . . . . . . . 40
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
11.1 Normative References . . . . . . . . . . . . . . . . . 40 11.1 Normative References . . . . . . . . . . . . . . . . . 41
11.2 Informative References . . . . . . . . . . . . . . . . . 41 11.2 Informative References . . . . . . . . . . . . . . . . . 42
Author Information . . . . . . . . . . . . . . . . . . . . . 41 Author Information . . . . . . . . . . . . . . . . . . . . . 42
Appendix A. Requirements for SIP Location Conveyance . . . . 42 Appendix A. Requirements for SIP Location Conveyance . . . . 43
Appendix B. Example of Civic-based PIDF-LO w/ S/MIME . . . . 44 Appendix B. Example of Civic-based PIDF-LO w/ S/MIME . . . . 45
Intellectual Property and Copyright Statements . . . . . . . 45
1. Conventions and Terminology used in this document 1. Conventions and Terminology used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described "OPTIONAL" in this document are to be interpreted as described
in [RFC2119]. in [RFC2119].
The following terms and acronyms used throughout this document are The following terms and acronyms used throughout this document are
defined here: defined here:
skipping to change at page 7, line 45 skipping to change at page 8, line 18
The pres-URI is defined in RFC 3859 [RFC3859]. The pres-URI is defined in RFC 3859 [RFC3859].
The cid-url is defined in [RFC2392] to locate message body The cid-url is defined in [RFC2392] to locate message body
parts. This URI type MUST be present in a SIP request if location parts. This URI type MUST be present in a SIP request if location
is transmitted LbyV only. is transmitted LbyV only.
Other protocols used in the Location URI MUST be reviewed against Other protocols used in the Location URI MUST be reviewed against
the RFC 3693 criteria for a Using Protocol. the RFC 3693 criteria for a Using Protocol.
The Geolocation header MAY have one or more locationValues. SIP The Geolocation header MAY have one or more locationValues. SIP
servers inserting a locationValue MUST add the new value to the end servers inserting a locationValue MUST add the new value as the last
of the header value, such that the last locationValue in the header locationValue in the Geolocation header (i.e., the last
is the most recent one added to the message. Placement of the locationValue in the header is the most recent one added to the
"routing-allowed" parameter does not matter within the Geolocation message). Placement of the "routing-allowed" parameter, when
header. present, MUST be the last header value in the Geolocation header.
A locationValue has the following independent header parameters, A locationValue has the following independent header parameters,
o the "inserted-by=" parameter provides the hostport o the "inserted-by=" parameter provides the hostport
(alice.example.com -- which is the same as the "sent-by" (alice.example.com -- which is the same as the "sent-by"
parameter in a Via header, with or without a port number) of the parameter in a Via header, with or without a port number) of the
SIP entity that inserted this locationValue into the request. If SIP entity that inserted this locationValue into the request. If
a Location Recipient has determined a supplied location is in a Location Recipient has determined a supplied location is in
error, as there can be more than one in any request, the error, as there can be more than one in any request, the
"inserted-by=" parameter is copied into the locationErrorValue in "inserted-by=" parameter is copied into the locationErrorValue in
the response indicating the location error, and to whom the error the response indicating the location error, and to whom the error
is for. Hence, this "inserted-by=" parameter MUST be present in is for. Hence, this "inserted-by=" parameter MUST be present in
each locationValue. If an entity receives an Geolocation-Error each locationValue. If an entity receives an Geolocation-Error
skipping to change at page 8, line 39 skipping to change at page 9, line 9
request. request.
There MUST NOT be more than one "inserted-by=" parameter or one There MUST NOT be more than one "inserted-by=" parameter or one
"used-for-routing" parameter in the same locationValue. However, "used-for-routing" parameter in the same locationValue. However,
there can be more than one locationValue in the same Geolocation there can be more than one locationValue in the same Geolocation
header. header.
The "routing-allowed" header parameter is a global parameter over The "routing-allowed" header parameter is a global parameter over
any (and all/each) locationValues in the Geolocation header. This any (and all/each) locationValues in the Geolocation header. This
is the reason why the placement of the header parameter is outside is the reason why the placement of the header parameter is outside
any locationValue, and appears only once in the header value. any locationValue, and appears only once, and is always last in the
header value.
This header parameter has values "=yes" or "=no" only. When this This header parameter has values "=yes" or "=no" only. When this
parameter "=yes", any locationValue can be used for routing parameter "=yes", any locationValue can be used for routing
decisions along the downstream signaling path by intermediaries. decisions along the downstream signaling path by intermediaries.
When this parameter "=no", this means no locationValue (inserted by When this parameter "=no", this means no locationValue (inserted by
the originating UAC or any (or subsequent) intermediary(ies) along the originating UAC or any (or subsequent) intermediary(ies) along
the signaling path) can be used by a SIP intermediary to make the signaling path) can be used by any SIP intermediary to make
routing decisions. This behavior MUST be adhered to. routing decisions. This behavior MUST be adhered to.
The practical implication is that when the "routing-allowed" The practical implication is that when the "routing-allowed"
parameter is set to "no", if an LbyV is present in the SIP request, parameter is set to "no", if an LbyV is present in the SIP request,
intermediaries needn't bother viewing the location (because they are intermediaries SHOULD NOT view the location (because it is not
not to do anything with it), and if an LbyR is present, do not for intermediaries to view), and if an LbyR is present, SHOULD NOT
bother to dereference it. dereference it. UASs are allowed to view location in the SIP
request even when the "routing-allowed" header parameter is set to
"no".
The default behavior when this header parameter is not present in a The default behavior when this header parameter is not present in a
message is to treat the SIP request as if the parameter were present message is to treat the SIP request as if the parameter were present
and its value is set to "no". and its value is set to "no".
This document defines the Geolocation header as valid in the This document defines the Geolocation header as valid in the
following SIP requests: following SIP requests:
INVITE [RFC3261], REGISTER [RFC3261], INVITE [RFC3261], REGISTER [RFC3261],
OPTIONS [RFC3261], BYE [RFC3261], OPTIONS [RFC3261], BYE [RFC3261],
skipping to change at page 9, line 47 skipping to change at page 10, line 30
NOT modify any pre-existing locationValue, including any associated NOT modify any pre-existing locationValue, including any associated
header parameters within an existing Geolocation header value, header parameters within an existing Geolocation header value,
unless one of the existing locationValues is used to retarget the unless one of the existing locationValues is used to retarget the
request towards a new destination UAS. This is discussed in section request towards a new destination UAS. This is discussed in section
6.3. 6.3.
[RFC3261] states message bodies cannot be added by proxies. [RFC3261] states message bodies cannot be added by proxies.
Therefore, any Geolocation header field added by a proxy MUST be in Therefore, any Geolocation header field added by a proxy MUST be in
the form of an LbyR URI, in its own locationValue header value. the form of an LbyR URI, in its own locationValue header value.
A SIP proxy MAY add a Geolocation header if one is not present, in A SIP proxy MAY add a Geolocation header if one is not present, and
the case that the "routing-allowed" parameter is not yet present in MAY add the "routing-allowed" parameter if not yet present in the
the SIP request. The value of this parameter MUST be set to "no" SIP request. When a "routing-allowed" parameter is already present
when added by a proxy. in the SIP request, a SIP server MUST NOT change the value of the
parameter (i.e., from 'yes' to 'no', or from 'no' to 'yes'). This
would override the policy set by an upstream SIP entity (i.e.,
likely the UAC).
Adding a new locationValue to an in-transit request SHOULD NOT Adding a new locationValue to an in-transit request SHOULD NOT
occur for at least two reasons, occur for at least two reasons,
#1 - SIP Servers are not the best Sighters, as defined by [RFC3693], #1 - SIP Servers are not the best Sighters, as defined by [RFC3693],
of geographically where a UAC can be; meaning the location of geographically where a UAC can be; meaning the location
information is not necessarily the greatest. There MAY be information is not necessarily the greatest. There MAY be
exceptions, but this SHOULD be the rule of thumb. exceptions, but this SHOULD be the rule of thumb.
#2 - without appropriate caution to the fact that Location #2 - without appropriate caution to the fact that Location
Recipients might not understand how to process more than one Recipients might not understand how to process more than one
location, given this document's limited guidance as to what a location, given this document's limited guidance as to what a
Location Recipient should do when receiving more than one Location Recipient should do when receiving more than one
location (i.e., currently no priority instructions are given location (i.e., currently no priority instructions are given
skipping to change at page 15, line 54 skipping to change at page 16, line 38
Geolocation-Error: 200; code="Retry Location Later"; Geolocation-Error: 200; code="Retry Location Later";
node="bob.example.com"; node="bob.example.com";
inserter="alice.example.com"; inserter="alice.example.com";
This category covers location errors 2XX; meaning there MAY be more This category covers location errors 2XX; meaning there MAY be more
specific errors added to this category in future effort(s). The specific errors added to this category in future effort(s). The
same basic actionable reaction is expected by a location "inserter=" same basic actionable reaction is expected by a location "inserter="
entity to any 2XX location error. entity to any 2XX location error.
If a SIP request has the "routing-allowed" header parameter set to If a SIP request has the "routing-allowed" header parameter set to
"no", and the SIP server believes it requires location within the "no", and the SIP server believes processing location within the
request in order to service the request properly, a 2XX location request in order to service the request properly, a 2XX location
error is sent towards the recipient. This error is the proper error error is sent towards the recipient. This error is the proper error
even when there is no location in the SIP request, but the SIP even when there is no location in the SIP request, but the SIP
request contains a policy statement that location is not to be request contains a policy statement that location is not to be
viewed during transit towards the ultimate destination. viewed during transit towards the ultimate destination.
4.3.3 Location Error: 300 "Retry Location Later" (device updated 4.3.3 Location Error: 300 "Retry Location Later" (device updated
location) location)
The location error 300 "Retry Location Later" (device updated The location error 300 "Retry Location Later" (device updated
skipping to change at page 22, line 4 skipping to change at page 22, line 41
CSeq: 31862 INVITE CSeq: 31862 INVITE
Contact: <sips:alice@atlanta.example.com> Contact: <sips:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
--boundary1 --boundary1
Content-Type: application/sdp Content-Type: application/sdp
...SDP goes here ...SDP goes here
--boundary1 --boundary1
Content-Type: application/pidf+xml Content-Type: application/pidf+xml
Content-ID: target123@atlanta.example.com Content-ID: <target123@atlanta.example.com>
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
entity="pres:alice@atlanta.example.com"> entity="pres:alice@atlanta.example.com">
<dm:device id="point2d"> <dm:device id="point2d">
<timestamp>2007-12-02T14:00:00Z</timestamp> <timestamp>2007-12-02T14:00:00Z</timestamp>
<status> <status>
skipping to change at page 25, line 54 skipping to change at page 26, line 43
the location information itself and thus TLS SHOULD be used when the location information itself and thus TLS SHOULD be used when
transmitting LbyR hop-by-hop along the path to the Location transmitting LbyR hop-by-hop along the path to the Location
Recipient, for protection reasons. This is not to be confused with Recipient, for protection reasons. This is not to be confused with
a possession model, in which possessing the LbyR grants a possession model, in which possessing the LbyR grants
authorization to dereference the URI. Any entity dereferencing the authorization to dereference the URI. Any entity dereferencing the
LbyR MUST pass whatever authentication and authorization rules are LbyR MUST pass whatever authentication and authorization rules are
on the LIS for this location record. The Ruleholder from [RFC3693] on the LIS for this location record. The Ruleholder from [RFC3693]
is still very much in control - for any entity possessing the LbyR. is still very much in control - for any entity possessing the LbyR.
If the Location Generator wishes to control whether any location If the Location Generator wishes to control whether any location
included in the SIP request, or added along the signaling path of included in the SIP request or added along the signaling path of
this request, can be viewed for routing decisions, the Location this request can be viewed for routing decisions, the Location
Generator adds a Geolocation header value including the Generator adds a Geolocation header value including the
"routing-allowed=no" parameter. This is header parameter provide "routing-allowed=no" parameter. This header parameter provides
specific policy rules for each locationValue (if there is more than specific policy rules for each locationValue (if there is more than
one inserted along the signaling path) within the SIP request. A one inserted along the signaling path) within the SIP request. A
UAC SHOULD include the "routing-allowed" header parameter, with or UAC SHOULD include the "routing-allowed" header parameter, with or
without a locationValue, to each SIP request supporting this without a locationValue, to each SIP request supporting this
specification to ensure the UAC's policy for intermediaries which specification to ensure the UAC's policy for intermediaries which
might add a locationValue of the Target downstream. The UAC might add a locationValue of the Target downstream. The UAC
understands that the default behavior for SIP servers is to consider understands that the default behavior for SIP servers is to consider
this value to be present, and that it is set to "no". this value to be present, and that it is set to "no".
The UAC MUST understand there is no feedback mechanism to inform the The UAC MUST understand there is no feedback mechanism to inform the
skipping to change at page 34, line 26 skipping to change at page 35, line 14
if this is the locationValue the proxy used to make a retargeting if this is the locationValue the proxy used to make a retargeting
decision based upon, but make no other modification. decision based upon, but make no other modification.
A SIP server MAY add a new Geolocation locationValue to a SIP A SIP server MAY add a new Geolocation locationValue to a SIP
request. The proxy SHOULD NOT insert a locationValue of a Location request. The proxy SHOULD NOT insert a locationValue of a Location
Target unless it is reasonably certain it knows the actual location Target unless it is reasonably certain it knows the actual location
of the Location Target, for example, if it thoroughly understands of the Location Target, for example, if it thoroughly understands
the topology of the underlying access network and it can identify the topology of the underlying access network and it can identify
the device reliably (in the presence of, for example, NAT or VPN). the device reliably (in the presence of, for example, NAT or VPN).
Routing errors are likely if the SIP server inserts an incorrect
locationValue.
A server adding a locationValue to an existing Geolocation header A server adding a locationValue to an existing Geolocation header
would look like: would look like:
Geolocation: <cid:alice123@atlanta.example.com>; Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by="alice123@atlanta.example.com", inserted-by="alice123@atlanta.example.com",
<sips:3sdefrhy2jj7@lis1.atlanta.example.com>; <sips:3sdefrhy2jj7@lis1.atlanta.example.com>;
inserted-by="lis1.atlanta.example.com" inserted-by="lis1.atlanta.example.com"
Notice the locationValue added by the proxy is last among Notice the locationValue added by the proxy is last among
skipping to change at page 45, line 4 skipping to change at page 45, line 45
Geolocation: <cid:target123@atlanta.example.com> Geolocation: <cid:target123@atlanta.example.com>
;inserted-by="alice@atlanta.example.com" ;inserted-by="alice@atlanta.example.com"
Supported: geolocation Supported: geolocation
Accept: application/sdp, application/pidf+xml Accept: application/sdp, application/pidf+xml
CSeq: 31862 INVITE CSeq: 31862 INVITE
Contact: <sips:alice@pc33.atlanta.example.com> Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
--boundary1 --boundary1
Content-Type: application/sdp Content-Type: application/sdp
...SDP goes here ...SDP goes here
--boundary1 --boundary1
Content-Type: application/pkcs7-mime; Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m smime-type=enveloped-data; name=smime.p7m
Content-ID: target123@atlanta.example.com Content-ID: <target123@atlanta.example.com>
$ Content-Type: application/pidf+xml $ Content-Type: application/pidf+xml
$ $
$ <?xml version="1.0" encoding="UTF-8"?> $ <?xml version="1.0" encoding="UTF-8"?>
$ <presence xmlns="urn:ietf:params:xml:ns:pidf" $ <presence xmlns="urn:ietf:params:xml:ns:pidf"
$ xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" $ xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
$ xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" $ xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
$ entity="pres:alice@atlanta.example.com"> $ entity="pres:alice@atlanta.example.com">
$ <tuple id="sg89ae"> $ <tuple id="sg89ae">
$ <timestamp>2007-07-09T14:00:00Z</timestamp> $ <timestamp>2007-07-09T14:00:00Z</timestamp>
skipping to change at page 45, line 50 skipping to change at line 2317
$ <gp:retention-expiry>2007-07-27T18:00:00Z</gp:retention- $ <gp:retention-expiry>2007-07-27T18:00:00Z</gp:retention-
$ expiry> $ expiry>
$ </gp:usage-rules> $ </gp:usage-rules>
$ <gp:method>DHCP</gp:method> $ <gp:method>DHCP</gp:method>
$ <gp:provided-by>www.example.com</gp:provided-by> $ <gp:provided-by>www.example.com</gp:provided-by>
$ </gp:geopriv> $ </gp:geopriv>
$ </status> $ </status>
$ </tuple> $ </tuple>
$ </presence> $ </presence>
--boundary1-- --boundary1--
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 30 change blocks. 
54 lines changed or deleted 92 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/