Re: [sipcore] composition or just indirection

"Thomson, Martin" <Martin.Thomson@andrew.com> Tue, 20 July 2010 23:48 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 452163A6980 for <sipcore@core3.amsl.com>; Tue, 20 Jul 2010 16:48:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.97
X-Spam-Level:
X-Spam-Status: No, score=-2.97 tagged_above=-999 required=5 tests=[AWL=-0.371, 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 laZ8Z11RkCJL for <sipcore@core3.amsl.com>; Tue, 20 Jul 2010 16:48:27 -0700 (PDT)
Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 4AF003A697D for <sipcore@ietf.org>; Tue, 20 Jul 2010 16:48:26 -0700 (PDT)
Received: from [10.86.20.103] ([10.86.20.103]:12152 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S28243750Ab0GTXsl (ORCPT <rfc822; sipcore@ietf.org>); Tue, 20 Jul 2010 18:48:41 -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; Tue, 20 Jul 2010 18:48:41 -0500
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 21 Jul 2010 07:48:39 +0800
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: Paul Kyzivat <pkyzivat@cisco.com>
Date: Wed, 21 Jul 2010 07:50:48 +0800
Thread-Topic: [sipcore] composition or just indirection
Thread-Index: AcsoCkunGdOyi5IuRt6DSEiFZ+ntFgAWGJFw
Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB773153@SISPE7MB1.commscope.com>
References: <8B0A9FCBB9832F43971E38010638454F03EB772EBB@SISPE7MB1.commscope.com> <C86A11BF.41D5D%jon.peterson@neustar.biz> <8B0A9FCBB9832F43971E38010638454F03EB7730BA@SISPE7MB1.commscope.com> <4C459BD7.9050007@cisco.com>
In-Reply-To: <4C459BD7.9050007@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 csmailgw1.commscope.com
X-BCN-Sender: Martin.Thomson@andrew.com
Cc: Roger Marshall <RMarshall@telecomsys.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] composition or just indirection
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: Tue, 20 Jul 2010 23:48:28 -0000

> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]:
> Thomson, Martin wrote:
> > The Geolocation header identifies a PIDF document by value or
> > reference.  A Geolocation header indicates that a) this particular
> > PIDF
> > document contains location information and b) that this location
> > information in particular may be relevant to the processing of the
> > SIP request.
> 
> IMO this is *too* vague.
> 
> For instance, I might want request that a call be routed *to* the phone
> closest to some geolocation. That location is also relevant to the
> processing of the request, but in an entirely different way.

Damn.  You would have to point out my big blind spot.  I've been concentrating on the routing-based-on-caller-location use case too long.

If we also consider that the location needs to be attributed to a particular entity, you can either add syntax that attempts to identify the entity that you are talking about (a "from" or "to" parameter might do this), or you can make the entity constant.  In the interest of simplicity, the latter seems more fashionable:

"
The Geolocation header identifies a source of location information.  This might be a PIDF-LO document that is identified by value or reference, or a geo: URI that includes location information directly.

A Geolocation header indicates that a) that this location information is somehow applicable to the entity that initiated the request and b) that this location information might be relevant to the processing of the SIP request.
"

This is almost the "bold" interpretation that says that this Target’s location should be considered the source of the request.  It does not imply that the Target and source are the same identity.  Nor does it expressly state that the source is actually located anywhere in particular, though we're walking a fairly fine line there.

--Martin