Re: [sipcore] draft-ietf-sipcore-location-conveyance-03
"Thomson, Martin" <Martin.Thomson@andrew.com> Fri, 23 July 2010 00:13 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 1C9F43A695F for <sipcore@core3.amsl.com>; Thu, 22 Jul 2010 17:13:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level:
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.850, 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 15FId35nrBiR for <sipcore@core3.amsl.com>; Thu, 22 Jul 2010 17:13:53 -0700 (PDT)
Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id EF2313A6A03 for <sipcore@ietf.org>; Thu, 22 Jul 2010 17:13:51 -0700 (PDT)
Received: from [10.86.20.103] ([10.86.20.103]:35336 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S342205Ab0GWAOJ (ORCPT <rfc822; sipcore@ietf.org>); Thu, 22 Jul 2010 19:14:09 -0500
Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 22 Jul 2010 19:14:09 -0500
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 23 Jul 2010 08:14:05 +0800
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: Paul Kyzivat <pkyzivat@cisco.com>, "James M. Polk" <jmpolk@cisco.com>
Date: Fri, 23 Jul 2010 08:14:04 +0800
Thread-Topic: [sipcore] draft-ietf-sipcore-location-conveyance-03
Thread-Index: Acspo+08pJMmoXskShuqBN3q0CjTtwAU3ixg
Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB828B8D@SISPE7MB1.commscope.com>
References: <4C47B6B6.2090009@cisco.com> <201007220329.o6M3TtCI013514@sj-core-1.cisco.com> <4C484B10.2000907@cisco.com>
In-Reply-To: <4C484B10.2000907@cisco.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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com
X-BCN-Sender: Martin.Thomson@andrew.com
Cc: SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-03
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: Fri, 23 Jul 2010 00:13:54 -0000
> >> ISTM there needs to be a requirement that the intermediary inserting > >> the Geolocation header handle any 424 errors that might result from > >> it, thus shielding the UAC from those. > > > > Do you think we can state this? I'm thinking from a purest protocol > > pov, that seems to me to break SIP's e2e model of communication, > > especially when involving a literal proxy - and not some other form > of > > SIP intermediary (e.g., b2bua or sbc that are made to do just this). No harm in making a statement about this. Of course, this sort of behaviour could simply be implied. If the intermediary is acting as a B2BUA, when it adds a feature, it can (and should) absorb the consequences of that. For geolocation, if it adds the header, it must be prepared for the consequences of that (424). I'll leave it to the discretion of the editors how much they want to dance around the sensitivities. But you could just say: An intermediary that adds a geolocation header MUST be prepared to handle any errors that this might result in, including a 424 response. The intermediary might then translate this error into an error that the UAC is known to support, or...
- Re: [sipcore] draft-ietf-sipcore-location-conveya… Paul Kyzivat
- Re: [sipcore] draft-ietf-sipcore-location-conveya… James M. Polk
- Re: [sipcore] draft-ietf-sipcore-location-conveya… Paul Kyzivat
- Re: [sipcore] draft-ietf-sipcore-location-conveya… Thomson, Martin
- Re: [sipcore] draft-ietf-sipcore-location-conveya… Winterbottom, James
- Re: [sipcore] draft-ietf-sipcore-location-conveya… Paul Kyzivat
- Re: [sipcore] draft-ietf-sipcore-location-conveya… DOLLY, MARTIN C (ATTLABS)
- Re: [sipcore] draft-ietf-sipcore-location-conveya… Winterbottom, James
- Re: [sipcore] draft-ietf-sipcore-location-conveya… James M. Polk
- Re: [sipcore] draft-ietf-sipcore-location-conveya… Elwell, John
- Re: [sipcore] draft-ietf-sipcore-location-conveya… Thomson, Martin
- Re: [sipcore] draft-ietf-sipcore-location-conveya… James M. Polk