Subject: [sipcore] Proposed location conveyance changes

From: Adam Roach <[email-masked]>
Date: Tue, 01 Feb 2011 18:34:09 -0600

[as chair]

As a follow up from last-week's ad-hoc call on the topic of location 
conveyance, the authors have proposed the following technical changes 
(along with several editorial changes). Please review and comment as 
soon as possible. If there are no objections, the document will updated 
accordingly on or after Thursday of this week.

Full proposed diffs can be viewed at http://ln-s.net/8T6P and 
http://ln-s.net/8T6Q

In section 3.2:

    *The example given in this section is only illustrative, not
    normative. In particular, applications can choose to dereference a
    location URI at any time, possibly several times, or potentially not
    at all. Applications receiving a Location URI in a SIP transaction
    need to be mindful of SIP's transaction timers. In particular, if
    the means of dereferencing the Location URI might take longer than
    the SIP transaction timeout (Timer C for INVITE transactions, Timer
    F for non-INVITE transactions), then it needs to rely on mechanisms
    other than the transaction's response code to convey location
    errors, if returning such errors are necessary.*

In section 4.3:

*    A SIP intermediary that requires Alice's location in order to
    properly process Alice's INVITE also sends a 424 with a
    Geolocation-Error code. This message flow is shown in Figure 4 of
    Section 3.4.

    If more than one locationValue is present in the SIP request and
    determined to be valid by the LR, the location in that SIP request
    MUST be considered good as far as location is concerned, and no
    Geolocation-Error is sent. This is a compromise of complexity vs.
    accurate information conveyance with respect to informing each
    location inserter of every bad location. We have gone through the
    exercise of getting this correct for every scenario, and deemed it
    not worth the excruciating effort involved.

    Here is an initial list of location based error ranges for any SIP*
    non-100 response, including the new 424  (Bad Location Information)
    response.  These error codes are divided into 4 categories, based on
    how the response receiver should react to these errors.*There can
    only be one Geolocation-Error code in a SIP response, regardless of
    how many locationValues there are in the correlating SIP request.
    There is no guidance given in this document as to which
    locationValue is formally errored (when more than one was present);
    meaning that, somehow not defined here, the LR just picks one to
    error.*

    o  1XX errors mean the LR cannot process the location within the
       request.

    o  2XX errors mean the LR wants
       *request

       A non-exclusive list of reasons for returning a 1XX is

       -*  theLS to send new  *location was not present*  orupdated  *could not be found,
       - there was not enough*  locationinformation, perhaps with a delay associated with when  *information*  tosend  *determine
         where*  therequest.  *Target was,
       - the location information was corrupted or known to be
         inaccurate,
       - etc...*

    o3XX   *2XX*  errors mean some specific permission is necessary to process
       the included location information.

    o4XX   *3XX*  errors mean there was trouble dereferencing the Location URI
       sent.

    *It should be noted that for non-INVITE transactions, the SIP
    response will likely be sent before the dereference response has
    been received. At this time, this document does not alter that SIP
    protocol reality. This means that any non-INVITE response to a
    request containing location SHOULD NOT consider a 200 OK to mean the
    act of dereferencing has concluded and the dereferencer (i.e., the
    LR) has successfully parsed the PIDF-LO for errors and found none.
    This was first brought up in Section 3.2.

    Additionally, if a SIP entity cannot or chooses not to process
    location or the SIP request containing location, the existing
    mechanism of responding with a 503 (Service Unavailable) SHOULD be
    used with or without a configurable Retry-After header field. There
    is no special location error code for what already exists within SIP
    today.*

    Within these4  *3*  number ranges, there is a top level error as follows:

    Geolocation-Error: 100 "Cannot Process Location"

    Geolocation-Error: 200"Retry Location Later with device updated
                            location"

    Geolocation-Error: 300  "Permission To Use Location Information"

    Geolocation-Error:400  *300*  "Dereference Failure"

    There are two specific Geolocation-Error codes necessary to include
    in this document, both have to do with permissions necessary to
    process the SIP request; they are

    Geolocation-Error:301  *201*  "Permission To Retransmit Location
                            Information to a Third Party"

    This location error is specific to having the Presence Information
    Data Format (PIDF-LO) [RFC4119]<retransmission-allowed>  element set
    to "=no". This location error is stating it requires permission
    (i.e., PIDF-LO<retransmission-allowed>  element set to "=yes") to
    process this SIP request further.  If the LS sending the location
    information does not want to give this permission, it will not reset
    this permission in a new request. If the LS wants this message
    processed without this permission reset, it MUST choose another
    logical path (if oneexists).  *exists) for this SIP request.*

    Geolocation-Error:302  *202*  "Permission to Route based on Location
                            Information"

    This location error is specific to having the locationValue header
    parameter<routing-allowed>  set to "=no". This location error is
    stating it requires permission (i.e., a<routing-allowed>  set to
    "=yes") to process this SIP request further.  If the LS sending the
    location information does not want to give this permission, it will
    not reset this permission in a new request. If the LS wants this
    message processed without this permission reset, it MUST choose
    another logical path (if oneexists).  *exists) for this SIP request.*

New section 4.5 (previously 4.6):

*4.5*  LocationURIs Allowed  *Profile Negotiation*

    The following is part of the discussion started in Section 3, Figure
    2, which introduced the concept of sending location indirectly.

    If a location URI is included in a SIP request,it SHOULD be  *the sending user
    agent MUST also include*  aSIP-,
    SIPS- or PRES-URI.  When PRES: is used, as  *Supported header field indicating which
    location profiles it supports. Two option tags for location profiles
    are*  defined*by this document: "geolocation-sip" and
    "geolocation-http". Future specifications may define further
    location profiles per the IANA policy described*  in[RFC3856], if  *Section 8.2.

    The "geolocation-sip" option tag signals support for acquiring
    location information via*  the*presence event package of SIP
    ([RFC3856]). A location recipient who supports this option can send
    a SUBSCRIBE request and parse a*  resultingresolution resolves to  *NOTIFY containing*  aSIP: or SIPS: URI,
    *PIDF-LO object. The URI schemes supported by*  this
    section applies.  These  *option include
    "sip", "sips" and "pres".

    The "geolocation-http" option tag signals support for acquiring
    location information via an HTTP ([RFC2616]). A location recipient
    who supports this option can request location with an HTTP GET and
    parse a resulting 200 response containing a PIDF-LO object. The URI*
    schemesMUST be implemented according to  *supported by*  thisdocument.  *option include "http" and "https". A
    failure to parse the 200 response, for whatever reason, will return
    a "Dereference Failure" indication to the original location sending
    user agent to inform it that location was not delivered as intended.*

    See[ID-GEO-FILTERS]  *(ID-GEO-FILTERS)*  for more details on dereferencinglocation.

    An HTTP: [RFC2616] or HTTPS: URI [RFC2818] are also allowed, and
    SHOULD be dereferenced according to [ID-HELD-DEREF].  *location
    information.*

Change in IANA registration:

   Code Description                                          Reference
   ---- ---------------------------------------------------  ---------
   100  "Cannot Process Location"                            [this doc]

   200"Retry Location Later with device updated location"  [this doc]

   300   "Permission To Use Location Information"             [this doc]

   301

   *201*   "Permission To Retransmit Location Information to a Third Party"
                                                             [this doc]

   302

   *202*   "Permission to Route based on Location Information"  [this doc]

   400

   *300*   "Dereference Failure"                                [this doc]

8.6  IANA Registration of Location URI Schemes

    This document directs IANA to create a new set of parameters in a
    separate location from SIP and Geopriv, called the "Location
    Reference URI" registry, containing the URI scheme, the
    Content-Type, and the reference, as follows:

    URI Scheme   Content-Type           Reference
    ----------   ------------           ---------
       SIP:                             [this doc]
       SIPS:                            [this doc]
       PRES:                            [this doc]
       HTTP:                            [this doc]
       HTTPS:                           [this doc]

    Additions to this registry must be defined in a permanent and
    readily available specification (this is the "Specification
    Required" IANA policy defined in [RFC5226]).

/a

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 2 Feb 2011 18:53:51 +0100

This seems to reflect what was discussed. A few points:

1. "If more than one locationValue is present in the SIP request and
   determined to be valid by the LR, the location in that SIP request
   MUST be considered good as far as location is concerned, and no
   Geolocation-Error is sent."
Should this say:
"If more than one locationValue is present in the SIP request and
   >>at least one location/Value is<< determined to be valid by the LR, the location in that SIP request
   MUST be considered good as far as location is concerned, and no
   Geolocation-Error is sent." ?

2. "We have gone through the
   exercise of getting this correct for every scenario, and deemed it
   not worth the excruciating effort involved."
This may be true, but do we really want this in the final document?

3. "These error codes are divided into 4 categories"
I only see 3.

4. "... any non-INVITE response to a
   request containing location SHOULD NOT consider a 200 OK to mean ..."
Is a response able to consider? Presumably the subject be the recipient of such a response.

5. "Within these 4 3 number ranges, there is a top level error as follows:"
Should this say "Within each of these..."?

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: 02 February 2011 00:34
> To: SIPCORE
> Subject: [sipcore] Proposed location conveyance changes
> 
> [as chair]
> 
> As a follow up from last-week's ad-hoc call on the topic of 
> location conveyance, the authors have proposed the following 
> technical changes (along with several editorial changes). 
> Please review and comment as soon as possible. If there are 
> no objections, the document will updated accordingly on or 
> after Thursday of this week.
> 
>    The example given in this section is only illustrative, not
>    errors, if returning such errors are necessary.
> 
> In section 4.3:
> 
> 
>    A SIP intermediary that requires Alice's location in order to
>    Here is an initial list of location based error ranges for any SIP
>    how the response receiver should react to these errors.  There can
>    error.
>       request
>       - the LS to send new location was not present or 
> updated could not be found,
>       - there was not enough location information, perhaps 
> with a delay associated with when information to send determine
>         where the request. Target was,
>       - etc...
>    o  3XX  2XX errors mean some specific permission is 
> necessary to process
>    o  4XX  3XX errors mean there was trouble dereferencing 
> the Location URI
>       sent.
> 
>    It should be noted that for non-INVITE transactions, the SIP
>    today.
>    Within these 4 3 number ranges, there is a top level error 
> as follows:
> 
>    Geolocation-Error: 200 "Retry Location Later with device updated
>                            location"
> 
>    Geolocation-Error: 400 300 "Dereference Failure"
> 
>    Geolocation-Error: 301 201 "Permission To Retransmit Location
>    Data Format (PIDF-LO) [RFC4119] <retransmission-allowed> 
> element set
>    (i.e., PIDF-LO <retransmission-allowed> element set to "=yes") to
>    logical path (if one exists). exists) for this SIP request.
> 
>    Geolocation-Error: 302 202 "Permission to Route based on Location
>                            Information"
> 
>    parameter <routing-allowed> set to "=no". This location error is
>    stating it requires permission (i.e., a <routing-allowed> set to
>    another logical path (if one exists). exists) for this SIP request.
> 4.5 Location URIs Allowed Profile Negotiation
> 
>    If a location URI is included in a SIP request, it SHOULD 
> be the sending user
>    agent MUST also include a SIP-,
>    SIPS- or PRES-URI.  When PRES: is used, as Supported 
> header field indicating which
>    are defined by this document: "geolocation-sip" and
>    location profiles per the IANA policy described in 
> [RFC3856], if Section 8.2.
> 
>    location information via the presence event package of SIP
>    a SUBSCRIBE request and parse a resulting resolution 
> resolves to NOTIFY containing a SIP: or SIPS: URI,
>    PIDF-LO object. The URI schemes supported by this
>    section applies.  These option include
>    parse a resulting 200 response containing a PIDF-LO object. The URI
>    schemes MUST be implemented according to supported by this 
> document. option include "http" and "https". A
>    user agent to inform it that location was not delivered as 
> intended.
> 
>    See [ID-GEO-FILTERS] (ID-GEO-FILTERS) for more details on 
> dereferencing location.
> 
>    SHOULD be dereferenced according to [ID-HELD-DEREF]. location
>    information.
>   200  "Retry Location Later with device updated location"  [this doc]
> 
>   201  "Permission To Retransmit Location Information to a 
> Third Party"
>                                                             [this doc]
> 
>   302
> 
>   202  "Permission to Route based on Location Information"  [this doc]
> 
>   400
> 
>   300  "Dereference Failure"                                [this doc]
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 02 Feb 2011 16:07:09 -0600

John

Thanks for the review. I have comments in-line below.

>    Geolocation-Error is sent." ?

I like the addition.

>This may be true, but do we really want this in the final document?

I'm ok with taking this out, but (no offense) want to here others 
opinions on this.

>3. "These error codes are divided into 4 categories"

thought I caught all of these from the most recent reduction (sorry)

fixed

>recipient of such a response.

changed to
   "This means the receiver of any non-INVITE response to a
               ^^^^^^^^^^^^^^^
    request containing location SHOULD NOT consider a 200 OK to mean the
    act of dereferencing has concluded and the dereferencer (i.e., the
    LR) has successfully received and parsed the PIDF-LO for errors
                         ^^^^^^^^^^^^
    and found none."

Does this read better?

>Should this say "Within each of these..."?

fixed

Thanks again

James

>_______________________________________________
>sipcore mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 3 Feb 2011 06:16:03 +0800

> I'm ok with taking this out, but (no offense) want to here others

Since you ask, this sort of statement is of transitory value at best.  I'm glad that you did go to the effort, but I'm not sure that future readers will appreciate it in the same way.  Removing it would be nice.

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 3 Feb 2011 08:39:03 +0800

These look good to me.

Some small suggestions below.

>    need to be mindful of SIP's transaction timers. In particular, if

Nit: possessive apostrophes on inanimate object are not good: s/SIP's transaction timers/timers used by different transactions/

> In section 4.3:
...
>    We have gone through the

Agree with John on this one: this is not necessary.

>    meaning that, somehow not defined here, the LR just picks one to

"errored" isn't in my dictionary.  Suggest:

  There is no mechanism provided to indicate which of multiple locationValues is in error.  If all locationValues are in error, the LR can select any locationValue for which to provide an error.

>    This was first brought up in Section 3.2.

I don't think that repeating this point is necessary or useful.  The point that is important is that if the 200 is dependent on the location, then you can send these responses; if the 200 is not, then don't.  For those cases where you can't dereference before the 200 is sent, then the location had better not be necessary for the 200 to be sent.

See Jon's email on the topic, i.e., "we should not try to build the expected behavior of applications into the low-level protocol building blocks"...

> New section 4.5 (previously 4.6):
...
>    location information via an HTTP ([RFC2616]). A location recipient

Suggest a reference to draft-ietf-geopriv-deref-protocol in addition to 2616.

>    See (ID-GEO-FILTERS) for more details on dereferencing location information.

Or here.   Why does this reference use parentheses now, rather than brackets?

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 02 Feb 2011 20:22:41 -0600

At 04:16 PM 2/2/2011, Thomson, Martin wrote:
>Since you ask, this sort of statement is of transitory value at 
>best.  I'm glad that you did go to the effort, but I'm not sure that 
>future readers will appreciate it in the same way.  Removing it would be nice.

ok, done

(unless my Jon has heartburn about it)

James

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 3 Feb 2011 12:46:48 -0500

I'm fine with removing it.

Jon Peterson
NeuStar, Inc.

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 03 Feb 2011 14:27:23 -0600

>I'm fine with removing it.

done

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 08 Feb 2011 11:44:34 -0600

Martin

thanks for the comments. My responses are in-line

At 06:39 PM 2/2/2011, Thomson, Martin wrote:
>Nit: possessive apostrophes on inanimate object are not good: 
>s/SIP's transaction timers/timers used by different transactions/

done

>Agree with John on this one: this is not necessary.

removed

>   There is no mechanism provided to indicate which of multiple 
> locationValues is in error.  If all locationValues are in error, 
> the LR can select any locationValue for which to provide an error.

I rewrote out the word errored before I noticed your suggested text. 
I think the new text says the same thing as what you suggest.

>I don't think that repeating this point is necessary or useful.

I disagree, since the first mention of this is in the non-normative 
section 3. Repeating this point in a normative section matters. Only 
having this point in 1 of the sections loses context - so I disagree here.

>The point that is important is that if the 200 is dependent on the 
>location, then you can send these responses; if the 200 is not, then 
>don't.  For those cases where you can't dereference before the 200 
>is sent, then the location had better not be necessary for the 200 to be sent.
>
>See Jon's email on the topic, i.e., "we should not try to build the 
>expected behavior of applications into the low-level protocol 
>building blocks"...

I agree with both of you, and do not rebuild anything - just am using 
the opportunity in both sections to fill out points to be made.

>Or here.

done here

>Why does this reference use parentheses now, rather than brackets?

oops, fixed.

James