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

"James M. Polk" <> Wed, 10 November 2010 13:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E2863A6968 for <>; Wed, 10 Nov 2010 05:39:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -109.751
X-Spam-Status: No, score=-109.751 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oz8JPz4H0flW for <>; Wed, 10 Nov 2010 05:38:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B7ABC3A6941 for <>; Wed, 10 Nov 2010 05:38:59 -0800 (PST)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiYFANUu2kyrRN+J/2dsb2JhbAChXlhxogGbK4JxglkEhFo
X-IronPort-AV: E=Sophos;i="4.59,178,1288569600"; d="scan'208";a="283916271"
Received: from ([]) by with ESMTP; 10 Nov 2010 13:39:26 +0000
Received: from ( []) by (8.13.8/8.14.3) with ESMTP id oAADdOXw021414; Wed, 10 Nov 2010 13:39:25 GMT
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Wed, 10 Nov 2010 07:39:21 -0600
To: "Thomson, Martin" <>, "Peterson, Jon" <>, "" <>
From: "James M. Polk" <>
In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F33652DB@SISPE7MB1.comms>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
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 13:39:05 -0000

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.
>I also really like the idea of cutting out the 
>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

>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

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

>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?

you don't (yet)


>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