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

From: "Mark Watson"<[email-masked]>
Date: Mon, 15 Apr 2002 17:50:13 +0100

Rejecting non-anonymous requests when anonymity is required is all very
well, but a 2543 client will not know what to do in order to get its call
through. It will require user intervention. For every call. How will the
user know when anonymity is required ? The user does not want to be forced
into anonymity unless absolutely necessary, so they will always try
non-anonymous first.
 
It's not a question of 'badly behaved clients'. The client is well-behaved
and following the users instructions to be 'non-anonymous' - sure, the
client can prevent its identity being revealed, but the user does not want
this. The SUBSCRIBER wants anonymity, not the user.
 
You could standardise a way of communicating the subscriber's wishes to the
UA, and then enforce them. But how does this work for a forwarding user (or
their subscriber) who does not wish to be identified ?
 
...Mark

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: 15 April 2002 17:40
To: Watson, Mark [MDN05:EP10:EXCH]; Chiou, Mark; Dean Willis;
[email-masked]; [email-masked]
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

Yes, it is a long thread :-)
 
I pretty much agree with your original assessment for when the network
authenticates From, although I would propose a better behavior would be to
just disallow a request with a non-anonymous From header _and_ with privacy
requested. This approach is more backwards compatible (in case something
involved still freaks out about modified From headers), and a lot simpler to
implement in the network (no B2BUA required, at least for _this_ reason)
 
But in general, the requirement that a network must prevent a badly behaved
client from revealing its identity accidentally seems a bit excessive. It
should be sufficient to say that a client _can_ prevent its identity from
being revealed.

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

Ben,
 
I know this is a long thread, but I have addressed all these points before.
Please see below...

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: 15 April 2002 15:44
To: Chiou, Mark; Dean Willis; [email-masked]; [email-masked]
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

You pretty much have to assume that the receiving user sees _anything_ you
send his UA, except in the rare case where the user has no control over the
UA behavior. Asking a UAS to hide information from its owner is not useful
in the generic case.
 
I agree with Dean on this in general, although it really doesn't matter if
any _network_ inserted identification is there with the consent of the
originating user or not. A privacy request need _only_ apply to
network-inserted identification data. The UAC has every opportunity _not_ to
insert identification if it does not want to. 

It doesn't matter what device inserts the information. It matters whether it
is part of the service for the information to be inserted. If it is a part
of the service, then the responsibility lies with the Service Provider -
they defined the service and they are responsible for things the users do
effectively at their behest.
 
If I check the From: field I receive from my users is valid, then I am
forcing them to put either their identity or 'Anonymous' in there.
 
If there is then a privacy requirement arising from the rights of ANOTHER
PERSON, NOT THE USER, then I have to do something about this - I as the
Service Provider have the responsibility, not the user. An example is when
the *subscriber* has requested anonymity.
 
If I let my users use any old From value, then the situation is not so
clear, but I still argue that for fields whose intention is defined for
transport of a particular identity, then the Service Provider has some
responsibility. (cf Special Arrangements in the ISDN).

Expecting the network to screen out ID that _I_ provide is a slippery slope.
What if I put "call from Ben" in a Subject header? Do you screen that out as
well? What if I _tell_ the destination user who I am in an IM associated
with the call? What about the media session,? 

Personally, I don't think screening out the Subject would be necessary,
although there might be some market demand for services which did this.
Subject is a genuinely transparent field. There is no intention that it
contain your identity, and UAs are unlikely to insert your identity here
automatically.
 
...Mark

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Chiou, Mark
Sent: Monday, April 15, 2002 9:28 AM
To: Dean Willis; [email-masked]; [email-masked]
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

Dean wrote:
#####################################

The point I'm trying to make is that To and From are USER supplied
information. The Service Provider doesn't insert them, inspect them, or have
any responsibility for them. Insisting that the service provider change them
is just like insisting that the service provider change any other
user-supplied information, such as the words I'm typing now. Anything I put
in my To or from field is deliberately and explicitly intended to be
delivered to the terminating side of the dialog, and if as a service
provider you FAIL to do that, then you have DAMAGED my data, and my lawyers
will be in touch!
 
The calling-party-identity presentation infromation (CLIP or RPID) is NOT
inserted by the user. It is inserted by the network, WITHOUT THE CONSENT of
the user. As such, the operator is responsible for the protection of that
information in a manner consistent with regulation and the expressed wishes
of the user.
<snip>
 ##########################################################
No, The CLIP is inserted by the network WITH THE CONSENT of the user. When
you subscribe a line from a PSTN service provider, the form you filled
indicating whether you want your telephone number to be PUBLIC or PRIVATE.
(of course, the default is PUBLIC if you leave it blank.) When you make a
call, the PRIVATE or PUBLIC status value is retrieved and set the Address
Presentation Restricted Indicator (APRI) field in SS7 environment (Note
that, CLIR toggles the values), then the terminating side of the network
based on the APRI value to determine whether the Calling Party Number shall
be delivered to the callee's CPE.
 
Since we want to push the decision making to the UA, we should standardize
the rule such that the UA shall display the From information based on
Privacy indication. If we think that too many UAs won't follow this rule,
than we should allow the Service Provider of terminating side (not the
originating side) to alter the From information before terminating the call
to the UA based on the Privacy indication.
 
This is my penny thought,
 
Mark Chiou

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 15 Apr 2002 12:08:34 -0500

Message
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of Mark
Watson
  Sent: Monday, April 15, 2002 11:50 AM
  To: 'Ben Campbell'; Chiou, Mark; Dean Willis; [email-masked];
[email-masked]
  Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

  I'm not sure how a 2543 client will know how to request privacy in the
first place. And I assume that a user knows whether or not he wishes to make
an anonymous call. I cannot think of a _technical_ solution for helping a
user decide if a call should be anonymous or not.

   It's not a question of 'badly behaved clients'. The client is
well-behaved and following the users instructions to be 'non-anonymous' -
sure, the client can prevent its identity being revealed, but the user does
not want this. The SUBSCRIBER wants anonymity, not the user.

  I'm not sure what you mean--who is the subscriber, if not the user (i.e.
the person trying to place an anonymous call)?  (This may be the source of
my confusion in the previous paragraph. I was using the term "user" and
"subscriber" interchangeably.)

  You could standardise a way of communicating the subscriber's wishes to
the UA, and then enforce them. But how does this work for a forwarding user
(or their subscriber) who does not wish to be identified ?

  Presumadly if a UA supports anonymous calling, it must give the subscriber
some way of expressing the desire to do so. I don't see any need to
standardize that. Once the subscriber expresses that desire, it is up to the
UA to do things right (like, don't _automatically_ put user identifiable
information in headers, From or otherwise.)  A UA that pretends to support
anonymity but screws it up fits my definition of "badly behaved."

  ...Mark
    -----Original Message-----
    From: Ben Campbell [mailto:[email-masked]]
    Sent: 15 April 2002 17:40
    To: Watson, Mark [MDN05:EP10:EXCH]; Chiou, Mark; Dean Willis;

    But in general, the requirement that a network must prevent a badly
behaved client from revealing its identity accidentally seems a bit
excessive. It should be sufficient to say that a client _can_ prevent its
identity from being revealed.
      -----Original Message-----
      From: Mark Watson [mailto:[email-masked]]
      Sent: Monday, April 15, 2002 11:17 AM
      To: 'Ben Campbell'; Chiou, Mark; Dean Willis; [email-masked];
[email-masked]

      Ben,

      I know this is a long thread, but I have addressed all these points
before. Please see below...
        -----Original Message-----
        From: Ben Campbell [mailto:[email-masked]]
        Sent: 15 April 2002 15:44
        To: Chiou, Mark; Dean Willis; [email-masked]; [email-masked]
        Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

        You pretty much have to assume that the receiving user sees
_anything_ you send his UA, except in the rare case where the user has no
control over the UA behavior. Asking a UAS to hide information from its
owner is not useful in the generic case.

        I agree with Dean on this in general, although it really doesn't
matter if any _network_ inserted identification is there with the consent of
the originating user or not. A privacy request need _only_ apply to
network-inserted identification data. The UAC has every opportunity _not_ to
insert identification if it does not want to.
      It doesn't matter what device inserts the information. It matters
whether it is part of the service for the information to be inserted. If it
is a part of the service, then the responsibility lies with the Service
Provider - they defined the service and they are responsible for things the
users do effectively at their behest.

      If there is then a privacy requirement arising from the rights of
ANOTHER PERSON, NOT THE USER, then I have to do something about this - I as
the Service Provider have the responsibility, not the user. An example is
when the *subscriber* has requested anonymity.

      If I let my users use any old From value, then the situation is not so
clear, but I still argue that for fields whose intention is defined for
transport of a particular identity, then the Service Provider has some
responsibility. (cf Special Arrangements in the ISDN).
        Expecting the network to screen out ID that _I_ provide is a
slippery slope. What if I put "call from Ben" in a Subject header? Do you
screen that out as well? What if I _tell_ the destination user who I am in
an IM associated with the call? What about the media session,?

      Personally, I don't think screening out the Subject would be
necessary, although there might be some market demand for services which did
this. Subject is a genuinely transparent field. There is no intention that
it contain your identity, and UAs are unlikely to insert your identity here
automatically.

      ...Mark

         -----Original Message-----
        From: [email-masked] [mailto:[email-masked]]On Behalf Of
Chiou, Mark
        Sent: Monday, April 15, 2002 9:28 AM
        To: Dean Willis; [email-masked]; [email-masked]
        Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

          Dean wrote:

          The calling-party-identity presentation infromation (CLIP or RPID)
is NOT inserted by the user. It is inserted by the network, WITHOUT THE
CONSENT of the user. As such, the operator is responsible for the protection
of that information in a manner consistent with regulation and the expressed
wishes of the user.
          <snip>
           ##########################################################
          No, The CLIP is inserted by the network WITH THE CONSENT of the
user. When you subscribe a line from a PSTN service provider, the form you
filled indicating whether you want your telephone number to be PUBLIC or
PRIVATE. (of course, the default is PUBLIC if you leave it blank.) When you
make a call, the PRIVATE or PUBLIC status value is retrieved and set the
Address Presentation Restricted Indicator (APRI) field in SS7 environment
(Note that, CLIR toggles the values), then the terminating side of the
network based on the APRI value to determine whether the Calling Party
Number shall be delivered to the callee's CPE.

          Since we want to push the decision making to the UA, we should
standardize the rule such that the UA shall display the From information
based on Privacy indication. If we think that too many UAs won't follow this
rule, than we should allow the Service Provider of terminating side (not the
originating side) to alter the From information before terminating the call
to the UA based on the Privacy indication.

          Mark Chiou