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

"Elwell, John" <john.elwell@siemens-enterprise.com> Wed, 10 November 2010 09:09 UTC

Return-Path: <john.elwell@siemens-enterprise.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 83B9F3A69DF for <sipcore@core3.amsl.com>; Wed, 10 Nov 2010 01:09:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.508
X-Spam-Level:
X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, 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 tGIz7TZOfEIC for <sipcore@core3.amsl.com>; Wed, 10 Nov 2010 01:09:04 -0800 (PST)
Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 69AB53A69D3 for <sipcore@ietf.org>; Wed, 10 Nov 2010 01:09:04 -0800 (PST)
Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2243193; Wed, 10 Nov 2010 10:09:25 +0100
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id A0A4B1EB82AB; Wed, 10 Nov 2010 10:09:25 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 10 Nov 2010 10:09:25 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: "Thomson, Martin" <Martin.Thomson@andrew.com>, "Peterson, Jon" <jon.peterson@neustar.biz>, "sipcore@ietf.org" <sipcore@ietf.org>
Date: Wed, 10 Nov 2010 10:09:24 +0100
Thread-Topic: [sipcore] Location-conveyance, option tags and URI scheme support
Thread-Index: AcuAe6GOF4JGUmD4TEKI1iKWD+xc3AAA+EWgAAGMM9AAAQptYAALQckg
Message-ID: <A444A0F8084434499206E78C106220CA023587F203@MCHP058A.global-ad.net>
References: <C9001EB7.480D2%jon.peterson@neustar.biz> <8B0A9FCBB9832F43971E38010638454F03F33652DB@SISPE7MB1.commscope.com> <A444A0F8084434499206E78C106220CA023587F13A@MCHP058A.global-ad.net> <8B0A9FCBB9832F43971E38010638454F03F33652F2@SISPE7MB1.commscope.com>
In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F33652F2@SISPE7MB1.commscope.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 09:09:05 -0000

OK, I go along with your expert opinion on this.

John 

> -----Original Message-----
> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] 
> Sent: 10 November 2010 03:51
> To: Elwell, John; Peterson, Jon; sipcore@ietf.org
> Subject: RE: [sipcore] Location-conveyance, option tags and 
> URI scheme support
> 
> On 2010-11-10 at 11:24:10, Elwell, John wrote:
> > > 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).
> > [JRE] But the point of supporting HELD is that you expect a 
> PIDF-LO in
> > the response. Just supporting HTTP does not necessarily mean you are
> > able to handle PIDF-LO in a response?
> 
> The point of supporting Geolocation-http is that you support 
> acquisition of a PIDF-LO using HTTP (and maybe HELD).  It's a 
> continuum of support that doesn't require discrete steps (in 
> my opinion).
> 
> --Martin
>