Subject: [MMUSIC] File-transfer issue 29: Multipart due to icon

From: Miguel Garcia <[email-masked]>
Date: Mon, 21 May 2007 16:36:32 +0300

Paul Kyzivat wrote:
 > Section 6:
 >
 >     file-icon-value      = cid-url        ;cid-url defined in RFC 2392
 >
 > I don't really have a problem with the syntax, but this implies that
 > there must be a multipart body. The use of SDP attributes rather than an
 > external body was justified on the assumption that many UAs don't
 > support multipart. There is an inconsistency here.

There are two issues here:
1) O/A exchange between two endpoints that implement this draft
2) O/A exchange when the file sender implements the draft but the file
receiver does not, and probably, does not implement multipart either.

With respect point 1) above: I think it is assumed that if you
implement this specification you HAVE to implement multipart. I have
added a new section about the file-icon to capture this. The current
text reads:

8.6.  Considerations with respect the 'file-icon' attribute

    This specification allows a file sender to include a small preview of
    an image file: an icon.  A 'file-icon' attribute contains a CID URL
    [5] that points to an additional body that contains the actual icon.
    Since the icon is sent as a separate body along the SDP body, the
    file sender has to use a MIME multipart/mixed body that contains an
    SDP body part and the icon body part.  Therefore, implementations
    according to this specification MUST implement the multipart/mix MIME
    type [3].

With respect point 2) above: If the file receiver gets a multipart
body, and it does not implement multipart, then it would reject (via
SIP, presumably) the request. I think in this case we should recommed
to remove the icon body and the multipart and re-try the request with
SDP only. So, I have added a new paragraph, below the above text:

    However, if the file sender sends a request that contains a
    multipart/mix MIME body that includes an SDP body part and an icon
    body part, and the file receiver does not support multipart MIME
    types, then the file receiver will reject, via a higher protocol
    mechanism (e.g., SIP), the request.  In this case, it is RECOMMENDED
    that the file sender removes the icon body part, creates a single SDP
    body (i.e., without multipart MIME) and re-tries the request again.
    This increases the chances of getting the SDP accepted at the file
    receiver (albeit the file receiver will not implement this
    specification, which mandates the implementation of multipart MIME
    bodies).

/Miguel
-- 
Please note my new e-mail address: miguel.garcia at nsn.com
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Helsinki, Finland

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 May 2007 13:01:14 -0400

Wouldn't the logic below, that explains the handling of the body for the 
icon, also allow the use of an external body for all the file attributes 
- contrary to the rationale for using sdp attributes rather than an 
external body?

(But I'm not going to give you a hard time on this.)

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 21 May 2007 21:02:33 +0300

Hi Paul:

The logic below explains the backward compatibility issues when one of 
the endpoints do not implement multipart.

What the logic below does not explain is what are the problems 
associated with B2BUAs and other nasty intermediary in the signaling 
path. Back some time ago, when Dan Wing proposed to use the external 
body, we became aware that some B2BUAS do nasty things to mutipart 
bodies (which I am not going to elaborate here). It was decided, in the 
sake of easy B2BUA traversal, to add these attributes rather than 
defining a message-external multipart body.

So I appreciate that you are not going to give me a hard time on this. 
We will stick to the decisions we took some time ago.

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 May 2007 14:18:11 -0400

> defining a message-external multipart body.

I'm still confused then, about how the problems with multipart for 
message-external arent' a problem for the mulipart for the icon. It 
seems like the same problems would apply to both, and the same solutions 
to those problems would apply to both.

What am I missing?

	Paul

>> Wouldn't the logic below, that explains the handling of the body for 
>> the icon, also allow the use of an external body for all the file 
>> attributes - contrary to the rationale for using sdp attributes rather 
>> than an external body?
>>

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 21 May 2007 21:46:55 +0300

> to those problems would apply to both.

What you are missing is the additional interoperability case we get with 
the current specification and that we wouldn't get with the 
message-external body. Let's assume both parties implement the file 
transfer spec, but there is a B2BUA that removes bodies that are not 
know or duly authorized.

- With the current specification, we get SDP O/A for file transfer, but 
if there are icon bodies, there will be removed. Things mostly work, 
only the icon fails to be displayed due to the B2BUA.

- With the message-external alternative, we don't get SDP O/A, we can 
just fall back to vanilla MSRP. User's wouldn't be able to see the file 
meta data and accept or reject a file based on that. They can still do a 
trial an error and send the file with vanilla MSRP, but no more.

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 May 2007 16:14:01 -0400

OK. I was missing that aspect of what you were trying to say.
I guess that is a plausible case.

I'll shut up now.

	Paul

Miguel Garcia wrote:
>> seems like the same problems would apply to both, and the same 
>> solutions to those problems would apply to both.
>>
>> What am I missing?
>