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

["Thomson, Martin" <[e-mail]>]

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.