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

"Thomson, Martin" <> Wed, 10 November 2010 03:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8378C3A680B for <>; Tue, 9 Nov 2010 19:08:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.239
X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=-0.640, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id od8GVUTAHnqD for <>; Tue, 9 Nov 2010 19:08:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E43463A67F8 for <>; Tue, 9 Nov 2010 19:08:38 -0800 (PST)
Received: from [] ([]:12910 "EHLO") by with ESMTP id S37921481Ab0KJDJE (ORCPT <rfc822;>); Tue, 9 Nov 2010 21:09:04 -0600
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 9 Nov 2010 21:09:04 -0600
Received: from ([fe80::9d82:a492:85e3:a293]) by ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 10 Nov 2010 11:09:01 +0800
From: "Thomson, Martin" <>
To: "Peterson, Jon" <>, "" <>
Date: Wed, 10 Nov 2010 11:08:58 +0800
Thread-Topic: Location-conveyance, option tags and URI scheme support
Thread-Index: AcuAe6GOF4JGUmD4TEKI1iKWD+xc3AAA+EWg
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on
Subject: Re: [sipcore] Location-conveyance, option tags and URI scheme support
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Nov 2010 03:08:42 -0000

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.


(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.