Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

From: "Mark Watson"<[email-masked]>
Date: Tue, 16 Apr 2002 11:31:20 +0100

The client capability issue was for the case where the user does not wish to
remain anonymous, but the subscriber does.

Without a network modification of the From field then:

1) The user includes their identity, and the session is rejected. There is
no reject code which clearly indicates what action the user/UA should take.
There will be no current UAs which would know to auto-retry with
'Anonymous', so this will require user intervention on all calls.
Auto-retrys are no good for wireless anyway.

2) It was suggested that the client should have a 'always anonymous' option
which the user can set, so that all calls via this subscription will be
anonymous. Again, current clients may or may not have this, so relying on
this to provide the 'subscriber anonymity' service without the retrys of (1)
is not such a good idea unless you have clearly told subscribers - before
they subscribe - that such a capability is needed.

Service Providers need to be well aware of the client capabilities needed to
implement the regulatory services they have to provide, so that they can
make it clear to potential subscribers what those required client
capabilities are.

Even so, I really can't see all the above being realistic. Imagine a
subscriber goes to their service provider and requests anonymity. The first
thing that happens is that all calls through the subscription start failing
with some 'Privacy violation' response code. 'Oh sorry,' says the Service
Provider, 'but you asked for all calls to be anonymous and then carried on
trying to make non-anonymous calls. You'll need to tell all the users to
change their settings to anonymous'.

Whilst heamoraging money due to lost business, as none of their employees
can make calls, the subscriber makes the not unreasonable point that they
could tell all their users to switch to anonymous calls anyway, without
asking the Service Provider, so what is the point of their regulatory right
to an anonymity service ??

It has to work in a manner which is transparent and simple to the users and
subscriber. If you want a client-based solution to this service, then you
need to standardise a way of automatically informing & updating clients
about the subscription anonymity policy. Still doesn't work for forwarding
users.

The alternative is to accept that From/To modification in the network is
required to implement these services & no standardisation is required.

....Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 16 April 2002 11:10
> To: Watson, Mark [MDN05:EP10:EXCH]
> Cc: 'Ben Campbell'; Chiou, Mark; Dean Willis; [email-masked];
> [email-masked]
> Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft
> 
> 
> the current bis-09 text says:
> 
> The From header field allows for a display name. A UAC SHOULD use the
> display name  Anonymous , along with a syntactically correct, but
> otherwise meaningless URI (like sip:[email-masked]), if
> the identity of the client is to remain hidden.
> 
> this is all that is needed except that in my service the uri must be
> meaningful.
> 
> most UAs on the market support this.  so fail to see what the 
> issue is.
> 
> -- juha
> 
>

---

From: [email-masked]
Date: Tue, 16 Apr 2002 13:58:39 +0300

> remain anonymous, but the subscriber does.

what is a subscriber and how does it differ from a user?  where is the
term subscriber defined?

 > Auto-retrys are no good for wireless anyway.

this whole hassle seems to originate from your subscriber business.  i
don't see any need to a subscriber that is not the same as the user.  is
this again some 3gpp thing?

 > they subscribe - that such a capability is needed.

as i said, most client that i have see do already have this "always
anonymous" option.  i don't see any need to complicate the sip specs for
those clients that don't because the implementation is trivial. 

 > make it clear to potential subscribers what those required client

i have no problem with that.  already know we need to test the clients
and give recommendations to users.

 > change their settings to anonymous'.

this is no problem, because the user requests anonymity by using
Anonymous in the display string.  it is not a subscription option.  all
subscriptions look the same in this regard.

 > to an anonymity service ??

it makes no sense to try to emulate stupid pstn phones using with sip
UAs.  we can and should assume that a sip UA is a user configurable
beast.  therefore, the user itself can decide either permanently or on a
call by call basis if it wants anonymity or not.

 > about the subscription anonymity policy. Still doesn't work for forwarding

as i have said, there is no such thing as subscription anonymity policy.

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 16 Apr 2002 17:38:33 -0700 (Pacific Daylight Time)

Mark,

I have a real problem with the way you have defined or envisioned a
privacy service.  Please see below...

On Tue, 16 Apr 2002, Mark Watson wrote:
> subscriber goes to their service provider and requests anonymity.

A user who wants privacy of their self-revealed information has two very
reasonable choices, both of which are possible using baseline SIP (either
2543 or 3261).  Note that this is a very separate problem from
network-asserted identity used for PSTN interop, call trace, and call
return services.

1) The subscriber can configure their user agent not to reveal most types
of private information.

2) A provider can insert an anonymizing B2BUA (with or without media
anonymity) into the signaling path before forwarding outside its network.

I do not buy the argument that we need the network to provide this
service, but that it is somehow a burden for the network to implement this
service using a B2BUA.

thanks,
-rohan

> The first