SIP Working Group                                         James M. Polk
Internet Draft                                            Cisco Systems
Expiration: Dec 17th, 2005                                  Brian Rosen
File: draft-ietf-sip-location-conveyance-00.txt               Emergicom



          Session Initiation Protocol Location Conveyance

                         June 17th, 2005

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   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 December 17th, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document presents the framework and requirements for usage of
   the Session Initiation Protocol (SIP) to convey user location
   information from one Session Initiation Protocol (SIP) entity to
   another SIP entity.  We consider cases where location information is
   conveyed from end to end, as well as cases where message routing by
   intermediaries is influenced by the location of the session
   initiator.  We offer a set of solutions to the requirements, each
   based on the scenario being addressed.


Polk & Rosen                                                   [Page 1]


Internet Draft         SIP Location Conveyance          June 17th, 2005

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . .  3
       1.2 Changes from Prior Versions . . . . . . . . . . . . . . .  3
   2.  Location In the Body or in a Header . . . . . . . . . . . . .  6
   3.  Scope of Location in a Message Body . . . . . . . . . . . . .  7
   4.  Requirements for UA-to-UA Location Conveyance . . . . . . . .  8
   5.  Requirements for UA-to-Proxy Server Location Conveyance . . .  9
   6.  Additional Requirements for Emergency Calls . . . . . . . . . 10
   7.  Location Conveyance Using SIP . . . . . . . . . . . . . . . . 12
   8.  Location Conveyance UA-to-UA  . . . . . . . . . . . . . . . . 13
       8.1 UA-to-UA Using INVITE . . . . . . . . . . . . . . . . . . 13
         8.1.1 UA-to-UA Using INVITE with Coordinate Format. . . . . 15
         8.1.2 UA-to-UA Using INVITE with Civic Format . . . . . . . 17
       8.2 UA-to-UA Using MESSAGE  . . . . . . . . . . . . . . . . . 20
       8.3 UA-to-UA Using UPDATE . . . . . . . . . . . . . . . . . . 23
       8.4 UA-to-UA Using PUBLISH  . . . . . . . . . . . . . . . . . 27
       8.5 UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY . 28
       8.6 424 "Bad Location Information" Response Code  . . . . . . 28
   9.  Special Considerations for Emergency Calls  . . . . . . . . . 28
       9.1 UA-to-Proxy Using INVITE  . . . . . . . . . . . . . . . . 29
       9.2 UA-to-Proxy Using UPDATE  . . . . . . . . . . . . . . . . 34
       9.3 425 "Retry Location Body" Response Code . . . . . . . . . 38
   10. Meeting RFC 3693 Requirements . . . . . . . . . . . . . . . . 39
   11. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 39
   12. Security Considerations . . . . . . . . . . . . . . . . . . . 39
   13. IANA Considerations   . . . . . . . . . . . . . . . . . . . . 40
       13.1 IANA Registration for Response Code 424  . . . . . . . . 40
       13.2 IANA Registration for Response Code 425  . . . . . . . . 40
   14. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 40
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . . 40
       15.1 Normative References   . . . . . . . . . . . . . . . . . 40
       15.2 Informative References . . . . . . . . . . . . . . . . . 40
   16. Author Information  . . . . . . . . . . . . . . . . . . . . . 41


1.  Introduction

   This document presents the framework and requirements for the usage
   of the Session Initiation Protocol (SIP) [RFC3261] for conveyance of
   user location information described by [RFC3693] from a SIP entity
   to another SIP entity.

   There are several situations in which it is appropriate for SIP to
   be used to convey Location Information (LI) from one SIP entity to
   another.  This document specifies requirements when a SIP UAC knows
   its location by some means not specified herein, and needs to inform
   another SIP entity.  One example is one user agent informing another
   user agent where it is (i.e., you want to tell your friend where you
   are).



Polk & Rosen                                                   [Page 2]


Internet Draft         SIP Location Conveyance          June 17th, 2005


   Another example is to reach your nearest pizza parlor.  A chain of
   pizza parlors may be contacted through a single well known uri
   (sip:pizzaparlor.com).  This SIP message could be forwarded to the
   closest franchise by the pizzaparlor.com proxy server.  The
   receiving franchise UAS uses the location information of the UAC to
   determine the location your delivery.

   Another important example is emergency calling.  A call to
   sip:sos@example.com is an emergency call as in [ID-SIP-SOS].  The
   example.com proxy server must route the call to the correct public
   safety answering point (PSAP) determined by the location of the
   caller. At the PSAP, the UAS must determine the correct
   police/fire/ambulance/... service, which is also based on your
   location.  In many jurisdictions, precise location information of
   the caller in distress is a required component of a call to an
   emergency center.

   A fourth example is a direction service, which might give you verbal
   directions to a venue from your present position.  This is a case
   where only the destination UAS needs to receive the location
   information.

   This document does not discuss how the UAC discovers or is
   configured with its location (either coordinate based such as from
   [RFC3825] or civic based such as from [ID-CIVIC]).  This document
   will also not discuss the contents of the SIP message body part that
   is the Location Object (LO) itself.  We will specify the
   requirements for SIP qualifying as a "using protocol" as defined by
   Geopriv in [RFC3693].

   Sections 7, 8 and 9 give specific examples (in well-formed SIP
   messages) of SIP UA and Proxy behavior for location conveyance, the
   last of which is a section devoted to the unique circumstances
   regarding emergency calling.  Section 10 addresses how this document
   adheres to the requirements specified in [RFC3693] (Geopriv
   Requirements).  Section 11 lists the current open issues with
   location conveyance in SIP, and the new open issues recently
   discovered as a result of the added effort to this revision.
   Section 13 IANA registers 2 new Response codes.


1.1  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described
   in [RFC2119].


1.2  Changes from Prior Versions

[NOTE TO RFC-EDITOR: If this document is to be published as an RFC,

Polk & Rosen                                                   [Page 3]


Internet Draft         SIP Location Conveyance          June 17th, 2005

this section is to be removed prior to that event.]

   This is a list of the changes that have been made from the SIPPING
   WG version -02 to this SIP WG item document version -00:

   - Changed which WG this document is in from SIPPING to SIP due to
     the extension of the protocol with new Response codes (424 and
     425) for when there is an error involving the LO message body.

   - Moved most of the well formed SIP messages out of the main body of
     this document and into separate appendixes.  This should clean up
     the document from a readability point of view, yet still provide
     the intended decode examples to readers of this document who wish
     that level of detail per flow.  The first few flows still have the
     decoded SIP messages (unencrypted and encrypted).

   - Removed some flow examples which no longer made sense

   - Changed all references of "ERC" (Emergency Response Center) to
     "PSAP" (Public Safety Answering Point) as a result of discussion
     within the new ECRIT WG to define a single term

   This is a list of the changes that have been made from the sipping-
   01 working group version of this effort to the sipping-02 version:

   - added requirements for 2 new 4XX error responses (Bad Location
     Information) and (Retry Location Body)

   - added "Bad Location Information" as section 8.6

   - added "Retry Location Body " as section 9.3

   - added support for session mode to cover packet sizes larger than
     the single packet limit of 1300 bytes in the message body

   - added requirement for a SIP entity to SUBSCRIBE to another for
     location information

   - added SUBSCRIBE and NOTIFY as section 8.5

   - added requirement to have user turn off any tracking created by
     subscription

   - removed doubt about which method to use for updating location
     after a INVITE is sent (update)

   - cleaned up which method is to be used if there is no dialog
     existing (message)

   - removed use of reINVITE to convey location

   - clarified that UAs include <provided-by> element of PIDF-LO when


Polk & Rosen                                                   [Page 4]


Internet Draft         SIP Location Conveyance          June 17th, 2005

     placing an emergency call (to inform PSAP who supplied Location
     information)

   - updated list of open issues

   - added to IANA Considerations section for the two new 4XX level
     error responses requested in the last meeting

   This is a list of the changes that have been made from the sipping-
   00 working group version of this ID to the sipping-01 version:

   - Added the offered solution in detail (with message flows,
     appropriate SIP Methods for location conveyance, and

   - Synchronized the requirements here with those from the Geopriv
     Working Group's (attempting to eliminate overlap)

   - Took on the task of making this effort the SIP "using protocol"
     specification from Geopriv's POV

   - Refined the Open Issues section to reflect the progress we've made
     here, and to indicate what we have discovered needs addressing,
     but has not been to date.

   This is a list of the changes that have been made from the -01
   individual submission version to the sipping-00 version of this ID:

   - Brian Rosen was brought on as a co-author

   - Requirements that a location header were negatively received in
     the previous version of this document.  AD and chair advice was to
     move all location information into a message body (and stay away
     from headers)

   - Added a section of "emergency call" specific requirements

   - Added an Open Issues section to mention what hasn't been resolved
     yet in this effort

   This is a list of the changes that have been made from the
   individual submission version -00 to the -01 version

   - Added the IPR Statement section

   - Adjusted a few requirements based on suggestions from the
     Minneapolis meeting

   - Added requirements that the UAC is to include from where it
     learned its location in any transmission of its LI

   - Distinguished the facts (known to date) that certain jurisdictions
     relieve persons of their right to privacy when they call an PSAP,


Polk & Rosen                                                   [Page 5]


Internet Draft         SIP Location Conveyance          June 17th, 2005

     while other jurisdictions maintain a person's right to privacy,
     while still others maintain a person's right to privacy - but only
     if they ask that their service be set up that way.

   - Made the decision that TLS is the security mechanism for location
     conveyance in emergency communications (vs. S/MIME, which is still
     the mechanism for UA-to-UA non-emergency location conveyance
     cases).

   - Added the Open Issue of whether a Proxy can insert location
     information into an emergency SIP INVITE message, and some of the
     open questions surrounding the implications of that action

   - added a few names to the acknowledgements section


2.  Location In the Body or in a Header

   In determining where "location" is placed in a SIP message,
   consideration is taken as to where the trust model is based on the
   architecture involved.

   If the user agent has the location stored within it, and one user
   agent wants to inform another user agent where it is, it seems
   reasonable to have this accomplished by placing the location
   information (coordinate or civic) in an S/MIME registered and
   encoded message body, and sending it as part of a SIP request or
   response.  No routing of the request based on the location
   information is required in this case; therefore no SIP Proxies
   between these two UAs need to view the location information
   contained in the SIP messages.  This is location by-value.

   Although SIP [RFC3261] does not permit SIP intermediaries to modify
   or delete a message body, there is no restriction on viewing message
   bodies.  S/MIME protected message bodies, implemented on bodies for
   communications between user agents only, would render the location
   object opaque to a proxy server for any desired modification if it
   is not correct or precise enough from that proxy's point of view
   (were it to be able to view it).  This problem is similar to that
   raised in Session Policy [ID-Sess-Pol], where an intermediary may
   need information in a body, such as IP address of media streams or
   codec choices to route a call properly.  Requirements in [ID-Sess-
   Pol] are applicable to routing based on location, and are
   incorporated in these requirements by reference.

   It is conceivable to create a new header for location information.
   However, [RFC3693] prefers S/MIME for security of Location
   Information, and indeed S/MIME is preferable in SIP [RFC3261] for
   protecting a message body.  Accordingly, these requirements specify
   location be carried in a body when it is known to/stored in a user
   agent.



Polk & Rosen                                                   [Page 6]


Internet Draft         SIP Location Conveyance          June 17th, 2005

   It is the use of S/MIME however, that limits routing based on
   location.  Therefore, it seems appropriate to require that, where
   routing is dependent on location, protection of the location
   information object be accomplished by other mechanisms visible to
   SIP proxies: here TLS ("sips:" from [RFC3261]).  It is envisioned
   that S/MIME SHOULD be used when location information is not required
   by proxy servers, and TLS MUST be used when it is.  The UAC will
   need to know the difference in the call's intent as to which
   security mechanism to engage for LI conveyance.

   This document does not address the behavior or configuration of SIP
   Proxy Servers in these cases in order to accomplish location-
   sensitive routing.  That is out of scope, and left for further
   (complementary) efforts within the ECRIT WG.


3.  Scope of Location in a Message Body

   As concluded from the previous section, location information is to
   be contained within a message body when the user agent has this
   information locally.  If either another body (SDP for example) is
   also to be sent in the message, or the LI is to be protected with
   S/MIME, the rules stated in section 7 of [RFC3261] regarding
   multipart MIME bodies MUST be followed.  The format and
   privacy/security rules of [RFC3693] MUST too be followed.

   User agents providing location can convey it incorrectly or
   inappropriately.  Therefore, there needs to be a new UAC error
   response code created to inform the UAC by a UAS or Proxy of this
   rejected
   request message because of the location information in the message.

   There needs to be two new response codes currently not defined in
   SIP:

   1) the first indicating the existing location information was not
      considered good by the viewing SIP element.

   There will be times in which the UAC does not know its location
   information, or another SIP entity knows the UAC's location better
   than the UAC itself.  How this is determined is out of scope of this
   document.  In these times, a Proxy servers that know the location
   of the UAC needs inform the UAC of its location information and have
   that UAC include that message body in its next SIP message to the
   same destination UA.  This error code needs to be unique with
   respect to the error code for merely incorrect location information
   from the UAC.

   2) a second new response code indicating the existing location
      information was not considered good by the viewing SIP element,
      one that includes a new message body with new location
      information of the UAC to be used in a subsequent SIP Request by


Polk & Rosen                                                   [Page 7]


Internet Draft         SIP Location Conveyance          June 17th, 2005

      the UAC.

   This second response code would be more applicable for cases in
   which a SIP intermediary knows more about the location of the UAC
   than the UAC, and needs to get the more appropriate LO into the SIP
   message.  This cannot occur with existing rules stating message
   bodies cannot be modified or added by intermediaries.  This new
   response code message containing a new LO of the UAC appears the
   best course of action.

   If there can be more than one LO within the same SIP message is not
   addressed in this document at this time.

   If there can be more than one LO within the same SIP message and the
   message is routed by a SIP Proxy based on the contents of an LO,
   this document currently does not specify how the proxy determines
   which LO to route the message based on.  This is currently an open
   question as to whether this topic is addressed in the SIP WG or in
   the ECRIT WG, therefore this is left for future study at this time.


4.  Requirements for UA-to-UA Location Conveyance

   The following are the requirements for UA-to-UA Location Conveyance
   Situations where routing is not based on the LI of either UA, and
   location is stored/cached in the UAC:

    U-U1 - Dialog-initiating SIP Requests and their responses MUST
           support Location Conveyance

    U-U2 - The SIP MESSAGE method [RFC3428] MUST support Location
           Conveyance

    U-U3 - Other SIP Requests SHOULD support Location Conveyance

    U-U4 - UAC Location information SHOULD remain confidential e2e
           to the destination UAS except when the session is to an
           identifiable emergency endsystem.

    U-U5 - UAC MUST not use S/MIME on the Location Object message body
           if the message is a dialog related or MESSAGE Request
           message unless the UAC has a pre-established association
           with the routing SIP intermediary.

    U-U6 - UAS Location information SHOULD remain confidential e2e
           to the destination UAC except when the session is to/from an
           identifiable emergency endsystem.

   Emergency callback is one example where this may apply.

    U-U7 - The privacy and security rules established within the
           Geopriv Working Group that would categorize SIP as a 'using


Polk & Rosen                                                   [Page 8]


Internet Draft         SIP Location Conveyance          June 17th, 2005

           protocol' MUST be met [RFC3693].  See Section 10 for
           analysis.

    U-U8 - Location information MUST be contained in the location
           Object as defined in [ID-PIDF-LO], which will satisfy all
           format requirements for interoperability.

    U-U9 - User Agents and Proxies SHOULD be able to handle SIP
           messages in which Location Information is fragmented across
           multiple packets.

    U-U10 - There MUST be a unique UAC error response code informing
           the UAC it did not provide applicable location information.

    U-U11 - There MUST be a means for publishing location state
           information for a particular presentity to a Presence
           Compositor Server

    U-U12 - User Agents and Proxies SHOULD be able to handle SIP
           messages which contain more than one Location Object.


5.  Requirements for UA-to-Proxy Server Location Conveyance

   The following are the requirements for UA-to-Proxy Server Location
   Conveyance situations:

    U-PS1 - MUST work with dialog-initiating SIP Requests and
            responses, as well as the SIP MESSAGE method [RFC3428], and
            SHOULD work with most SIP messages.

    U-PS2 - UAC location information SHOULD remain opaque to
            intermediaries the message was not addressed to, but MUST
            be useable (i.e. viewable) by intermediary proxy servers
            requiring location knowledge of the UAC to properly route
            the message.

    U-PS3 - The privacy and security rules established within the
            Geopriv Working Group which would categorize SIP as a
            'using protocol' MUST be met [RFC3693].

    U-PS4 - Proxy servers MUST NOT modify or remove an LO message body
            part ([RFC3261] currently forbids this).

    U-PS5 - A SIP message containing a Location Object MUST NOT be
            rejected by a SIP intermediary because the message body
            part or LO itself was not understood (except when the
            intermediary complies with requirement U-PS7 below, or when
            the SIP message is addressed to that intermediary).

   With regards to requirement U-PS5, not all SIP Proxies are expected
   to route messages based on the contained Location Object from the


Polk & Rosen                                                   [Page 9]


Internet Draft         SIP Location Conveyance          June 17th, 2005

   UAC.  There will likely be a SIP Proxy able to perform this function
   downstream, and the original SIP message needs to reach that
   location enabled Proxy to route correctly.

    U-PS6 - There MUST be a unique UAC error response code informing
            the UAC it did not provide applicable location information.

    U-PS7 - There MUST be a unique UAC error response code informing
            the UAC it did not provide applicable location information,
            and to include the location information contained in the
            message body of the error message for usage in the UAC's
            next attempt to the same UAS of the original message.


6. Additional Requirements for Emergency Calls

   Emergency calls have requirements that are not generally important
   to other uses for location in SIP:

   Emergency calls presently have between 2 and 8-second call setup
   times.  There is ample evidence that the longer call setup end of
   the range causes an unacceptable number of callers to abandon the
   call before it is completed.  Two-second call completion time is a
   goal of many existing emergency call centers.  Allocating 25% of the
   call set up for processing privacy concerns seems reasonable; 1
   second would be 50% of the goal, which seems unacceptable; less than
   0.5 second seems unachievable, therefore:

    E-1 - Privacy mechanisms MUST add no more than 0.5 second of call
          setup time when implemented in present technology UAs and
          Proxy Servers.

   It may be acceptable for full privacy mechanisms related to the
   location of the UAC (and it's user) to be tried on an initial
   attempt to place a call, as long as the call attempt may be retried
   without the privacy mechanism present (or enabled) if the first
   attempt fails.  Abandoning privacy in cases of failure of the
   privacy mechanism might be subject to user preference, although such
   a feature would be within the domain of a UA implementation and thus
   not subject to standardization.  It should be noted that some
   jurisdictions have laws that explicitly deny any expectation of
   location privacy when making an emergency call, while others grant
   the user the ability to remain anonymous even when calling an PSAP.
   So far, this has been offered in some jurisdictions, but the user
   within that jurisdiction must state this preference, as it is not
   the default configuration.

    E-2 û Privacy mechanisms MUST NOT be mandatory for successful
          conveyance of location during an (sos-type) emergency call.

    E-3 - It MUST be possible to provide a privacy mechanism (that does
          not violate the other requirements within this document) to a


Polk & Rosen                                                  [Page 10]


Internet Draft         SIP Location Conveyance          June 17th, 2005

          user within a jurisdiction that gives that user the right to
          choose not to reveal their location even when contacting an
          PSAP.

    E-4 û The retention and retransmission policy of the PSAP MUST be
          able to be made available to the user, and override the
          user's normal policy when local regulation governs such
          retention and retransmission (but does not violate
          requirement E-3).  As in E-2 above, requiring the use of the
          PSAP's retention and/or retransmission policy may be subject
          to user preference; although in most jurisdictions, local
          laws specify such policies and may not be overridden by user
          preference.

   Location information is considered so important during emergency
   calls, that it is to be transmitted even when it is not considered
   reliable, or might even be wrong.  For example, some application
   might know that the DHCP reply with location information was
   overwritten recently (or exactly) when a VPN connection was
   activated.  This could, and likely will, provide any new location
   information to the UA from somewhere far away from the UA (perhaps
   the user's corporate facility).

    E-5 - A call transfer between response centers MUST NOT be
          considered a violation of the distribution privacy attribute
          contained within the location object.

   This transfer will likely be for legitimate reasons; for example,
   the session was misrouted to the wrong PSAP, and is referred
   [RFC3515] to the correct one.

    E-6 Location information MUST be transmitted if known to the UAC,
        in all calls to a PSAP, even in the case it is not considered
        reliable.

   With that in mind, it is important to distinguish the location
   information learned locally from LI learned over a VPN; which in
   itself is useful additional information to that PSAP operator.

    E-7 THE UA must provide the actual LI of the endpoint, and not
        location which might have been erroneously given to it by, e.g.
        a VPN tunnel DHCP server.

    E-8 A PSAP MAY wish to SUBSCRIBE to the UAC that initiated a
        session.  If this is supported by the UAC, all NOTIFY messages
        MUST contain the UAC's location information.

   This is a means for the emergency response centers to maintain a
   location the callers in distress.

    E-9 It MUST be possible that any UAC supporting E-8 be informed of
        this subscription, as this will provide a means of alert to the


Polk & Rosen                                                  [Page 11]


Internet Draft         SIP Location Conveyance          June 17th, 2005

        user who does not wish this capability to remain enabled.


7.  Location Conveyance using SIP

   Geopriv is the IETF working group assigned to define a Location
   Object for carrying within another protocol to convey geographic
   location of an endpoint to another entity.  This Location Object
   will be supplied within SIP to convey location of a UA (or user of a
   UA).  The Location Object (LO) is defined in [ID-PIDF-LO]. Section
   26 of [RFC3261] defines the security functionality SIPS for
   transporting SIP messages with either TLS or IPsec, and S/MIME for
   encrypting message bodies from SIP intermediaries that would
   otherwise have access to reading the clear-text bodies.  For UA-to-
   UA location conveyance, using the PIDF-LO body satisfies the entire
   format and message-handling requirements as stated in the baseline
   Geopriv Requirements [RFC3693].  SIP entities that will carry an LO
   MUST implement S/MIME for encrypting on an end-to-end basis the
   location of a user agent, satisfying [RFC3693]'s security
   requirements.  The SIPS-URI from [RFC3261] SHOULD also be used for
   further message protection (message integrity, authentication and
   message confidentiality) and MUST be used when S/MIME is not used
   (when not violating the requirements for emergency messaging
   detailed in section 6 of this document).  The entities sending and
   receiving the LO MUST obey the privacy and security instructions in
   the LO to be compliant with this specification.

   Self-signed certificates SHOULD NOT be used for protecting LI, as
   the sender does not have a secure identity of the recipient.

   Several LOs MAY be included in a body.  If the message length
   exceeds the maximum message length of a single packet, session mode
   is to be used.

   Several SIP Methods are capable (and applicable) to carry the LO
   message body.  The Methods are divided into two groups, one for
   those applicable for UA-to-UA location conveyance, and the other
   group for UA-to-Proxy Location conveyance for routing the message.

   The list of applicable Methods for UA-to-UA location conveyance is:

      INVITE,
      UPDATE,
      MESSAGE,
      SUBSCRIBE/NOTIFY, and
      PUBLISH.

   The list of applicable Methods for UA-to-Proxy location conveyance
   is:

      INVITE,
      UPDATE, and


Polk & Rosen                                                  [Page 12]


Internet Draft         SIP Location Conveyance          June 17th, 2005

      MESSAGE

   While the authors do not yet see a reason to have location conveyed
   in the OPTIONS, ACK, PRACK, BYE, REFER and CANCEL Methods, we do not
   see a reason to prevent carrying a LO within these Method Requests
   as long as the SIP message meets the requirements stated within this
   document.

   A 200 OK to an INVITE MAY carry the UAS's LO back to the UAC that
   provided its location in the INVITE, but this is not something
   that can be required due to the timing of the INVITE to 200 OK
   messages, with potential local/user policy requiring the called user
   to get involved in determining if the caller is someone they wish to
   give location to (and at what precision).

   For UA-to-Proxy location conveyance, there are two cases: one in
   which all proxies on the path from the UA to the proxy that requires
   location can be trusted with the LI, and one in which intermediate
   proxies may not be trusted.  The former may be implemented with
   "hop-by-hop" security as specified in [RFC3261] using sips: (i.e.
   TLS security).   In particular, emergency call routing requires
   routing proxies to know location, and sips: protection is
   appropriate.  The latter case is under study by the SIPPING working
   group under the  subject "End to Middle" security [ID-End-Mid-Sec].

   Regardless which scenario (UA-to-UA or UA-to-Proxy) is used to
   convey location, SIP entities MUST adhere to the rules of [RFC3693],
   specifically the retention and distribution (privacy) attributes of
   a UA's location.  When Alice is deciding how to transmit her
   location, she should be keenly aware of the parameters in which she
   wants her location to be stored and distributed.  However, once she
   sends that location information to Bob, he MUST also now obey
   Alice's wishes regarding these privacy attributes if he is deciding
   to inform another party about Alice.  This is a fundamental
   principle of the Geopriv Working Group, i.e. "PRIVACY".


8.  User Agent-to-User Agent Location Conveyance

   The offered solution here for the User-to-User location conveyance
   between UAs is used with the INVITE, UPDATE, MESSAGE, SUB/NOT and
   PUBLISH Methods in the following subsections.

   Well formed SIP messages are only in the main body of this document
   for the first few examples.  All well formed SIP message flows are
   in separate appendixes at the end of this document for brevity here,
   while there providing a complete set of example flows to review and
   comment on.

8.1 UA-to-UA using INVITE Method

   Below is a common SIP session set-up sequence between two user


Polk & Rosen                                                  [Page 13]


Internet Draft         SIP Location Conveyance          June 17th, 2005

   agents.  In this example, Alice will provide Bob with her geographic
   location in the INVITE message.

   UA Alice                                  UA Bob

      |                INVITE [M1]              |
      |---------------------------------------->|
      |                                         |
      |                200 OK [M2]              |
      |<----------------------------------------|
      |                                         |
      |                  ACK [M3]               |
      |---------------------------------------->|
      |                                         |
      |                   RTP                   |
      |<=======================================>|
      |                                         |

      Figure 1. UA-UA with Location in INVITE

   User agent Alice invites user agent Bob to a session [M1 of Figure
   1].

   - Within this INVITE is a multipart body indication that it is
     S/MIME encrypted [according to the rules of RFC3261] by Alice for
     Bob.  One body part contains the SDP offered by Alice to Bob.
     Alice's location (here coordinate based) is the other body part
     contained in this INVITE.

   - Bob responses with a 200 OK [M2] (choosing a codec as specified by
     the Offer/Answer Model [RFC3264]).  Bob can include his location
     in the 200 OK response, but this shouldn't be expected due to user
     timing.  If Bob wants to provide his location to Alice after the
     200 OK, but before a BYE, the UPDATE Method [RFC3311] should be
     used.

   - Alice's UA replies with an ACK and the session is set up.

   Figure 1. does not include any Proxies because in it assumed they
   would not affect the session set-up with respect to whether or not
   Alice's location is in a message body part, and Proxies don't react
   to S/MIME bodies, making their inclusion more or less moot and more
   complex than necessary.

   The most relevant message in Figure 1 having to do with location is
   (obviously) the message with the location object in it [M1].  So to
   cut down on length of this document, only the INVITE message in this
   example will be shown. Section 8.1.1 will give an example of this
   well formed INVITE message using a Coordinate location format.
   Section 8.1.2 will give an example of this well formed INVITE
   message using the civic location format.



Polk & Rosen                                                  [Page 14]


Internet Draft         SIP Location Conveyance          June 17th, 2005


8.1.1 UA-to-UA INVITE with Coordinate Location Using S/MIME

   Below is a well-formed SIP INVITE Method message to the example in
   Figure 1 in section 8.1.

   [Message 1 in Figure 1]

   INVITE sips:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com
    ;branch=z9hG4bK776asdhds
   Max-Forwards: 70
   To: Bob <sips:bob@biloxi.example.com>
   From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710@pc33.atlanta.example.com
   CSeq: 314159 INVITE
   Contact: <sips:alice@pc33.atlanta.example.com>
   Content-Type: application/pkcs7-mime;
      smime-type=enveloped-data; name=smime.p7m
   Content-Disposition: attachment;
      filename=smime.p7m  handling=required

   Content-Type: multipart/mixed; boundary=boundary1

   --boundary1

   Content-Type: application/sdp
   v=0
   o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
   c=IN IP4 10.1.3.33
   t=0 0
   m=audio 49172 RTP/AVP 0 4 18
   a=rtpmap:0 PCMU/8000

   --boundary1

   Content-type: application/cpim-pidf+xml
   <?xml version="1.0" encoding="UTF-8"?>
       <presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gml="urn:opengis:specification:gml:schema-
                    xsd:feature:v3.0"
          entity="pres:alice@atlanta.example.com">
        <tuple id="sg89ae">
         <timestamp>2005-11-11T08:57:29Z</timestamp>
         <status>
          <gp:geopriv>
            <gp:location-info>
              <gml:location>
                <gml:Point gml:id="point96" srsName="epsg:4326">
                  <gml:coordinates>41.87891N
                                   87.63649W</gml:coordinates>


Polk & Rosen                                                  [Page 15]


Internet Draft         SIP Location Conveyance          June 17th, 2005

                </gml:Point>
               </gml:location>
              <method>dhcp</method>
            </gp:location-info>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>
              <gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
                            expiry>
             </gp:usage-rules>
          </gp:geopriv>
         </status>
        </tuple>
       </presence>

   --boundary1--


8.1.1.1 UA-to-UA INVITE with Coordinate Location Not Using S/MIME

   Below is a well-formed SIP INVITE Method message to the example in
   Figure 1 in section 8.1.  This message is here to show that although
   the requirements are mandatory to implement proper security, it is
   not mandatory to use.  This message below is show for those cases
   where hop-by-hop security is deployed.

   [Message 1 in Figure 1]

   INVITE sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP pc33.atlanta.example.com
     ;branch=z9hG4bK74bf9
   Max-Forwards: 70
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 31862 INVITE
   Contact: <sip:alice@atlanta.example.com>
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1

   Content-Type: application/sdp
   v=0
   o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
   c=IN IP4 10.1.3.33
   t=0 0
   m=audio 49172 RTP/AVP 0 4 18
   a=rtpmap:0 PCMU/8000

   --broundary1

   Content-Type: application/cpim-pidf+xml


Polk & Rosen                                                  [Page 16]


Internet Draft         SIP Location Conveyance          June 17th, 2005

   <?xml version="1.0" encoding="UTF-8"?>
       <presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gml="urn:opengis:specification:gml:schema-
          xsd:feature:v3.0"
          entity="pres:alice@atlanta.example.com">
        <tuple id="sg89ae">
         <timestamp>2005-11-11T08:57:29Z</timestamp>
         <status>
          <gp:geopriv>
            <gp:location-info>
              <gml:location>
                <gml:Point gml:id="point96" srsName="epsg:4326">
                  <gml:coordinates>41.87891N
                                   87.63649W</gml:coordinates>
                </gml:Point>
               </gml:location>
              <method>dhcp</method>
            </gp:location-info>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>
              <gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
                     expiry>
            </gp:usage-rules>
          </gp:geopriv>
         </status>
        </tuple>
       </presence>

   --boundary1--


8.1.2 UA-to-UA INVITE with Civic Location Using S/MIME

   Below is a well-formed SIP INVITE Method message to the example in
   Figure 1 in section 8.1 using the civic location format.


   [Message 1 in Figure 1]

   INVITE sips:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com
    ;branch=z9hG4bK776asdhds
   Max-Forwards: 70
   To: Bob <sips:bob@biloxi.example.com>
   From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710@pc33.atlanta.example.com
   CSeq: 314159 INVITE
   Contact: <sips:alice@pc33.atlanta.example.com>
   Content-Type: application/pkcs7-mime;
      smime-type=enveloped-data; name=smime.p7m
   Content-Disposition: attachment;


Polk & Rosen                                                  [Page 17]


Internet Draft         SIP Location Conveyance          June 17th, 2005

      filename=smime.p7m  handling=required

   Content-Type: multipart/mixed; boundary=boundary1

   --boundary1

   Content-Type: application/sdp
   v=0
   o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
   c=IN IP4 10.1.3.33
   t=0 0
   m=audio 49172 RTP/AVP 0 4 18
   a=rtpmap:0 PCMU/8000

   --boundary1

   Content-type: application/cpim-pidf+xml
   <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gml="urn:opengis:specification:gml:schema-
                     xsd:feature:v3.0"
          entity="pres:alice@atlanta.example.com">
        <tuple id="sg89ae">
         <timestamp>2005-11-11T08:57:29Z</timestamp>
         <status>
          <gp:geopriv>
            <gp:location-info>
              <cl:civilAddress>
                <cl:country>US</cl:country>
                <cl:A1>Illinois</cl:A1>
                <cl:A3>Chicago</cl:A3>
                <cl:HNO>233</cl:HNO>
                <cl:PRD>South</cl:PRD>
                <cl:A6>Wacker</cl:A6>
                <cl:STS>Drive</cl:STS>
                <cl:PC>60606</cl:PC>
                <cl:LMK>Sears Tower</cl:LMK>
                <cl:FLR>1</cl:FLR>
              <cl:civilAddress>
              <method>dhcp</method>
              <provided-by><nena>www.cisco.com</nena></provided-by/>
            </gp:location-info>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>
              <gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
                            expiry>
            </gp:usage-rules>
          </gp:geopriv>
         </status>
        </tuple>
       </presence>


Polk & Rosen                                                  [Page 18]


Internet Draft         SIP Location Conveyance          June 17th, 2005


--boundary1--


8.1.2.1 UA-to-UA INVITE with Civic Location Not Using S/MIME

   Below is a well-formed SIP INVITE Method message to the example in
   Figure 1 in section 8.1.  This message is here to show that although
   the requirements are mandatory to implement proper security, it is
   not mandatory to use.  This message below is show for those cases
   where the sending user does not wish to use security mechanisms in
   transmitting their coordinate location.


   [Message 1 in Figure 1]

   INVITE sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP pc33.atlanta.example.com
     ;branch=z9hG4bK74bf9
   Max-Forwards: 70
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 31862 INVITE
   Contact: <sip:alice@atlanta.example.com>
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1

   Content-Type: application/sdp
   v=0
   o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
   c=IN IP4 10.1.3.33
   t=0 0
   m=audio 49172 RTP/AVP 0 4 18
   a=rtpmap:0 PCMU/8000

   --broundary1

   Content-type: application/cpim-pidf+xml
   <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gml="urn:opengis:specification:gml:schema-
                     xsd:feature:v3.0"
          entity="pres:alice@atlanta.example.com">
        <tuple id="sg89ae">
         <timestamp>2005-11-11T08:57:29Z</timestamp>
         <status>
          <gp:geopriv>
            <gp:location-info>


Polk & Rosen                                                  [Page 19]


Internet Draft         SIP Location Conveyance          June 17th, 2005

              <cl:civilAddress>
                <cl:country>US</cl:country>
                <cl:A1>Illinois</cl:A1>
                <cl:A3>Chicago</cl:A3>
                <cl:HNO>233</cl:HNO>
                <cl:PRD>South</cl:PRD>
                <cl:A6>Wacker</cl:A6>
                <cl:STS>Drive</cl:STS>
                <cl:PC>60606</cl:PC>
                <cl:LMK>Sears Tower</cl:LMK>
                <cl:FLR>1</cl:FLR>
              <cl:civilAddress>
              <method>dhcp</method>
              <provided-by><nena>www.cisco.com</nena></provided-by/>
            </gp:location-info>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>
              <gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
                            expiry>
            </gp:usage-rules>
          </gp:geopriv>
         </status>
        </tuple>
       </presence>

--boundary1--


8.2 UA-to-UA Using MESSAGE Method

   Anytime a user transmits location information outside a dialog, the
   MESSAGE Method is to be used.  The logic here is as follows:

      - UPDATE isn't appropriate because it is for the updating of
        session capabilities and parameters of a dialog (after the
        INVITE included location information).

      - reINVITE isn't appropriate because it is only used (or only
        supposed to be used) for changing the parameters of an existing
        dialog, and one might not exist in all cases of location
        conveyance.

   This leaves MESSAGE as the only viable Request Method for location
   conveyance outside of a dialog between two users (Alice and Bob in
   this case). The following is an example of this communication.


   UA Alice                                  UA Bob

      |               MESSAGE [M1]              |
      |---------------------------------------->|
      |                                         |


Polk & Rosen                                                  [Page 20]


Internet Draft         SIP Location Conveyance          June 17th, 2005

      |                200 OK [M2]              |
      |<----------------------------------------|
      |                                         |

      Figure 2. UA-UA with Location in MESSAGE

   Section 8.2.1 will give the well formed MESSAGE Method containing a
   well formed Geopriv Location Object using the Coordinate location
   format that fully complies with all security requirements - SIPS for
   hop-by-hop security, and S/MIME for message body confidentiality
   end-to-end, as well as adhering to the retention and distribution
   concerns from [RFC3693].  Section 8.2.2 will show the Civic Location
   format alternative to the same location, as conveyed from Alice to
   Bob.  This section does not adhere to confidentiality or integrity
   concerns of [RFC3693], but does convey retention and distribution
   indicators from Alice.


8.2.1 UA-to-UA MESSAGE with Coordinate Location Using S/MIME

   Below is M1 from Figure 2 in section 8.2. that is fully secure and
   in compliance with Geopriv requirements in [RFC3693] for security
   concerns.


   [Message 1 in Figure 2]

   MESSAGE sips:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com
    ;branch=z9hG4bK776asegma
   Max-Forwards: 70
   To: Bob <sips:bob@biloxi.example.com>
   From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710@pc33.atlanta.example.com
   CSeq: 22756 MESSAGE
   Content-Type: application/pkcs7-mime;
      smime-type=enveloped-data; name=smime.p7m
   Content-Disposition: attachment;
      filename=smime.p7m  handling=required

   Content-Type: multipart/mixed; boundary=boundary1

   --boundary1

   Content-Type: text/plain
   Here's my location, Bob?

   --broundary1

   Content-Type: application/cpim-pidf+xml
   Content-Disposition: render
   Content-Description: my location


Polk & Rosen                                                  [Page 21]


Internet Draft         SIP Location Conveyance          June 17th, 2005

   <?xml version="1.0" encoding="UTF-8"?>
       <presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gml="urn:opengis:specification:gml:schema-
          xsd:feature:v3.0"
          entity="pres:alice@atlanta.example.com">
        <tuple id="sg89ae">
         <timestamp>2005-11-11T08:57:29Z</timestamp>
         <status>
          <gp:geopriv>
            <gp:location-info>
              <gml:location>
                <gml:Point gml:id="point96" srsName="epsg:4326">
                  <gml:coordinates>41.87891N
                                   87.63649W</gml:coordinates>
                </gml:Point>
               </gml:location>
              <method>dhcp</method>
            </gp:location-info>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>
              <gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
                     expiry>
            </gp:usage-rules>
          </gp:geopriv>
         </status>
        </tuple>
       </presence>

   --boundary1--


8.2.2 UA-to-UA MESSAGE with Civic Location Not Using S/MIME

   Below is a well-formed SIP MESSAGE Method message to the example in
   Figure 2 in section 8.2 when hop-by-hop security mechanisms are
   deployed.

   [Message 1 in Figure 2]

   MESSAGE sip:bob@biloxi.example.com SIP/2.0
   From: <sip:alice@atlanta.example.com>;tag=34589882
   To: <sip:bob@biloxi.example.com>
   Call-ID: 9242892442211117@atlanta.example.com
   CSeq: 6187 MESSAGE
   Content-Type: application/cpim-pidf+xml
   Content-ID: <766534765937@atlanta.example.com>
   Content-Disposition: render
   Content-Description: my location

   <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"


Polk & Rosen                                                  [Page 22]


Internet Draft         SIP Location Conveyance          June 17th, 2005

          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gml="urn:opengis:specification:gml:schema-
          xsd:feature:v3.0"
          entity="pres:alice@atlanta.example.com">
        <tuple id="sg89ae">
         <timestamp>2005-11-11T08:57:29Z</timestamp>
         <status>
          <gp:geopriv>
            <gp:location-info>
              <cl:civilAddress>
                <cl:country>US</cl:country>
                <cl:A1>Illinois</cl:A1>
                <cl:A3>Chicago</cl:A3>
                <cl:HNO>233</cl:HNO>
                <cl:PRD>South</cl:PRD>
                <cl:A6>Wacker</cl:A6>
                <cl:STS>Drive</cl:STS>
                <cl:PC>60606</cl:PC>
                <cl:LMK>Sears Tower</cl:LMK>
                <cl:FLR>1</cl:FLR>
              <cl:civilAddress>
              <method>dhcp</method>
            </gp:location-info>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>
              <gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
                      expiry>
            </gp:usage-rules>
          </gp:geopriv>
         </status>
        </tuple>
       </presence>


8.3 UA-to-UA Location Conveyance Using UPDATE

   UPDATE MUST NOT be used to send location information from UA-to-UA
   unless location has already been sent in an INVITE or corresponding
   200 OK that was the first message exchange in the same dialog set-
   up.  The same security properties used in the INVITE MUST be used in
   the UPDATE message.

   The UPDATE Method is to be used any time location information is to
   be updated between UAs setting up a dialog or after the dialog has
   been established, no matter how long that dialog has been
   operational.  reINVITE is out of scope here, and the MESSAGE Method
   is for non-dialog location conveyance between UAs only.

   One reason for this message being generated is if either UA that
   sent its location information to the other UA (say in the INVITE and
   corresponding 200 OK) is if either UA determines that is has moved
   while the dialog has remained operational.  How this movement is


Polk & Rosen                                                  [Page 23]


Internet Draft         SIP Location Conveyance          June 17th, 2005

   determined is outside the scope of this document, but ultimately
   should be configurable by local administration or the user of the
   UA.  By how much Alice has moved to trigger the "sense of movement"
   (i.e. the need to send new location) to Bob is also outside the
   scope of this specification, but ultimately should be configurable
   by local administration or the user of the UA.

   In Figure 3., we have an example message flow involving the UPDATE
   Method. We are not including all the messages for space reasons.  M1
   is a well formed SIP message that contains Alice's location. During
   the session set-up, Alice's UA knows it has moved while knowing too
   the session has not been formally accepted by Bob.  Alice's UA
   decides to update Bob with her new location with an UPDATE Method
   message.   Messages M2, M3 and M4 have nothing to do with location
   conveyance, therefore will not be shown in detail.  Only M1 and M5
   will be shown.

   NOTE: A similar use for UPDATE is within the UA-to-Proxy Location
         Conveyance section of this document.


   UA Alice                                  UA Bob

      |                INVITE [M1]              |
      |---------------------------------------->|
      |                                         |
      |        183 (session Progress) [M2]      |
      |<----------------------------------------|
      |                                         |
      |                 PRACK [M3]              |
      |---------------------------------------->|
      |                                         |
      |              ACK (PRACK) [M4]           |
      |<----------------------------------------|
      |                                         |
      |                 UPDATE [M5]             |
      |---------------------------------------->|
      |                                         |
      |              ACK (UPDATE) [M6]          |
      |<----------------------------------------|
      |                                         |
      |            200 OK (INVITE) [M7]         |
      |<----------------------------------------|
      |                                         |
      |                   RTP                   |
      |<=======================================>|
      |                                         |

      Figure 3. UA-UA with Location in UPDATE


   The following section will include the M1 and M5 messages in detail,


Polk & Rosen                                                  [Page 24]


Internet Draft         SIP Location Conveyance          June 17th, 2005

   but only in the civic format.


8.3.1 UA-to-UA UPDATE with Civic Location Not Using S/MIME

   Here is the initial INVITE from Alice to Bob.

  [M1 INVITE to Bob]

   INVITE sips:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com
    ;branch=z9hG4bK776asdhds
   Max-Forwards: 70
   To: Bob <sips:bob@biloxi.example.com>
   From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710@pc33.atlanta.example.com
   CSeq: 314159 INVITE
   Contact: <sips:alice@pc33.atlanta.example.com>
   Content-Type: application/pkcs7-mime;
      smime-type=enveloped-data; name=smime.p7m
   Content-Disposition: attachment;
      filename=smime.p7m  handling=required

   Content-Type: multipart/mixed; boundary=boundary1

   --boundary1

   Content-Type: application/sdp
   v=0
   o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
   c=IN IP4 10.1.3.33
   t=0 0
   m=audio 49172 RTP/AVP 0 4 18
   a=rtpmap:0 PCMU/8000

   --boundary1

   Content-type: application/cpim-pidf+xml
   <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gml="urn:opengis:specification:gml:schema-
                     xsd:feature:v3.0"
          entity="pres:alice@atlanta.example.com">
        <tuple id="sg89ae">
         <timestamp>2005-11-11T08:57:29Z</timestamp>
         <status>
          <gp:geopriv>
            <gp:location-info>
              <cl:civilAddress>
                <cl:country>US</cl:country>
                <cl:A1>Illinois</cl:A1>


Polk & Rosen                                                  [Page 25]


Internet Draft         SIP Location Conveyance          June 17th, 2005

                <cl:A3>Chicago</cl:A3>
                <cl:HNO>233</cl:HNO>
                <cl:PRD>South</cl:PRD>
                <cl:A6>Wacker</cl:A6>
                <cl:STS>Drive</cl:STS>
                <cl:PC>60606</cl:PC>
                <cl:LMK>Sears Tower</cl:LMK>
                <cl:FLR>1</cl:FLR>
              <cl:civilAddress>
              <method>dhcp</method>
              <method>802.11</method>
             <provided-by>www.cisco.com</provided-by/>
            </gp:location-info>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>
              <gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
                            expiry>
            </gp:usage-rules>
          </gp:geopriv>
         </status>
        </tuple>
       </presence>

--boundary1--

   Alice moves locations (with her UA detecting the movement), causing
   her UA to generate an UPDATE message ([M5] of Figure 3) prior to
   her UA receiving a final response from Bob.  Here is that message:

  M5 UPDATE to Bob

   UPDATE sips:bob@biloxi.example.com/TCP SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com
    ;branch=z9hG4bK776asdhds
   Max-Forwards: 70
   To: Bob <sips:bob@biloxi.example.com>
   From: Alice <sips:alice@atlanta.example.com>;tag=1928
   Call-ID: a84b4c76e66710@pc33.atlanta.example.com
   CSeq: 10197 UPDATE
   Contact: <sips:alice@pc33.atlanta.example.com>
   Content-Type: application/pkcs7-mime;
      smime-type=enveloped-data; name=smime.p7m
   Content-Disposition: attachment;
      filename=smime.p7m  handling=required

   Content-Type: multipart/mixed; boundary=boundary1

   --boundary1

   Content-Type: application/sdp
   v=0
   o=alice 2890844526 2890844526 IN IP4 atlanta.example.com


Polk & Rosen                                                  [Page 26]


Internet Draft         SIP Location Conveyance          June 17th, 2005

   c=IN IP4 10.1.3.33
   t=0 0
   m=audio 49172 RTP/AVP 0 4 18
   a=rtpmap:0 PCMU/8000

   --boundary1

   Content-type: application/cpim-pidf+xml
   <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gml="urn:opengis:specification:gml:schema-
                     xsd:feature:v3.0"
          entity="pres:alice@atlanta.example.com">
        <tuple id="sg89ae">
         <timestamp>2005-11-11T08:57:29Z</timestamp>
         <status>
          <gp:geopriv>
            <gp:location-info>
              <cl:civilAddress>
                <cl:country>US</cl:country>
                <cl:A1>Illinois</cl:A1>
                <cl:A3>Chicago</cl:A3>
                <cl:HNO>250</cl:HNO>
                <cl:PRD>South Upper</cl:PRD>
                <cl:A6>Wacker</cl:A6>
                <cl:STS>Drive</cl:STS>
                <cl:PC>60606</cl:PC>
                <cl:NAM>Venice Cafe</cl:NAM>
                <cl:FLR>1</cl:FLR>
              <cl:civilAddress>
              <method>dhcp</method>
              <method>802.11</method>
              <provided-by>www.t-mobile.com</provided-by/>
            </gp:location-info>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>
              <gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
                            expiry>
            </gp:usage-rules>
          </gp:geopriv>
         </status>
        </tuple>
       </presence>

--boundary1--


8.4 UA-to-UA Location Conveyance Using PUBLISH

   ** This section could not be completed before submission time and
   will be completed shortly after IETF61. A thousand and one pardons.


Polk & Rosen                                                  [Page 27]


Internet Draft         SIP Location Conveyance          June 17th, 2005



8.5 UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY

   This section was not completed in time for the ID cut-off, thus all
   text was removed until it can be completed.  The authors apologize.


8.6 424 "Bad Location Information" Error Response

   In the case that a user agent server or SIP Proxy detects an error
   in a message containing location information specific to that
   message body, a new 4XX level error needs to be sent.  This document
   creates the new error code:

      424 (Bad Location Information)

   This will provide the UAC with directed feedback about the status of
   location information it sent to that UAS or Proxy.  The UAC MAY
   attempt to retry sending the message providing its location.

   This new error code will be IANA registered.

   An example flow of this scenario will be included in the next
   version of this internet draft.


9.  Special Considerations for Emergency Calls

   When a Proxy Server knows to look for a location message body to
   route an emergency call as in [ID-EMER-ARCH].

   Emergency calls, which might be detected as detailed in [ID-SIP-
   SOS], have special rules for conveyance of location:

   1. An emergency call MUST have all LI available to the UA, if any,
      sent with the INVITE, and subsequent UPDATE or reINVITE messages
      as a PIDF-LO in a body

   2. The LO must be protected with sips: unless the attempt to
      establish hop-by-hop TLS connection fails and cannot reasonably
      be established in a very short (less than a second) time.  In
      such a case, the LO SHOULD be sent without TLS ONLY for those
      hops that failed to support TLS establishment.

   3. User Agents MUST NOT use S/MIME

   4. User Agents MUST include the <provided-by> element in the PIDF-LO
      (if known) to give the PSAP an indication as to who is
      responsible for providing the UA with its location information.




Polk & Rosen                                                  [Page 28]


Internet Draft         SIP Location Conveyance          June 17th, 2005

   Proxies MUST NOT remove a location message body at any time.  In the
   case where the Proxy knows the location of the UAC and does not
   detect the UAC's location information message body in the message
   (or determines the LO is bad), the Proxy generates a new 4XX (Retry
   Location Body) error message that includes a location information
   message body for that UAC to include in the subsequent message.  The
   user agent MUST include this message body in the subsequent
   emergency message.

   In the <provided-by> element of the PIDF-LO, the Proxy MUST identify
   itself as the source of this location information.  The user agent
   MUST NOT alter this field's value if received from a Proxy server.

   If the UAS of the PSAP receives a SIP request with multiple location
   objects, it must determine which to use, since more than one may be
   present.  This specification does not limit the number of LOs in a
   message, even in session mode.


9.1 UA-to-Proxy Routing the Message with INVITE (secure)

   When Alice signifies "sos@" [per 3], her UA must understand this
   message MUST NOT use S/MIME for the message body, because this is an
   emergency call - otherwise the message will not properly route to
   the correct destination.  Two definite possibilities will exist for
   how this message flow will occur [note: the message flows are not
   being defined here, they are defined in [ID-EMER-ARCH], but two are
   shown here to show the messages themselves].  The first possibility
   has Alice sending her INVITE to her first hop Proxy, which
   recognizes the message as an emergency message.  The Proxy knows to
   look into the message bodies for the location body; determine where
   Alice is and route the call to the appropriate PSAP.  This is shown
   in Figure 4A.

   UA Alice             Proxy                  PSAP

      |    INVITE [M1]    |                     |
      |------------------>|                     |
      |                   |      INVITE [M2]    |
      |                   |-------------------->|
      |                   |      200 OK [M3]    |
      |                   |<--------------------|
      |   200 OK [M4]     |                     |
      |<------------------|                     |
      |     ACK [M5]                            |
      |---------------------------------------->|
      |                   RTP                   |
      |<=======================================>|
      |                                         |

      Figure 4A. UA-PROXY with Location in INVITE



Polk & Rosen                                                  [Page 29]


Internet Draft         SIP Location Conveyance          June 17th, 2005

   [M1 of  Figure 4A]

   INVITE sips:sos@atlanta.example.com SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com
     ;branch=z9hG4bK74bf9
   Max-Forwards: 70
   From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
   To: <sips:sos@atlanta.example.com>
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 31862 INVITE
   Contact: <sips:alice@atlanta.example.com>
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1

   Content-Type: application/sdp
   v=0
   o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
   c=IN IP4 10.1.3.33
   t=0 0
   m=audio 49172 RTP/AVP 0 4 18
   a=rtpmap:0 PCMU/8000

   --boundary1


   Once the Proxy receives M1 and recognizes it as an emergency INVITE
   Request, this proxy knows to look into the message body for a
   location body part to determine the location of the UAC in order to
   match the location to an PSAP.  Once this look-up occurs, the
   message is sent directly to the PSAP (in message [M2]).

   [M2 of Figure 4A] - Proxy has determined when to send message

   INVITE sips:sos@192.168.10.20 SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com
     ;branch=z9hG4bK74bf9
   Max-Forwards: 69
   From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
   To: <sips:sos@atlanta.example.com>
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 31862 INVITE
   Contact: <sips:alice@atlanta.example.com>
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1

   Content-Type: application/sdp
   v=0
   o=alice 2890844526 2890844526 IN IP4 atlanta.example.com


Polk & Rosen                                                  [Page 30]


Internet Draft         SIP Location Conveyance          June 17th, 2005

   c=IN IP4 10.1.3.33
   t=0 0
   m=audio 49172 RTP/AVP 0 4 18
   a=rtpmap:0 PCMU/8000

   --boundary1

   Content-type: application/cpim-pidf+xml
   <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gml="urn:opengis:specification:gml:schema-
                     xsd:feature:v3.0"
          entity="pres:alice@atlanta.example.com">
        <tuple id="sg89ae">
         <timestamp>2005-11-11T08:57:29Z</timestamp>
         <status>
          <gp:geopriv>
            <gp:location-info>
              <cl:civilAddress>
                <cl:country>US</cl:country>
                <cl:A1>Illinois</cl:A1>
                <cl:A3>Chicago</cl:A3>
                <cl:HNO>233</cl:HNO>
                <cl:PRD>South</cl:PRD>
                <cl:A6>Wacker</cl:A6>
                <cl:STS>Drive</cl:STS>
                <cl:PC>60606</cl:PC>
                <cl:LMK>Sears Tower</cl:LMK>
                <cl:FLR>1</cl:FLR>
              <cl:civilAddress>
              <method>dhcp</method>
              <method>802.11</method>
              <provided-by>www.t-mobile.com</provided-by/>
            </gp:location-info>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>
              <gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
                            expiry>
            </gp:usage-rules>
          </gp:geopriv>
         </status>
        </tuple>
       </presence>

--boundary1--


   The second probability in message flows is in Figure 4B. in which
   the first hop Proxy1 does not either: understand location, or does
   not know where the appropriate PSAP is to route the message to.  In
   either case, that Proxy(1) forwards the message to another Proxy(2)


Polk & Rosen                                                  [Page 31]


Internet Draft         SIP Location Conveyance          June 17th, 2005

   for proper message routing ([ID-EMER-ARCH] talks to how this
   occurs).


   UA Alice      Proxy1         Proxy2         PSAP

      | INVITE [M1] |             |             |
      |------------>|             |             |
      |             | INVITE [M2] |             |
      |             |------------>|             |
      |             |             | INVITE [M3] |
      |             |             |------------>|
      |             |             | 200 OK [M4] |
      |             |             |<------------|
      |             | 200 OK [M5] |             |
      |             |<------------|             |
      | 200 OK [M6] |             |             |
      |<------------|             |             |
      |   ACK [M7]                              |
      |---------------------------------------->|
      |                   RTP                   |
      |<=======================================>|
      |                                         |

      Figure 4B. UA-PROXY with Location in INVITE

   In message flows similar to 4A and/or 4B, the Record-Route header
   could be added by the proxies, this is OPTIONAL in usage and left to
   other documents to refine.

   In the case of an identifiable emergency call, something that cannot
   happen is for any Proxy to Challenge [per RFC3261] the INVITE
   message.  In fact, while usage of the SIPS URI is encouraged and
   SHOULD be used, it MUST NOT be mandatory for successful message
   routing.  If the first SIPS INVITE fails for security property
   reasons, the second attempt by Alice (in these examples) MUST be
   allowed to be in the clear, not challenged, and routed properly.
   Security mechanisms MUST NOT fail any call attempt, and if they do
   once, they MUST NOT be mandatory for the subsequent attempt for a
   successful session set-up to an PSAP.  The results of this are that
   the Proxy that failed the first attempt for security reasons MUST be
   aware of this failed attempt for the subsequent attempt that MUST
   process without failure a second time.   It must be assumed that the
   INVITE in any instance is considered "well formed".

   The remaining messages in both 4A and 4B are not included at this
   time.  If the working groups wants these added, they will be in the
   next revision of this document.


9.1.1 UA-to-Proxy Routing the Message with INVITE (unsecure)



Polk & Rosen                                                  [Page 32]


Internet Draft         SIP Location Conveyance          June 17th, 2005

   Below can be considered the initial unsecure INVITE M1 from Figures
   4A and 4A, or the second attempt message to an initial message that
   was failed by a Proxy.  This version of M1 is not using any security
   measures and is using the civic format message body that is the
   identical location to the previous example.


   [Message M1 from Figure 4A]

   INVITE sip:sos@atlanta.example.com SIP/2.0
   Via: SIP/2.0/TCP pc33.atlanta.example.com
     ;branch=z9hG4bK74bf9
   Max-Forwards: 70
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: <sip:sos@atlanta.example.com>
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 31862 INVITE
   Contact: <sip:alice@atlanta.example.com>
   Content-Type: multipart/mixed; boundary=boundary1
   Contact-Length: ...

   --boundary1

   Content-Type: application/sdp
   v=0
   o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
   c=IN IP4 10.1.3.33
   t=0 0
   m=audio 49172 RTP/AVP 0 4 18
   a=rtpmap:0 PCMU/8000

   --boundary1

   Content-type: application/cpim-pidf+xml
   <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gml="urn:opengis:specification:gml:schema-
                     xsd:feature:v3.0"
          entity="pres:alice@atlanta.example.com">
        <tuple id="sg89ae">
         <timestamp>2005-11-11T08:57:29Z</timestamp>
         <status>
          <gp:geopriv>
            <gp:location-info>
              <cl:civilAddress>
                <cl:country>US</cl:country>
                <cl:A1>Illinois</cl:A1>
                <cl:A3>Chicago</cl:A3>
                <cl:HNO>233</cl:HNO>
                <cl:PRD>South</cl:PRD>
                <cl:A6>Wacker</cl:A6>


Polk & Rosen                                                  [Page 33]


Internet Draft         SIP Location Conveyance          June 17th, 2005

                <cl:STS>Drive</cl:STS>
                <cl:PC>60606</cl:PC>
                <cl:LMK>Sears Tower</cl:LMK>
                <cl:FLR>1</cl:FLR>
              <cl:civilAddress>
              <method>dhcp</method>
              <method>802.11</method>
              <provided-by>www.t-mobile.com</provided-by/>
            </gp:location-info>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>
              <gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
                            expiry>
            </gp:usage-rules>
          </gp:geopriv>
         </status>
        </tuple>
       </presence>

--boundary1--


9.2 UA-to-Proxy Routing with UPDATE

   If the previous example of the location contained in the INVITE were
   to account for the movement of Alice (and her UA) before the PSAP
   responded with a 200 OK, the UPDATE method is the appropriate SIP
   Request Method to use to update the proxies and PSAP personnel that
   Alice has moved locations from where she initially made her set-up
   request.

   In this scenario (shown in the call flow of Figure 5A), Alice
   sending the UPDATE message here may cause the Proxy to CANCEL an
   existing pending INVITE Request, and retransmit INVITE to a NEW
   PSAP(2), for example, if she walked across a street into a new PSAP
   coverage area.  The Proxy MUST remain transaction stateful in order
   to be aware of the 200 OK Response from PSAP1.  Upon receiving the
   UPDATE from Alice and analyzing the location provided by the message
   looking for a location change, either forwarding that message to
   PSAP1 if the change is still within PSAP1's coverage area, or
   deciding to forward a message to another PSAP covering where Alice
   is now (PSAP2 in this case) with her new location.  If the latter
   change in destinations is required, the Proxy MUST CANCEL the
   pending INVITE to PSAP1 (with a 487 "terminated request" being the
   specified response).

   SIPS SHOULD be used by Alice initially.  Upon any failure of the
   initial Request, Alice's UA MUST decide to send the new message
   without SIPS.





Polk & Rosen                                                  [Page 34]


Internet Draft         SIP Location Conveyance          June 17th, 2005

   UA Alice           Proxy         PSAP1          PSAP2

      |   INVITE [M1]   |             |             |
      |---------------->|             |             |
      |                 | INVITE [M2] |             |
      |                 |------------>|             |
      |   183 SP [M3]   |             |             |
      |<----------------|             |             |
      |    PRACK [M4]   |             |             |
      |---------------->|             |             |
      | 200 OK (PR)[M5] |             |             |
      |<----------------|             |             |
      |   UPDATE [M6]   |             |             |
      |---------------->|             |             |
      | 200 OK (UP)[M7] |             |             |
      |<----------------|             |             |
      |                 | CANCEL [M8] |             |
      |                 |------------>|             |
      |                 | 487 [M9]    |             |
      |                 |<------------|             |
      |                 | INVITE [M10]              |
      |                 |-------------------------->|
      |                 |        200 OK (INV) [M11] |
      |                 |<--------------------------|
      |200 OK (INV)[M12]|                           |
      |<----------------|                           |
      |   ACK [M13]                                 |
      |-------------------------------------------->|
      |                      RTP                    |
      |<===========================================>|
      |                                             |

      Figure 5A. UA-PROXY with Location in UPDATE

   ** see new open issue #9 for the problems with messages 8 through 10
   ** of the above flow.


9.2.1 UA-to-Proxy Routing the Message with UPDATE (secure)

   INVITE sip:sos@atlanta.example.com SIP/2.0
   Via: SIP/2.0/TCP pc33.atlanta.example.com
     ;branch=z9hG4bK74bf9
   Max-Forwards: 70
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: <sip:sos@atlanta.example.com>
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 31862 INVITE
   Contact: <sip:alice@atlanta.example.com>
   Content-Type: multipart/mixed; boundary=boundary1
   Contact-Length: ...



Polk & Rosen                                                  [Page 35]


Internet Draft         SIP Location Conveyance          June 17th, 2005

   --boundary1

   Content-Type: application/sdp
   v=0
   o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
   c=IN IP4 10.1.3.33
   t=0 0
   m=audio 49172 RTP/AVP 0 4 18
   a=rtpmap:0 PCMU/8000

   --boundary1

   Content-type: application/cpim-pidf+xml
   <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gml="urn:opengis:specification:gml:schema-
                     xsd:feature:v3.0"
          entity="pres:alice@atlanta.example.com">
        <tuple id="sg89ae">
         <timestamp>2005-11-11T08:57:29Z</timestamp>
         <status>
          <gp:geopriv>
            <gp:location-info>
              <cl:civilAddress>
                <cl:country>US</cl:country>
                <cl:A1>Illinois</cl:A1>
                <cl:A3>Chicago</cl:A3>
                <cl:HNO>233</cl:HNO>
                <cl:PRD>South</cl:PRD>
                <cl:A6>Wacker</cl:A6>
                <cl:STS>Drive</cl:STS>
                <cl:PC>60606</cl:PC>
                <cl:LMK>Sears Tower</cl:LMK>
                <cl:FLR>1</cl:FLR>
              <cl:civilAddress>
              <method>dhcp</method>
              <method>802.11</method>
             <provided-by>www.cisco.com</provided-by/>
            </gp:location-info>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>
              <gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
                            expiry>
            </gp:usage-rules>
          </gp:geopriv>
         </status>
        </tuple>
       </presence>

--boundary1--



Polk & Rosen                                                  [Page 36]


Internet Draft         SIP Location Conveyance          June 17th, 2005

   Alice moves locations (with her UA detecting the movement), causing
   her UA to generate an UPDATE message ([M5] of Figure 3) prior to her
   UA receiving a final response from the PSAP.  In this case, Alice
   has walked across the South Wacker Drive to another building.  Here
   is that message:

  [M5 UPDATE to PSAP]

   UPDATE sips:bob@biloxi.example.com/TCP SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com
    ;branch=z9hG4bK776asdhds
   Max-Forwards: 70
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: <sip:sos@atlanta.example.com>
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 10187 UPDATE
   Contact: <sip:alice@atlanta.example.com>
   Content-Type: multipart/mixed; boundary=boundary1
   Contact-Length: ...

   --boundary1

   Content-Type: application/sdp
   v=0
   o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
   c=IN IP4 10.1.3.33
   t=0 0
   m=audio 49172 RTP/AVP 0 4 18
   a=rtpmap:0 PCMU/8000

   --boundary1

   Content-type: application/cpim-pidf+xml
   <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gml="urn:opengis:specification:gml:schema-
                     xsd:feature:v3.0"
          entity="pres:alice@atlanta.example.com">
        <tuple id="sg89ae">
         <timestamp>2005-11-11T08:57:29Z</timestamp>
         <status>
          <gp:geopriv>
            <gp:location-info>
              <cl:civilAddress>
                <cl:country>US</cl:country>
                <cl:A1>Illinois</cl:A1>
                <cl:A3>Chicago</cl:A3>
                <cl:HNO>250</cl:HNO>
                <cl:PRD>South Upper</cl:PRD>
                <cl:A6>Wacker</cl:A6>
                <cl:STS>Drive</cl:STS>


Polk & Rosen                                                  [Page 37]


Internet Draft         SIP Location Conveyance          June 17th, 2005

                <cl:PC>60606</cl:PC>
                <cl:NAM>Venice Cafe</cl:NAM>
                <cl:FLR>1</cl:FLR>
              <cl:civilAddress>
              <method>dhcp</method>
              <method>802.11</method>
              <provided-by>www.t-mobile.com</provided-by/>
            </gp:location-info>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>
              <gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
                            expiry>
            </gp:usage-rules>
          </gp:geopriv>
         </status>
        </tuple>
       </presence>

--boundary1--


9.2.2 UA-to-Proxy Routing the Message with UPDATE (unsecure)

   left blank for now


9.3 425 "Retry Location Body" Error Response

   In the case that a SIP Proxy detects an error in a SIP message
   containing location information specific to that message body and
   has the location of that UAC locally, a new 4XX level error needs to
   be sent back to the UAC containing a new Location Object message
   body of the UAC as the SIP intermediary understands where the UAC is
   with the intent of the UAC including this LO message body in a
   subsequent message to the originally addressed UAS.  This document
   creates the new error code:

      425 (Retry Location Body)

   The UAC MUST include the SIP intermediary provided LO message body
   in the retransmission of the rejected message to the original UAS if
   the UAC attempts this communication.  User agents may conclude they
   have already supplied a proper LO in the rejected request.  That LO
   can be resent, but the intermediary supplied LO MUST be included as
   well.

   This new error code will be IANA registered.

   An example flow of this scenario will be included in the next
   version of this internet draft.




Polk & Rosen                                                  [Page 38]


Internet Draft         SIP Location Conveyance          June 17th, 2005

10.  Meeting RFC3693 Requirements

   Section 7.2 of [RFC3693] details the requirements of a "using
   protocol".  They are:

   Req. 4.  The using protocol has to obey the privacy and security
      instructions coded in the Location Object and in the
      corresponding Rules regarding the transmission and storage of the
      LO.

   This document requires, in Section 7, that SIP entities sending or
   receiving location MUST obey such instructions.

   Req. 5.  The using protocol will typically facilitate that the keys
      associated with the credentials are transported to the respective
      parties, that is, key establishment is the responsibility of the
      using protocol.

   [RFC3261] and the documents it references define the key establish
   mechanisms.

   Req. 6.  (Single Message Transfer)  In particular, for tracking of
      small target devices, the design should allow a single
      message/packet transmission of location as a complete
      transaction.

   This document specifies that the LO be contained in the body of a
   single message.


11. Current Known Open issues

   This is a list of open issues that have not yet been addressed to
   conclusion:

   1) Still have not determined how a SIP entity can request location
      to be delivered in a certain format (civil vs. coordinate).


11.1  New Open Issues

   These are new open issues to be addressed within this document or
   the topics/areas dropped from consideration:

   1) May add a section for end-to-middle in a services model


12.  Security Considerations

   Conveyance of geo-location of a UAC is problematic for many reasons.
   This document calls for that conveyance to normally be accomplished
   through secure message body means (like S/MIME or TLS).  In cases


Polk & Rosen                                                  [Page 39]


Internet Draft         SIP Location Conveyance          June 17th, 2005

   where a session set-up is routed based on the location of the UAC
   initiating the session or SIP MESSAGE, securing the location with an
   end-to-end mechanism such as S/MIME is problematic.


13.  IANA Considerations

   This section defines two new 4XX error response codes within the
   sip-parameters section of IANA.  [NOTE: RFC XXXX denotes this
   document.


13.1 IANA Registration for Response Code 4XX

   Reference: RFC-XXXX (this document)
   Response code: 424
   Default reason phrase: Bad Location Information

13.2 IANA Registration for Response Code 4XX

   Reference: RFC-XXXX (this document)
   Response code: 425
   Default reason phrase: Retry Location Body


14.  Acknowledgements

   To Dave Oran for helping to shape this idea. To Jon Peterson and
   Dean Willis on guidance of the effort. To Henning Schulzrinne,
   Jonathan Rosenberg, Dick Knight, Mike Hammer and Keith Drage for
   constructive feedback.


15. References

15.1 References - Normative

 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
           Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
           Session Initiation Protocol", RFC 3261, May 2002.

 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
           Requirement Levels", RFC 2119, March 1997

 [ID-SIP-SOS] H. Schulzrinne, "draft-ietf-sipping-sos-00.txt", Internet
           Draft, Feb 2004, Work in progress

 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema,
           D. Gurle, "Session Initiation Protocol (SIP) Extension for
           Instant Messaging" , RFC 3428, December 2002

 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host


Polk & Rosen                                                  [Page 40]


Internet Draft         SIP Location Conveyance          June 17th, 2005

           Configuration Protocol Option for Coordinate-based Location
           Configuration Information", RFC 3825, July 2004

 [ID-CIVIC] H. Schulzrinne, "draft-ietf-geopriv-dhcp-civic-06.txt",
           Internet Draft, May 05, Work in progress

 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,
           "Geopriv Requirements", RFC 3693, February 2004

 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
           Method", RFC 3311, October 2002

 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
           for Event State Publication", RFC 3903, October 2004.

 [ID-PIDF-LO] J. Peterson, "draft-ietf-geopriv-pidf-lo-03", Internet
           Draft, Sept 2004, work in progress

 [RFC3264] J. Rosenberg, H. Schulzrinne, "The Offer/Answer Model with
           Session Description Protocol", RFC 3264, June 2002

 [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer
           Method", RFC 3515, April 2003

 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
           Event Notification", RFC 3265, June 2002.


16.1 References - Informative

 [ID-End-Mid-Sec] "Requirements for End to Middle Security in SIP",
           draft-ietf-sipping-e2m-sec-reqs-03.txt, Internet Draft, June
           2004, work in progress,

 [ID-Sess-Pol] J. Rosenberg, "Requirements for Session Policy for the
           Session Initiation Protocolö, draft-ietf-sipping-session-
           policy-req-00", Internet Draft, June, 2003, "work in
           progress"

 [ID-EMER-ARCH] H. Schulzrinne, B. Rosen, "draft-schulzrinne-sipping-
           emergency-arch", Internet Draft, Feb 2004, work in progress


16. Author Information

   James M. Polk
   Cisco Systems
   2200 East President George Bush Turnpike          33.00111N
   Richardson, Texas 75082 USA                       96.68142W
   jmpolk@cisco.com




Polk & Rosen                                                  [Page 41]


Internet Draft         SIP Location Conveyance          June 17th, 2005

   Brian Rosen                                       40.4N
   br@brianrosen.net                                 80.0W


Appendix A.  Additional stuff

   This section is coming in the next release.


Intellectual Property Statement

   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.


Disclaimer of Validity

   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 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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.




Polk & Rosen                                                  [Page 42]


Internet Draft         SIP Location Conveyance          June 17th, 2005

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




The Expiration date for this Internet Draft is:

December 17th, 2005











































Polk & Rosen                                                  [Page 43]