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

Hadriel Kaplan <HKaplan@acmepacket.com> Mon, 08 November 2010 22:04 UTC

Return-Path: <HKaplan@acmepacket.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 3F5903A68AE for <sipcore@core3.amsl.com>; Mon, 8 Nov 2010 14:04:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.841
X-Spam-Level:
X-Spam-Status: No, score=-0.841 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_74=0.6, RDNS_NONE=0.1]
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 desAQubigr+n for <sipcore@core3.amsl.com>; Mon, 8 Nov 2010 14:04:17 -0800 (PST)
Received: from ETMail2.acmepacket.com (unknown [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id 4DF1F3A68D5 for <sipcore@ietf.org>; Mon, 8 Nov 2010 14:04:17 -0800 (PST)
Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 8 Nov 2010 17:04:39 -0500
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 8 Nov 2010 17:04:38 -0500
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: "<R.Jesske@telekom.de> <R.Jesske@telekom.de>" <R.Jesske@telekom.de>
Date: Mon, 08 Nov 2010 17:04:34 -0500
Thread-Topic: AW: [sipcore] Yet more comments on rfc4244bis-02
Thread-Index: Act/kO6EzKExWkAuSLeRG1PhsUYvkA==
Message-ID: <DC8C3A6A-1DD1-4CCC-BBD9-37B6037FCCCD@acmepacket.com>
References: <A444A0F8084434499206E78C106220CA0235546D2F@MCHP058A.global-ad.net><A5DC4410-2B76-4EC6-B39A-1FFF5F04B853@ntt-at.com><AANLkTikXeBRvTaDg8ZX+TsqG_ZL24FUiQFf2se5UAgcm@mail.gmail.com><4CD7CF13.5000005@cisco.com><A5E1BEC3-6E39-4247-A826-B36E4AEB9B31@ntt-at.com> <55338E45-63A9-43F2-9983-85252365B73F@acmepacket.com> <9886E5FCA6D76549A3011068483A4BD406D5D1D4@S4DE8PSAAQB.mitte.t-com.de>
In-Reply-To: <9886E5FCA6D76549A3011068483A4BD406D5D1D4@S4DE8PSAAQB.mitte.t-com.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAUA=
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
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: Mon, 08 Nov 2010 22:04:18 -0000

Right but isn't that done with the _embedded_ Privacy header in the H-I URI?  I was talking about the Privacy header of the request message itself - that's what I meant by "(I mean a real Privacy header in the message, not an embedded one in a particular HI URI)".  Sorry for the confusion.

-hadriel



On Nov 8, 2010, at 10:18 AM, <R.Jesske@telekom.de> <R.Jesske@telekom.de> wrote:

> Hi Hadriel,
> is has also an other reason. When you send from the retargeting SIP Server an call Forwarding (Retargeting) notification in backward direction (181 Response) with an History Info, the target should be marked as private, because the retargeting server has no knowledge about the privacy instructions of the terminating user.
> 
> Best Regards
> 
> Roland
> 
> -----Ursprüngliche Nachricht-----
> Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag von Hadriel Kaplan
> Gesendet: Montag, 8. November 2010 16:02
> An: Shida Schubert
> Cc: sipcore@ietf.org
> Betreff: 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