Re: [Sip] RE: Question on draft-ietf-sip-asserted-identity-02

[Mpierce1@aol.com]

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