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

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

Ben wrote:

Which then allows the user to decide whether or not to continue according to
policy, or just not make the call. Otherwise, the network seems to be in the
business of deciding that the user really does not mind if the call is
anonymous. That seems fairly benign in this particular case, but not
generically (what if the policy was _no_ anonymous calls.) 

A 'no anonymous calls' policy would be in breach of the users right to make
anonymous calls. It is not the network that is deciding that the user does
not mind if the call is anonymous, it is the subscriber, and they have a
legal right to do this. The subscribe must be able to control what
information the network reveals about them. The user does not have the right
to ask the network to reveal information that the subscriber does not want
revealed - although the use can of course reveal the information themselves.

2) Even with a well-crafted UA, why is the _user_ expected to re-configure
their client because of the _subscriber's_ wishes. And when the policy
changes, how will we indicate to all the users that they should now
re-configure their clients again ? 
 
They don't have to. Doing so just cuts down on the
reject-due-to-policy-violation-oops-retry cycles. Now, I assume the user
must have some relationship with the subscriber (else how does he have
credentials), and the subscriber _could_ just tell the user. Not everything
has to be automatic. 

Frequent reject-due-to- policy-violation-oops-retry cycles are just
unaceptable for wireless environments. There must be a 'works first time'
solution. If you think the user needs to be informed that their call has
become anonymous, then fine, let's standardise this indication.

I hope all the Service Providers wanting to launch SIP services have got
their list of client requirements worked out. If your subscriber asks for
this anonymity service they will not be impressed if they have to
upgrade/re-configure all their clients. If you didn't inform them in advance
that the clients needed these capabilities, then they could refuse to
upgrade and still demand the anonymity service. 
 
Well, once the idea of an anonymity service is fully formed (presumably what
we are doing here) it makes sense that it is a feature that a client can
support or not support. (Maybe even a supported or requires tag?) Then it is
reasonable for a service provider to say you can make anonymous calls if
your client supports anonymity. If a subscriber has a policy of _only_
anonymous calls, and a user has a client that cannot make anonymous calls,
then he is SOL.  I don't see why this is any different than any _other_
situation where an optional client feature might be required by SP or
subscriber policy. Again, the alternative is a presumption on the networks
part that it knows what the user _really_ means to do better than the user
does. Such an presumption on policy violations scares me in the generic
sense.  

It's different because the 'subscriber policy' feature is not just a groovy
addition to the service, but something that the Service Provide must provide
for the subscriber 'by a simple means' (in the words of the European
legislation) by which they mean I make a phone call to my Service Provider
and ask. Upgrading possibly hundreds of clients might not be considered a
'simple means'.
 
Again, not a question of knowing what the user 'wants' - in this case the
subscribers wishe's overrule the users wishe's - we know the user wants to
reveal their identity but in this case the user is 'SOL'.
 
...Mark

---

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

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

_______________________________________________
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: "Ben Campbell" <[email-masked]>
Date: Tue, 16 Apr 2002 08:12:12 -0500

Message
  -----Original Message-----
  From: Mark Watson [mailto:[email-masked]]
  Sent: Tuesday, April 16, 2002 4:21 AM
  To: 'Ben Campbell'; Chiou, Mark; Dean Willis; [email-masked];
[email-masked]
  Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

  Ben wrote:
      Which then allows the user to decide whether or not to continue
according to policy, or just not make the call. Otherwise, the network seems
to be in the business of deciding that the user really does not mind if the
call is anonymous. That seems fairly benign in this particular case, but not
generically (what if the policy was _no_ anonymous calls.)
  A 'no anonymous calls' policy would be in breach of the users right to
make anonymous calls. It is not the network that is deciding that the user
does not mind if the call is anonymous, it is the subscriber, and they have
a legal right to do this. The subscribe must be able to control what
information the network reveals about them. The user does not have the right
to ask the network to reveal information that the subscriber does not want
revealed - although the use can of course reveal the information themselves.

  I was referring to a no anonymous calls policy on the part of the
subscriber.
      2) Even with a well-crafted UA, why is the _user_ expected to
re-configure their client because of the _subscriber's_ wishes. And when the
policy changes, how will we indicate to all the users that they should now
re-configure their clients again ?

  A wireless network is one in which the network tends to excercise a lot
more control over the UA than might be typical for other environments. It
this case, the network is likely to be able to push configuration to the
phone itself (i.e. the config for "what default privacy option to use".
(This of course makes the b2bua changing From headers more feasible as well,
as wireless providers tend to have fewer qualms about asserting this level
of control.)
      I hope all the Service Providers wanting to launch SIP services have
got their list of client requirements worked out. If your subscriber asks
for this anonymity service they will not be impressed if they have to
upgrade/re-configure all their clients. If you didn't inform them in advance
that the clients needed these capabilities, then they could refuse to
upgrade and still demand the anonymity service.

      Well, once the idea of an anonymity service is fully formed
(presumably what we are doing here) it makes sense that it is a feature that
a client can support or not support. (Maybe even a supported or requires
tag?) Then it is reasonable for a service provider to say you can make
anonymous calls if your client supports anonymity. If a subscriber has a
policy of _only_ anonymous calls, and a user has a client that cannot make
anonymous calls, then he is SOL.  I don't see why this is any different than
any _other_ situation where an optional client feature might be required by
SP or subscriber policy. Again, the alternative is a presumption on the
networks part that it knows what the user _really_ means to do better than
the user does. Such an presumption on policy violations scares me in the
generic sense.
  It's different because the 'subscriber policy' feature is not just a
groovy addition to the service, but something that the Service Provide must
provide for the subscriber 'by a simple means' (in the words of the European
legislation) by which they mean I make a phone call to my Service Provider
and ask. Upgrading possibly hundreds of clients might not be considered a
'simple means'.

  ...Mark