[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 draft-ietf-sipcore-location-conveyance

SIP Working Group                                         James M. Polk
Internet Draft                                            Cisco Systems
Expiration: Jan 17th, 2006                                  Brian Rosen
                                                                NeuStar



          Session Initiation Protocol Location Conveyance
               draft-ietf-sip-location-conveyance-01.txt
                         July 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 January 17th, 2006.

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, the user agent client (UAC).  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          July 17th, 2005

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . .  4
       1.2 Changes from Prior Versions . . . . . . . . . . . . . . .  4
   2.  Location In the Body or in a Header . . . . . . . . . . . . .  7
   3.  Scope of Location Conveyance  . . . . . . . . . . . . . . . .  8
       3.1 Scope of Location in a Message Body . . . . . . . . . . .  8
       3.2 Scope of Location in a Header . . . . . . . . . . . . . .  9
   4.  Requirements for UA-to-UA Location Conveyance . . . . . . . . 10
   5.  Requirements for UA-to-Proxy Server Location Conveyance . . . 11
   6.  Additional Requirements for Emergency Calls . . . . . . . . . 12
   7.  Location Conveyance Using SIP . . . . . . . . . . . . . . . . 14
       7.1 Indicating Support for Location by the UAC  . . . . . . . 16
       7.2 Location Rejection Responses  . . . . . . . . . . . . . . 19
       7.3 Example PIDF-LO in Geo Format . . . . . . . . . . . . . . 20
       7.4 Example PIDF-LO in Civic Format . . . . . . . . . . . . . 21
   8.  Location Conveyance UA-to-UA  . . . . . . . . . . . . . . . . 23
       8.1 UA-to-UA Using INVITE . . . . . . . . . . . . . . . . . . 23
         8.1.1 UA-to-UA Using INVITE w/ Geo Format w-w/o S/MIME  . . 25
         8.1.2 UA-to-UA Using INVITE w/ Civic Format w-w/o S/MIME  . 26
         8.1.3 UA-to-UA Using INVITE Involving 3 Users . . . . . . . 28
       8.2 OPTIONS Method and Location . . . . . . . . . . . . . . . 31
         8.2.1 OPTIONS Request to Learn UAC's Location . . . . . . . 31
         8.2.2 OPTIONS Request to Learn UAS's Location . . . . . . . 33
       8.3 UA-to-UA Using MESSAGE  . . . . . . . . . . . . . . . . . 34
       8.4 UA-to-UA Using UPDATE . . . . . . . . . . . . . . . . . . 36
         8.4.1 UPDATE Updates Location During Session
                                          Establishment  . . . . . . 37
         8.4.2 UPDATE Updates Location After Session
                                          Establishment  . . . . . . 39
         8.4.3 UPDATE Updates Location After a UA Moves
                                            in a Dialog  . . . . . . 40
       8.5 Location Conveyance Using PUBLISH . . . . . . . . . . . . 42
       8.6 UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY . 44
   9.  Special Considerations for Emergency Calls  . . . . . . . . . 47
       9.1 Emergency UAC Behavior Rules  . . . . . . . . . . . . . . 49
       9.2 Emergency UAS/Intermediary Behavior Rules . . . . . . . . 50
       9.3 Basic Emergency Message Flow Examples . . . . . . . . . . 52
   10. Meeting RFC 3693 Requirements . . . . . . . . . . . . . . . . 55
   11. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 55
   12. Security Considerations . . . . . . . . . . . . . . . . . . . 56
   13. IANA Considerations   . . . . . . . . . . . . . . . . . . . . 56
       13.1 IANA Registration for Response Code 424  . . . . . . . . 56
       13.2 IANA Registration for Response Code 425  . . . . . . . . 56
       13.3 IANA Registration for the SIP Location Header  . . . . . 56
   14. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 57
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . . 57
       15.1 Normative References   . . . . . . . . . . . . . . . . . 57
       15.2 Informative References . . . . . . . . . . . . . . . . . 58
       Author Information  . . . . . . . . . . . . . . . . . . . . . 58
       Intellectual Property and Copyright Statements  . . . . . . . 72


Polk & Rosen                                                   [Page 2]

Internet Draft         SIP Location Conveyance          July 17th, 2005

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).  There is a migration issue requiring the capability to convey
   location seemingly from the source to destination, but in times in
   which the source, or the originating user agent, has not be upgraded
   to support this extension to the SIP architecture.  There are
   limitations to this "fix", but it serves a purpose for a critical
   service discussed in sections 6 and 9 of this document.

   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


Polk & Rosen                                                   [Page 3]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   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).  Sections 11 and 12 list 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,
this section is to be removed prior to that event.]

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

   - cleaned up a lot of loose ends in the text

   - created a new Location header to convey many means (location is in
     the body - even if not viewable, which location format is present,
     which format is requested in a query, how to request more than one
     location format in a query, whether the UAC understands location
     at all, if the UA knows its location, how to push location from
     one UA to through a second to a third UA, etc).

   - added the ability to convey location by-reference, but only under
     certain conditions.

   - Added support for the OPTIONS Request to query a server for the
     UAC's location, through the use of the new Location header.

   - moved both new Response code sections forward in the document for
     their meaning to be clearer, earlier for necessary discussion.

   - Changed the message flows to only have the pertinent message
     headers shown for brevity.

   - Added text to the SUB/NOT section showing how and why the location
     of a UA can be refreshed or updated with an interval, or by a
     trigger.

   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:


Polk & Rosen                                                   [Page 4]

Internet Draft         SIP Location Conveyance          July 17th, 2005


   - 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
     placing an emergency call (to inform PSAP who supplied Location
     information)

   - updated list of open issues


Polk & Rosen                                                   [Page 5]

Internet Draft         SIP Location Conveyance          July 17th, 2005


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



Polk & Rosen                                                   [Page 6]

Internet Draft         SIP Location Conveyance          July 17th, 2005

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

   It is the use of S/MIME however, that limits message routing based
   on the location of the UAC.  Therefore, it seems appropriate to
   require that, where routing is dependent on location, protection of
   the location information object be accomplished by other mechanisms


Polk & Rosen                                                   [Page 7]

Internet Draft         SIP Location Conveyance          July 17th, 2005

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

   There is another limitation, one that is very real, as a unfortunate
   result of how certain messages are addressed that limits this
   restriction to "only in a message body shall location be".  Because
   SIP will be used for emergency calling, and because emergency
   calling has nothing like an area code - given SIP's purposeful
   separation from geophysical awareness - a means must be created for
   any SIP UA to call 911 or 112 (or the like).  Because this document
   is not being generated when all SIP devices are, it is an extension
   to all UAs existing today.  This means for some time, there will
   need to at least be a stop-gap mechanism for conveying location for
   the purposes of routing an emergency call which is highly dependent
   on where it is on the planet; something SIP generally cares nothing
   about.  With this in mind, a Location header will be created to
   accomplish a location by-reference insertion by a SIP intermediary
   along the path from UAC towards a Public Safety Answering Point
   (PSAP).  This will not be the sole purpose of this header, but this
   header can be used for this purpose, as [RFC3261] allows SIP
   intermediaries to insert headers in transit.

   This document does not address the behavior or configuration of SIP
   Proxy Servers in cases in order to accomplish location-sensitive
   routing.  That is out of scope, and left for further study.


3.  Scope of Location Conveyance

   As concluded from the previous section, location information is to
   be contained within a message body when the user agent has this
   information locally.  Location, if not known to the user agent, can
   be inserted by a SIP intermediary in transit, but there must be
   rules surround this capability.


3.1  Scope of Location in a Message Body

   If location is to be protected with S/MIME, even when another body
   (SDP for example) is also to be sent in the message, 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.  If the SIP intermediary has location knowledge of the UAC,


Polk & Rosen                                                   [Page 8]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   it can include that information in an error message for use in a
   subsequent request by that UAC, therefore, 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 or receiving 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,
      but in this case, the SIP element does have current and correct
      location information for the UAC to be one that included in a new
      message body to be used in a subsequent SIP Request by 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 location
   information into the SIP message in order for it to be processed
   correctly by it, and upstream SIP intermediaries.  This cannot occur
   with existing rules stating message bodies cannot be modified or
   added by intermediaries.  This new response code message containing
   new location information of the UAC appears the best course of
   action.

   Since there can be multiple location observations of the same UAC,
   each transmitted or otherwise inputted into the UAC, there MUST be a
   means for including more than one piece of location information in a
   SIP message.  As best as possible, each should be labeled to
   indicate they are separate observations for the receiving entity to
   determine which is most correct.


3.2 Scope of Location in a Header

   The first, best location for location relating to the endpoint is in
   the endpoint.  This allows the endpoint to send its location to
   wherever it wants, using whichever application it wants to use.
   Keeping the location of an endpoint in a server on a network may be
   detrimental to the operation at hand.  One example is for emergency
   calling.  If the UA does not have its location, and a server does,
   that means the server has to be 100% stateful of that UA's location
   100% of the time, wherever that UA goes.  [ID-EMER-ARCH] states
   clearly that time is of the essence in placing an emergency call.


Polk & Rosen                                                   [Page 9]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   The time it takes to do a non-stateful lookup of a UAC's mobile
   location will impact the time it takes SIP signaling to process that
   location to determine which PSAP the call should be routed to.

   Therefore, the use of location by-reference SHOULD be used as a last
   resort. This becomes obviously the only choice if the UA has no
   concept of location to include by-value in the first place.  For
   that reason, there needs to be an identifier in SIP messaging
   indicating a UA is aware of location conveyance.  This will greatly
   speed up the processing at a SIP intermediary and limit its choices
   when processing a SIP Request that may require location to be
   present in the SIP message (such as emergency calling).  Sections 6
   and 9 delve deep into this topic.

   This indication of location awareness MUST be outside a message
   body, therefore in a header - and as one does not exist today
   related to location, this document will create one.  Section 7
   details the many purposes of this header, including the ability to
   convey which location format a UAC is transmitting, or a UAS wants.


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 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 10]

Internet Draft         SIP Location Conveyance          July 17th, 2005

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

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

    U-U9 - Location information MAY be contained in a by-reference URI
           contained in a Location Header.  All privacy and security
           rules associated with a Location message body as defined in
           [ID-PIDF-LO], MUST be maintained.

    U-U10- User Agents MUST have a means for querying a remote server
           for the UAC's location; including offering a preferential
           location format to be returned.

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

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

    U-U13- There MUST be a unique UAC error response code informing the
           UAC of new Location Information known to a SIP Intermediary,
           and the UAC MUST be prepared to receive that information in
           the error response itself.

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

    U-U15- User Agents and Proxies SHOULD be able to process SIP
           messages which contains more than one piece of Location
           information.

    U-U16- User Agents MUST have the ability to query another user
           agent for location information refresh and movement of the
           UA.


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


Polk & Rosen                                                  [Page 11]

Internet Draft         SIP Location Conveyance          July 17th, 2005

            be useable (i.e. viewable) by intermediary proxy servers
            requiring location knowledge of the UAC to properly route
            the message.

    U-PS3- User Agents MUST have a means for indicating they understand
           what location conveyance is, but currently do not have their
           location information to convey.

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

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

    U-PS6 - A SIP message containing location information 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-PS8 below, or when
            the SIP message is addressed to that intermediary).

   With regards to requirement U-PS6, not all SIP Proxies are expected
   to route messages based on the contained location information from
   the 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-PS7 - There MUST be a unique UAC error response code informing
            the UAC it did not provide applicable location information.

    U-PS8 - 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


Polk & Rosen                                                  [Page 12]

Internet Draft         SIP Location Conveyance          July 17th, 2005

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


Polk & Rosen                                                  [Page 13]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   [RFC3515] to the correct one.  Of there might have been an overload
   condition in which more calls were directed to a PSAP than if could
   handle efficiently, so some of the calls were diverted to another
   PSAP.

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

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

    E-7 The UA must provide the actual location 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, even if the UA were to move, even
   if the caller does not indicate there was a move.  This lets the
   PSAP determine what it considers to be "movement", and leaves that
   decision out of the user's.

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


Polk & Rosen                                                  [Page 14]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   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,
      OPTIONS,
      UPDATE,
      MESSAGE,
      SUBSCRIBE/NOTIFY, and
      PUBLISH.

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

      INVITE,
      UPDATE, and
      MESSAGE

   While the authors do not yet see a reason to have location conveyed
   in the 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 in 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.


Polk & Rosen                                                  [Page 15]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   TLS security).  In particular, emergency call routing requires
   routing proxies to know the location of the UAC, 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 by who she transmits
   her location to.  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".


7.1  Indicating Support for Location by the UAC

   User agent clients who supports this specification will indicate
   that support in two ways, by including two headers in all messages
   conveying location of any kind specified here: a new "Location"
   header, and the Supported Header indicating "location" as the value
   of the header.  SIP Requests lacking this combination will indicate
   to SIP intermediaries that determine there is a problem with a SIP
   Request that should contain location information whether any of
   their responses will have a chance at successful understanding.  In
   other words, does the UAC have location clue, or not?  If not,
   because the SIP Request from that UAC didn't include these headers,
   the intermediary will not rely on the UAC to correct the problem,
   and will do what it can to fix the problem without the UAC.  More on
   this in section 8 of this document.

   Location inclusion within a SIP Request will be by-value or by-
   reference.  By-value is the case in which the location information
   of the UAC is included or contained within the SIP message itself.
   By-reference is the case in which the location of the UAC is in a
   database (record or document) somewhere else, but the UAC knows the
   URI to that record/document and includes only that URI in the SIP
   Request, in the location header.

   A UAC that conforms with this specification will include within this
   INVITE message an indication that it understands what "location"
   means, that it is necessary to convey location in this INVITE
   message, and understands any location based rejection responses from
   the SIP intermediary.  There are two new 4XX level Responses defined
   later in this document.  This indication is a new "Location" header
   with the following syntax:




Polk & Rosen                                                  [Page 16]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   Location           =  "Location" HCOLON Location-value *(COMMA
                         Location-value)
   location-value     =  (addr-spec / option-tag / token)
   addr-spec          =  cid-url / absoluteURI
   option-tag         =  string
   token              =  token / quoted-string
   cid-url            =
   absoluteURI        =


   IANA Registered Option-tags are: loc-body, civic-loc, geo-loc,
        convey-uac, convey-uas, unknown

   - "loc-body" identifies location is present in the message body of
     this message, but gives no indication which format it is in, or
     even if it is visible to the SIP element viewing the message.

   - "civic-loc" identifies the format of location included, or
     desired.

   - "geo-loc" identifies the format of location included, or desired.

   - "convey-uac" identifies in a message for the receiver of this
     message to forward the sender's location information to another
     UA.

   This convey-uac is telling the UAS of this transaction to convey the
   location of the UAC of this transaction to another UA.  This is most
   clearly applicable in a REFER transaction (see section 8.3).

   - "convey-uas" identifies to a UAS within a transaction to convey
     its location to the UAC of that transaction, or to a third party
     UA (see section 8.3 for this latter example involving REFER).

   This convey-uas indication is both a request for a UAS to respond to
   the UAC with the UAS's location (see section 8.1) and a request for
   a UA to send location information somewhere else (see section 8.3).

   Civic-loc and geo-loc are defined as being "desired" (not known yet)
   because each can be placed in a location header within an OPTIONS
   Request message to learn the UAC's location.  See section 8.2 for
   the details of this.

   - "unknown" indicates the UAC understands the concept of location,
     but does not have knowledge of where it is to include in the
     message.

   Unknown is a case in which the UAC is asking for help of any
   intermediary to populate a location header with a by-reference URI,
   or to return a 425 (Retry Location Body) response that includes a
   PIDF-LO message body that describes the location for that UAC to be
   used at a later time.  The intermediary that responds to this query


Polk & Rosen                                                  [Page 17]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   could become the UAS target for future OPTIONS requests.

   The following table extends the values in Table 2/3 of RFC3261
   [RFC3261].

      Header field             where proxy INV ACK CAN BYE REG OPT PRA
      ----------------------------------------------------------------
      Location                 Rr    amdr   o   -   -   o   o   o   -

      Header field             where proxy SUB NOT UPD MSG REF INF PUB
      ----------------------------------------------------------------
      Location                 Rr    amdr   o   o   o   o   o   o   o

   The Location header MAY be added, modified, read or deleted if
   present in a Request message listed above.  Deleting a location
   header appears detrimental for communicating a necessary piece of
   information described throughout this document, unless this is an
   act of hiding that information.  Modifying this header, other than
   correcting the header of some error, appears to cause more harm than
   good, and is ill advised. Unless from the SIP Proxy/intermediary
   generating an error response (see section 7.2), the location header
   SHOULD NOT be modified or deleted if present in a Response.  Only
   the intermediary that is originating the header value in the
   response SHOULD add a location header, if one is not yet present.
   A Proxy/intermediary MAY add the location header in transit if one
   is not present.  A Proxy/intermediary MAY read the location header
   in transit if present.

   Here is an example INVITE that includes the proper Location and
   Supported headers (with a reduced size multipart message body):

   INVITE sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP pc33.atlanta.example.com
     ;branch=z9hG4bK74bf9
   Max-Forwards: 70
   To: Bob <sip:bob@biloxi.example.com>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   Call-ID: 3848276298220188511@atlanta.example.com
   Location: cid: alice123@atlanta.example.com, geo-loc
   Supported: location
   Accept: application/sdp, application/cpim-pidf+xml
   CSeq: 31862 INVITE
   Contact: <sip:alice@atlanta.example.com>
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1

   Content-Type: application/sdp

   ...SDP here



Polk & Rosen                                                  [Page 18]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   --boundary1

   Content-Type: application/cpim-pidf+xml
   Content-ID: alice123@atlanta.example.com

   ...PIDF-LO with geolocation coordinates here

   --boundary1--


   The location header from the above INVITE:

      Location: cid:alice123@atlanta.example.com, geo-loc

   indicates the Content-ID location [RFC2392] within the multipart
   message body of were location information is.  The geo-loc option-
   tag indicates the location format within the PIDF-LO message body.
   If both geo-loc and civic-loc formats were present in the PIDF-LO,
   the UAC SHOULD include both option-tags if it includes either.  The
   UAC MAY NOT include either option-tag indicating the format of
   location within the message body.

   If the Location header were this instead:

      Location: <server5@atlanta.example.com/alice123>, geo-loc

   this would indicate location by-reference was included in this
   message, and in the geo-loc format for whoever fetches it.

   More than one location by-value message body-part MAY be included in
   the same SIP message.


7.2 Location Rejection Responses

   Two new 4XX Response messages are created here:

   - '424 Bad Location Information' - indicates the location in the SIP
     Request message was bad.

   - '425 Retry Location Body' - indicates to the UAC that location in
     the SIP Request message was bad and this response has a new PIDF-
     LO location-by-value to be stored in the UAC for future use.


7.2.1 The 424 "Bad Location Information" Error Code

   In the case that a UAS or SIP intermediary detects an error
   in a Request message specific to the location information supplied
   by-value or by-reference, a new 4XX level error is called for to
   indicate this is the problem with the message.  This document
   creates the new error code:


Polk & Rosen                                                  [Page 19]

Internet Draft         SIP Location Conveyance          July 17th, 2005


      424 (Bad Location Information)

   The 424 Bad Location Information Response code is a rejection of the
   location contents, whether by-value or by-reference of the original
   SIP Request.  The server function of the recipient (UAS or
   intermediary) had deemed this location by-reference or location by-
   value to be bad.  No further action by the UAC is expected.  The UAC
   can use whatever means it knows to verify/refresh its location
   information before attempting the Request again.

   This new error code will be IANA registered.


7.2.2 The 425 "Retry Location Body" Error Code

   In the case that a UAS or SIP intermediary detects an error
   in a Request message specific to the location information supplied
   by-value or by-reference within that message, and both has the
   location by-value of that UAC stored locally and wants to transmit
   this value to the UAC, a new 4XX level error need is called for to
   indicate this.  This document creates the new error code:

      425 (Retry Location Body)

   The 425 Retry Location Body Response code is a rejection of the by-
   value or by-reference location contained in the original SIP
   Request.  The 425 Response will contain a application/cpim-pidf+xml
   encoded message body to be stored in the UAC for future use.  This
   will typically be incorporated into the subsequent SIP Request from
   the UAC that received the 425 Response to the previous message
   attempt.

   The UAC SHOULD include this PIDF-LO message body in the subsequent
   Request message towards that same intermediary - as it felt strong
   enough to reject the last message that had bad location information
   to send the UAC new location information.

   This new error code will be IANA registered.

   An example flow of this scenario will be included in section 9 of
   this document.


7.3 Example PIDF-LO in Geo Format

   This subsection will show a sample of what just the PIDF-LO can look
   like, as defined in [ID-PIDF-LO].  Having this here will first offer
   a look at a location by-value message body, and secondly, give the
   authors the ability to show how large this is to persuade readers
   that this doesn't have to be shown in every example of this
   document.  Full example message flows will be in the appendixes of


Polk & Rosen                                                  [Page 20]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   this document.

   Whether this PIDF-LO message body is S/MIME encrypted in the SIP
   message or not, the PIDF-LO stays exactly the same.  There is no
   change to its format, text or characteristics.  Whether TLS or IPsec
   is used to encrypt this overall SIP message or not, the PIDF-LO
   stays exactly the same.  There is no change to its format, text or
   characteristics.  The examples in section 7.3 (Geo format) taken
   from [RFC3825] and 7.4 (Civic format) taken from [ID-CIVIC] are for
   the exact same position on the earth.  The civic formatted PIDF-LO
   is a little larger (i.e. more lines), but this is not substantial.
   The differences between the two formats is within the <gp:location-
   info> are of the examples.  Other than this portion of each PIDF-LO,
   the rest the same for both location formats.

   <?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-08-01T10:00:00Z</timestamp>
         <status>
          <gp:geopriv>
            <gp:location-info>
              <gml:location>
                <gml:Point gml:id="point96" srsName="epsg:4326">
                  <gml:coordinates>33.001111N
                                   96.68142W</gml:coordinates>
                </gml:Point>
               </gml:location>
            </gp:location-info>
            <method>dhcp</method>
            <provided-by><nena>www.cisco.com</nena></provided-by/>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>
              <gp:retention-expiry>2005-08-05T01:00:00Z</gp:retention-
                            expiry>
             </gp:usage-rules>
          </gp:geopriv>
         </status>
        </tuple>
       </presence>


7.4 Example PIDF-LO in Civic Format

   This subsection will show a sample of what just the PIDF-LO can look
   like, as defined in [ID-PIDF-LO].  Having this here will first offer
   a look at a location by-value message body, and secondly, give the
   authors the ability to show how large this is to persuade readers


Polk & Rosen                                                  [Page 21]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   that this doesn't have to be shown in every example of this
   document.  Full example message flows will be in the appendixes of
   this document.

   Whether this PIDF-LO message body is S/MIME encrypted in the SIP
   message or not, the PIDF-LO stays exactly the same.  There is no
   change to its format, text or characteristics.  Whether TLS or IPsec
   is used to encrypt this overall SIP message or not, the PIDF-LO
   stays exactly the same.  There is no change to its format, text or
   characteristics.  The examples in section 7.3 (Geo format) taken
   from [RFC3825] and 7.4 (Civic format) taken from [ID-CIVIC] are for
   the exact same position on the earth.  The civic formatted PIDF-LO
   is a little larger (i.e. more lines), but this is not substantial.
   The differences between the two formats is within the <gp:location-
   info> are of the examples.  Other than this portion of each PIDF-LO,
   the rest the same for both location formats.

   <?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-08-01T10:00:00Z</timestamp>
         <status>
          <gp:geopriv>
            <gp:location-info>
              <cl:civilAddress>
                <cl:country>US</cl:country>
                <cl:A1>Texas</cl:A1>
                <cl:A3>Colleyville</cl:A3>
                <cl:HNO>3913</cl:HNO>
                <cl:A6>Treemont</cl:A6>
                <cl:STS>Circle</cl:STS>
                <cl:PC>76034</cl:PC>
                <cl:LMK>Polk Place</cl:LMK>
                <cl:FLR>1</cl:FLR>
              <cl:civilAddress>
            </gp:location-info>
            <method>dhcp</method>
            <provided-by><nena>www.cisco.com</nena></provided-by/>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>
              <gp:retention-expiry>2005-08-05T01:00:00Z</gp:retention-
                            expiry>
            </gp:usage-rules>
          </gp:geopriv>
         </status>
        </tuple>
       </presence>



Polk & Rosen                                                  [Page 22]

Internet Draft         SIP Location Conveyance          July 17th, 2005


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, OPTIONS, UPDATE, MESSAGE,
   SUB/NOT and PUBLISH Methods in the following subsections.

   All complete message flows in this document will be with well-formed
   SIP messages.  That said, there will be a few individual example
   messages containing only the key headers to convey the point being
   made that do not include all the requisite SIP headers.  As you will
   see in the following section (8.1), a well-formed SIP message
   containing a PIDF-LO is quite large (at least 59 lines of text), and
   will likely be overload to most readers if written for every example
   here (given how many examples there are).  All well formed SIP
   message flows are in separate appendixes at the end of this document
   for brevity here.

8.1 UA-to-UA using INVITE Method

   Below is a common SIP session set-up sequence between two user
   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].

   INVITE sips:bob@biloxi.example.com SIP/2.0
   To: Bob <sips:bob@biloxi.example.com>
   From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
   Supported: Location
   Location: loc-body, geo-loc
   Content-Type: application/pkcs7-mime;
      smime-type=enveloped-data; name=smime.p7m

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


Polk & Rosen                                                  [Page 23]

Internet Draft         SIP Location Conveyance          July 17th, 2005

     Alice's location (here coordinate based) is the other body part
     contained in this INVITE.

     Within the message body is this:

   Content-Type: multipart/mixed; boundary=boundary1

   --boundary1

   Content-Type: application/sdp
   v=0
   ...

   --boundary1

   Content-type: application/cpim-pidf+xml
   PIDF-LO

   --boundary1--

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

   Bob also has Alice's location once he decrypts the S/MIME (in
   conjunction with decrypting if for the SDP message body).

   In this message, Alice decided to include the Supported and
   Location headers in the SIP headers even though SIP intermediaries
   would not be able to view the information.  This SHOULD be
   configurable, based on local policy for revealing such information
   hints.

   If Alice wanted to know Bob's location, she could have included in
   the existing Location header an option-tag of "convey-uas".  This is
   the indication to the UAS within this transaction, in this case Bob,
   to return his location in the 200 OK if he chooses too.  This
   request MAY prompt Bob, the user, of the request, and wait for him
   to indicate to his UA whether he would want his location included in
   the 200 OK.

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



Polk & Rosen                                                  [Page 24]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   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.


8.1.1 UA-to-UA INVITE Request with Geo 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
   [Alice's Geo PIDF-LO goes here]

   --boundary1--


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



Polk & Rosen                                                  [Page 25]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   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
   [Alice's Geo PIDF-LO goes here]

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


Polk & Rosen                                                  [Page 26]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   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
   [Alice's Civic PIDF-LO goes here]

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



Polk & Rosen                                                  [Page 27]

Internet Draft         SIP Location Conveyance          July 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

   --broundary1

   Content-type: application/cpim-pidf+xml
   [Alice's Civic PIDF-LO goes here]

--boundary1--


8.1.3 UA-to-UA Location Conveyance Involving 3 Users

   As stated in [RFC3693], the distribution indication within the PIDF-
   LO provides the information regarding if a learned PIDF-LO of
   another UA can be given out or not.  The distribution element within
   the PIDF-LO looks like this:

      <gp:retransmission-allowed>no</gp:retransmission-allowed>

   The values within this element are either "yes" or "no".

   The element within the PIDF-LO indicating how long this location
   information is to be considered good/reliable for is the location
   expiration element, which looks like this:

    <gp:retention-expiry>2005-08-05T01:00:00Z</gp:retention-expiry>

   So, if Bob's location, which was transmitted to Alice, has not
   reached the expiration time, and Bob set his distribution indication
   to "can redistribute", then when Bob refers Alice to call Carol,
   Alice can include both hers and Bob's LOs in that new INVITE (from
   Alice to Carol).  This will tell Carol where both Alice and Bob are.
   Bob should be conscious of this capability when setting his
   distribution indication with any location conveyance transmission.

   Consider the following example message flow [Figure 1a] to show a
   3-way communication of location, coupled with how a UA can include
   someone else's location.








Polk & Rosen                                                  [Page 28]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   UA Alice                        Bob          Carol

      |           INVITE [M1]       |             |
      |---------------------------->|             |
      |           200 OK [M2]       |             |
      |<----------------------------|             |
      |            ACK [M3]         |             |
      |---------------------------->|             |
      |              RTP            |             |
      |<===========================>|             |
      |     reINVITE (hold) [M4]    |             |
      |<----------------------------|             |
      |          200 OK [M5]        |             |
      |---------------------------->|             |
      | REFER (Refer-to:Carol) [M6] |             |
      |<----------------------------|             |
      |          NOTIFY [M7]        |             |
      |---------------------------->|             |
      |          200 OK [M8]        |             |
      |<----------------------------|             |
      |                 INVITE [M9]               |
      |------------------------------------------>|
      |                 200 OK [M10]              |
      |------------------------------------------>|
      |                     RTP                   |
      |<=========================================>|
      |          NOTIFY [M11]       |             |
      |---------------------------->|             |
      |          200 OK [M12]       |             |
      |<----------------------------|             |
      |           BYE [M13]         |             |
      |<----------------------------|             |
      |          200 OK [M14]       |             |
      |---------------------------->|             |
      |                                           |

      Figure 1a. UA-to-UA with Location in REFER


   M1 - Alice presents her location in the INVITE to Bob;

   INVITE sips:bob@biloxi.example.com SIP/2.0
   To: Bob
   From: Alice
   Supported: location
   Location: geo-loc
   Content-Type: multipart/mixed; boundary=boundary1

   --boundary1

   Content-Type: application/sdp
   v=0


Polk & Rosen                                                  [Page 29]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   ...

   --boundary1

   Content-type: application/cpim-pidf+xml
   [Alice's geo formatted PIDF-LO goes here]

   --boundary1--


   M2 - Bob 200 OKs this INVITE and includes his location back to Alice
        (with his distribution indication set to "yes").

   If Alice included a location header with a "convey-uas" option-tag:

   INVITE sips:bob@biloxi.example.com SIP/2.0
   Location: convey-uas

   Bob SHOULD feel compelled to reply with his location to Alice.  If
   Bob doesn't understand this request, Bob returns an Unsupported
   header with "location" if his UA doesn't understand location, or
   just "convey-uas" if his UA does understand location but doesn't
   know his location, or cannot process the request in time for the 200
   OK return.

   M6 - Bob then directs Alice to contact Carol using a REFER Request
        (RFC3515].

   The REFER is used in this message sequence, but it does not carry
   anyone's location within the REFER message.  UAs SHOULD be prepared
   to receive a PIDF-LO message body in a REFER Method Request,
   although this doesn't seem likely.  Nothing here prevents that from
   occurring.  If Bob didn't return his location in the 200 OK, but
   still wants to convey his location to Alice to send to Carol, he can
   include the PIDF-LO in the REFER.  Bob can include the following
   header in the REFER to tell Alice to tell Carol both of their
   locations:

   REFER sips:alice@atlanta.example.com SIP/2.0
   Location: convey-uac, convey-uas

   The [M11] NOTIFY message from Alice to Bob MAY confirm to Bob that
   Alice did indeed convey both UA's locations.

   If Alice accepted the transaction request of the REFER in a 202
   Accepted message, but didn't include her location in the subsequent
   INVITE to Carol, her 202 Accepted message would have this header in
   it:

   [M7]
   SIP/2.0 202 Accepted
   To: Alice


Polk & Rosen                                                  [Page 30]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   From: Bob
   Unsupported: convey-uac

   This indicates to Bob his request was partially fulfilled.  Bob
   knows his location was conveyed to Carol and that his REFER Request
   was accepted, but Alice chose not to send Carol her location
   information.

   Regardless of Bob's request in the REFER, if he set his retention
   indication to "no", Alice MUST NOT forward Bob's location to Carol,
   even if he asked her to.  This document currently doesn't have a
   granular enough indication from Alice to Bob to tell Bob this piece
   of information.


8.2 OPTIONS Method and Location

   The OPTIONS Method can be used by a UAC to learn its location from a
   SIP intermediary that may know this information, or to request the
   location of a UAS.  A combination of the location header option-tags
   in an OPTIONS query can achieve this.


8.2.1 OPTIONS Request to Learn UAC's Location

   If Alice knows which server knows her location, perhaps because her
   UA was either configured with this server manually or through
   registration to the network, she can send an OPTIONS query to it to
   learn her location.  Take the following message flow as an example:

   UA Alice                                  Server1

      |               OPTIONS [M1]              |
      |---------------------------------------->|
      |               200 OK [M2]               |
      |<----------------------------------------|

         Figure 2a. OPTIONS Request for Location

   A non-well-formed message example of how an OPTIONS Method Request
   could be used to query a server for the UAC's location might be:

   [M1 of Figure 2a]
   OPTIONS sips:server1@atlanta.example.com SIP/2.0
   To: server1
   From: Alice
   Proxy-Require: location
   Require: location
   Location: unknown, geo-loc

   Including both the "unknown" and "geo-loc" option-tags in the
   Location header indicates the UAC wants to learn its location in the


Polk & Rosen                                                  [Page 31]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   geo format only.  If the Location header were:

   OPTIONS sips:server1@atlanta.example.com SIP/2.0
   To: server1
   From: Alice
   Proxy-Require: location
   Require: location
   Location: unknown, geo-loc, civic

   the UAC is asking for both formats to be in the reply.

   The key to this request is the "unknown" option-tag.  This, in an
   OPTIONS Request, if telling the server the UAC doesn't know its
   location, and to include the UAC's location in the 200 OK Response.
   The presence or lack of presence of other option-tags indicate to
   the server how its response will be formed. If no other option-tags
   are present in the Location header of this OPTIONS Request, the
   server is free to choose whatever format it wishes in the reply.

   In the above partial OPTIONS Request, there is a Proxy-Require
   header (if the intermediary is a Proxy) and a Require header (if the
   intermediary is an instance of a B2BUA).  If either apply to the
   responding UAS in this transaction, and the location header included
   an option-tag the UAS cannot answer, perhaps because it doesn't have
   the UAC's civic location format, the 200 OK to this Request will
   include what location format(s) is has, and indicates it does not
   have the remainder of the request with the Unsupported header
   indicating which formats were requested, but not available.  An
   example of this is the following partial SIP message;

   [M2 in Figure 2a]
   SIP/2.0 200 OK
   To: server1
   From: Alice
   Unsupported: civic-loc
   Content-type: application/cpim-pidf+xml

   [Alice's geo formatted PIDF-LO goes here]

   If location is to be returned as a by-reference location header
   value, a subset of the 200 OK could look like this:

   [M2 of Figure 2a]
   SIP/2.0 200 OK
   To: server1
   From: Alice
   Location: <www.atlanta.example.com/server1/alice123>

   The above 200 OK example MAY include an additional option-tag
   indicating the format or the location at that by-reference URI.

   An OPTIONS Request for the location of the UAC MAY be 401


Polk & Rosen                                                  [Page 32]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   (Unauthorized) or 407 (Proxy Authentication Required) challenged.

   An OPTIONS Request can be redirected to a server that knows the
   UAC's location.

   A 424 (Bad Location) is the proper indication if the queried server
   has no knowledge of the UAC's location.  An Unsupported header MUST
   be in this 424 Response indicating "location" was not supported.

   [alternate M2 in Figure 2b]
   SIP/2.0 424 (Bad Location Information)
   To: server1
   From: Alice
   Unsupported: location


8.2.2 OPTIONS Request to Learn UAS's Location

   Below is Figure 2b, which shows the OPTIONS Request being used to
   query another UA for its location.  In this case, it is the UA for
   Bob.

   UA Alice                                    Bob

      |               OPTIONS [M1]              |
      |---------------------------------------->|
      |               200 OK [M2]               |
      |<----------------------------------------|

         Figure 2b. OPTIONS Request for Location

   Here is a non-well-formed example of the OPTIONS Request from Alice
   to Bob:

   [M1 of Figure 2b]
   OPTIONS sips:bob@biloxi.example.com SIP/2.0
   To: Bob
   From: Alice
   Require: location
   Location: geo-loc

   In M1 of Figure 2b, Alice queries Bob for his location, and
   specifically in his geo format.  She has included a Require header
   to compel Bob to answer, unless he wishes to reject that inquiry
   even if he knows his location.  From M1, Bob can do one of the
   following:

   1) 200 (OK) this with his geo PIDF-LO

   2) 488 (Not Acceptable Here), with no further information

   3) 488 (Not Acceptable Here), with a Unsupported Header indicating


Polk & Rosen                                                  [Page 33]

Internet Draft         SIP Location Conveyance          July 17th, 2005

      Bob does not know or understand his geo format, with no further
      Information

   4) 488 (Not Acceptable Here), with a Unsupported Header indicating
      Bob does not know or understand his geo format, but include a
      location header indicating he does support the civic-loc format

   If Alice did not include a Require header (location), and if Bob
   sends option#4 above, Alice can retransmit the OPTIONS Request
   indicating the civic format is fine to respond with.  Bob SHOULD NOT
   send a format not requested unless Alice included a Require header
   (with Location) and Bob could not provide location in that format,
   but could in another format.

   Bob's option#1 200 OK would look like this (non-well-formed)
   message:

   [M2 in Figure 2b]
   SIP/2.0 200 OK
   To: Bob
   From: Alice
   Content-type: application/cpim-pidf+xml

   [Bob's geo formatted PIDF-LO goes here]

   Bob's option#4 488 (Not Acceptable Here) would look like this (non-
   well-formed) message if Bob had his civic location and did not have
   his geo location:

   [alternate M2 in Figure 2b]
   SIP/2.0 488 Not Acceptable Here
   To: Bob
   From: Alice
   Unsupported: geo-loc
   Content-type: application/cpim-pidf+xml

   [Bob's civic formatted PIDF-LO goes here]

   The 424 (Bad Location Information) and 425 (Retry Location Body)
   MUST NOT be used in response to an OPTIONS Request.  This is because
   both of these response codes are for the react to inclusion of
   location information in the Request.  With OPTIONS, Alice MUST NOT
   include her location.  Another SIP Method is used for that purpose
   (MESSAGE, PUBLISH).


8.3 UA-to-UA Using MESSAGE Method

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



Polk & Rosen                                                  [Page 34]

Internet Draft         SIP Location Conveyance          July 17th, 2005

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

   To comply with privacy concerns raised in [RFC3693] and [ID-PIDF-
   LO], a MESSAGE Method Request including a location message body
   SHOULD S/MIME encrypt the message body (part) under the rules
   outlined in [RFC3261].  This is not generally possible if the
   location is conveyed by-reference in a Location header.
   Implementers and end-users should be aware of this shortcoming of
   this means for location conveyance.


   UA Alice                                  UA Bob

      |               MESSAGE [M1]              |
      |---------------------------------------->|
      |                200 OK [M2]              |
      |<----------------------------------------|
      |                                         |

      Figure 3. UA-UA with Location in MESSAGE

   Below is a sample, non-well-formed MESSAGE Method message from Alice
   to Bob conveying her geo location:

   [M1 of Figure 3]
   OPTIONS sips:bob@biloxi.example.com SIP/2.0
   To: Bob
   From: Alice
   Supported: location
   Location: geo-loc
   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


Polk & Rosen                                                  [Page 35]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   [Alice's geo format PIDF-LO goes here]

   --broundary1--

   The Content-type of M1 here is "multipart/mixed" to have a text
   message incorporated into the message.  Within the PIDF-LO message
   body, there is a Content-Disposition of "render" to display this
   location information to Bob when his UA receives it.  The cautions
   about whether or not Bob actually reads this message are outlined in
   [RFC3428].

   The 200 OK to M1 of Figure 3 is a simple OK.

   A 424 (Bad Location Information) Response with a Unsupported header
   (stating Location) is the proper response if Bob's UA cannot display
   this information, but does understand the concept of location.

   [Alternative M2 of figure 3]
   SIP/2.0 424 Bad Location Information
   To: Bob
   From: Alice
   Unsupported: location

   If Bob's UA merely does not support that location format, the
   Location header would be:

   [Alternative M2 of figure 3]
   SIP/2.0 424 Bad Location Information
   To: Bob
   From: Alice
   Unsupported: geo-loc

   This alternative indicates to Alice to send another location format
   (civic) if she knows her location in that other format.  A
   subsequent MESSAGE Request could supply this information to Bob.

   If Bob is declining the original M1 MESSAGE Request, a 488 (Not
   Acceptable Here) is the appropriate response.  This 488 MAY include
   a location header indicating he does support the civic-loc format.

   [Alternative M2 of figure 3]
   SIP/2.0 488 Not Acceptable Here
   To: Bob
   From: Alice
   Location: civic-loc


8.4 UA-to-UA Location Conveyance Using UPDATE

   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


Polk & Rosen                                                  [Page 36]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   operational.  reINVITE is out of scope here, and the MESSAGE Method
   is for non-dialog location conveyance between UAs only.  The same
   security properties used in the INVITE MUST be used in the UPDATE
   message.

   There are 3 conditions UPDATE is to be used to convey location
   between Uas:

   1) During dialog establishment, but before the final 200 OK (see
      section 8.4.1)

   2) After dialog establishment, but no prior location information has
      been convey (see section 8.4.2), and

   3) After dialog establishment, when a UA has determined it has moved
      (see section 8.4.3)


8.4.1 UPDATE Updates Location During Session Establishment

   Use#1 of the UPDATE Method is during dialog establishment, Alice
   updates Bob with her location information.  This might be different
   location information than was in message [M1] of Figure 4a., or it
   could be the first time Alice conveys location to Bob.

   UA Alice                                  UA Bob

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

      Figure 4a. UA-UA with Location in UPDATE

   [M2 of Figure 4a]
   UPDATE sips:bob@biloxi.example.com SIP/2.0
   To: Bob
   From: Alice
   Supported: location
   Location: geo-loc
   Content-Type: multipart/mixed; boundary=boundary1

   --boundary1


Polk & Rosen                                                  [Page 37]

Internet Draft         SIP Location Conveyance          July 17th, 2005


   Content-Type: application/sdp
   v=
   ...

   --broundary1

   Content-Type: application/cpim-pidf+xml
   [Alice's geo format PIDF-LO goes here]

   --broundary1--

   The above example has Alice also changing something within her
   original SDP, but this is not necessary for this update of location
   information.

   A 424 (Bad Location Information) Response with a Unsupported header
   (stating Location) is the proper response if Bob's UA cannot support
   this information, but does understand the concept of location.

   [Alternative M3 of figure 4a]
   SIP/2.0 424 Bad Location Information
   To: Bob
   From: Alice
   Unsupported: location

   If Bob's UA merely does not support that location format, the
   Location header would be:

   [Alternative M3 of figure 4a]
   SIP/2.0 424 Bad Location Information
   To: Bob
   From: Alice
   Unsupported: geo-loc

   This alternative indicates to Alice to send another location format
   (civic) if she knows her location in that other format.  A
   subsequent UPDATE Request could supply this information to Bob.

   If Bob is declining the M2 UPDATE Request message, a 488 (Not
   Acceptable Here) is the appropriate response.  This 488 MAY include
   a location header indicating he does support the civic-loc format.

   [Alternative M3 of figure 4a]
   SIP/2.0 488 Not Acceptable Here
   To: Bob
   From: Alice
   Location: civic-loc






Polk & Rosen                                                  [Page 38]

Internet Draft         SIP Location Conveyance          July 17th, 2005

8.4.2 UPDATE Updates Location After Session Establishment

   Use #2 of the UPDATE Method is if a dialog *has been* set up between
   more than one UA, say between Alice and Bob without location
   conveyed in either direction, and location is now going to be sent
   from one of those UAs to the other.  For example, if Alice invites
   Bob to a dialog, but does not include her location in that dialog
   establishment.  Anytime during that dialog, Alice uses the UPDATE
   Method, not the INVITE Method (in a reINVITE), to update the
   location parameters of that dialog by sending an UPDATE message,
   even if it is from no location parameters to start with.

   Once a dialog has been established, a UAC MUST NOT use the INVITE
   Method to convey location.  The UPDATE Method MUST be used.

   Consider the following example message flow in Figure 4b.:

   UA Alice                                  UA Bob

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

      Figure 4b. UA-UA with Location in UPDATE


   [M4 of Figure 4b]
   UPDATE sips:bob@biloxi.example.com SIP/2.0
   To: Bob
   From: Alice
   Supported: location
   Location: geo-loc
   Content-Type: application/cpim-pidf+xml

   [Alice's geo format PIDF-LO goes here]

   A 424 (Bad Location Information) Response with a Unsupported header
   (stating Location) is the proper response if Bob's UA cannot support
   this information, but does understand the concept of location.

   [Alternative M5 of figure 4b]
   SIP/2.0 424 Bad Location Information


Polk & Rosen                                                  [Page 39]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   To: Bob
   From: Alice
   Unsupported: location

   If Bob's UA merely does not support that location format, the
   Location header would be:

   [Alternative M5 of figure 4b]
   SIP/2.0 424 Bad Location Information
   To: Bob
   From: Alice
   Unsupported: geo-loc

   This alternative indicates to Alice to send another location format
   (civic) if she knows her location in that other format.  A
   subsequent UPDATE Request could supply this information to Bob.

   If Bob is declining the M4 UPDATE Request message, a 488 (Not
   Acceptable Here) is the appropriate response.  This 488 MAY include
   a location header indicating he does support the civic-loc format.

   [Alternative M5 of figure 4b]
   SIP/2.0 488 Not Acceptable Here
   To: Bob
   From: Alice
   Location: civic-loc

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


8.4.3 UPDATE Updates Location After a UA Moves in a Dialog

   Use#3 of the UPDATE Method is if one UA that already conveyed
   location to the other UA, has moved since the dialog was originally
   sent up.  How a UA determines it has moved is out of scope for this
   document.

   However that "movement" trigger occurred, M4 of Figure 4c. is the
   result: an UPDATE Method Request indicating new location by Alice.

   UA Alice                                  UA Bob

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



Polk & Rosen                                                  [Page 4]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   **Alice's UA determines it has moved, and needs to update Bob**

      |                UPDATE [M4]              |
      |---------------------------------------->|
      |            200 OK (UPDATE) [M5]         |
      |<----------------------------------------|
      |                                         |

      Figure 4c. UA-UA with Location in UPDATE

   Message M4 of Figure 4c. shows the UPDATE of Alice's location
   information to Bob.  That message may look like this (non-well-
   formed SIP message):

   [M4 of Figure 4c]
   UPDATE sips:bob@biloxi.example.com SIP/2.0
   To: Bob
   From: Alice
   Supported: location
   Location: geo-loc
   Content-Type: application/cpim-pidf+xml

   [Alice's geo format PIDF-LO goes here]

   There currently is not an indication Alice can make conveying this
   PIDF-LO is new, replacement location information from a previous
   message (here in the M1 INVITE message).

   A 424 (Bad Location Information) Response with a Unsupported header
   (stating Location) is the proper response if Bob's UA cannot support
   this information, but does understand the concept of location.

   [Alternative M5 of figure 4c]
   SIP/2.0 424 Bad Location Information
   To: Bob
   From: Alice
   Unsupported: location

   If Bob's UA merely does not support that location format, the
   Location header would be:

   [Alternative M5 of figure 4c]
   SIP/2.0 424 Bad Location Information
   To: Bob
   From: Alice
   Unsupported: geo-loc

   This alternative indicates to Alice to send another location format
   (civic) if she knows her location in that other format.  A
   subsequent UPDATE Request could supply this information to Bob.

   If Bob is declining the M4 UPDATE Request message, a 488 (Not


Polk & Rosen                                                  [Page 41]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   Acceptable Here) is the appropriate response.  This 488 MAY include
   a location header indicating he does support the civic-loc format.

   [Alternative M5 of figure 4c]
   SIP/2.0 488 Not Acceptable Here
   To: Bob
   From: Alice
   Location: civic-loc

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


8.5 UA-to-UA Location Conveyance Using PUBLISH

   The PUBLISH Method Request [RFC3903] is for conveying state
   information of a user agent to a compositor server for others to
   query for that information.  This creates the benefit of the user
   agent not always being requested from all angles of the Internet.
   That task or chore can be left for a SIP entity build for that task,
   as well as one that is built for the efficient task of doing proper
   challenges for each user's state information.  One piece of state
   information interesting to those involved in Presence is geophysical
   location.  The PUBLISH Method Request message is used by a user
   agent to transmit location information to this compositor server for
   queries by others.

   Consider the following basic message flow in Figure 5:


                                           Compositor
   UA Alice                                  Server2

      |               PUBLISH [M1]              |
      |---------------------------------------->|
      |               200 OK [M2]               |
      |<----------------------------------------|

         Figure 5. OPTIONS Request for Location

   A non-well-formed message example of how an PUBLISH Method Request
   could be used to push location information to a server representing
   the UAC might be:

   [M1 of Figure 5]
   PUBLISH sips:server2@atlanta.example.com SIP/2.0
   To: server2
   From: Alice
   Accept: application/cpim-pidf+xml
   Location: geo-loc
   Expires: 21600
   Content-type: application/cpim-pidf+xml


Polk & Rosen                                                  [Page 42]

Internet Draft         SIP Location Conveyance          July 17th, 2005


   [Alice's geo formatted PIDF-LO goes here]

   The record location on this compositor server MAY become the
   location by-reference URI for future location conveyance by this
   UAC.  This would have to be returned to the UAC in Location header
   of the 200 OK Response if the UAC is expected to use this.

   Otherwise, the response to the PUBLISH Request would be something
   like this non-well-formed 200 OK message:

   [M2 in Figure 5]
   SIP/2.0 200 OK
   To: server2
   From: Alice
   Location: geo-loc
   SIP-ETag: alice987
   Expires: 21600

   The Location header copying the option-tag from the Request SHOULD
   be considered the indication the compositor server understood the
   format and the elements within the PIDF-LO message body of the
   PUBLISH message.

   PUBLISH performs 4 functions: initial, modify, refresh, or
   terminate.  Based on this, it can be easily concluded that a PUBLISH
   Request conveying the location of a UAC MAY be 401 (Unauthorized) or
   407 (Proxy Authentication Required) challenged.  UAs MUST be
   prepared to be challenged when they communicate location to a
   compositor server.

   A 424 (Bad Location) is the proper indication if the compositor
   server has no knowledge of location capabilities.  An Unsupported
   header MUST be in this 424 Response indicating "location" was not
   supported.

   [alternate M2 in Figure 5]
   SIP/2.0 424 (Bad Location Information)
   To: server2
   From: Alice
   Unsupported: location

   If a compositor server understands location, but does not prefer (or
   like) the location format the UAC chose to convey location in, a 488
   (Not Acceptable Here) would be the appropriate response.  Within
   this message, the 488 MUST indicate which format was not preferred
   using the Unsupported header and a location option-tag indicating
   the existing format.  The 488 MUST also have a Location header with
   the preferred option-tag format to plainly inform the UAC which
   location format to send in a subsequent Request.

   This 488 could look like this (non-well-formed) message if the


Polk & Rosen                                                  [Page 43]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   server received Alice's civic location and prefers her location in
   the geo format

   [alternate M2 in Figure 5]
   SIP/2.0 488 Not Acceptable Here
   To: server2
   From: Alice
   Unsupported: civic
   Location: geo-loc
   Accept: application/cpim-pidf+xml

   ** The corresponding appendix has not be completed at this time.**


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

   The SUBSCRIBE Method Request [RFC3265] can be used to request the
   location, by-reference or by-value of another SIP entity.  What is
   different in this method of conveying location is the answer is in
   the NOTIFY Method Request [RFC3265] from the original UAS, the
   subscribed-to entity.  This has at least two advantages:

   1) This transaction can be used in conjunction with a Geopriv-based
      Target and SIMPLE-based Presentity's use of the PUBLISH Method to
      a Location server or Compositor.  This allows a location target
      to publish their location to a server and have that server be the
      focus of AAA processes for that target's location, and not burden
      the target's device - other than if that target wants to real-
      time authorize a location request from one or more requestors.

   2) A UAC can subscribe to a UAS (or its server/compositor) for an
      ongoing location conveyance; meaning, this can be how a location
      requestor (or seeker) establishes a connection to a knowledgeable
      source of the UAC's/Presentity's location for more than a one
      time request.  Consider this to be a tracking capability.

   This tracking capability MUST be authorized by the rulemaker of the
   UAC/Target/Presentity, but there are some uses in which this is
   valuable; consider the 911/112 caller.

   When a UAC calls a 911/112-type of local emergency service for help,
   regardless of how this occurs within SIP, one of the key functions
   of this call is to convey the location of the caller for a PSAP
   operator to dispatch first responders.  It is very important that
   the PSAP operator knows where the caller is to do this.  If the
   person who called for help is mobile or roaming, depending on how
   each is defined, the fact that the caller is not tied to a cable
   means they can move to a new location even during the emergency
   call.  The UPDATE Method is used to update a UAS if the UAC moves,
   but this is not necessary reliable, and currently cannot be required
   within existing SIP capabilities.  This is where the SUB/NOT Request
   Methods come in.


Polk & Rosen                                                  [Page 44]

Internet Draft         SIP Location Conveyance          July 17th, 2005


   Once a caller (UAC) calls a PSAP (UAS) for help (regardless of the
   routing issues discussed in section 9 of this document), the PSAP
   operator may want to SUBSCRIBE to the caller's UAC to learn where it
   is.  This can be considered a location refresh.  The US Cellular
   industry calls this "reachback", and it is part of Wireless Phase II
   systems today.  This subscription can perform a nearly identical
   function, plus a little more.  This subscription can request of the
   UAC to let the UAS know if there are any location changes to the
   UAC.  The subscription SHOULD define, or include, what it considers
   locally to be "movement".  In this way, what one jurisdiction
   considers to a large enough change to be "movement" by the UAC does
   not mandate this for all jurisdictions.  Just as SIP message carry
   all the necessary addressing and routing information in each message
   - this type of subscription can include what it considers to be a
   "movement" by the UAC.  This will be what triggers the caller's UA
   to NOTIFY the PSAP it has moved, either as a delta from the original
   location or a new location the UAC is at.

   Here is an example message flow depicting this SUB/NOT for movement
   of Alice's UA during an emergency call:

   UA Alice             Proxy                  PSAP

      |    INVITE [M1]    |                     |
      |------------------>|                     |
      |                   |      INVITE [M2]    |
      |                   |-------------------->|
      |                   |      200 OK [M3]    |
      |                   |<--------------------|
      |   200 OK [M4]     |                     |
      |<------------------|                     |
      |     ACK [M5]                            |
      |---------------------------------------->|
      |                   RTP                   |
      |<=======================================>|
      |                                         |
      |               SUBSCRIBE [M6]            |
      |<----------------------------------------|
      |             200 OK (SUB) [M7]           |
      |---------------------------------------->|
      |       NOTIFY (init loc verify) [M8]     |
      |---------------------------------------->|
      |             200 OK (NOT) [M9]           |
      |<----------------------------------------|

      **Alice moves locations, causes a trigger**

      |        NOTIFY (new loc given) [M10]     |
      |---------------------------------------->|
      |            200 OK (NOT) [M11]           |
      |<----------------------------------------|


Polk & Rosen                                                  [Page 45]

Internet Draft         SIP Location Conveyance          July 17th, 2005


      Figure 6a. UA-PROXY with Location in INVITE

   The call flow shows this:

   - Alice called 911/112 (M1 of Figure 6a) and included here location
     in a PIDF-LO message body.

   - The message was routed correctly (M2 of Figure 6a) (message
     routing is not defined here).

   - The call was accepted and RTP packets flowed.

   - The PSAP operator, either manually or automatically, sent a
     SUBSCRIBE Method Request (M6 of Figure 6a) to Alice's UA to
     determine or refresh where she is located.

   This SUBSCRIBE informs Alice's UA with all it needs to look for
   (i.e. what constitutes a change in location, and perhaps which is
   the preferred location format for the NOTIFY messages to be sent
   back to the PSAP.

   - The SUB was accepted with a 200 OK (M7 of Figure 6a).

   - Alice's UA immediately, according to [RFC3265], MUST send an
     initial status to the subscriber (M8 of Figure 6a).  In this
     NOTIFY MUST be (perhaps another copy of the same) PIDF-LO from
     Alice to the PSAP.

   - The PSAP acknowledged receipt of this PIDF-LO in the 200 OK to the
     NOTIFY (M9 of Figure 6a).

   - If Alice and her UA move enough for the UA to detect what the
     SUBSCRIBE considered "movement", Alice's UA, without Alice being
     necessarily told, sends a new NOTIFY (M10 of Figure 6a) with this
     new location PIDF-LO as a message body.

   - This new NOTIFY is acknowledged with another 200 OK (M11 of Figure
     6a).

   The Subscription SHOULD be for as long as the PSAP operator
   considers it needs to know if movement can occur at Alice's UA.  In
   other words, Alice's UA SHOULD be prepared to receive a SUBSCRIBE
   with a very lengthy expires time, and not attempt to reduce the time
   requested. When the PSAP considers it time to end the subscription,
   it will actively refresh the subscription with a expires of 0, thus
   terminating the it.

   ** the corresponding appendix has not be completed at this time.





Polk & Rosen                                                  [Page 46]

Internet Draft         SIP Location Conveyance          July 17th, 2005

9.  Special Considerations for Emergency Calls

   Calling for local emergency, such as 911 or 112 today, has special
   handling characteristics.  First of which is the identification of
   the call as an emergency call.  When a node detects a call is a
   local emergency call, certain processes need to occur that are more
   complicated in a SIP architecture than in the circuit switched
   world.  In the circuit switched world, a caller is tied to a known
   Class-5 switch, or a PBX connected to a Class-5 switch.  This has
   the benefit of providing a location of the end of the wire of that
   phone, or more accurately, to the termination point on a wall (of an
   office or cube) or on the side of a house or building.  Each of
   these locations is just that, a physical location.  This location
   (typically the street address) is entered into a database that
   provides a means for looking up where an emergency call came from
   during that call's set-up to the PSAP.  The look-up is to the
   binding of that phone number to that street address.

   The challenge in SIP is the disconnect of call processing, either by
   the UA itself or by a SIP intermediary, from where the UAC is
   located when this emergency call is made.  A "call" here in SIP can
   be for voice, video, instant messaging or something else - all of
   this is considered a call in this document.  If the call needs to be
   routed to the proper PSAP by some network entity, for example
   because the Request-URI didn't have an IP address in it, the routing
   entity has to have enough information to route this call to the
   proper PSAP.

   The routing function towards the proper PSAP is out of scope of this
   document, but this document must specify enough SIP capabilities and
   information to that SIP intermediary to do the routing correctly
   from the contents of that SIP message.

   [ID-SIP-SOS] provides one means for identifying a SIP Request as an
   emergency session set-up.  Once that information is understood by a
   routing SIP intermediary, the intermediary (Proxy or an instance of
   a B2BUA) must look for the location of the UAC originating the
   Request to determine internally or externally where to route the
   message to.  The mapping of a location to where to route the message
   to is also out of scope of this document, and is currently under
   investigation.  The capability to include location of the UAC in a
   SIP message is the task of this document.  And this is where it is
   separate from the task of defining how to convey location between
   user agents that merely want to share location of the UAC.  This SIP
   intermediary MUST look into the SIP Request, for example an INVITE
   Request Method message, for the location of the UAC to be included
   in the message.

   Location inclusion within a SIP Request will be by-value or by-
   reference.  By-value is the case in which the location information
   is included or contained within the SIP message itself.  By-
   reference is the case in which the location of the UAC in a


Polk & Rosen                                                  [Page 47]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   (database) record or document on a server somewhere else, but the
   UAC knows the URI to that record/document and includes only that URI
   in the SIP Request.

   Including this new Location header is not always enough.  Therefore,
   if the UAC chooses to require there be location recognizable by the
   intermediary in order to process this message, the UAC will include
   both the "Proxy-Require" and "Require" headers, each with "location"
   as their option-tags.  The reason for both is that the UAC will not
   know the type of SIP element that is doing the routing to the PSAP.
   [RFC3261] states the "Proxy-Require" header is for SIP Proxies to
   process, and the "Require" header is for SIP UAs to process.  Since
   the SIP intermediary can be an instance of a B2BUA or a Border
   Controller, and neither is guaranteed to adhere to the "Proxy-
   Require" header, the Require header MUST be included as well in this
   emergency SIP message.

   A non-well formed message example would be:

   INVITE sip:sos@psap1.tx.us
   Proxy-Require: location
   Require: location
   Location: <location of "location", and/or type of location included>

   If the intermediary understands this message and is able to learn
   the UAC's location because it is recognizable as included in the
   Request, or to perform a mapping function (locally or remotely) to
   determine where to route the call (to the correct PSAP), the message
   is forwarded towards that PSAP with the new Request-URI of that
   PSAP.

   NOTE: The ability and process of this mapping function (taking a
         location and determining the correct PSAP for that location)
         within the SIP intermediary is defined elsewhere.

   If the intermediary does not understand this message and its
   relationship to location, perhaps because it does not understand the
   concept of routing based on the UAC's location, it needs to forward
   the message to another intermediary that will understand how to take
   location from the message and route it correctly, or communicate
   with the UAC if there are issues with the message.  The intermediary
   MUST not reject the message because it does not understand the
   concept of "location".  This document does not define how this
   occurs, as the offered solution here is to include a "Proxy-Require"
   and a "Require" header in this original Request.

   [NOTE: the authors are not sure where that needs to be defined -
          here, or in another document. Another way to address this
          inconsistency, one that is less forceful, is to mandate the
          inclusion of the Supported header instead of the "Proxy-
          Require" and a "Require" headers by the UAC in the original
          Request.  An option is to have the subsequent message from


Polk & Rosen                                                  [Page 48]

Internet Draft         SIP Location Conveyance          July 17th, 2005

          the UAC remove the Proxy-Require and Require headers and
          insert a Supported header, which will not cause a well
          behaving intermediary to reject the request.  Comments are
          desired]

   The ability of a PSAP to SUBSCRIBE to the caller's UA to learn if it
   moves to a new location, thus changing where the first responders
   need to be dispatched, is described in section 8.6 of this document.
   That section goes into some detail on how this subscription can be
   long lasting to receive repeated updates from the caller's UA if
   there is movement.


9.1 Emergency UAC Behavior Rules

   The following are the rules of behavior for the UAC transmitting an
   emergency SIP Request:

   1) The UAC MUST include a location header with a viable location
      value indicating where the UAC is to aid the routing
      intermediary.

   If location is by-value, the location header will have a "loc-body"
   option-tag, and the message will include a PIDF-LO message body
   indicating the UAC's currently location.

   If the location is by-reference, the location header will have the
   URI of the location of that UAC as the header value.

   Either of the above will indicate to the intermediary that the UAC
   is knowledgeable of location, and indicated where the location can
   be learned by the intermediary.  If this is not present, the
   intermediary will act accordingly and supply location other than in
   a location message body.  This gives the intermediary the ability to
   add a location header with a uri of the location record from a
   database that the UAS (in the PSAP) will access to learn the UAC's
   location when necessary.

   2) The UAC MUST include both the "Proxy-Require" and a "Require"
      header indicating "location" is required for this message.

   3) The UAC MUST understand any 425 (Retry Location Body) Response
      message with the PIDF-LO included as a message body part for that
      UAC to include in the subsequent retry INVITE to the PSAP as its
      location.

   NOTE: An open question remains in the case in which the UAC includes
         what it thinks is a viable location by-value or by-reference
         and receives a 488 (Not Acceptable Here) with an Unsupported
         header indicating "Location".

   Option#1 to this would be for the UAC to back off including the


Polk & Rosen                                                  [Page 49]

Internet Draft         SIP Location Conveyance          July 17th, 2005

        "Proxy-Require" and a "Require" headers and merely put in a
        Supported Header with "location" in the attempt to get the
        message past the SIP intermediary that is rejecting the INVITE
        Request message from a lack of understanding of location.

       Comments are asked in this case.

   4) the UAC SHOULD NOT S/MIME or SIPFRAG protect location
      Information without certainty of knowledge the intermediary can
      decrypt the message to learn the location of the UAC.  This
      defeats the purpose of an intermediary assisting in routing the
      message correctly - which will be required for 911/112-type
      request attempts.

   5) the SIP Request from the UAC to the PSAP SHOULD be protected
      through a SIPS-URI, TLS or IPsec, but the UAC MUST be prepared to
      initially send the message, or a retransmission (based on a
      timeout or rejection message) in cleartext to ensure the session
      set-up does not fail due to security incompatibilities in
      transit, or at the PSAP.

   6) the UAC MUST include both a <provided-by> element and a <method>
      element in the PIDF-LO message body indicating #1 the
      organization that provided the location information to the UAC,
      and #2 how the UAC learned its location information,
      respectively.

   7) The UAC SHOULD be prepared to receive a SUBSCRIBE Request message
      from the PSAP seeking verification of its location.  This
      subscription SHOULD want to last for more than one NOTIFY back to
      the subscriber, for the purposes of getting updates of movement
      the calling (UAC) detects, based on what is in the original
      SUBSCRIBE Request message.  As such, this SUBSCRIBE SHOULD have a
      lengthy Expires timer.  The original (the calling) UAC MUST NOT
      reduce the time of this Expires Timer if it accepts the
      SUBSCRIBE.  See section 8.6 for more on SUB/NOT and location
      conveyance.

   This SUBSCRIBE SHOULD provide within the message what it considers
   to be "movement" by the emergency calling (UAC).


9.2 Emergency UAS/Intermediary Behavior Rules

   The following are the rules of behavior for the UAS or intermediary
   receiving an emergency SIP Request:

   1) identifies that SIP Request as an emergency Request.

   2) The intermediary looks for the "location" header to inform it
      where location is within this message (by-reference or by-value),
      and if the format of the location information is given as a hint.


Polk & Rosen                                                  [Page 50]

Internet Draft         SIP Location Conveyance          July 17th, 2005


   3) The intermediary looks for a "Proxy-Require" and/or a "Require"
      header indicating "location" is required for this message.

   4) If the intermediary does not understand location, or does not
      observe viable location information within this message MUST do
      one of the following action items:

      a) reject the message with a 488 (Not Acceptable Here) with a
         Unsupported header indicating "location" if the intermediary
         does not understand location and there is a "Proxy-Require"
         and/or a "Require" header indicating "location"

      b) if the intermediary does not understand location, and there is
         no "Proxy-Require" and/or a "Require" header indicating
         "location", the intermediary MUST not reject the message, but
         MUST forward this message to another (upstream) SIP
         intermediary for proper processing.

      c) reject the message with a 425 (Retry Location Body) if it
         understands the concept of location, but does not detect
         location in the message, and has a current PIDF-LO for that
         UAC.  The UAC will know to reattempt the INVITE with this new
         PIDF-LO message body.

      d) if the intermediary understands the concept of location, but
         does not detect location within this message, it MAY insert a
         location by-reference, if known

   Of particular concern to this option "d" above is the fact this
   information never gets back to the UAC, so it MAY remain in the dark
   as to its location.  If the UAC does not understand location, which
   SHOULD be indicated by the lack of presence of the Location header,
   insertion is the best possible solution short of upgrading the UAC.
   However, if the UAC includes a Location header, an intermediary
   SHOULD NOT insert location by-reference and forward the message.

   5) the intermediary MUST NOT delete a PIDF-LO message body

   6) the intermediary that knows the concept of location SHOULD NOT
      insert a location by-reference header value if there is a
      location by-value currently in the SIP message from the UAC.

   Behavior #5 above MUST NOT be done to satisfy Behavior #6 here, just
   to get a by-reference location indication in the message.

   7) If the UAC included a location header, but this was not deemed
      usable, or determined to be incorrect, the intermediary MAY
      reject the Request with one of the following response codes:

      a) a 424 (Bad Location Information) response informing the UAC to
         include its location in a subsequent attempt, or


Polk & Rosen                                                  [Page 51]

Internet Draft         SIP Location Conveyance          July 17th, 2005


      b) a 425 (Retry Location Body) if the intermediary can include
         what it considers to be current and accurate location
         information to the UAC.


9.3  Basic Emergency Message Flow Examples

   The following subsections provide a discussion on the basic message
   flows for emergency messaging.


9.3.1 Basic INVITE with Location Body

   Here is the basic message flow for Alice calling for help.

   UA Alice             Proxy                  PSAP

      | INVITE (w/ PIDF-LO)[M1]                 |
      |------------------>|                     |
      |             INVITE (w/ PIDF-LO) [M2]    |
      |                   |-------------------->|
      |                   |      200 OK [M3]    |
      |                   |<--------------------|
      |   200 OK [M4]     |                     |
      |<------------------|                     |
      |     ACK [M5]                            |
      |---------------------------------------->|
      |                   RTP                   |
      |<=======================================>|
      |                                         |

      Figure 7a. UA-PROXY with Location in INVITE

   Consider Figure 7a as a very basic message flow establishing an
   emergency call from Alice to the correct PSAP suiting her location.

   [M1 of  Figure 7a]

   INVITE sips:sos@atlanta.com SIP/2.0
   From: Alice
   To: sos@
   Proxy-Require: Location
   Require: Location
   Location: geo-loc
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1

   Content-Type: application/sdp
   v=0


Polk & Rosen                                                  [Page 52]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   ...

   --boundary1

   Content-Type: application/cpim-pidf+xml
   (Alice's geo PIDF-LO goes here)


   Once the intermediary's mapping function determines the correct PSAP
   for Alice's sos@ call to go to, the INVITE will look something like
   this (with a changed Request-URI):

   [M2 of  Figure 7a]

   INVITE sips:sos@psap1.atlanta.us SIP/2.0
   From: Alice
   To: sos@
   Proxy-Require: Location
   Require: Location
   Location: geo-loc
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1

   Content-Type: application/sdp
   v=0
   ...

   --boundary1

   Content-Type: application/cpim-pidf+xml
   (Alice's geo PIDF-LO goes here)

   The call gets set up and everything is grand.

   See section 8.6 for the message flow that will likely be the follow-
   on to this flow in Figure 7a.


9.3.2 Basic INVITE Retry from 425 Response

   If the routing SIP intermediary does not detect location in Alice's
   INVITE, or determines if it is wrong, and the intermediary knows the
    current and correct location of Alice's UAC, it transmits a 425
   (Retry Location Body) and includes that location information (by-
   value or by-reference) in the rejection response.  Figure 7b shows
   this basic message flow.






Polk & Rosen                                                  [Page 53]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   UA Alice             Proxy                  PSAP

      |    INVITE [M1]    |                     |
      |------------------>|                     |
      | 425 Retry Location Body [M2]            |
      |<------------------|                     |
      |    INVITE [M3]    |                     |
      |------------------>|                     |
      |                   |      INVITE [M4]    |
      |                   |-------------------->|
      |                   |      200 OK [M5]    |
      |                   |<--------------------|
      |     ACK [M6]                            |
      |---------------------------------------->|
      |                   RTP                   |
      |<=======================================>|
      |                                         |

      Figure 7b. INVITE Retry with Location

   The 425 rejection Response could look something like this:

   [M2 of  Figure 7b]

   SIP/2.0 425 Retry Location Body
   To: psap1
   From: Alice
   Location: geo-loc
   Content-type: application/cpim-pidf+xml

   [Alice's geo formatted PIDF-LO goes here]


   [M3 of  Figure 7b]

   INVITE sips:sos@psap1.atlanta.us SIP/2.0
   From: Alice
   To: sos@
   Proxy-Require: Location
   Require: Location
   Location: geo-loc
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1

   Content-Type: application/sdp
   v=0
   ...

   --boundary1



Polk & Rosen                                                  [Page 54]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   Content-Type: application/cpim-pidf+xml
   (Alice's geo PIDF-LO goes here)


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

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

   1) Should a Proxy somehow label its location information in the 4XX
      (Retry Location Body) message?


11.1  New Open Issues

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

   1) There is an outstanding request to be able to include more than
      one location element, and label at least one the current position
      of the UAC, and another the "billing" address of the owner of the
      UAC.  This comes from the country of Sweden, from our favorite


Polk & Rosen                                                  [Page 55]

Internet Draft         SIP Location Conveyance          July 17th, 2005

      Patrik Faltstrom.

   Options to this are use the Content-Type headers associated with
   each message body part, using either:

   A) multipart/mixed - because they could be considered different

   B) multipart/alternative - for one application to use only one, and
               allowing another application to use another

   C) multipart/related - because they could be considered similar
                enough as they each deal with location


   2) 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
   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

13.3 IANA Registration for the SIP Location Header

   This subsection will be completed once the authors work out the ABNF
   for the header




Polk & Rosen                                                  [Page 56]

Internet Draft         SIP Location Conveyance          July 17th, 2005

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.

   To Paul Kyzivat for inspiring some of the recent text addressing
   lingering issues the authors could not resolve.


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

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

 [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource
           Locators", RFC 2393, August 1998

 [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


Polk & Rosen                                                  [Page 57]

Internet Draft         SIP Location Conveyance          July 17th, 2005

           Method", RFC 3515, April 2003

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


15.2 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-SIP-SOS] H. Schulzrinne, "draft-ietf-sipping-sos-00.txt", Internet
           Draft, Feb 2004, Work in progress

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


   Author Information

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


   Brian Rosen                                       40.4N
   br@brianrosen.net                                 80.0W
   NeuStar


   NOTE: these appendixes are not in good order yet, and will be worked
         on soon.














Polk & Rosen                                                  [Page 58]

Internet Draft         SIP Location Conveyance          July 17th, 2005

Appendix A1. 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
   <?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>


Polk & Rosen                                                  [Page 59]

Internet Draft         SIP Location Conveyance          July 17th, 2005

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

Appendix A2. INVITE and REFER between 3 UAs

   In the following example, Alice presents her location in the INVITE
   to Bob, which Bob 200 OKs with his location as well.  Bob then
   directs Alice to contact Carol.  The REFER Method [RFC3515] is used
   in the message sequence, but it does not carry anyone's location
   within the REFER message.  This example is here to show a 3-way
   communication of location, coupled with how a UA can include someone
   else's location.  This has security implications due to neither
   primary party in the last location transfer being the owner of the
   location information.  Alice (in this case) MUST adhere to the
   retention and distribution privacy requirements within Bob's
   location object regarding his location information prior to
   considering its inclusion in the INVITE to Carol.

   UA Alice                        Bob          Carol

      |           INVITE [M1]       |             |
      |---------------------------->|             |
      |           200 OK [M2]       |             |
      |<----------------------------|             |
      |            ACK [M3]         |             |
      |---------------------------->|             |
      |              RTP            |             |
      |<===========================>|             |
      |     reINVITE (hold) [M4]    |             |
      |<----------------------------|             |
      |          200 OK [M5]        |             |
      |---------------------------->|             |
      | REFER (Refer-to:Carol) [M6] |             |
      |<----------------------------|             |
      |          NOTIFY [M9]        |             |
      |---------------------------->|             |
      |          200 OK [M10]       |             |
      |<----------------------------|             |
      |                 INVITE [M7]               |
      |------------------------------------------>|
      |                 200 OK [M8]               |


Polk & Rosen                                                  [Page 60]

Internet Draft         SIP Location Conveyance          July 17th, 2005

      |------------------------------------------>|
      |                     RTP                   |
      |<=========================================>|
      |          NOTIFY [M9]        |             |
      |---------------------------->|             |
      |          200 OK [M10]       |             |
      |<----------------------------|             |
      |           BYE [M11]         |             |
      |<----------------------------|             |
      |          200 OK [M12]       |             |
      |---------------------------->|             |
      |                                           |

      Figure A2. UA-to-UA with Location in REFER


Appendix A3. UA-to-UA REFER with Civic Location Using S/MIME

   In Figure A2., we have an example message flow involving the REFER
   Method.  The REFER itself does not carry location objects.

   We are not including all the messages for space reasons.  M1 is a
   well-formed SIP message that contains Alice's location.  M2 is Bob's
   200 OK in response to Alice's INVITE, and it contains Bob's
   Location.

[M1 of Figure A2] - Alice at Sears Tower

   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


Polk & Rosen                                                  [Page 61]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   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>

   --boundary1--


   Bob replies to Alice's INVITE with a 200 OK and includes his
   location.

[M2 of Figure A2] - Bob watching Cubs Game at Wrigley Field

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP pc33.atlanta.example.com
     ;branch=z9hG4bKnashds8 ;received=10.1.3.33


Polk & Rosen                                                  [Page 62]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
   From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 INVITE
   Contact: <sip:bob@192.168.10.20>
   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=bob 2890844530 2890844530 IN IP4 biloxi.example.com
   c=IN IP4 192.168.10.20
   t=0 0
   m=audio 3456 RTP/AVP 0
   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:bob@biloxi.example.com">
        <tuple id="sg89ae">
         <timestamp>2005-11-6T02:30: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:A6>Addison</cl:A6>
                <cl:HNO>1060</cl:HNO>
                <cl:PRD>W</cl:PRD>
                <cl:STS>street</cl:STS>
                <cl:LMK>Wrigley Field</cl:LMK>
                <cl:PC>60613</cl:PC>
              <cl:civilAddress>
              <method>dhcp</method>
              <provided-by>www.cisco.com</provided-by/>
            </gp:location-info>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>


Polk & Rosen                                                  [Page 63]

Internet Draft         SIP Location Conveyance          July 17th, 2005

              <gp:retention-expiry>2005-11-6T18:30:29Z</gp:retention-
                            expiry>
            </gp:usage-rules>
          </gp:geopriv>
         </status>
        </tuple>
       </presence>

   --boundary1--

   Bob refers Alice to Carol, and in M7, Alice includes both locations
   in a single SIP message.  This is possible because Bob set his
   retention value to "yes", thus allowing Alice to pass his location
   on to Carol.

[M7 of Figure A2] - Alice tells Carol where she and Bob are

   INVITE sips:carol@chicago.example.com SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com
    ;branch=z9hG4bK776asdhdt
   Max-Forwards: 70
   To: Carol <sips:carol@chicago.example.com>
   From: Alice <sips:alice@atlanta.example.com>;tag=1928301775
   Call-ID: a84b4c76e66711@pc33.atlanta.example.com
   CSeq: 314160 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 2890844531 2890844531 IN IP4 atlanta.example.com
   c=IN IP4 10.1.3.33
   t=0 0
   m=audio 49173 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:bob@biloxi.example.com">


Polk & Rosen                                                  [Page 64]

Internet Draft         SIP Location Conveyance          July 17th, 2005

        <tuple id="sg89af">
         <timestamp>2005-11-5T02:30: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:A6>Addison</cl:A6>
                <cl:HNO>1060</cl:HNO>
                <cl:PRD>W</cl:PRD>
                <cl:STS>street</cl:STS>
                <cl:LMK>Wrigley Field</cl:LMK>
                <cl:PC>60613</cl:PC>
              <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>yes</gp:retransmission-
                                                             allowed>
              <gp:retention-expiry>2005-11-6T18:30:29Z</gp:retention-
                            expiry>
            </gp:usage-rules>
          </gp:geopriv>
         </status>
        </tuple>
       </presence>

   --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-6T02:30: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 65]

Internet Draft         SIP Location Conveyance          July 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.marconi.com</provided-by/>
            </gp:location-info>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>
              <gp:retention-expiry>2005-11-6T18:30:29Z</gp:retention-
                            expiry>
            </gp:usage-rules>
          </gp:geopriv>
         </status>
        </tuple>
       </presence>

   --boundary1--


   It is an open question of whether there should be a mechanism to
   request or require the transmission of an LO.  The LO is contained
   in a body, so the available sip mechanisms do not apply.


Appendix A4. UAC to UAS or Proxy Using OPTIONS Method (from 8.2)



Appendix A5. UA-to-UA Using MESSAGE Method (from 8.3)

   UA Alice                                  UA Bob

      |               MESSAGE [M1]              |
      |---------------------------------------->|
      |                200 OK [M2]              |
      |<----------------------------------------|
      |                                         |

      Figure A5. UA-UA with Location in MESSAGE



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




Polk & Rosen                                                  [Page 66]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   [Message 1 in Figure A5]

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


Polk & Rosen                                                  [Page 67]

Internet Draft         SIP Location Conveyance          July 17th, 2005

         </status>
        </tuple>
       </presence>

   --boundary1--


Appendix A7. 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 A5]

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


Polk & Rosen                                                  [Page 68]

Internet Draft         SIP Location Conveyance          July 17th, 2005

              <gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
                      expiry>
            </gp:usage-rules>
          </gp:geopriv>
         </status>
        </tuple>
       </presence>


Appendix A8. UA-to-UA Location Conveyance Using UPDATE (from 8.4)

   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 A6. UA-UA with Location in UPDATE


   The following section will include the M1 and M5 messages in detail,
   but only in the civic format.


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


Polk & Rosen                                                  [Page 69]

Internet Draft         SIP Location Conveyance          July 17th, 2005

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


Polk & Rosen                                                  [Page 70]

Internet Draft         SIP Location Conveyance          July 17th, 2005

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


Polk & Rosen                                                  [Page 71]

Internet Draft         SIP Location Conveyance          July 17th, 2005

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


Appendix A10. UA-to-UA Location Conveyance Using PUBLISH (from 8.5)

   ** This appendix is not be completed at this time.


Appendix A11. UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY
              (from 8.6)

   ** This appendix is not be completed at this time.



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


Polk & Rosen                                                  [Page 72]

Internet Draft         SIP Location Conveyance          July 17th, 2005

   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.


Acknowledgment

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




The Expiration date for this Internet Draft is:

January 17th, 2006


Polk & Rosen                                                  [Page 73]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/