Subject: [Sipping] SIP Conferencing and Invitee-list thoughts with possible Consent tie-in

From: Dean Willis <[email-masked]>
Date: Thu, 14 Apr 2005 02:07:03 -0500

OMA apparently has a requirement that people who are invited to a 
conference can see the entire list of other people invited to that 
conference before responding to the conference invitation.

As I think about it, it seems to me that we've sort of built the "bcc" 
function into conferencing using URI-lists and the consent framework. 
Do we need to build in a "cc" function as well?

One approach would be that the device generating the conference INVITES 
would add a header or a body part that either contains or references 
the invitee list. That seems relatively straightforward, but may 
require some agreements on mechanism.

However, lets consider this from a "consent framework" model.

New email users often CC jokes to a big list of friends. This has the 
side effect of exposing every address on the list to every recipient of 
the message, often creating a snowball effect of reply-alls and 
spam-harvesting.

With the consent framework as we currently have it, a consenter grants 
an exploder permission to include said consenter in requests exploded 
from a specific source. However, the consenter doesn't grant the 
exploder permission to send his SIP address to every other recipient of 
the exploded request.

Do we need a second permission operation here?

--
Dean

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

---

From: David R Oran <[email-masked]>
Date: Thu, 14 Apr 2005 08:11:32 -0400

On Apr 14, 2005, at 3:07 AM, Dean Willis wrote:

> One approach would be that the device generating the conference 
> INVITES would add a header or a body part that either contains or 
> references the invitee list. That seems relatively straightforward, 
> but may require some agreements on mechanism.
>
> side effect of exposing every address on the list to every recipient 
> of the message, often creating a snowball effect of reply-alls and 
> spam-harvesting.
>
> exploder permission to send his SIP address to every other recipient 
> of the exploded request.
>
Yes.

David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: [email-masked]
Date: Thu, 14 Apr 2005 08:58:06 -0500

Though I agree on all points with Dean here, there is a nagging discomfort
for a number of reasons:

- Where is the line drawn between standardizing an application
(conferencing) and a standard protocol required for the Internet to work?

- How much design can be made by committee (at least two IETF WGs), before
even having implementations on which to base emerging standards?

Thanks, Henry

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Thursday, April 14, 2005 2:07 AM
To: sipping WG
Subject: [Sipping] SIP Conferencing and Invitee-list thoughts with
possibleConsent tie-in

--
Dean

---

From: Aki Niemi <[email-masked]>
Date: Thu, 14 Apr 2005 17:14:34 +0300

Inline.

ext Dean Willis wrote:
--snip
> Do we need a second permission operation here?

Well, I'd say that the permission operation needs additional parameters. 
  So instead of a simple boolean argument, the operation should probably 
carry an object that can have this "do-not-redistribute-my-identity" 
flag set (among possibly others?).

Cheers,
Aki

---

From: David R Oran <[email-masked]>
Date: Thu, 14 Apr 2005 10:27:26 -0400

> (conferencing) and a standard protocol required for the Internet to 
This gives me less discomfort because the problem is generic to any 
form of exploder and is not restricted to conferencing, centralized or 
otherwise. Dean's point is that it may be desirable to separate out the 
permission to  have a given sender issue you requests via an exploder 
from the permission for the exploder to tell the other receivers of the 
request that you were a receiver too.

> even having implementations on which to base emerging standards?
Seems like we can defer this since it's a nice-to-have add-on, but it 
may/should be easy to add if we in fact have the exploder, conference 
framework, and consent framework design right. In fact, this is a good 
test case for extensibility.

Dave.

David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: David R Oran <[email-masked]>
Date: Thu, 14 Apr 2005 10:48:34 -0400

On Apr 14, 2005, at 10:14 AM, Aki Niemi wrote:

> Inline.
>
> ext Dean Willis wrote:
> --snip
>> With the consent framework as we currently have it, a consenter 
>> grants an exploder permission to include said consenter in requests 
>> exploded from a specific source. However, the consenter doesn't grant 
>> the exploder permission to send his SIP address to every other 
>> recipient of the exploded request.
> Well, I'd say that the permission operation needs additional 
> parameters.  So instead of a simple boolean argument, the operation 
> should probably carry an object that can have this 
> "do-not-redistribute-my-identity" flag set (among possibly others?).
>
Ugh. Why should these not be independent? Although somewhat weird, I 
might consent to have my identity revealed to the other receivers of an 
exploded request but not consent to receive a request from a particular 
sender.

David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Apr 2005 11:04:07 -0400

This is now on its way to becoming a general delegation framework, 
potentially expressing what you are granting permission for, with 
arbitrary detail.

(I'm grant you permission to call me, but only between the hours of 9am 
and 5pm on weekdays. I also grant you permission to send me MESSAGEs, 
but only ones that are smaller than 1kb, an only it the content is 
deemed acceptable by the Committee for Clean Living.)

This is a really slippery slope, and I don't know how far down that 
slope we want to go.

Also, looking at the immediate issue: the consent framework might be 
used to deal with the exposure of people that the server dials out to. 
But what about people who dial in? A caller may not know he is calling a 
conference. Once he gets to it, his identity is potentially available 
via the roster. If he realizes it is a conference he could quickly try 
to update his status to hide his identity. But there is a window of 
opportunity before he can do it, and no guarantee he will be allowed to 
do it.

To be really serious about this, visibility in the roster probably ought 
to be opt-in rather than opt-out.

	Paul