RE: [Sip] RE: Question on draft-ietf-sip-asserted-identity-02
"Cullen Jennings" <fluffy@cisco.com> Wed, 23 October 2002 16:33 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24683 for <sip-archive@odin.ietf.org>; Wed, 23 Oct 2002 12:33:18 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9NGZ9W09471 for sip-archive@odin.ietf.org; Wed, 23 Oct 2002 12:35:09 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NGY9v09391; Wed, 23 Oct 2002 12:34:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NGWjv09305 for <sip@optimus.ietf.org>; Wed, 23 Oct 2002 12:32:45 -0400
Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24594 for <sip@ietf.org>; Wed, 23 Oct 2002 12:30:22 -0400 (EDT)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9NGWVcl015896; Wed, 23 Oct 2002 09:32:31 -0700 (PDT)
Received: from fluffyw2k (dhcp-128-107-142-114.cisco.com [128.107.142.114]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id AAM34747; Wed, 23 Oct 2002 09:32:59 -0700 (PDT)
From: Cullen Jennings <fluffy@cisco.com>
To: Mpierce1@aol.com, jon.peterson@neustar.biz, sunayak@hss.hns.com, sip@ietf.org, mwatson@nortelnetworks.com
Subject: RE: [Sip] RE: Question on draft-ietf-sip-asserted-identity-02
Date: Wed, 23 Oct 2002 09:32:33 -0700
Message-ID: <IOELLHIFFNFPHNDEMKCPAEEKEKAA.fluffy@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <21.262f6b8c.2ae7f66c@aol.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
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>
Content-Transfer-Encoding: 7bit
The privacy provided by this system is only as good in as much as you can trust the provider providing the privacy service. Let me explain this confusing statement. Say I, fluffy, have a SIP phone. I have some sort of subscriber contract with service.com. I set my outbound proxy to service.com and send them a call and request privacy. Regardless of what number I dialed, service.com can choose to do anything they want with this information. The only thing I can do is take legal action if they do something other than what my contract with them says they will do. I would hope that my contract would say that they would always anonymize the call and if that was not legally possible they would reject it and the only exception to this would be a E911 call. I can easily imagine it will say they make no guarantees about ever anonymizing anything and if it happened to work you got lucky and all the liability of this was yours and if you ever sued them they got to take your first born. Cullen -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Wednesday, October 23, 2002 5:56 AM To: jon.peterson@neustar.biz; sunayak@hss.hns.com; sip@ietf.org; fluffy@cisco.com; mwatson@nortelnetworks.com Subject: Re: [Sip] RE: Question on draft-ietf-sip-asserted-identity-02 In a message dated 10/23/2002 5:41:00 AM W. Europe Daylight Time, jon.peterson@neustar.biz writes: We make no provision in any of these privacy/identity drafts, as far as I can recall for cases in which a privacy service has policies that preclude user requests for privacy. This would be comparable to the telephone network rejecting your attempt to dial *67. Personally, I am not interested in standardizing any case in which a privacy service with the relevant capabilities would purposefully refuse to fulfill a user's request for privacy. I suppose that if you were to implement this as a non-standard mechanism, your option (a) would be vastly preferable (and would follow the spirit of Section 5 of the privacy draft). [MAP] I'm not sure if it is an example of what you referred to as "the telephone network rejecting your attempt to dial *67", but today, dialing *67 should have no effect on the delivery of the calling identity to the other end when you dial an "800" number or 911 in the US. In addition, I remember some years ago that the PUC in Florida approved the assignment of a special office code that would override the originator's request for privacy when they dialed *67 followed by a number in that office code. It was just a regular looking telephone number (not something recognizable like 800) that would always get the calling line ID. And it was not intended specifically for police departments, etc. In this case, the calling user's request for "privacy" was ignored. These are not cases in which the privacy service refuses to fulfil the user's request or rejects the *67, but rather, ones in which some other service takes precedence. Is the "asserted identity" draft taking these types of cases into account? Mike Pierce Artel _______________________________________________ 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] Question on draft-ietf-sip-asserted-identit… sunayak
- [Sip] RE: Question on draft-ietf-sip-asserted-ide… Peterson, Jon
- Re: [Sip] RE: Question on draft-ietf-sip-asserted… Mpierce1
- RE: [Sip] RE: Question on draft-ietf-sip-asserted… Cullen Jennings