Subject: [sipcore] Ad-hoc call notes

From: Adam Roach <[email-masked]>
Date: Thu, 27 Jan 2011 14:46:26 -0600

[as an individual]

I took some (occasionally interrupted) notes on the location conveyance 
call today.

/a

Location Conveyance Ad-Hoc Phone Call January 12, 2011
=======================================================

Participants:
   Adam Roach
   Jon Peterson
   Hannes Tschofenig
   James Polk
   John Elwell
   Martin Thomson
   Paul Kyzivat
   Robert Sparks

First Issue: Use of IANA-registered option tags

   Proposal is to use "geolocation-sip" and "geolocation-http"

   Martin Thomson beleives this is sufficient for HELD, and that
     "geolocation-held" would be too specific

   General agreement from various that this approach seems sound.

Second Issue: Is standards action the right level?

   Jon thinks we won't need many, so setting the bar high is good.

   Paul K agrees that the more we have, the less interoperability
     is fostered, so a high bar helps overall.

Third Issue: Removal of 200-class geoloc errors

   Jon thinks there might be some cruft left behind from this change.
     The assertion is that these can be communicated using normal SIP
     error codes, and that we don't want to re-state a bunch of normative
     behavior from 3261.

   James and Paul expressed concerns about not noting the use of
     specific error codes.

   James notes that one of the motivations for 200 codes was to
     be able to communicate to the client "your location is stale,
     update it and try again."

   Jon points out that he's trying to get rid of as many error codes
     as possible.

   James says he's find with that, but that we should tell implementors
     to use a 503 with a "Retry-After" for the conditions previously
     covered by 200.

   Martin Thomson indicates that 503 isn't really the right semantic,
     because it isn't an overload condition. Stale location isn't
     a server error.

   Robert: 503 isn't really "I'm overloaded." It's "Stop talking to me."

   The assertion seems to be that we can collapse everything into 100.
     Martin is okay with that, but that we might want to put additional
     text in the 100 description to include problems ("can't find it,
     can't parse, not good enough").

   Proposal is to make existing 300s into new 200s, and so on. (Bascially,
     I don't have permission to get to your location).

       100: get me different or better location
       2xx (formerly 3xx): fix your permissions
       3xx (formerly 4xx): get me a URI that works (or a location-by-value)

   James talks about a use case where he sends a "geolocation-sip"
     message, but can't subscribe to the SIP resource (because, e.g.,
     of firewalls).

   Adam points out that you end up with some really bad protocol timer
     interactions if you wait for the NOTIFY to show up, and that the
     only way to really make sure that the server has received the
     information would be to set up a subscription to that state.

   Martin points out that there's no way to signal "I can't dereference,
     just send me a location by value."

   Jon thinks we don't need that. The reason people don't use LbyV is
     by necessity, and this isn't something the client will likely
     be able to solve. LbyR is mostly for use cases where the network
     won't provide data to the endpoint, and so LbyR is the only option.

   Martin proposes that's a good reason for omitting specific text on the
     issue.

   James asks whether we need to solve this problem? And do we need to
     fix it for both INVITE and non-INVITE?

   Jon asserts that the "200 OK" should simply indicate that the message
     has been received, not that the location has been successfully
     retrieved.

   Some dicussion follows, the upshot of which is (1) Non-INVITE 
transactions
     can't pend for long enough to dereference [will add text], and
     (2) The call flows are examples, not normative. Other data flows
     are possible.

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 27 Jan 2011 15:29:31 -0600

>[as an individual]

comments and clarifications in-line below

>I took some (occasionally interrupted) notes on the location 
>conveyance call today.
>
>/a
>

everyone on the call seemed to believe this was a really good way forward.

>   The assertion seems to be that we can collapse everything into 100.

correction: not "everything" into one error code, but all the

- bad location
- can't parse location
- don't understand what (location) you sent me
- you left (a) key part(s) of your location out
- etc

all these types of errors above are to be collapsed into the 100 
geoloc error code

>       3xx (formerly 4xx): get me a URI that works (or a location-by-value)

this 3xx isn't solved yet, as "get me a URI that works (or a 
location-by-value)" is solved with Jon's new option-tags. This last 
error category was to indicate there was a problem during 
Dereferencing (i.e., "Dereference Failure") which was to be included 
in the SIP response back to the UAC to inform them whether or not the 
location that the UAC included reached it's destination (or, 
conversely to the intermediary server that inserted location).  It 
appears that we can keep this for the INVITE request, but that for 
ther other request types this plays badly with session timers (as 
Adam chronicles below), so we'll modify the text accordingly.

>     has been received, not that the location has been successfully

Jon said this, but I don't believe others on the call agreed to this 
by the time the call ended. For example, I think we need a 
verification that location sent was received, and not treat that by 
basically ignoring if location was in the message at all. This goes 
towards treating location reception explicitly vs. implicitly.

>   Some dicussion follows, the upshot of which is (1) Non-INVITE transactions

this was agreeable on the call and Adam (perhaps via Robert) to offer 
as text for inclusion.

(btw - I have now seen the text, and it looks good)

James

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 28 Jan 2011 05:46:18 +0800

Agree with James, one minor thing to add below...

> Adam chronicles below), so we'll modify the text accordingly.
 
My suggestions may have been misinterpreted.  I was only suggesting that there are a specific actions that might be useful in response to each of the classes of geolocation-error (1xx, 2xx and 3xx).  That's my test for whether the distinction between each class is good.  That's the theoretical test I use.

There are myriad reasons that (the new) 3xx might arise in practice.  Unsupported protocols we've addressed with the option tags.  For the rest, firewalls, authentication and authorization problems are all possible and are all potentially unrepairable.  When that happens, that's regrettable; but in practice, things fail all the time and that's beyond the power of the protocol design to fix.

What is there seems adequate to address the problems we know and care about.

> towards treating location reception explicitly vs. implicitly.

Jon walk talking about MESSAGE specifically.  It seemed that there would be little reason to withhold a 200 based on whether or not the URI had been successfully followed or not.  That was in rebuttal to a specific question about MESSAGE - I'm not sure if this was intended to cover all cases.

In any case, I think that the general idea of the text (as promised) that says: If you don't dereference and send 200 anyway, make sure you have another channel to use if problems arise.

> (btw - I have now seen the text, and it looks good)

Good.  I too would like to see the text.  (An updated draft will suffice :)

--Martin

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 27 Jan 2011 18:36:00 -0500

> In any case, I think that the general idea of the text (as promised) that says: If you don't dereference and send 200 anyway, make sure you have another channel to use if problems arise.

What I said repeatedly was that we should not try to build the expected behavior of applications into the low-level protocol building blocks. The termination of a non-INVITE transaction like MESSAGE with a 200 response, I said, acknowledges that at a protocol level the transaction was "OK," not that the payload of the message is useful or agreeable. If you send me a MESSAGE method with the text "can i borrow $40?", the 200 OK does not imply that I accede to your request. For some applications relying on non-INVITE transactions, I can imagine the 200 meaning nothing more than "I got the message," not "I got the message and I was able to dereference the URI in it." 

I am especially concerned here about the implication that location by-reference simply does not work for non-INVITE transactions, since those transactions would ordinarily complete before the dereference could be performed. We'd need to look at specific use cases to figure out the best way to adapt non-INVITE transactions to their behavior, but for the time being, I think we just need to add to 3.2 a note suggesting that for non-INVITE transactions, the defer may not be performed prior to sending a 200 response.

Jon Peterson
NeuStar, Inc.