Subject: Re: [Simple] draft on MSRP conferencing

From: Hisham Khartabil <[email-masked]>
Date: Wed, 2 Mar 2005 10:07:38 +0100

On Feb 23, 2005, at 7:47 AM, Miguel Garcia wrote:

> Ben Campbell wrote:
>> I apologize in advance for offering a knee jerk opinion after having 
>> done only the briefest scan of this draft:
>> Couldn't this be accomplished by simply adding multiple To headers to 
>> the message/cpim envelope, rather than by adding an extension method?
>
> What you are proposing is what we have proposed in version -01 of the 
> draft. However, we went into some problems with that approach:
>
> a) If the MSRP does not implement this extension, then it will 
> distributed the message to all the participants of the conference. 
> Certainly not what the creator of the message wanted.

In this draft, you are defining the behaviour of the MSRP conferencing 
entity that thus far is not defined anywhere. Therefore, you can 
mandate for this behaviour to be implemented.

>
> b) Message/CPIM contains To and Cc headeers. However, there wouldn't 
> be a mechanism to do the effect of a Bcc, because we are linking 
> routing with presentation.

What does it mean to have a cc and bcc in an instant messaging 
conference? This is not email. But if it is really needed then we can 
extend message/cpim to have bcc header (I'm on a plane so I cannot 
validate your claim that there is no bcc header in message/cpim).

Regards,
Hisham

>
> So we ended up proposing a new method, because if the MSRP switch 
> dooes not support, it returns and 501 response, and at least the 
> message is not distributed to the whole roster.
>
> Then we added the Distsend header, that contains the desired 
> distribution list. This list need to not be the same as the To and Cc 
> headers of the Message/CPIM, so that the creator can create blind 
> copies.
>
> /Miguel
>
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Research Center      Helsinki, Finland
>
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
>

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 03 Mar 2005 10:59:38 +0200

Inline comments.

Hisham Khartabil wrote:

> entity that thus far is not defined anywhere. Therefore, you can mandate 
> for this behaviour to be implemented.

I would agree with what you say, if we say that this draft will contain 
the minimum set of requirements to implement in an MSRP switch, and that 
none can implement an MSRP switch without implementing this draft. My 
initial thought would be that this draft would be an enhanced MSRP 
switch functionality. I am fine with any of both proposals.

> validate your claim that there is no bcc header in message/cpim).

First, what is the meaning of CC and Bcc in instant messaging is 
something that is, in a way, inherited from Message/CPIM and e-mail. At 
the end of the day, we are speaking about messaging, no matter whether 
it is instant or almost instant (e-mail).

Second: There is no point in adding a Bcc header to Message/CPIM, 
because then it would automatically require the MSRP switch to open the 
Message/CPIM and remove it (the point of Bcc is that others don't know 
who is receiving the Blind copy). I have been trying to make an effor 
for the MSRP switch to avoid opening bodies. I think it is a nice 
requirement for a high performance switch.

What we are proposing is to separate the list of recipients 
(Distribution header) from the presentations aspects (To and Cc in 
Message/CPIM). This is the approach taken by RFC 822 and seems to be 
woking fine. I think RFC 822 wouldn't perform that well if SMTP relays 
would have to open bodies to remove Bcc headers.

/Miguel

>> headers of the Message/CPIM, so that the creator can create blind copies.
>>
>> /Miguel
>>
>> --