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

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

Return-Path: <jmpolk@cisco.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 5E2863A6968 for <sipcore@core3.amsl.com>; Wed, 10 Nov 2010 05:39:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.751
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oz8JPz4H0flW for <sipcore@core3.amsl.com>; Wed, 10 Nov 2010 05:38:59 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B7ABC3A6941 for <sipcore@ietf.org>; Wed, 10 Nov 2010 05:38:59 -0800 (PST)
Authentication-Results: sj-iport-5.cisco.com; 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 sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 10 Nov 2010 13:39:26 +0000
Received: from jmpolk-wxp01.cisco.com (sjc-vpn6-697.cisco.com [10.21.122.185]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id oAADdOXw021414; Wed, 10 Nov 2010 13:39:25 GMT
Message-Id: <201011101339.oAADdOXw021414@sj-core-3.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 10 Nov 2010 07:39:21 -0600
To: "Thomson, Martin" <Martin.Thomson@andrew.com>, "Peterson, Jon" <jon.peterson@neustar.biz>, "sipcore@ietf.org" <sipcore@ietf.org>
From: "James M. Polk" <jmpolk@cisco.com>
In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F33652DB@SISPE7MB1.comms cope.com>
References: <C9001EB7.480D2%jon.peterson@neustar.biz> <8B0A9FCBB9832F43971E38010638454F03F33652DB@SISPE7MB1.commscope.com>
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-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 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.
>
>--Martin
>
>(How do you say OR in a require header?

you don't (yet)

James

>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