Subject: [sipcore] Location-conveyance, option tags and URI scheme support

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 9 Nov 2010 21:04:39 -0500

As much as I hoped not to have to introduce any "clever" new ideas for location-conveyance, some of Mr. Elwell's comments caused us to circle round and think about the intended application of option tags in location-conveyance, especially in conjunction with the various mechanisms intended to negotiate URI scheme support.

For a while, I've been uncomfortable with the various error codes proposed to negotiate URI scheme support for a couple of reasons: mostly because a URI scheme does not completely express the behavior that an endpoint needs to support. For example, what does it mean to say that an endpoint supports SIP as a URI scheme for acquiring location by reference? That it supports SUBSCRIBE/NOTIFY, or specifically fetch behavior, or specifically the presence event package, or specifically some subset thereof? The same applies to HTTP - one can easily imagine a bare HTTP GET for a location object, or one can imagine a broader package like HELD. Simply articulating support for a URI scheme seems insufficient. To invoke an overloaded term, we lack a means to support these sorts of "profiles" for delivering location by reference.

Meanwhile, the way the draft is written today, the use case for an option tag expressing support for "geolocation" is certainly murky at best. Rather than removing the tag, however, perhaps we should replace it instead with more specific tags for those "profiles." In this model, if you imagine we have a "presence" profile (and send requests with that tag in a Supported), and you send location to a server that supports the "held" profile, it could return a 421 with that "held" in a Require or what have you and inform the UAC what it needs to send.

This would also replace the proposed IANA registry of supported URI schemes, presumably with a registry of these "profiles," which would have something roughly like Spec Required for its policy.

Thoughts about whether or not we can endure this cleverness at this stage in the process? Backwards compatibility snafus?

Jon Peterson
NeuStar, Inc.

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 10 Nov 2010 11:08:58 +0800

This sounds like a good idea.  Clever is something I can appreciate, even at this stage.  This should improve the interoperability situation.

I also really like the idea of cutting out the geolocation-error header.  There was a lot of mechanism there, for little significant value.

Thinking about this a little more there might be a need for three values:

I need a PIDF-LO
  Require: Geolocation-value 
I need an HTTP[s]/HELD URI 
  Require: Geolocation-value 
I need a SIP[s]/pres URI
  Require: Geolocation-presence 

I see little reason to separately identify HELD.  HELD dereference works with HTTP GET well enough and a HELD-capable client can recognize a HELD-capable server if they care about using HELD (for quality of service constraints and so on).

From the perspective of late changes, I expect that the error handling cases are not yet mature enough in existing implementations to be concerned.  I will confirm, but don't let that stop you from proceeding.

--Martin

(How do you say OR in a require header?  e.g., I need HTTP or a value; do we need to define specific semantics?)

On 2010-11-10 at 10:04:39, Peterson, Jon wrote:
> 
> As much as I hoped not to have to introduce any “clever” new ideas for
> location-conveyance, some of Mr. Elwell’s comments caused us to circle
> round and think about the intended application of option tags in
> location-conveyance, especially in conjunction with the various
> mechanisms intended to negotiate URI scheme support.
> 
> For a while, I’ve been uncomfortable with the various error codes
> proposed to negotiate URI scheme support for a couple of reasons:
> mostly
> because a URI scheme does not completely express the behavior that an
> endpoint needs to support. For example, what does it mean to say that
> an
> endpoint supports SIP as a URI scheme for acquiring location by
> reference? That it supports SUBSCRIBE/NOTIFY, or specifically fetch
> behavior, or specifically the presence event package, or specifically
> some subset thereof? The same applies to HTTP – one can easily imagine
> a
> bare HTTP GET for a location object, or one can imagine a broader
> package like HELD. Simply articulating support for a URI scheme seems
> insufficient. To invoke an overloaded term, we lack a means to support
> these sorts of “profiles” for delivering location by reference.
> 
> Meanwhile, the way the draft is written today, the use case for an
> option tag expressing support for “geolocation” is certainly murky at
> best. Rather than removing the tag, however, perhaps we should replace
> it instead with more specific tags for those “profiles.” In this model,
> if you imagine we have a “presence” profile (and send requests with
> that
> tag in a Supported), and you send location to a server that supports
> the
> “held” profile, it could return a 421 with that “held” in a Require or
> what have you and inform the UAC what it needs to send.
> 
> This would also replace the proposed IANA registry of supported URI
> schemes, presumably with a registry of these “profiles,” which would
> have something roughly like Spec Required for its policy.
> 
> Thoughts about whether or not we can endure this cleverness at this
> stage in the process? Backwards compatibility snafus?
> 
> Jon Peterson
> NeuStar, Inc.

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 10 Nov 2010 04:24:10 +0100

Sounds like a good idea to me too.

Require in a response is something that perhaps goes beyond RFC 3261, but there are precedents. Supported in a response might be sufficient. If there are two you support (say value and HELD, but not SIP Presence), I don't think you could convey that semantic using Require, but you could using Supported. Putting both "value" and "HELD" in Require would imply you require the recipient to support both.

Comments on Martin's comments below: 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Thomson, Martin
> Sent: 10 November 2010 03:09
> To: Peterson, Jon; [email-masked]
> Subject: Re: [sipcore] Location-conveyance, option tags and 
> URI scheme support
> 
> This sounds like a good idea.  Clever is something I can 
> appreciate, even at this stage.  This should improve the 
> interoperability situation.
> 
> I also really like the idea of cutting out the 
> geolocation-error header.  There was a lot of mechanism 
> there, for little significant value.
> 
[JRE] I hadn't picked this one up from Jon's proposal, but it makes sense.

> I see little reason to separately identify HELD.  HELD 
> dereference works with HTTP GET well enough and a 
> HELD-capable client can recognize a HELD-capable server if 
> they care about using HELD (for quality of service 
> constraints and so on).
[JRE] But the point of supporting HELD is that you expect a PIDF-LO in the response. Just supporting HTTP does not necessarily mean you are able to handle PIDF-LO in a response?

John

> 
> From the perspective of late changes, I expect that the error 
> handling cases are not yet mature enough in existing 
> implementations to be concerned.  I will confirm, but don't 
> let that stop you from proceeding.
> 
> --Martin
> 
> (How do you say OR in a require header?  e.g., I need HTTP or 
> a value; do we need to define specific semantics?)
> 
> > As much as I hoped not to have to introduce any "clever" 
> new ideas for
> > location-conveyance, some of Mr. Elwell's comments caused 
> us to circle
> > For a while, I've been uncomfortable with the various error codes
> > some subset thereof? The same applies to HTTP - one can 
> easily imagine
> > a
> > these sorts of "profiles" for delivering location by reference.
> > 
> > option tag expressing support for "geolocation" is 
> certainly murky at
> > it instead with more specific tags for those "profiles." In 
> this model,
> > if you imagine we have a "presence" profile (and send requests with
> > that
> > "held" profile, it could return a 421 with that "held" in a 
> Require or
> > schemes, presumably with a registry of these "profiles," which would
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 10 Nov 2010 11:50:47 +0800

On 2010-11-10 at 11:24:10, Elwell, John wrote:
> [JRE] But the point of supporting HELD is that you expect a PIDF-LO in
> the response. Just supporting HTTP does not necessarily mean you are
> able to handle PIDF-LO in a response?

The point of supporting Geolocation-http is that you support acquisition of a PIDF-LO using HTTP (and maybe HELD).  It's a continuum of support that doesn't require discrete steps (in my opinion).

--Martin

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 10 Nov 2010 10:09:24 +0100

OK, I go along with your expert opinion on this.

John 

> From: Thomson, Martin [mailto:[email-masked]] 
> Sent: 10 November 2010 03:51
> To: Elwell, John; Peterson, Jon; [email-masked]
> Subject: RE: [sipcore] Location-conveyance, option tags and 
> URI scheme support
> 
> The point of supporting Geolocation-http is that you support 
> acquisition of a PIDF-LO using HTTP (and maybe HELD).  It's a 
> continuum of support that doesn't require discrete steps (in 
> my opinion).
> 
> --Martin
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 10 Nov 2010 07:39:21 -0600

At 09:08 PM 11/9/2010, Thomson, Martin wrote:
>This sounds like a good idea.  Clever is 
>something I can appreciate, even at this 
>stage.  This should improve the interoperability situation.
>
>geolocation-error header.  There was a lot of 
>mechanism there, for little significant value.

Martin - there is no proposal to completely 
remove the Geolocation-Error header value, just 
cut down (further) the number of error codes we specify in this doc. The

         - 100
         - 300
         - 301
         - 302 and
         - 400

error codes remain, and we're still unsettled 
with how a SIP 503 response with a Retry-After 
header value can replace the 200 error code. 
Right now, I don't see how a SIP 503 response 
gets related back to a location error, which we 
want to assert, and not a general 503 (service 
unavailable) response that has nothing to do with location

>   Require: Geolocation-value

this one would be "Require: Geolocation-HTTP" (not -value) right?

>I see little reason to separately identify 
>HELD.  HELD dereference works with HTTP GET well 
>enough and a HELD-capable client can recognize a 
>HELD-capable server if they care about using 
>HELD (for quality of service constraints and so on).
>
> From the perspective of late changes, I expect 
> that the error handling cases are not yet 
> mature enough in existing implementations to be 
> concerned.  I will confirm, but don't let that stop you from proceeding.
>
>--Martin
>
>(How do you say OR in a require header?

you don't (yet)

James

>e.g., I need HTTP or a value; do we need to define specific semantics?)
>
> > As much as I hoped not to have to introduce any â€œcleverâ€ new ideas for
> > location-conveyance, some of Mr. Elwellâ€™s comments caused us to circle
> > For a while, Iâ€™ve been uncomfortable with the various error codes
> > some subset thereof? The same applies to HTTP  one can easily imagine
>
> > a
> > these sorts of â€œprofilesâ€ for delivering location by reference.
> >
> > option tag expressing support for â€œgeolocationâ€ is certainly murky at
> > it instead with more specific tags for those â€œprofiles.â€ In this model,
> > if you imagine we have a â€œpresenceâ€ profile (and send requests with
> > that
> > â€œheldâ€ profile, it could return a 421 
> with that â€œheldâ€ in a Require or
> > schemes, presumably with a registry of these â€œprofiles,â€ which would
>sipcore mailing list [email-masked]