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