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

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: sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] On Behalf Of Thomson, Martin
> Sent: 10 November 2010 03:09
> To: Peterson, Jon; sipcore@ietf.org
> 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.
> 
> Thinking about this a little more there might be a need for 
> three values:
> 
> I need a PIDF-LO
>   Require: Geolocation-value 
[JRE] I hadn't picked this one up from Jon's proposal, but it makes sense.

> 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).
[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?)
> 
> 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.
> 
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 