Subject: [Simple] draft on MSRP conferencing

From: Miguel Garcia <[email-masked]>
Date: Mon, 21 Feb 2005 08:53:54 +0200

Hi:

Aki and me had made a new revision of a draft that discusses how to do 
conferences with MSRP. We propose to define a new MSRP method and a 
couple of new headers, in addition to a number of conventions.

The draft should be officially published soon. In the meantime you can 
download a copy from (html and txt):

http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-02.html
http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-02.txt

Comments are welcome.

- 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

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 23 Feb 2005 09:04:44 +0200

Hi Paul.

Thanks for your comments. Inline answers.

Paul Kyzivat wrote:

> Aki / Miguel,
> 
> Just read over draft-niemi-simple-chat-02. I'm glad you are continuing 
> to work on this. I have a few comments and questions:
> 
> - Adding the DISTSEND seems especially ugly. It shouldn't be necessary 
> to extend the protocol for this kind of purpose, which is just a 
> meta-operation performed by the MSRP switch.
> 
> Instead of this, how about simply defining a new body type for the 
> purpose? It could be a kind of multipart, where one contained part is 
> the dist list, and the other is the CPIM body. When the switch receives 
> a body of this type, it extracts the two parts from it, then forwards 
> the CPIM body part to the list provided by the other part. Support can 
> be learned by the focus announcing support for the body type during 
> offer/answer.

Yeap, Ben just proposed a similar thing. Actually we have many of the 
components already done. The new body could be the URI-list with the 
'capacity' extensions defined in Section 4.1 of 
http://www.ietf.org/internet-drafts/draft-ietf-sipping-uri-list-message-02.txt

The only requirement for going into this approach is that there must be 
a mechanism for the client to find out that the feature is supported at 
the MSRP switch, otherwise "private messages" sent by the client might 
end up being distributed to all the participants of the conference.

I think it is a bit uglier that routing information (or meta-data 
routing information) is buried in a body. It will require the MSRP 
switch to open all the bodies to find out whether a distribution list is 
included or not. I will also require to include this list as the first 
body, to allow chunks to be routed immediately. I think this is kind of 
ugly...

> 
> - Your discussion implies that you have synchronous operation in mind - 
> the MSRP switch receiving an entire message before forwarding it on. But 
> MSRP certainly makes it feasible for the switch to begin forwarding 
> *before* a complete message is received. This could be significant for 
> large messages. I think you ought to mention that an implementation 
> working that was is acceptable.

Yeap, right... It certainly deserves further discussion.

> 
> - When performing a DISTSEND (or my suggested replacement), I question 
> whether the whole request should be aborted if one of the recipients 
> cannot be identified. Given that users come and go from conferences with 
> some regularity, this could cause a lot of messages to go wrong, only to 
> be retried with the missing name removed. This could be a problem when 
> trying to stream LoTR to several people in the conference, but one of 
> them happens to disconnect.

Sounds reasonable. I would like to formulate the requirement and capture 
it in the requirements section.

> 
> - What should happen if the MSRP switch can resolve all the recipients, 
> but the resulting SEND fails to some but not all of them?

At the moment we don't describe this case. I think we are heading to 
bring a requirement whereby the creator of the message can request a 
super-Report from the MSRP, this report should contain some sort of 
information about the delivery of the message to the recipients.

> 
> - There is no mention of the possibility that multiple conferences could 
> be joined by connecting their foci. I'm not sure if this would have 
> impact on the mechanism you are proposing. Seems worthy of discussion.

Note taken, I guess the discussion is worthy.

Thanks,

      Miguel
>     Thanks,
>     Paul
> Miguel Garcia wrote:

---

From: Ben Campbell <[email-masked]>
Date: Tue, 22 Feb 2005 15:37:17 -0600

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?

---

From: Ben Campbell <[email-masked]>
Date: Tue, 22 Feb 2005 15:41:00 -0600

(replying to self)

Or alternatively, by adding a body part with a URL list of some sort in 
it. Then, support of the feature can be negotiated as part of the SDP 
exchange.

On Feb 22, 2005, at 3:37 PM, Ben Campbell wrote:

>> Aki and me had made a new revision of a draft that discusses how to 
>> do conferences with MSRP. We propose to define a new MSRP method and 
>> a couple of new headers, in addition to a number of conventions.
>>
>> The draft should be officially published soon. In the meantime you 
>> can download a copy from (html and txt):
>>

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 23 Feb 2005 08:50:59 +0200

> it. Then, support of the feature can be negotiated as part of the SDP 

This sounds a bit better to me, providing that there is a mechanism to 
negotiate the feature as you mention.

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 23 Feb 2005 08:47:30 +0200

> 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.

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.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Feb 2005 18:20:10 -0500

Aki / Miguel,

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Feb 2005 09:37:02 -0500

Miguel Garcia wrote:
>> the dist list, and the other is the CPIM body. When the switch 
>> receives a body of this type, it extracts the two parts from it, then 
>> forwards the CPIM body part to the list provided by the other part. 
>> Support can be learned by the focus announcing support for the body 
>> type during offer/answer.
> 
> 

You are making this too hard.

What I had in mind was a special *container* type. Whenever this type is 
received, the switch is expected to do the "special switching". For 
instance the type might be multipart/msrp-multicast+xml. This would then 
have two components:
- a URI-list
- a CPIM body to be sent to the list.

You then don't have to open all bodies - only this body type.

And negotiation of support for the body type determines whether the 
feature is supported.

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 24 Feb 2005 08:51:22 +0200

> You are making this too hard.

I think the same about your proposal ;-)

> - a CPIM body to be sent to the list.

First, I guess you are not proposing to have an XML wrapper document 
that contains, somehow, the URI-list and the Message/CPIM. IMHO it does 
not make sense to use XML for this.

So if you don't use XML, the multipart/msrp-multicast MIME type becomes 
the same as the multipart/mixed MIME type, and it would be hard to 
justify its existence.

> You then don't have to open all bodies - only this body type.

So we have two problems, one if we have only multipart/mixed, I would 
have to open all bodies. Still I would have to open a body as a minimum, 
to do routing at the application layer. There are other side effecs:

a) What about if the creator uses S/MIME to protect the whole multipart 
stuff... and if it is a long message (chunked) then the MSRP mixer won't 
be able to open the URI-list until the last chunk has been sent. This 
seems to conflict with your early wise proposal of allowing routing of 
chunks rather of whole messages.

b) Even if s/MIME is not used, then we will need to define an order 
insdide the multipart MIME and specify that the URI list must be the 
first body.

This mechanism has been used in SMTP since... long time. The RCPT verb 
in SMTP adds a new recipient to the list. It is the most similar thing 
to a header, rather than a body.

> And negotiation of support for the body type determines whether the 

If we can justify the creation of a new MIME type, yes. Otherwise, it 
won't get distinguished in the SDP.

/Miguel