R: [Sip] a question about IETF draft location conveyance 09
"daniel grotti" <daniel.grotti@unibo.it> Thu, 22 November 2007 16:57 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 1IvFMR-0004l2-F4; Thu, 22 Nov 2007 11:57:07 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IvFMP-0004kO-8B for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 11:57:05 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFMO-0004k9-T5 for sip@ietf.org; Thu, 22 Nov 2007 11:57:04 -0500
Received: from poster.unibo.it ([137.204.24.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvFMO-0005Mt-71 for sip@ietf.org; Thu, 22 Nov 2007 11:57:04 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by poster.unibo.it (Postfix) with ESMTP id 52268452; Thu, 22 Nov 2007 17:57:03 +0100 (CET)
Received: from EXBK03 (unknown [137.204.25.211]) by poster.unibo.it (Postfix) with ESMTP id E981F8B; Thu, 22 Nov 2007 17:56:52 +0100 (CET)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: R: [Sip] a question about IETF draft location conveyance 09
Date: Thu, 22 Nov 2007 17:56:52 +0100
Message-ID: <A30B7FF9263D5340AD5DECB88A243C42015FEE65@EXBK03.personale.dir.unibo.it>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] a question about IETF draft location conveyance 09
Thread-Index: Acgsl9IvrmTIh6AAQ8CwTy/zYck4hgAjkBVB
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> <p0624060ac36a6ec4f1c2@[67.169.50.136]>
From: daniel grotti <daniel.grotti@unibo.it>
To: Ted Hardie <hardie@qualcomm.com>, "James M. Polk" <jmpolk@cisco.com>, IETF SIP List <sip@ietf.org>
X-Virus-Scanned: Cineca AppOs 1.00 at poster.unibo.it
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
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
I believe that if a UA puts "recipient=routing-entity" paramenter into locationValue, the location information should be read only by Proxy Server for location-based routing. But if a UA wants its own location information to be known and seen by endusers, then UA have to insert the "recipient=endpoints" paramenter. In this case Proxy server, from my view, should only forward the message to the destination. UA would just like to bring its own location to an endpoint, and could not interested in location-based routing. Does this make sense? Regards, Daniel ----------------------------- Daniel Grotti DEIS - Universita' di Bologna ----------------------------- Via Venezia, 52 47023 Cesena (FC) - ITALY ----------------------------- email:daniel.grotti@unibo.it ----------------------------- -----Messaggio originale----- Da: Ted Hardie [mailto:hardie@qualcomm.com] Inviato: gio 11/22/2007 12:36 A: James M. Polk; daniel grotti; IETF SIP List Oggetto: Re: [Sip] a question about IETF draft location conveyance 09 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
- [Sip] a question about IETF draft location convey… Daniel Grotti
- Re: [Sip] a question about IETF draft location co… James M. Polk
- Re: [Sip] a question about IETF draft location co… Ted Hardie
- Re: [Sip] a question about IETF draft location co… James M. Polk
- Re: [Sip] a question about IETF draft location co… Ted Hardie
- Re: [Sip] a question about IETF draft location co… James M. Polk
- Re: [Sip] a question about IETF draft location co… Ted Hardie
- Re: [Sip] a question about IETF draft location co… Dean Willis
- R: [Sip] a question about IETF draft location con… daniel grotti
- Re: R: [Sip] a question about IETF draft location… Hannes Tschofenig
- R: R: [Sip] a question about IETF draft location … daniel grotti
- Re: R: R: [Sip] a question about IETF draft locat… Hannes Tschofenig
- R: R: R: [Sip] a question about IETF draft locati… daniel grotti
- Re: R: R: [Sip] a question about IETF draft locat… Dean Willis
- R: R: R: [Sip] a question about IETF draft locati… daniel grotti
- RE: R: R: [Sip] a question about IETF draft locat… DRAGE, Keith (Keith)
- RE: R: R: [Sip] a question about IETF draft locat… James M. Polk
- Re: R: R: [Sip] a question about IETF draft locat… Matt Lepinski
- Re: R: R: [Sip] a question about IETF draft locat… James M. Polk
- RE: R: R: [Sip] a question about IETF draft locat… Ted Hardie
- Re: R: R: [Sip] a question about IETF draft locat… Ted Hardie
- Re: R: R: [Sip] a question about IETF draft locat… Dean Willis
- Re: R: R: [Sip] a question about IETF draft locat… James M. Polk
- Re: R: [Sip] a question about IETF draft location… James M. Polk
- Re: [Sip] a question about IETF draft location co… James M. Polk
- Re: R: [Sip] a question about IETF draft location… Paul Kyzivat