--- 1/draft-ietf-sip-location-conveyance-08.txt 2007-11-19 19:14:21.000000000 +0100 +++ 2/draft-ietf-sip-location-conveyance-09.txt 2007-11-19 19:14:21.000000000 +0100 @@ -1,45 +1,44 @@ SIP Working Group James Polk Internet Draft Cisco Systems -Expiration: Jan 9th, 2008 Brian Rosen -Intended Status: Standards Track NeuStar +Expiration: May 16th, 2008 Brian Rosen +Intended Status: Standards Track (PS) NeuStar Location Conveyance for the Session Initiation Protocol - draft-ietf-sip-location-conveyance-08.txt - July 9th, 2007 + draft-ietf-sip-location-conveyance-09.txt + Nov 16th, 2007 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." + 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 9th, 2008. + This Internet-Draft will expire on May 16th, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension covers end to end @@ -47,46 +46,46 @@ make routing decisions based on the location of the SIP user agents. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Overview of SIP Location Conveyance . . . . . . . . . . . 4 3.2 The Geolocation Header . . . . . . . . . . . . . . . . . 5 3.3 424 (Bad Location Information) Response Code . . . . . . 8 - 3.4 The Geolocation-Error Header . . . . . . . . . . . . . . 8 - 3.5 The Geolocation Option Tag . . . . . . . . . . . . . . . 16 - 3.6 Using sip/sips/pres as a Dereference Scheme . . . . . . . 17 - 4. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 17 - 4.1 Location-by-value (Coordinate Format) . . . . . . . . . . 18 - 4.2 Location-by-reference . . . . . . . . . . . . . . . . . . 19 - 5. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 20 - 5.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 21 - 5.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 23 - 5.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 25 - 6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 27 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29 - 8.1 IANA Registration for New SIP Geolocation Header . . . . 30 - 8.2 IANA Registration for New SIP Geolocation Option Tag . . 30 - 8.3 IANA Registration for New 424 Response Code . . . . . . . 30 - 8.4 IANA Registration for New SIP Geolocation-Error Header . 30 - 8.5 IANA Registration for New SIP Geolocation-Error Codes . . 30 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 10.1 Normative References . . . . . . . . . . . . . . . . . 32 - 10.2 Informative References . . . . . . . . . . . . . . . . . 33 - Author Information . . . . . . . . . . . . . . . . . . . . . 33 - Appendix A. Requirements for SIP Location Conveyance . . . . 34 - Appendix B. Example of Civic-based PIDF-LO w/ S/MIME . . . . 36 - Intellectual Property and Copyright Statements . . . . . . . 37 + 3.4 The Geolocation-Error Header . . . . . . . . . . . . . . 9 + 3.5 The Geolocation Option Tag . . . . . . . . . . . . . . . 18 + 3.6 Using sip/sips/pres as a Dereference Scheme . . . . . . . 19 + 4. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 20 + 4.1 Location-by-value (Coordinate Format) . . . . . . . . . . 20 + 4.2 Location-by-reference . . . . . . . . . . . . . . . . . . 22 + 5. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 23 + 5.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 24 + 5.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 26 + 5.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 29 + 6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 32 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 + 8.1 IANA Registration for New SIP Geolocation Header . . . . 34 + 8.2 IANA Registration for New SIP Geolocation Option Tag . . 35 + 8.3 IANA Registration for New 424 Response Code . . . . . . . 35 + 8.4 IANA Registration for New SIP Geolocation-Error Header . 35 + 8.5 IANA Registration for New SIP Geolocation-Error Codes . . 35 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 10.1 Normative References . . . . . . . . . . . . . . . . . 37 + 10.2 Informative References . . . . . . . . . . . . . . . . . 38 + Author Information . . . . . . . . . . . . . . . . . . . . . 38 + Appendix A. Requirements for SIP Location Conveyance . . . . 39 + Appendix B. Example of Civic-based PIDF-LO w/ S/MIME . . . . 41 + Intellectual Property and Copyright Statements . . . . . . . 42 1. Introduction This document describes how Location can be "conveyed" (that is, transmitted over the Internet) from one SIP user agent (UA), or in some circumstances, a proxy server acting in support of a UA, to another entity using SIP [RFC3261]. Here "Location" is a description of the physical geographical area where something currently exists. The phrase "location conveyance" describes scenarios in which a SIP user agent client (UAC) is informing a user @@ -259,67 +258,83 @@ The cid-url is defined in [RFC2392] to locate message body parts. This URI type MUST be present in a SIP message if location is by-value in that same message. Other protocols used in the Location URI MUST be reviewed against the RFC 3693 criteria for a Using Protocol. The Geolocation header MAY have one or more locationValues. SIP servers inserting a locationValue MUST add the new value to the end - of the header value, such that the last locationValue is the most - recent one added to the message. + of the header value, such that the last locationValue in the header + is the most recent one added to the message. - A locationValue has the following header parameters. These - header parameters include, + A locationValue has the following independent header parameters, - o the "inserted-by=" provides the host-id (alice.example.com) of - the SIP entity that inserted this locationValue into the request. - This is used to map to any Geolocation-Error message to determine - which location, if there is more than one in a request, the error - corresponds to. If an entity receives an Geolocation-Error with - a host-id not of this entity, the Geolocation-Error SHOULD be - ignored. + o the "inserted-by=" parameter provides the host-id + (alice.example.com -- which is the same as the "sent-by" + parameter in a Via header) of the SIP entity that inserted this + locationValue into the request. This is used to map to any + Geolocation-Error message to determine which location, if there + is more than one in a request, the error corresponds to. If an + entity receives an Geolocation-Error with a host-id not of this + entity, the Geolocation-Error SHOULD be ignored. - o "used-for-routing" to inform recipients that the location in this - locationValue was used to route the message towards the ultimate - destination UAS. This can occur more than once along the - request's path. Because locationValues are inserted as last - inserted is last in the header, the last locationValue is the - most recent one added to the message. This also gives the - "used-for-routing" header parameter added integrity - as the - receiving SIP entity knows which locationURI the message was - routed upon. + o the "used-for-routing" parameter to inform recipients that the + location in this locationValue was used to route the message + towards the ultimate destination UAS. This can occur more than + once along the request's path. Because locationValues are + inserted as last inserted is last in the header, the last + locationValue is the most recent one added to the message. This + also gives the "used-for-routing" header parameter added + integrity - as the receiving SIP entity knows which locationURI + the message was routed upon. - o the "recipient=" to allow recipients to infer what SIP element - type this locationValue was intended to be for. The types are - "endpoint", meaning the ultimate destination UAS; - "routing-entity", meaning SIP servers; and "both" meaning this - locationValue is to be viewed by both types of SIP entities. + o the "recipient=" parameter to allow recipients to infer what SIP + element type this locationValue was intended to be for. The + types are + + o "endpoint" - meaning the ultimate destination UAS; + + o "routing-entity" - meaning SIP servers that route messages + based on the location contents of requests; and + + o "both" - meaning this locationValue is to be viewed by both + types of SIP entities. + + Not all SIP entities have to read the locationValue within a + Geolocation header, therefore a parameter value of "both" does + not mean "every" SIP element receiving this request, it means all + that care to pay attention to a locationValue. The default + behavior of SIP entities reading the locationValue is that if + this header parameter is NOT present, the intended recipient is + the destination UAS. + + Each locationValue MUST contain exactly one "inserted-by" parameter, + indicating which SIP entity added the locationValue to the SIP + request. Each of the three types of header parameters listed here MAY appear in any locationValue once. There MUST NOT be more than one - "inserted-by=" parameter or "used-for-routing" parameter or - "recipient=" parameter in the same locationValue. However, since - there can be more than one locationValue in the same Geolocation - header, each can with their own set of these header parameters and - not violate this rule. + "inserted-by=" parameter or one "used-for-routing" parameter or one + "recipient=" parameter in the same locationValue. However, there + can be more than one locationValue in the same Geolocation header. This document defines the Geolocation header as valid in the following SIP requests: INVITE [RFC3261], REGISTER [RFC3261], OPTIONS [RFC3261], BYE [RFC3261], UPDATE [RFC3311], INFO [RFC2976], MESSAGE [RFC3428], REFER [RFC3515], - SUBSCRIBE [RFC3265], NOTIFY [RFC3265] and - PUBLISH [RFC3903] + SUBSCRIBE [RFC3265], NOTIFY [RFC3265], + PUBLISH [RFC3903] and PRACK [RFC3262] Discussing location using the PUBLISH Request Method is out of scope for this document, but the Table 1 shows PUBLISH is to support Location Conveyance via this extension. The following table extends the values in Table 2&3 of RFC 3261 [RFC3261]. Header field where proxy INV ACK CAN BYE REG OPT PRA ---------------------------------------------------------------- @@ -334,138 +349,210 @@ The Geolocation header field MAY be included in any one of the above requests by a UAC. A proxy MAY add the Geolocation header, but MUST NOT modify any pre-existing locationValue, including its associated header parameters of within an existing Geolocation header value, unless one of the existing locationValues is used to retarget the request towards a new destination UAS. This is discussed in section 5.3. [RFC3261] states message bodies cannot be added by proxies. Therefore, any Geolocation header field added by a proxy MUST be in - the form of a location-by-reference URI. + the form of a location-by-reference URI, in its own locationValue + header value. - Adding a locationValue to an existing Geolocation header SHOULD be - done with caution, given this document's limited guidance as to what - a Location Recipient should do when receiving more than one - location. A Location Recipient can easily be confused by too much - location information, producing undesirable results. + Adding a new locationValue to an existing Geolocation header SHOULD + NOT occur without appropriate caution to the fact that Location + Recipients might not understand how to process more than one + location, given this document's limited guidance as to what a + Location Recipient should do when receiving more than one location + (i.e., currently no priority instructions are given for which + locationValue to use if there are more than one). A Location + Recipient can easily be confused by too much location information, + producing undesirable results. The element in the + PIDF-LO XML indicates whose location is contained in the PIDF-LO. Location Recipients receiving a location object, received directly or as the result of a dereference, MUST honor the usage element rules within that XML document, per RFC 4119. Such entities MUST NOT alter the rule set. 3.3 424 (Bad Location Information) Response Code If a UAS or SIP intermediary detects an error in a request message specific to the location information supplied by-value or by-reference. The new 4XX level error is created here to indicate a problem with the location in the request message. This document creates and IANA registers the new error code: 424 (Bad Location Information) The 424 (Bad Location Information) response code is a rejection of the request, due to its location contents, indicating the location information was malformed or not satisfactory for the recipient's - purpose or could not be dereferenced. + purpose, or could not be dereferenced. Section 3.4 creates the Geolocation-Error header to provide more detail about what was wrong with the location information in the - request. This header MUST be in the 424 response with the most - applicable code. + request. This header MUST be in the 424 response, containing a + locationErrorValue for each invalid locationValue in the request + (i.e., and one-for-one matching if all locationValues in the request + were bad). If more than one location is present in a request (by-value or by-reference), and any of the locationValues is good for the Location Recipient to process, a 424 MUST NOT be sent. The 424 is - only appropriate when there are no locationValues included in a SIP - request that are usable by a recipient. + only appropriate when the Location Recipient needs a locationValue + and there are no locationValues included in a SIP request that are + usable by a recipient. A 424 (Bad Location Information) response is a final response within a transaction, and does not terminate a dialog. The UAC can use whatever means it knows of to verify/refresh its location information before attempting a new request that includes location. There is no cross-transaction awareness expected by either the UAS or SIP intermediary as a result of this error message. The new 424 (Bad Location Information) error code is IANA registered in Section 8 of this document. An initial set of location error of IANA registered Geolocation-Error codes are in Section 3.4 of this document. -3.4 The Geolocation-Error Header for Error Granularity +3.4 The Geolocation-Error Header Providing Error Granularity As discussed in Section 3.3, more granular error notifications, specific to location errors within a received request, are required if the UAC is to know what was wrong within the original request. The Geolocation-Error header is created here for this purpose. Geolocation-Error header is used to convey location specific errors within a response. Additions to this IANA registered header require an RFC be published. - Geolocation-Error = "Geolocation-Error" HCOLON (locationErrorValue - *(COMMA locationErrorValue)) - locationErrorValue = numeric-code SEMI (error-node-id) - SEMI (host-id) SEMI (geoloc-error-param) - numeric-code = decimal-string - error-node-id = node-id - host-id = "inserter" EQUAL host name - geoloc-error-param = "code" EQUAL error-text-string - / generic-param ; (from RFC 3261) - error-text-string = string + Geolocation-Error = "Geolocation-Error" HCOLON + [locationErrorValue + *(COMMA locationErrorValue)] + locationErrorValue = location-error-code *(SEMI + location-error-params) + location-error-code = 1*3DIGIT + location-error-params = location-error-node-id + / DQOUTE location-error-host-id DQOUTE + / CAtype *(SEMI CAtype) + / DQOUTE location-error-code-text DQOUTE + / generic-param ; from RFC3261 + location-error-node-id = "node" EQUAL hostname; from RFC3261 + location-error-host-id = "inserter" EQUAL hostname ; from RFC3261 + CAtype = "CAtype" EQUAL civic-code *(SEMI "CAtype" + EQUAL civic-code) + location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 + civic-code = IANA registered CAtypes; from + [IANA-civic] - The Geolocation-Error header contains a locationErrorValue, which is - a numeric code of the error with its associated descriptive text, - the error-text-string. The error-text-string is human understandable - text for each error code. The Geolocation-Error can have more than - one locationErrorValue, separated by a comma. Included error codes - SHOULD NOT conflict in meaning. Each locationErrorValue is targeted - at a specific location inserter, which is learned from the - "inserted-by=" parameter in the locationValue of the request. + The Geolocation-Error header MUST contain at least one + locationErrorValue to indicate what was wrong with the original + locationValue in the corresponding request. If a Location Recipient + experienced more than one error in the locationValue of the + corresponding SIP request, there can be one locationErrorValue per + problem with the locationValue in the request (the except to this is + involving CAtypes, which will be covered later here). If there was + something wrong with more than one locationValue in a request, a + corresponding locationErrorValue would be sent, one per error, in + the response. Each locationErrorValue contains a 3-digit error code + (defined in subsections to this section of this doc) indicating what + was wrong with the location(s) in the request. Each error type has + a corresponding quoted error text string that is human + understandable. - The Numeric-code value is the number assigned to a particular error. - These error codes start 1, and are not necessarily consecutively - incremented. All Numeric-code values are IANA registered. + Also within the locationErrorValue is the Location Recipient + identifier (the "node=") who experienced the location error, as well + as an identifier of which SIP entity (the "inserter=") the Location + Recipient is told (in the locationValue) added the locationValue to + this request. The "node=" and "inserter=" are domain identifier of + a SIP entity, the same as is entered in the "sent-by" parameter of + the Via header for that entity [RFC3261]. As stated in section 18 + of RFC 3261, the usage of FQDN is RECOMMENDED. Here are examples of + both - The error-node-id is the node identification of the entity that - experienced the location-based error from the request, and MUST NOT - be an IP address for many reasons, including the presence of NATs. - This can be useful for troubleshooting. Here is an example of an - error-node-id + node=bob.example.com - alice.example.com + inserter=alice.example.com - The host-id has the same form as the error-node-id, but the host-id - is the host name of the entity that inserted the location into the - request. This value can be found in the "inserted-by=" parameter of - the Geolocation header in the request. If this is not present in - the request, the host-id cannot be in the response. This value, - when present, gives the response recipients an indication as to - which location, therefore which entity, this particular error is - intended for. Here is an example of the host-id + Both "node=" and "inserter=" parameters MUST be present in all + locationErrorValues in a response, unless the "inserted-by=" + parameter was not in the request. The "inserter=" parameter is + copied from the "inserted-by=" parameter within the locationValue of + the request. - bob.example.com + Here's why, a Location Recipient that experienced the location + problem with the request needs to tell who added which location into + the original request. Since more than one SIP entity can insert + location into a request, all other SIP elements may be confused by + receiving this error header. So, the header has to identify who it + is for, so that all other SIP entities that read the header know to + ignore it, since it is not for them. This is of particular use if + the original UAC did not include a locationValue in the original SIP + request, but a SIP server along the path did insert a locationValue. + The locationErrorValue would travel to each SIP entity along the + original path and tell both the server that included the + locationValue what was wrong with the location and the UAC who + did not know what the error meant. - If an entity receives an Geolocation-Error with a host-id not of - this entity, the Geolocation-Error SHOULD be ignored because the - error is not intended for this entity. + A worse case is when both the original UAC and a SIP server along + the path included a locationValue, but there was only something + wrong with one of the locationValues. Without this identification + of which locationValue was in error, both entities would react and + one would do so incorrectly. - The error-text-string is a natural language ASCII string that is - intelligible to a human user reading the error message, which - describes the type of error experienced. This string MUST appear in - each locationErrorValue of a response. + Finally, there can be a list of one or more CAtype civic-codes that + are determined to be in error by the Location Recipient. Perhaps + the Location Recipient believes one or more CAtypes are missing, and + required in order to fully process the locationValue in the request, + or perhaps data entered in one or more CAtypes is wrong, according + to the Location Recipient. The list of CAtypes is taken from those + that are IANA registered at [IANA-civic]. + + More than one locationErrorValue in a Geolocation-Error header is + separated by a comma. + + If more than one locationErrorValue is in a response, and intended + for the same "inserter=", the error codes SHOULD NOT conflict in + meaning. In other words, two error codes (within separate + locationErrorValues of the same response) SHOULD NOT give misleading + or inconsistent indications to the location "inserter=". Here is an example of a Geolocation-Error header - Geolocation-Error: 1; alice.example.com; code="Location Format not - supported" + Geolocation-Error: 106; "node=bob.example.com"; + "inserter=alice.example.com"; + CAtype=A3; CAtype=STS; + code="incomplete location supplied" + + In this example, the Location Recipient (node=Bob) has determined + the location supplied by the "inserter=" (inserter=Alice) was not + enough to determine where (Alice) was. Specifically, Bob has + determined that CAtypes A3 (the city) and STS (the street type + (Street, Road, Avenue, etc)) were not present to form a complete + location of the Alice. A subsequent request by Alice that included + these two additional pieces of location information would tell Bob + where Alice was. + + Notice the CAtypes that were in error are (in the above example + Geolocation-Error header), according to the Location Recipient, + listed in the locationErrorValue. The associated CAtype values MUST + NOT be listed in the locationErrorValue. This is for + privacy/security concerns. It is up to the Location Recipient to + determine which CAtypes were in error, and only list those CAtypes + in the response. The "inserter=" entity MUST determine what to do + about correcting each CAtype found in error for subsequent location + conveyance. Usually, this would involve either refreshing its + location information however it learned its location in the first + place, or merely listing what information is lacking/wrong to the + location sender (i.e., the user) or its network management. The following table extends the values in Table 2&3 of RFC 3261 [RFC3261]. Header field where proxy INV ACK CAN BYE REG OPT PRA ---------------------------------------------------------------- Geolocation-Error r ar o - - o o o o Header field where proxy SUB NOT UPD MSG REF INF PUB ---------------------------------------------------------------- @@ -463,169 +550,165 @@ The following table extends the values in Table 2&3 of RFC 3261 [RFC3261]. Header field where proxy INV ACK CAN BYE REG OPT PRA ---------------------------------------------------------------- Geolocation-Error r ar o - - o o o o Header field where proxy SUB NOT UPD MSG REF INF PUB ---------------------------------------------------------------- Geolocation-Error r ar o o o o o o o - Table 2: Summary of the Geolocation-Error Header - The Geolocation-Error header field MAY be included in the response + The Geolocation-Error header field MAY be included in any response to one of the above SIP requests, so long as Geolocation was in the request part of the transaction. The choice of which SIP requests are in table 2 above come from which Methods can optionally have the Geolocation header (see section 3.2). - The Geolocation-Error header allows for multiple locationErrorValues - to be returned in the same response. For instance, if a - location-by-reference is sent and the supplied scheme is not desired - or cannot be processed, but more than one other scheme can be, the - 424 response can list more than one code from the 20-22 range in the - response. The UAC can subsequently retry the transaction with one of - the schemes supported or desired by the recipient. - - To illustrate this, here is an example of Alice including - location-by-reference using an HTTP scheme. In this case, Bob - cannot dereference using HTTP, but can dereference using SIP, SIPS, - and PRES. An example of this transaction, with a 424 (Bad Location - Information) response, including a Geolocation-Error header, is in - Figure 1. + Here is an example of a transaction that has a location error. In + this case, Bob responds with a 424 (Bad Location Information) + response, including a Geolocation-Error header, is in Figure 1. Alice Bob | | | Request w/ Location | - | using http scheme | - |----------------------------------->| + |--------------------------------------->| | | | | | 424 (Bad Location Information) | | with Geolocation-Error containing | - | 20 (SIP), 21 (SIPS), 22 (PRES) | - |<-----------------------------------| + | 106 (Incomplete Location Information) | + |<---------------------------------------| | | + Figure 1. Basic Transaction with 424 and Geolocation-Error Header The following subsections provide an initial list of location specific granular codes for any SIP responses, including the new 424 (Bad Location Information) response. If more than one specific Geolocation-Error code is applicable for a response, each MUST be in - the response. Geolocation-Error Code 1 is the generic 'location was - supplied, but not understood' error. If a more specific code - applies, a code 1 is unnecessary. + the response. Geolocation-Error Code 100 is the generic 'location + was supplied, but not understood' error. If a more specific code + applies, a code 100 is unnecessary. -3.4.1 Geolocation-Error Code 1 Location Not Understood +3.4.1 Geolocation-Error Code 100 Location Not Understood - Geolocation-Error code 1 "Location Format not supported" means the + Geolocation-Error code 100 "Location Format not supported" means the location format supplied in the request, by-value or by-reference, was not supported. This code means the recipient understood that location was included in the message, but the format is not supported. Perhaps the format was a freeform text format or data-URL and the recipient only understood location in RFC 4119 PIDF-LO format (civic or x.y(.z) coordinate). This error code applies when a recipient has difficulty parsing the location supplied in the request. - If the format is understood, but not desired, an error code 2 or 3 - MUST be returned in a 424 response, depending on which location - format is desired. The Location Recipient returns an error code 2 or - 3 when it only understands one location format (coordinate or civic) - and did not receive that format. + If the format is understood, but not desired, an error code 101 or + 102 MUST be returned in a 424 response, depending on which location + format is desired. The Location Recipient returns an error code 101 + or 102 when it only understands one location format (coordinate or + civic) and did not receive that format. If a more specific error code is appropriate in a response, - including error code 1 is unnecessary. + including error code 100 is unnecessary. error-text-string: Location format not supported An example usage in a SIP 424 response: - Geolocation-Error: 1 alice.example.com "Location Format not - supported" + Geolocation-Error: 100; "node=bob.example.com"; + "inserter=alice.example.com"; + CAtype=A3; CAtype=STS; + code="Location Format not supported" -3.4.2 Geolocation-Error Code 2 Coordinate-location Format Desired +3.4.2 Geolocation-Error Code 101 Coordinate-location Format Desired - Geolocation-Error code 2 "Coordinate-location Format Desired" means - the location format supplied in the request (probably formatted in - civic), by-value or by-reference, was understood and supported, but - that the recipient, or an application on the recipient, can or - prefers to only process location in the coordinate-location format. + Geolocation-Error code 101 "Coordinate-location Format Desired" + means the location format supplied in the request (probably + formatted in civic), by-value or by-reference, was understood and + supported, but that the recipient, or an application on the + recipient, can or prefers to only process location in the + coordinate-location format. A typical reaction to receiving this code is to resend the original message with location formatted in coordinate instead. error-text-string: Coordinate-location Format Desired An example usage in a SIP 424 response: - Geolocation-Error: 2 node_alice.example.com "Coordinate-location - Format Desired" + Geolocation-Error: 101; "node=bob.example.com"; + "inserter=alice.example.com"; + code="Coordinate-location Format Desired" -3.4.3 Geolocation-Error Code 3 Civic-location Format Desired +3.4.3 Geolocation-Error Code 102 Civic-location Format Desired - Geolocation-Error code 3 "Civic-location Format Desired" means the + Geolocation-Error code 102 "Civic-location Format Desired" means the location format supplied in the request (probably formatted in coordinate), by-value or by-reference, was understood and supported, but that the recipient, or an application on the recipient, can or prefers to only process location in the civic-location format. A typical reaction to receiving this code is to resend the original message with location formatted in civic instead. error-text-string: Civic-location Format Desired An example usage in a SIP 424 response: - Geolocation-Error: 3 alice.example.com "Civic-location Format - Desired" + Geolocation-Error: 102; "node=bob.example.com"; + "inserter=alice.example.com"; + code="Civic-location Format Desired" -3.4.4 Geolocation-Error Code 4 Cannot Parse Location Supplied +3.4.4 Geolocation-Error Code 103 Cannot Parse Location Supplied - Geolocation-Error code 4 "Cannot parse location supplied" means the - location provided, whether by-value or by-reference, in a request is - not well formed. + Geolocation-Error code 103 "Cannot parse location supplied" means + the location provided, whether by-value or by-reference, in a + request is not well formed. error-text-string: Cannot parse location supplied An example usage in a SIP 424 response: - Geolocation-Error: 4 alice.example.com "Cannot parse location - supplied" + Geolocation-Error: 103; "node=bob.example.com"; + "inserter=alice.example.com"; + code="Cannot parse location supplied" -3.4.5 Geolocation-Error Code 5 Cannot Find Location +3.4.5 Geolocation-Error Code 104 Cannot Find Location Information - Geolocation-Error code 5 "Cannot find location" means location was + Geolocation-Error code 104 "Cannot find location" means location was expected in the request, but the recipient cannot find it. This can be either because the cid: pointed to a message body part that is not present in the request, there was no location message body part, or what is dereferenced at the supplied locationURI did not return a PIDF-LO, or location is encrypted/opaque to the recipient. A typical reaction to receiving this code is for the location sender to verify that it has indeed included location information in the request in the properly indicated place and then to send the request again. error-text-string: Cannot find location An example usage in a SIP 424 response: - Geolocation-Error: 5 alice.example.com "Cannot find location" + Geolocation-Error: 104; "node=bob.example.com"; + "inserter=alice.example.com"; + code="Cannot find location" -3.4.6 Geolocation-Error Code 6 Conflicting Locations Supplied +3.4.6 Geolocation-Error Code 105 Conflicting Locations Supplied - Geolocation-Error code 6 "Conflicting Locations Supplied" means a + Geolocation-Error code 105 "Conflicting Locations Supplied" means a Location Recipient received more than one location describing where the Target is, and is either unsure which whole location is true or which parts of multiple locations make up where the Target is. This is generally a case of either too much information, and the information is pointing towards at least two different positions, confusing the recipient. A possible scenario exists in which at least two locations are in the request, perhaps one or more were added by proxies along the @@ -637,101 +720,111 @@ request. A typical reaction to receiving this code is to reduce the number of different locations supplied in the request, if under control by the Target, and send another message to the Location Recipient. error-text-string: Conflicting Locations Supplied An example usage in a SIP 424 response: - Geolocation-Error: 6 alice.example.com "Conflicting Locations - Supplied" + Geolocation-Error: 105; "node=bob.example.com"; + "inserter=alice.example.com"; + code="Conflicting Locations Supplied" -3.4.7 Geolocation-Error Code 7 Incomplete Location Supplied +3.4.7 Geolocation-Error Code 106 Incomplete Location Supplied - Geolocation-Error code 7 "Incomplete Location Supplied" means there - is not enough location information, by-value or retrieved + Geolocation-Error code 106 "Incomplete Location Supplied" means + there is not enough location information, by-value or retrieved by-reference, to determine where the location Target is. Perhaps the coordinate precision is not fine enough, or the civic address lacks the fields to inform the UAS or proxy where the Target is. This might be true for request retargeting, or it might be true for first responder dispatch or pizza delivery (for example, because the street address is missing). A typical reaction to receiving this code is for the location sender to convey more (precise) location information, if doing so is allowed by local policy. error-text-string: Incomplete location supplied An example usage in a SIP 424 response: - Geolocation-Error: 7 alice.example.com "Incomplete location - supplied" + Geolocation-Error: 106; "node=bob.example.com"; + "inserter=alice.example.com"; + code="Incomplete location supplied" -3.4.8 Geolocation-Error Code 8 Cannot Dereference +3.4.8 Geolocation-Error Code 107 Cannot Dereference - Geolocation-Error code 8 "Cannot dereference" means the act of + Geolocation-Error code 107 "Cannot dereference" means the act of dereferencing failed to return the Target's location. This generally means the supplied URI is bad. error-text-string: Cannot dereference An example usage in a SIP 424 response: - Geolocation-Error: 8 alice.example.com "Cannot dereference" + Geolocation-Error: 107; "node=bob.example.com"; + "inserter=alice.example.com"; + code="Cannot dereference" -3.4.9 Geolocation-Error Code 9 Dereference Denied +3.4.9 Geolocation-Error Code 108 Dereference Denied - Geolocation-Error code 9 "Dereference Denied" means there was + Geolocation-Error code 108 "Dereference Denied" means there was insufficient authorization to dereference the Target's location. error-text-string: Dereference Denied An example usage in a SIP 424 response: - Geolocation-Error: 9 alice.example.com "Dereference Denied" + Geolocation-Error: 108; "node=bob.example.com"; + "inserter=alice.example.com"; + code="Dereference Denied" -3.4.10 Geolocation-Error Code 10 Dereference Timeout +3.4.10 Geolocation-Error Code 109 Dereference Timeout - Geolocation-Error code 10 "Dereference Timeout" means the + Geolocation-Error code 109 "Dereference Timeout" means the dereferencing node has not received the Target's location within a reasonable timeframe. error-text-string: Dereference Timeout An example usage in a SIP 424 response: - Geolocation-Error: 10 alice.example.com "Dereference Timeout" + Geolocation-Error: 109; "node=bob.example.com"; + "inserter=alice.example.com"; + code="Dereference Timeout" -3.4.11 Geolocation-Error Code 11 Cannot Process Dereference +3.4.11 Geolocation-Error Code 110 Cannot Process Dereference - Geolocation-Error code 11 "Cannot process Dereference" means the + Geolocation-Error code 110 "Cannot process Dereference" means the dereference protocol has received an overload condition error, indicating the location cannot be accessed at this time. If a SIP or SIPS scheme were used to dereference the Target's location, and a 503 (Service Unavailable) were the response to the dereference query, this Geolocation-Error code 11 would be placed in the 424 (Bad Location Information) response to the location sender. error-text-string: Cannot process Dereference An example usage in a SIP 424 response: - Geolocation-Error: 11 alice.example.com "Cannot process Dereference" + Geolocation-Error: 110; "node=bob.example.com"; + "inserter=alice.example.com"; + code="Cannot process Dereference" -3.4.12 Geolocation-Error Code 20 Unsupported Scheme - SIP desired +3.4.12 Geolocation-Error Code 120 Unsupported Scheme - SIP desired - Geolocation-Error code 20 "Unsupported Scheme - SIP desired" means + Geolocation-Error code 120 "Unsupported Scheme - SIP desired" means the location dereferencer cannot dereference using the location-by-reference URI scheme supplied because it does not support the necessary protocol to do this. This code means the Location Recipient can dereference the Target's location using a SIP-URI scheme. There can be more than one locationErrorValue in a Geolocation-Error header, indicating in this context the recipient can dereference using each scheme protocol included in the Geolocation-Error header. @@ -741,110 +834,143 @@ An exception can be made for emergency calling, preferably after SIPS has been attempted, and failed. A typical reaction to receiving this code would be for the location sender to send a URI with the sip scheme. error-text-string: unsupported scheme - SIP desired An example usage in a SIP 424 response: - Geolocation-Error: 20 alice.example.com "unsupported scheme - SIP - desired" + Geolocation-Error: 120; "node=bob.example.com"; + "inserter=alice.example.com"; + code="unsupported scheme - SIP desired" -3.4.13 Geolocation-Error Code 21 Unsupported Scheme - SIPS desired +3.4.13 Geolocation-Error Code 121 Unsupported Scheme - SIPS desired - Geolocation-Error code 21 "Unsupported Scheme - SIPS desired" means + Geolocation-Error code 121 "Unsupported Scheme - SIPS desired" means the location dereferencer cannot dereference using the location-by-reference URI scheme supplied because it does not support the necessary protocol to do this. This code means the Location Recipient can dereference the Target's location using a SIPS-URI scheme. There can be more than one locationErrorValue in a Geolocation-Error header, indicating in this context the recipient can dereference using each scheme protocol included in the Geolocation-Error header. error-text-string: unsupported scheme - SIPS desired An example usage in a SIP 424 response: - Geolocation-Error: 21 alice.example.com "unsupported scheme - SIPS - desired" + Geolocation-Error: 121; "node=bob.example.com"; + "inserter=alice.example.com"; + code="unsupported scheme - SIPS desired" -3.4.14 Geolocation-Error Code 22 Unsupported Scheme - pres desired +3.4.14 Geolocation-Error Code 122 Unsupported Scheme - pres desired - Geolocation-Error code 22 "Unsupported Scheme - pres desired" means + Geolocation-Error code 122 "Unsupported Scheme - pres desired" means the location dereferencer cannot dereference using the location-by-reference URI scheme supplied because it does not support the necessary protocol to do this. This code means the Location Recipient can dereference the Target's location using a PRES-URI scheme. There can be more than one locationErrorValue in a Geolocation-Error header, indicating in this context the recipient can dereference using each scheme protocol included in the Geolocation-Error header. error-text-string: unsupported scheme - pres desired An example usage in a SIP 424 response: - Geolocation-Error: 22 alice.example.com "unsupported scheme - pres - desired" + Geolocation-Error: 122; "node=bob.example.com"; + "inserter=alice.example.com"; + code="unsupported scheme - pres desired" 3.5 The Geolocation Option Tag This document creates and IANA registers one new option tag: "geolocation". This option tag is to be used, per RFC 3261, in the Require, Supported and Unsupported headers. Whenever a UA wants to indicate support for this SIP extension, the geolocation option tag is included in a Supported header of the SIP message. Including the geolocation option-tag within an Unsupported header of a 420 (Bad Extension) response is appropriate when a UAS does not support this Geolocation extension. A UAC adding this option-tag to a Require header field indicates to a UAS the UAS MUST support this extension in order to continue processing the message, or send a 420 response back to the UAC. - Some environments MAY use a Require header in this way, but it - SHOULD be used with caution to prevent unnecessary communications + Some environments might use a Require header in this way, but it + should be used with caution to prevent unnecessary communications problems. A UAC SHOULD NOT include this option tag in a Proxy-Require header, since a UAC is not likely to understand the topology of the infrastructure, and therefore would not understand which proxy will do the location-based routing function, if any. A potentially bad scenario would have the first proxy not support this extension, but a subsequent proxy does. This would result in no communications past the first proxy, which MUST send the 420 back under these circumstances. 3.6 Using sip/sips/pres as a Dereference Scheme - If a location-by-reference URI is included in a SIP request, in MUST - be in a locationValue in the Geolocation header and it MUST be a - SIP, SIPS or PRES-URI . When PRES: is used, if the resulting + If a location-by-reference (LbyR) URI is included in a SIP request, + it MUST be in a locationValue in the Geolocation header and it MUST + be a SIP, SIPS or PRES-URI . When PRES: is used, if the resulting resolution, per [RFC3856], resolves to a SIP: or SIPS: URI, this section applies. Use of other protocols for dereferencing of a PRES: URI is not defined, and such use is subject to review against RFC 3693 Using Protocol criteria. Dereferencing a Target's location using SIP or SIPS MUST be accomplished by treating the URI as a presence URI and generating a - SUBSCRIBE request to a presence server as per [RFC3856]. The - resulting NOTIFY will contain a PIDF, which MUST contain a PIDF-LO. + SUBSCRIBE request to a presence server as per [RFC3856] using the + 'presence' event package. The resulting NOTIFY will contain a PIDF, + which MUST contain a PIDF-LO. See Figure 2. for a basic message flow + for a dereference. When used in this manner, SIP is a Using Protocol per [RFC3693] and elements receiving location MUST honor the 'usage-element' rules as defined in this extension. + Alice Location Server Bob + | | + | INVITE w/ Location-by-Reference URI | + |-------------------------------------------------------->| + | | | + | 200 (OK) | + |<--------------------------------------------------------| + | | | + | | SUBSCRIBE to LbyR URI | + | |<-----------------------------| + | | 200 (OK) | + | |----------------------------->| + | | | + | | NOTIFY w/ PIDF-LO | + | |----------------------------->| + | | 200 (OK) | + | |<-----------------------------| + | | | + + Figure 2. Location-by-Reference and Dereferencing + In Figure 2., Alice sends Bob her location in a LbyR URI. Bob + receives this LbyR URI in the INVITE and generates a new transaction + (SUBSCRIBE) to retrieve the PIDF-LO of Alice. If accepted, the + PIDF-LO will be in the NOTIFY request from the Location Server. + This is the first instance between Alice and Bob that Alice's + location is in any message, therefore it is sent only once, from the + Location Server to Bob. + A dereference of a location-by-reference URI using SUBSCRIBE is not violating a PIDF-LO 'retransmission-allowed' element value set to 'no', as the NOTIFY is the only message in this multi-message set of transactions that contains the Target's location, with the location recipient being the only SIP element to receive location - which is the purpose of this extension: to convey location to a specific destination. 4. Geolocation Examples @@ -899,33 +1025,33 @@ Content-Type: application/pidf+xml Content-ID: alice123@atlanta.example.com - 2007-07-09T14:00:00Z + 2007-12-02T14:00:00Z 33.001111 -96.68142 no - 2007-07-27T18:00:00Z2007-12-07T18:00:00Z DHCP www.example.com --boundary1-- @@ -963,21 +1089,21 @@ usage. INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com ;branch=z9hG4bK74bf9 Max-Forwards: 70 To: Bob From: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Geolocation: - ;inserted-by=bigbox3.atlanta.example.com ;recipient=server + ;inserted-by=bigbox3.atlanta.example.com ;recipient=both Supported: geolocation Accept: application/sdp, application/pidf+xml CSeq: 31862 INVITE Contact: ...SDP goes here as the only message body A Location Recipient would need to dereference the sips-URI in the Geolocation header field to retrieve Alice's location. If the atlanta.example.com domain chooses to implement location conveyance @@ -1002,51 +1128,62 @@ Possession of a dereferenceable location URI can be equivalent to possession of the location information itself and thus TLS SHOULD be used when transmitting location-by-reference hop-by-hop along the path to the Location Recipient. A PIDF includes identity information. It is possible for the identity in the PIDF to be anonymous. Implementations of this extension should consider the appropriateness of including an anonymous identity in the location information where a real identity is not required. When using location-by-reference, it is - RECOMMENDED that the URI does not contain any identifying + RECOMMENDED that the URI does not contain any user identifying information (for example use 3fg5t5yqw@example.com rather than alice@example.com). Location Recipients MUST obey the privacy and security rules in the PIDF-LO as described in RFC 4119 regarding retransmission and retention. Self-signed certificates SHOULD NOT be used for protecting a PIDF, as the sender does not have a secure identity of the recipient. More than one location format (civic and coordinate) MAY be included in the same message body part, but all location parts of the same PIDF-LO MUST point at the same position on the earth. The same location in multiple formats can allow the recipient to use the most convenient or preferable format for its use. Multiple PIDF-LOs are allowed in the same request, with each allowed to point at separate - positions. + positions - because each PIDF-LO has a Target identifier in it. + Therefore, there will be no confusion by a Location Recipient + receiving more than one PIDF-LO (in a message body or when + dereferenced, or a combination). It is RECOMMENDED there is only one "location" in a single SIP - request. This means SIP servers SHOULD NOT add another - locationValue to a SIP request that already contains location. This - will likely lead to confusion at the ultimate location recipient - because this extension does not provide guidance on what a recipient - is to do with more than one location, nor does it give any - preference regarding which location is better or worse than another - location in the same request. + Request for a given Target. This means SIP servers SHOULD NOT add + another locationValue to a SIP request that already contains + location. This will likely lead to confusion at the ultimate + location recipient because this extension does not provide guidance + on what a recipient is to do with more than one location, nor does + it give any preference regarding which location is better or worse + than another location in the same request. + + It is allowed, but NOT RECOMMENDED, for more than one SIP element to + insert location into a request along its path. As described earlier + in this document, each insertion of location into a SIP request is + accompanied by a locationValue in a Geolocation header. Also + described earlier, each locationValue MUST contain an "inserted-by=" + value indicated to a Location Recipient which host inserted location + into a particular request. 5.1 UAC Behavior - A UAC can send location in a SIP request, because it was requested, + A UAC can send location in a SIP request, because it is expected to facilitate location-based routing of the request, or spontaneously (i.e., a purpose not defined in this document but known to the UAC). A UAC conveying location MUST include a locationValue in a Geolocation header (see section 3.2) with either a location-by-value indication (a cid-URL), or a location-by-reference indication (a dereferenceable URI). A location-by-value message body sent without a Geolocation header field MUST NOT occur. The UAC supporting this extension MUST include a Supported header with the geolocation @@ -1083,161 +1220,253 @@ The UAC MAY include an intended target of this location parameter by adding the "recipient=" parameter to the locationValue like this: Geolocation: ; inserted-by=alice@atlanta.example.com; recipient=endpoint See section 3.2 for further details about all the header parameters of a locationValue. + A UAC MAY SUBSCRIBE to a LbyR URI, using the 'presence' event + package, for its own location. The obvious reason for this is for + the UAC to have its LbyV local to it. This document does not give a + reason why a UAC would want to do this. + +5.1.1 UAC Receiving a Location Failure Indication + If a sent request failed based on the location in the original - request, a 424 (Bad Location Information) response is sent. The UAC - should receive a Geolocation-Error header in any response message. - The Geolocation-Error has a header parameter indicating which entity - inserted the location pertaining to this error. This is in the form - of a host-id. A UAC receiving this 424 should review this - "inserter=" locationErrorValue parameter to see if it indicates this - UAC. If it does not, the 424 should be ignored. If this value - does, 424 is intended for this UAC, and MUST process the response, - including the Geolocation-Error code (defined in section 3.4). The - UAC SHOULD take correct steps to rectify future errors, based on the - received error code, to increase the possibility of less request - failures going forward. A UAC MAY reattempt a new request if it - believes it can correct the stated failure in the Geolocation-Error - header. + request, a 424 (Bad Location Information) response is sent back to + the UAC. The 424 MUST have a Geolocation-Error header containing + one or more locationErrorValues in the response message. A + locationErrorValue has a header parameter indicating which entity + inserted the location pertaining to this error, called the + "inserter=" parameter. This "inserter=" parameter is copied from + the "inserted-by=" parameter of the locationValue by the UAS or + proxy sending the error response. A UAC receiving this 424 should + review this "inserter=" parameter in the locationErrorValue to see + if it indicates this UAC. If locationErrorValue does not, the + locationErrorValue should be ignored, and the response SHOULD be + treated as a 4XX response. If locationErrorValue does indicate this + UAC, this UAC MUST process the response, including the + Geolocation-Error code (defined in section 3.4). + + In addition to the error code, there MAY be a list of CAtypes in the + locationErrorValue. If there are any, these are what the UAS or + proxy determined was wrong with the location contained in the + original response. The listed CAtypes will not contain the values + sent by the UAC in the request. This is for security/privacy + reasons. + + The UAC SHOULD take correct steps to rectify future errors, based on + the received error code and any CAtypes listed, to increase the + probability of successful requests in the future. A UAC MAY + reattempt a new request if it believes it can correct the stated + failure in the Geolocation-Error header. Any UAC that inserted location into a request should be prepared to receive the Geolocation-Error header in any response, looking to determine if the header is meant for the UAC, and to react accordingly. + If a UAC includes location in a request, and either the UAS does not + determine errored location was critical to the transaction and + accept the request, or the request failed for another reason than + location, any response MAY contain a Geolocation-Error header + containing a locationErrorValue with the details of the location + error. + 5.2 UAS Behavior If the Geolocation header field is present in a received SIP request, the type of URI contained in the locationValue will indicate if location has been conveyed by-value in a message body (part) or by-reference, requiring an additional dereference transaction. If the by-reference URI is sip:, sips: or pres:, the UAS MUST initiate a SUBSCRIBE to the URI provided to retrieve the PIDF-LO being conveyed by the UAC per [RFC3856]. If successful, the - PIDF-LO will be returned in the NOTIFY request from the server. + PIDF-LO will be returned in the NOTIFY request from the remote host. A Require header with the geolocation option tag indicates the - UAC is requiring the UAS to understand this extension or else send + UAC is requiring the UAS understand this extension or else send an error response. A 420 (Bad Extension) with a geolocation option - tag in a Unsupported header would be the appropriate response in + tag in an Unsupported header would be the appropriate response in this case. - In the undesired situation in which location is conveyed without a - Geolocation header, that contains the URI of where the location is, - the UAS MUST be able to read a location-by-value message body. A - Location-by-reference URI MUST NOT be placed in any other SIP header - than Geolocation. - - If the UAC conveys location in a request, but the UAS has one or - more problems with each location in the request (or while attempting - to dereference the UAC's location), the UAS MUST indicate what - problem was experienced with the location in the request. A - Geolocation-Error header is how the UAS informs the UAC of a - location-based error within the request. Section 3.4 lists these - errors, which are all IANA registered. - - The Geolocation-Error header is permitted in any response. For - example, Bob can reply to Alice with a 486 because he's not willing - to accept the call at this time, and inform Alice that the location - contained in the request was bad in some way. In this case, the 486 - would contain a Geolocation-Error header indicating the specific - location error experienced - - If the request had a Require header with a geolocation option-tag, - then a 424 (Bad Location Information) response would be an - appropriate response. This 424 would include a locationErrorValue - in a Geolocation-Error header. - - Because this extension allows more than one locationValue, - potentially from more than SIP entity, there needs to be a means of - identifying which entity inserted a particular locationValue for - error response purposes. Also, there needs to be a means to inform - that entity what the Location Recipient considered in error with - that locationValue. + It is possible, but undesirable, for a message to arrive with a body + containing a location-by-value, but with no Geolocation header field + value pointing to it (potentially no Geolocation header field at + all). In this case, the recipient MAY still read and use the message + body. Unless stated otherwise by future standards-track + publications, a Location-by-reference URI only has meaning within + the Geolocation header field and MUST NOT appear in any other SIP + header field. - If a Geolocation locationValue is present in a request, it can - contain as many as three header parameters, "inserted-by=", - "used-for-routing" and "recipient=" parameters. + There are 3 Geolocation header parameters, - The "inserted-by" parameter in the locationValue of the request that - had errors in it is copied into the "inserter=" parameter of the - locationErrorValue of the Geolocation-Error header of the response. - This SHOULD happen for each location that was considered bad by the - UAS to ensure each location inserter understands which error code(s) - is intended for them. + o "inserted-by=" + o "used-for-routing" + o "recipient=" - Further, more than one error code is allowed in the - locationErrorValue - each having an "inserter=" parameter. The - error codes destined for the same inserter MUST NOT contradict the - meaning of the problem the UAS had with a particular locationValue. + The "inserted-by=" parameter informs a Location Recipient which SIP + element added this locationValue to the SIP request. This parameter + is mandatory for each locationValue in the request. The value in + the "inserted-by=" parameter is copied into the "inserter=" + parameter in each locationErrorValue if there is an error in the + location to be reported back to the location sender. See section + 5.2.1. - If a locationValue contains the "inserted-by=" parameter, the - recipient will learn the SIP entity who added that locationValue. + The "used-for-routing" parameter is included in the locationValue if + a SIP server used the location in the request to determine how to + route or forward the message towards the ultimate destination. If + there are more than one locationValue in the Geolocation header, and + it is possible that different locationValues were used to route the + message at different times of this request's journey. This is + allowed, as it is consistent with the rule that anytime a message is + routed based upon a locationValue, a "used-for-routing" parameter is + added to the applicable locationValue. This parameter should be + present in each locationValue used along the path. - If a Geolocation locationValue contains the "used-for-routing" - parameter, the UAS will learn which location was used to retarget - this request towards this UAS. This parameter MAY be present in - each locationValue within the Geolocation header (meaning up to one - per locationValue). locationValues are placed into the Geolocation - header in an order. The location inserted first, remains first in - the header. A subsequence locationValue is placed next in the - header (and so on). The last locationValue in the header was the - most recently added locationValue to the request. From this - order, the more recent "used-for-routing" parameter, if present, was - the locationValue used for retargeting this request at this UAS. In - this case, a "used-for-routing" parameter on a previous - locationValue should be ignored, except perhaps in the case of - after-the-fact analysis of how a request took the whole path it - took. + More than one locationValue inserted in a request should be placed + the order it was placed, and not rearranged. This informs a + Location Recipient which was the last locationValue in the message + that was used to route the message. This is for troubleshooting and + management reasons. The "recipient=" header parameter allow recipients to infer the SIP entity type this locationValue is intended to be for. The types are "endpoint", meaning the ultimate destination UAS; "routing-entity", meaning SIP servers; and "both" meaning this locationValue is to be viewed by both types of SIP entities. - If there are any header parameters in a received locationValue, - they MUST NOT be modified or deleted in transit to the ultimate - destination. + Individual header parameters in any received locationValue MUST NOT + be modified or deleted in transit to the ultimate destination. + + A UAS MUST NOT send location in a response message, as there can be + any number of issues/problems with receiving location, and the UAC + or proxy servers cannot error a response. Therefore, the UAS, if it + wants to send a UAC its location, SHOULD do so in a new request in a + separate transaction. This document gives no guidance which SIP + request to use. + + A UAS MAY include a geolocation option-tag in the Supported header + of a response, indicating it does understand this extension, even if + location was not in a request to the UAS. + + A UAS wishing to dereference a location-by-reference URI contained + in a received request will use the 'presence' event package in a + SUBSCRIBE request to the URI. If accepted, the PIDF-LO will return + to the UAS in a NOTIFY request. If there are any errors during + dereferencing, or in the PIDF-LO itself, the UAS will error the + original request to the UAC with a locationErrorValue indicating + what the UAS concluded was wrong with the location. This is to + include any dereferencing problems encountered. + +5.2.1 UAS Generating a Location Failure Indication + + If a received request conveys location, but the UAS has one or + more problems with a locationValue in the request (to include while + attempting to dereference the UAC's location), the UAS MUST indicate + each problem experienced with the location in the request in a + 424 (Bad Location Information) response back to the inserting + entity if the UAS wants to reject the request because of the + location. A Geolocation-Error header is how the UAS informs the UAC + of a location-based error within the request. Section 3.4 lists + these errors, which are all IANA registered. + + Because this extension to SIP allows more than one locationValue in + a Geolocation header, each from separate SIP entities, there + needs to be a means of identifying which entity inserted a + particular locationValue for single error response purposes. This + is further complicated because SIP sends a single rejection + response, that in this case, needs to go to more than one entity, + and be ignored by all other entities not identified in such a way as + to not confuse other SIP entities. + + Each locationValue has an "inserted-by=" parameter identifying which + SIP entity added this locationValue to the request. This value is + copied to the locationErrorValue "inserter=" parameter if one needs + to be sent, thus identifying the intended target of this + locationErrorValue. This locationErrorValue is ignored by all other + receivers of this SIP response. + + Each locationErrorValue can have more than one error code within it. + Each locationErrorValue is destined for one "inserter=" entity. + This gives a UAS one mechanism to tell each inserter what the + Location Recipient concluded was wrong with what the inserter + included (as far as location is concerned). Therefore, + + o there MUST be a locationErrorValue for each locationValue that + was considered bad by the UAS to ensure each upstream location + inserter understands which error code(s)is intended for them (and + which to ignore). + + o if the PIDF-LO (received by-value or after dereference) contains + civic CAtypes that the Location Recipient considers malformed or + bad, each CAtype SHOULD be listed in the locationErrorValue to + inform the "inserter=" entity what specifically was wrong with + the locationValue, in addition to the error code. Without these + details, the location inserter might not know what part was + malformed or incomplete about the information supplied in the + request. + + o the CAtype values MUST NOT be sent along with the CAtype names + listed in the locationErrorValue. This is for privacy/security + reasons. + + o there MUST NOT be more than one locationErrorValue in the + response per locationValue in the request. + + o there MUST NOT be more than one locationErrorValue in the + response for the same locationValue in the request. + + o there MUST NOT be a locationErrorValue in the response for a + locationValue in the request that was not in error, according to + the Location Recipient. + + Here is an example of a Geolocation-Error header + + Geolocation-Error: 106; "node=bob.example.com"; + "inserter=alice.example.com"; + CAtype=A3; CAtype=STS; + code="incomplete location supplied" + + See Section 3.4 for further rules about the Geolocation-Error header + and the locationErrorValue. + + The Geolocation-Error header is permitted in any response. For + example, Bob can reply to Alice with a 486 because he's not willing + to accept the call at this time, and inform Alice that the location + contained in the request was bad in some way. In this case, the 486 + would contain a Geolocation-Error header indicating the specific + location error experienced If there is more than one locationValue in a request, and any one of them is valid (i.e., one contains enough information to not generate a 424 if that was the only location present in the request), all other locations MAY be ignored, and a 424 MUST NOT be sent because of these other locations in the request. Another response MAY be sent, which includes a locationErrorValue. This document says nothing about what a Location Recipient does with more than one 'good' location in a request (i.e., which to choose to use). + Further, more than one error code is allowed in the + locationErrorValue - each having an "inserter=" parameter. The + error codes destined for the same inserter MUST NOT contradict the + meaning of the problem the UAS had with a particular locationValue. + A Geolocation-Error is permissible in a 200 OK response. This means everything else in the request was acceptable, but the location was not for a given error code(s). One exception to this set of rules is if a geolocation option-tag was in the Require header in the request. This would necessitate a 424 response. - A UAS MUST NOT send location in a response message, as there can be - any number of issues/problems with receiving location, and the UAC - or proxy servers cannot error a response. Therefore, the UAS, if it - wants to send a UAC its location, SHOULD do so in a new request in a - separate transaction. This document give no guidance which request - to use. - - A UAS MAY include a geolocation option-tag in the Supported header - of a response, indicating if does understand this extension. - 5.3 Proxy Behavior [RFC3261] states message bodies cannot be added by proxies. However, proxies are permitted to add a header to a request. This implies that a proxy can add a Geolocation locationValue with location-by-reference URI, but not location-by-value message body. However, if location is already in a SIP request, a SIP server SHOULD NOT add another instance of the UAC's location to the same request. This will likely cause confusion at the Location Recipient as to which to use. This document gives no guidance how a UAS is to @@ -1250,113 +1479,128 @@ A proxy is permitted to read any locationValue, and the associated body, if not S/MIME protected, in transit if present, and MUST use the contents of the header field to make location-based retargeting decisions, if retargeting requests based on location is a function of that proxy. More than one Geolocation locationValue in a message is permitted, but can cause confusion at the recipient. If a proxy chooses to add a locationValue to a Geolocation header, which would be a local policy decision, the new locationValue MUST be added to the end of - the header (after previous locationValue(s)). This to create an - order of insertion of locationValues along the path. Proxies MUST - NOT modify the order of locationValues in a geolocation header. + the header (after previous locationValue(s)). This is done to + create an order of insertion of locationValues along the path. + Proxies MUST NOT modify the order of locationValues in a geolocation + header. + + A proxy wishing to dereference a location-by-reference URI contained + in a received request will use the 'presence' event package in a + SUBSCRIBE request to the URI. If accepted, the PIDF-LO will return + to the proxy in a NOTIFY request. If there are any errors during + dereferencing, or in the PIDF-LO itself, the proxy will error the + original request to the UAC with a locationErrorValue indicating + what the proxy concluded was wrong with the location. This is to + include any dereferencing problems encountered. 5.3.1 Proxy Behavior with Geolocation Header Parameters SIP servers MUST NOT delete any existing Geolocation locationValue (URI or header parameter) from a request. A Geolocation locationValue (URI or header parameter) MAY only be modified to by adding a "used-for-routing" parameter to an existing locationValue, if the request was retargeted based on the location within that locationValue. Further modification of this Geolocation header field MUST NOT occur. For example, an existing Geolocation locationValue in a request of: Geolocation: ; inserted-by=alice123@atlanta.example.com; can be modified by a proxy to add the "used-for-routing" parameter, like this: Geolocation: ; - inserted-by=alice@atlanta.example.com; + inserted-by=alice123@atlanta.example.com; used-for-routing if this is the locationValue the proxy used to make a retargeting decision based upon, but make no other modification. A SIP server MAY add a new Geolocation locationValue to a SIP request. The proxy SHOULD NOT insert a locationValue of the UAC unless it is reasonably certain it knows the actual location of the endpoint, for example, if it thoroughly understands the topology of the underlying access network and it can identify the device reliably (in the presence of, for example, NAT). - B2BUAs MUST set the "inserted-by" header parameter with their - Host-ID. This is for error mapping reasons. - A server adding a locationValue to an existing Geolocation header would look like: Geolocation: ; - inserted-by=alice@atlanta.example.com, + inserted-by=alice123@atlanta.example.com, ; inserted-by=lis1.atlanta.example.com; Notice the locationValue added by the proxy is last among locationValues. This practice MUST be done for all added locationValues. If this request was then retargeted by an intermediary using the locationValue inserted by the server, the intermediary would add a "used-for-routing" parameter like this: Geolocation: ; - inserted-by=alice@atlanta.example.com, + inserted-by=alice123@atlanta.example.com, ; inserted-by=lis1.atlanta.example.com; used-for-routing It is conceivable that an initial routing decision is made on an one locationValue, and subsequently another routing decision is made on a different locationValue. This retargeting decision can be made on a newly inserted locationValue. While unusual, it can occur. In such a case, proxies MUST NOT remove any existing "used-for-routing" header parameter. In this instance, the SIP server retargeting based on another locationValue MUST add the "used-for-routing" header parameter to the locationValue used for retargeting by this server. This will result in a Geolocation header looking as if it were retargeting more than once, which would be true - and is the desired outcome. -5.3.2 Proxy Error Behavior with Geolocation-Error Codes +5.3.2 Proxy Error Behavior for Sending or Receiving locationErrorValues - If a proxy determines there is an error within an existing - locationValue, the proxy SHOULD provide a suitable error response. - The 424 (Bad Location Information) is the appropriate location-based - error response here. The 424 MUST contain a Geolocation-Error - header (see section 3.4). If a proxy errors a request for some - other reason than location, and there is a location error also in - the request, the Geolocation-Error (see section 3.4) SHOULD be added - to the response, to inform the UAC of all the errors in the request. + For proxies that receive a SIP request that contains a location + error, either in a contained message body or after the proxy does a + dereference of the LbyR URI, all the rules applicable to a UAS apply + here (see Section 5.2.1.), since in this case, the proxy is + considered a Location Recipient. Therefore, there is no reason to + restate them here, and potentially have the two section be + inconsistent. The one thing to add is that a proxy does not need to + examine location contained in a request. Section 5.2.1. only applies + to proxies that are monitoring or policing location within requests + (for whatever reason). - The proxy making the error decision copies the host-id value from - the "inserted-by=" locationValue of the Geolocation header into the - host-id value of the "inserter=" locationErrorValue of the - Geolocation-Error header. This ensures the error is targeted at the - entity that inserted the bad location. More than one error can be - present for each locationValue. These error are in the - locationErrorValue of the response. Each locationErrorValue will - have one "inserter=" value. Thus, the number of locationErrorValues - in a response cannot exceed the number of locationValues in the - request - all within the same transaction. This ensures each error - type is received properly by the offending location inserter. + If a proxy inserted a locationValue into a request, it SHOULD be + ready to examine the response to that request, in case there is one + or more location errors in the response. To a great degree, this + scenario has the proxy behaving as a UAC (see section 5.1.1.) that + included a locationValue a request, which then receives an error to + that locationValue. + + If there is one or more locationErrorValues in the response, the + proxy SHOULD examine each "inserter=" parameter in each + locationErrorValue - looking for one that identifies the proxy. If + one matches the proxy's "inserted-by" value, that locationErrorValue + is for only that proxy. This locationErrorValue needs to be reviewed + for each error code and CAtype contained in the value. The proxy + SHOULD attempt to correct for the error reported to it for future + insertion of location into requests. This document gives no + guidance what the proxy should do to rectify the bad location + information, but a future document MAY address this. 6. Geopriv Privacy Considerations Transmitting location information is considered by most to be highly sensitive information, requiring protection from eavesdropping, tracking, and altering in transit. [RFC3693] articulates rules to be followed by any protocol wishing to be considered a Geopriv "Using Protocol", specifying how a transport protocol meetings those rules. This section describes how SIP as a Using Protocol meets those requirements. @@ -1406,23 +1650,23 @@ mechanism such as S/MIME is problematic, because one or more proxies on the path need the ability to read the location information to retarget the message to the appropriate new destination UAS. Securing the location hop-by-hop, using TLS, protects the message from eavesdropping and modification, but exposes the information to all proxies on the path as well as the endpoint. In most cases, the UAC does not know the identity of the proxy or proxies providing location-based routing services, so that end-to-middle solutions might not be appropriate either. - These same issue exist for basic SIP signaling, but SIP normally + These same issues exist for basic SIP signaling, but SIP normally does not carry information to physically track a user; making this - extension especially sensitive, unfortunately. + extension especially sensitive. When location is inserted by a UAC, which is RECOMMENDED, it can decide whether to reveal its location using hop-by-hop methods. UAC implementations MUST make such capabilities conditional on explicit user permission, and SHOULD alert a user that location is being conveyed. Proxies inserting location for location-based routing are unable to meet this requirement, and such use is NOT RECOMMENDED. Proxies conveying location using this extension MUST have the permission of the Target to do so. @@ -1438,56 +1682,56 @@ Consider, specifically, a nomadic user connected to an access network in a hotel. The UAC has no way to provide a credential acceptable to the hotel Location Server (LS) to any of its intended Location Recipients. The recipient of a reference does not know if a reference has appropriate authorization policies or not. The LS should provide location to any requestor. Accordingly, possession of the reference should be considered equivalent to possession of the value, and the reference should be treated with the same degree of care as the value. Specifically, - TLS MUST be used to protect the security of the reference. + TLS MUST be used to protect the security of the reference. Notice + that this does not constrain the dereference protocol to use TLS. + That specification is left entirely to the dereferencing protocol Because SIP servers can add location in transit, made more easy of the server is a Session Border Controller or B2BUA, this might cause there to be conflicting location information (error-code=6), which could be purposeful to error the request or just cause operation problems. This problem might be inadvertent, compounded by the fact that there will likely be some SIP servers that add location on every call set-up. There is no integrity on any locationValue or locationErrorValue header parameter, so recipients of either header need to implicitly trust the header contents, and take whatever precautions each entity deems appropriate give these facts. 8. IANA Considerations The following are the IANA considerations made by this SIP extension. Modifications and additions to these registrations - require a standards track RFC. + require a standards track RFC (Standards Action). 8.1 IANA Registration for the SIP Geolocation Header The SIP Geolocation header is created by this document, with its definition and rules in Section 3.2 of this document, to be added to the sip-parameters. The Geolocation Header has the following header parameters to be Registered in a new table: Geolocation Header parameters Header Parameters Parameter-values Reference ---------------- ---------------- -------------- - inserted-by (string) RFC XXXX (this document) - used-for-routing N/A RFC XXXX (this document) recipient endpoint RFC XXXX (this document) recipient routing-entity RFC XXXX (this document) recipient both RFC XXXX (this document) 8.2 IANA Registration for New SIP Option Tag The SIP option-tag "geolocation" is created by this document, with the definition and rule in Section 3.5 of this document, to be added to sip-parameters within IANA. @@ -1513,96 +1757,97 @@ document. Geolocation-Error codes ----------------------- Geolocation-Error codes provide reason for the error discovered by Location Recipients, to place into SIP response messages to inform the location inserter of the error. Code Description Reference ---- --------------------------------------------------- --------- - 1 Location Format Not Supported: the location format [this doc] + 100 Location Format Not Supported: the location format [this doc] supplied in the request, by-value or by-reference, was not supported. - 2 Coordinate-location Format Desired: the location [this doc] + 101 Coordinate-location Format Desired: the location [this doc] format supplied in the request was understood and supported, but that the recipient, or an application on the recipient, can or prefers to only process location in the coordinate-location format. - 3 Civic-location Format Desired: the location [this doc] + 102 Civic-location Format Desired: the location [this doc] format supplied in the request was understood and supported, but that the recipient, or an application on the recipient, can or prefers to only process location in the civic-location format. - 4 Cannot Parse Location Supplied: the location [this doc] + 103 Cannot Parse Location Supplied: the location [this doc] provided, whether by-value or by-reference, in a request is not well formed. - 5 Cannot Find Location: the location was expected in [this doc] + 104 Cannot Find Location: the location was expected in [this doc] the request, but the recipient cannot find it. - 6 Conflicting Locations Supplied: a Location Recipient [this doc] + 105 Conflicting Locations Supplied: a Location Recipient [this doc] received more than one location describing where the Target is, and is either unsure which whole location is true or which parts of multiple locations make up where the Target is. - 7 Incomplete Location Supplied: there is not enough [this doc] + 106 Incomplete Location Supplied: there is not enough [this doc] location information in the request to determine where the location Target is. - 8 Cannot Dereference: the act of dereferencing failed [this doc] + 107 Cannot Dereference: the act of dereferencing failed [this doc] to return the Target's location. This generally means the supplied URI is bad. - 9 Dereference Denied: there was insufficient [this doc] + 108 Dereference Denied: there was insufficient [this doc] authorization to dereference the Target's location. - 10 Dereference Timeout: the dereferencing node has not [this doc] + 109 Dereference Timeout: the dereferencing node has not [this doc] received the Target's location within a reasonable. - timeframe - 11 Cannot Process Dereference: the dereference protocol [this doc] + 110 Cannot Process Dereference: the dereference protocol [this doc] has received an overload condition error, indicating the location cannot be accessed at this time. - 20 Unsupported Scheme - sip desired: the location [this doc] + 120 Unsupported Scheme - sip desired: the location [this doc] dereferencer cannot dereference using the location-by-reference URI scheme supplied, and prefers a sip-uri. - 21 Unsupported Scheme - sips desired: the location [this doc] + 121 Unsupported Scheme - sips desired: the location [this doc] dereferencer cannot dereference using the location-by-reference URI scheme supplied, and prefers a sips-uri. - 22 Unsupported Scheme - pres desired: the location [this doc] + 122 Unsupported Scheme - pres desired: the location [this doc] dereferencer cannot dereference using the location-by-reference URI scheme supplied, and prefers a pres-uri. 9. Acknowledgements To Dave Oran for helping to shape this idea. To Jon Peterson and Dean Willis on guidance of the effort. To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, Mike Hammer, Paul Kyzivat, - Shida Shubert, Umesh Sharma, Richard Barnes, Ted Hardie, Robert - Sparks and Matt Lepinski for constructive feedback. A special - thanks to Dan Wing for help with the S/MIME example. + Shida Shubert, Umesh Sharma, Richard Barnes, Ted Hardie and Matt + Lepinski for constructive feedback. A special thanks to Dan Wing + for help with the S/MIME example, and to Robert Sparks for many + helpful comments and the proper building of the Geolocation-Error + header. 10. References 10.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. [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object @@ -1626,20 +1869,27 @@ [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging" , RFC 3428, December 2002 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. + [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of + Provisional Responses in Session Initiation Protocol (SIP)", + RFC 3262, June 2002. + + [IANA-civic] http://www.iana.org/assignments/civic-address-types- + registry + 10.2 References - Informative [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, "Geopriv Requirements", RFC 3693, February 2004 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information ", draft-ietf-geopriv-dhcp-civil-09, "work in @@ -1703,20 +1954,26 @@ UAC-8 The PIDF-LO [RFC 4119] is a mandatory to implement format for location conveyance within SIP, whether included by-value or by-reference. Motivation: interoperability with other IETF location protocols and mechanisms UAC-9 There must be a mechanism for the UAC to request the UAS send its location + + UAC-9 has been DEPRECATED by the SIP WG, due to the many + problems this requirement would have caused if implemented. + The solution is for the above UAS to send a new request to + the original UAC with the UAS's location. + UAC-10 There must be a mechanism to differentiate the ability of the UAC to convey location from the UACs lack of knowledge of its location Motivation: Failure to receive location when it is expected can be because the UAC does not implement this extension, or it can be that the UAC implements the extension, but does not know where it is. This may be, for example, due to the failure of the access network to provide a location acquisition mechanisms the UAC understands. These cases must be @@ -1726,20 +1983,25 @@ along the path. Motivation: Location-based routing. A.2 Requirements for a UAS Receiving Location The following are the requirements for location conveyance by a UAS: UAS-1 SIP Responses must support location conveyance. + Just as with UAC-9, UAS-1 has been DEPRECATED by the SIP WG, + due to the many problems this requirement would have caused + if implemented. The solution is for the above UAS to send a + new request to the original UAC with the UAS's location. + UAS-2 There must be a unique 4XX response informing the UAC it did not provide applicable location information. In addition, requirements UAC-5, 6, 7 and 8 apply to the UAS A.3 Requirements for SIP Proxies and Intermediaries The following are the requirements for location conveyance by a SIP proxies and intermediaries: @@ -1841,45 +2102,46 @@ --boundary1-- Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + This document and the information contained herein are provided on + an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE + IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL + WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY + WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE + ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS + FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology described + in this document or the extent to which any license under such + rights might or might not be available; nor does it represent that + it has made any independent effort to identify any such rights. + Information on the procedures with respect to rights in RFC + documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF