Subject: [MMUSIC] some suggestions to draft-ietf-mmusic-file-transfer-mech-07.txt

From: "zhangwei" <[email-masked]>
Date: Mon, 31 Mar 2008 11:10:25 +0800

Hi,

I have read the latest draft about file transfer using
MSRP(draft-ietf-mmusic-file-transfer-mech-07.txt). Though it has made some
improvement, I still have some suggestions and problems with it. 

MSRP[RFC4975] is a protocol for transmitting instant messages in the context
of a session. In addition to plain text messages, MSRP is able to carry
arbitrary MIME compliant content. So, current many communication
applications, such as file transfer, whitebroad and application sharing, can
be implemented using MSRP. Draft-ietf-mmusic-file-transfer-mech defines the
implementation of file transfer which is only one of these applications.

I think we should extend a new SDP attribute that provide the information to
describe the application type, which is used to distinguish the variable
applications. This new attribute can be as the following.

msrp-app-id = "msrp-app-id:" app-id-string

app-id-string = token

                 ; "filetransfer" describes file transfer application,
"whitebroad" describes whitebroad application and so on.

This new attribute provides good scalability to define many applications not
only file transfer.

Another problem is about the size of SIP INVITE with a SDP body. 

Before the actual transfer, it is needed to pass some meta information on
the file which provides potential information for the receiver to decide to
accept or reject.

So the draft defines some new attributes such as file-selector,
file-transfer-id, file-date, file-icon and so on.

A sender that wishes to send more than one file needs to generates an "m="
line per file along with the file attributes described in this
specification.

This specification also allows a file sender to include an icon of an image
file.

All the above lead to a very big SDP body. And it will exceed the MTU of the
most networks, especially the wireless network.

So I think we should focus some effort on how to reduce the size of SDP
body.

Regards

Zhang Wei

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 31 Mar 2008 15:15:48 +0300

Zhang Wei:

Thanks for your comments. See some inline discussions.

zhangwei wrote:
> MSRP(draft-ietf-mmusic-file-transfer-mech-07.txt). Though it has made 
> some improvement, I still have some suggestions and problems with it.
> 
>  
> 
> MSRP[RFC4975] is a protocol for transmitting instant messages in the 
> context of a session. In addition to plain text messages, MSRP is able 
> to carry arbitrary MIME compliant content. So, current many 
> communication applications, such as file transfer, whitebroad and 
> application sharing, can be implemented using MSRP. 
> Draft-ietf-mmusic-file-transfer-mech defines the implementation of file 
> transfer which is only one of these applications.

I am not aware of any standard application using whiteboard and 
application sharing over MSRP. We (I) have proposed it in a separate 
draft, see draft-garcia-mmusic-sdp-collaboration-00.txt, but that is 
only an individual submission, not a chartered item, not a working group 
draft, nothing. So, at the moment (today) there is no standard mechanism 
to do whiteboard or application sharing over MSRP. I wish there would be 
one, but it seems that not many people care.

Anyway, I don't feel comfortable adding words about all these fancy 
usages of MSRP when we don't have information that they are going to be 
standardized.

> 
> I think we should extend a new SDP attribute that provide the 
> information to describe the application type, which is used to 
> distinguish the variable applications. This new attribute can be as the 
> following.
> 
> msrp-app-id = “msrp-app-id:” app-id-string
> 
> app-id-string = token
> 
>                  ; “filetransfer” describes file transfer application, 
> “whitebroad” describes whitebroad application and so on.

This has been proposed at the SIP level. Please read 
draft-drage-sipping-service-identification and 
draft-ietf-sipping-service-identification. Notice that none of them 
belong to the MMUSIC WG, so, if you have comments about these drafts, 
please send them to the SIPPING WG list.

> 
> This new attribute provides good scalability to define many applications 
> not only file transfer.

I don't get how the Service identification helps with scalability, but 
anyway, this is a topic of SIPPING, not MMUSIC.

> Before the actual transfer, it is needed to pass some meta information 
> on the file which provides potential information for the receiver to 
> decide to accept or reject.
> 
> A sender that wishes to send more than one file needs to generates an 
> “m=” line per file along with the file attributes described in this 
> specification.
> 
> This specification also allows a file sender to include an icon of an 
> image file.
> 
> All the above lead to a very big SDP body. And it will exceed the MTU of 
> the most networks, especially the wireless network.
> 

Look. It is true that the size of SIP+SDP messages is getting bigger and 
bigger. But, that statement also holds if we don't have this draft, so, 
we should be working in the area of addressing these problems 
generically, not for this draft in particular, because even without this 
draft, the problem will remain.

Some of this problems are mitigated with SigComp: RFC 3320, 3321, 3485, 
4077, 4896, and 5049.

On the other hand, if the request is too long to fit in the MTU, the 
protocol says that you must use TCP as a transport. I doubt we can do 
something more on this draft.

> Zhang Wei

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland