Re: [sipcore] composition or just indirection

Paul Kyzivat <pkyzivat@cisco.com> Wed, 21 July 2010 01:33 UTC

Return-Path: <pkyzivat@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 78C103A69C0 for <sipcore@core3.amsl.com>; Tue, 20 Jul 2010 18:33:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.499
X-Spam-Level:
X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 L1eULzT5dUq1 for <sipcore@core3.amsl.com>; Tue, 20 Jul 2010 18:33:01 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 040553A69B9 for <sipcore@ietf.org>; Tue, 20 Jul 2010 18:33:00 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 21 Jul 2010 01:33:16 +0000
Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6L1XGo6021521; Wed, 21 Jul 2010 01:33:16 GMT
Message-ID: <4C464E5C.6000607@cisco.com>
Date: Tue, 20 Jul 2010 21:33:16 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: "Thomson, Martin" <Martin.Thomson@andrew.com>
References: <8B0A9FCBB9832F43971E38010638454F03EB772EBB@SISPE7MB1.commscope.com> <C86A11BF.41D5D%jon.peterson@neustar.biz> <8B0A9FCBB9832F43971E38010638454F03EB7730BA@SISPE7MB1.commscope.com> <4C459BD7.9050007@cisco.com> <8B0A9FCBB9832F43971E38010638454F03EB773153@SISPE7MB1.commscope.com>
In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03EB773153@SISPE7MB1.commscope.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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: Wed, 21 Jul 2010 01:33:04 -0000

Thomson, Martin wrote:
>> 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.

You're welcome :-)

> 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.

This sounds plausible to me, but I have not been following this stuff 
closely and so am not familiar with all the sensitivities.

	Thanks,
	Paul