Re: [sipcore] Yet more comments on rfc4244bis-02

Paul Kyzivat <pkyzivat@cisco.com> Tue, 09 November 2010 00:10 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 10F8D28C0E7 for <sipcore@core3.amsl.com>; Mon, 8 Nov 2010 16:10:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.199
X-Spam-Level:
X-Spam-Status: No, score=-110.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 pst4INuiw8Vi for <sipcore@core3.amsl.com>; Mon, 8 Nov 2010 16:10:32 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2B1CA3A6860 for <sipcore@ietf.org>; Mon, 8 Nov 2010 16:10:32 -0800 (PST)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjYFAK8f2ExAaMHG/2dsb2JhbACUHI4BcaE0m3KCcoJWBIRYhX2DCg
X-IronPort-AV: E=Sophos;i="4.59,172,1288569600"; d="scan'208";a="378876011"
Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-1.cisco.com with ESMTP; 09 Nov 2010 00:10:54 +0000
Received: from [10.75.234.6] (hkidc-vpn-client-234-6.cisco.com [10.75.234.6]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA90Al0P015824 for <sipcore@ietf.org>; Tue, 9 Nov 2010 00:10:49 GMT
Message-ID: <4CD89186.9050604@cisco.com>
Date: Mon, 08 Nov 2010 19:10:46 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: sipcore@ietf.org
References: <708708.88960.qm@web29117.mail.ird.yahoo.com>
In-Reply-To: <708708.88960.qm@web29117.mail.ird.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [sipcore] Yet more comments on rfc4244bis-02
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, 09 Nov 2010 00:10:35 -0000

On 11/8/2010 1:17 PM, Ian Elz wrote:
> Hadriel,
>
> Roland missed one other case in his reply.
>
> If I divert a call I may want my identity to be private even if the original caller allows his identity to be presented; i.e. I don't want the final destination of the call to know the identity of the diverting party.

Won't your identity still be present in the To URI?

	Thanks,
	Paul

> Ian Elz
>
> ----- Original Message -----
> From: "Hadriel Kaplan"<HKaplan@acmepacket.com>
> To: "Shida Schubert"<shida@ntt-at.com>
> Cc: sipcore@ietf.org
> Sent: Monday, 8 November, 2010 3:01:39 PM
> Subject: Re: [sipcore] Yet more comments on rfc4244bis-02
>
>
>
> On Nov 8, 2010, at 6:01 AM, Shida Schubert wrote:
>
>> Privacy:none is used when caller (UAC) wants his/her identity delivered
>> to the destination (callee) despite the existence of privacy service, but
>> with regards to H-I, when does it ever contain the URI that identifies the
>> caller (UAC) ?
>> I agree that privacy:none will be valid if we can find a situation where
>> URI of UA will be one of the hi-entry but my imagination is not strong
>> enough to see this.
>
> But that also begs the question of why we need a Privacy header of "history" to begin with. (I mean a real Privacy header in the message, not an embedded one in a particular HI URI)
>
> The only case I could imagine for such things is that the caller doesn't want their domain known about.  I.e., I make an anonymous call from my SIP phone through my corporate SIP proxy, and my SIP phone sets "Privacy: history" so that Acme Packet's anonymization proxy removes "acmepacket.com" from any H-Is, before sending it out our SIP trunk, etc.
>
> -hadriel
>
>
>
>
>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>