Re: [Sip] a question about IETF draft location conveyance 09

Ted Hardie <hardie@qualcomm.com> Wed, 21 November 2007 23:36 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuz7M-0005sN-4L; Wed, 21 Nov 2007 18:36:28 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iuz7K-0005sB-Qd for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 18:36:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuz7K-0005s3-HC for sip@ietf.org; Wed, 21 Nov 2007 18:36:26 -0500
Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuz7G-000367-UM for sip@ietf.org; Wed, 21 Nov 2007 18:36:26 -0500
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lALNaLR1023301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Nov 2007 15:36:21 -0800
Received: from [67.169.50.136] (carbuncle.qualcomm.com [129.46.226.27]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lALNaK3X010787; Wed, 21 Nov 2007 15:36:20 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p0624060ac36a6ec4f1c2@[67.169.50.136]>
In-Reply-To: <XFE-SJC-212AOmAfjuU000013bb@xfe-sjc-212.amer.cisco.com>
References: <4742BDF5.9040302@unibo.it> <XFE-SJC-212qXLFfJNw000012bf@xfe-sjc-212.amer.cisco.com> <p06240607c36a38613297@[67.169.50.136]> <XFE-SJC-211EAOeIiGX000013f8@xfe-sjc-211.amer.cisco.com> <p06240608c36a4849ecf3@[67.169.50.136]> <XFE-SJC-212AOmAfjuU000013bb@xfe-sjc-212.amer.cisco.com>
Date: Wed, 21 Nov 2007 15:36:18 -0800
To: "James M. Polk" <jmpolk@cisco.com>, Daniel Grotti <daniel.grotti@unibo.it>, IETF SIP List <sip@ietf.org>
From: Ted Hardie <hardie@qualcomm.com>
Subject: Re: [Sip] a question about IETF draft location conveyance 09
Content-Type: text/plain; charset="us-ascii"
X-PerlMx: Message inspected by PerlMx
X-PerlMx: Message inspected by PerlMx
X-Spam-Score: -4.0 (----)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc:
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At 4:18 PM -0600 11/21/07, James M. Polk wrote:
>\
>Ted -- This header parameter is for a PIDF-LO, yes -- but it pertains to the SIP WG's expertise in knowing and agreeing with SIP's ability to foresee the type of topology from UAC to UAS, and each server (whether there even is one) in between.  I'm not so sure the SIP WG agrees that a UAC can make this determination, and am soliciting their input here in a broad way.
>
>Can a UAC understand enough about the topology of the Internet to understand where it is sending a request, including how SIP servers may or may not act upon that request?
>
>I believe, if the answer is no, the the "recipient=" parameter is a flawed SIP header parameter.
>
>If the answer is yes, then it stays with no further arguments from me.


I think we have fundamentally different ideas of how much understanding of the
topology this implies.  My view is that the header as currently specified says
either "This is meant for the person answering the call/taking the session" or
"This is meant to help get the call through/get the session to the right responder".
Within the latter case, it requires no knowledge at all of topology; it does
not distinguish among the many different routing elements which might be
trying to make that happen. 

A UA that does not care whether it is used for routing can enter "both"
and all is well.  A UA that *wants* it to be used this way can enter "routing-entity".
The availability of "endpoint" as a separate possibility makes sure that
an endpoint can indicate that use by the routing system is not intended. 
If the SIP community believes "routing-entity" is too vague
and needs to be broken out, I do not see how the GeoPRIV could object or
why it would want to; certainly this working group should have the final word
on that.  But collapsing things so that entering "endpoint" is
not an indicator to the routing entities that they should just pass things along
would find opposition (at the very least from me).  That would break a pretty
fundamental assumption that users are in control of the pidf-lo distributions.

Hope you have a great Thanksgiving,
				Ted


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip