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
- [sipcore] Location-conveyance, option tags and UR… Peterson, Jon
- Re: [sipcore] Location-conveyance, option tags an… Thomson, Martin
- Re: [sipcore] Location-conveyance, option tags an… Elwell, John
- Re: [sipcore] Location-conveyance, option tags an… Thomson, Martin
- Re: [sipcore] Location-conveyance, option tags an… Elwell, John
- Re: [sipcore] Location-conveyance, option tags an… James M. Polk