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

"Thomson, Martin" <Martin.Thomson@andrew.com> Wed, 10 November 2010 03:08 UTC

Return-Path: <Martin.Thomson@andrew.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8378C3A680B for <sipcore@core3.amsl.com>; Tue, 9 Nov 2010 19:08:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.239
X-Spam-Level:
X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=-0.640, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id od8GVUTAHnqD for <sipcore@core3.amsl.com>; Tue, 9 Nov 2010 19:08:39 -0800 (PST)
Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id E43463A67F8 for <sipcore@ietf.org>; Tue, 9 Nov 2010 19:08:38 -0800 (PST)
Received: from [10.86.20.102] ([10.86.20.102]:12910 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S37921481Ab0KJDJE (ORCPT <rfc822; sipcore@ietf.org>); Tue, 9 Nov 2010 21:09:04 -0600
Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 9 Nov 2010 21:09:04 -0600
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 10 Nov 2010 11:09:01 +0800
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: "Peterson, Jon" <jon.peterson@neustar.biz>, "sipcore@ietf.org" <sipcore@ietf.org>
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: <8B0A9FCBB9832F43971E38010638454F03F33652DB@SISPE7MB1.commscope.com>
References: <C9001EB7.480D2%jon.peterson@neustar.biz>
In-Reply-To: <C9001EB7.480D2%jon.peterson@neustar.biz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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 csmailgw1.commscope.com
X-BCN-Sender: Martin.Thomson@andrew.com
Subject: Re: [sipcore] Location-conveyance, option tags and URI scheme support
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=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.

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