Re: [Sip] Support for Multipart/MIME

[Paul Kyzivat <[e-mail]>]

Gonzalo,

Thank you for doing this. It is a great start. I largely agree with what 
you have written.

One specific comment about the draft:

- Open issue in section 3: perhaps a new Reason code, to be used
   with a 415 response would be adequate.

I think there are a number of loose ends, some mentioned, some not. In 
many cases, while I have an opinion what the right answer might be I 
think it needs discussion. Here is what I came up with:

- How to determine what processing a body part should receive

In many cases the processing of a body part is determined by: the 
content disposition, the content type, and perhaps the context within 
which the message is received. For instance, this is true for type sdp 
with disposition session in an INVITE; for type text/plain with 
disposition render in a MESSAGE; and for type kpml with disposition ??? 
in a SUBSCRIBE. In these cases there is no overt *reference* to the body 
part.

In other cases the processing is determined by the context of a 
reference to the body part via a cid: url that references the Content-ID 
of the body part. You mentioned this as well.

The case I am concerned with is when there is ambiguity between these. 
For instance 3261 defines Content-Dispositions "alert" and "icon". While 
these aren't described very well, it appears that if a body part is 
present with disposition "alert" then it should be used for alerting 
based on its presence, without any overt reference. But there is also an 
Alert-Info header, which *could* contain a cid: url. If there was an 
Alert-Info header with a cid: url that referenced a body part, must that 
body part be of disposition "alert"?

Its my feeling that the definition of each disposition should specify 
how use decisions should be made for body parts having this disposition. 
There should be one or more dispositions that state that their use is to 
be determined by how they are referenced. And headers that might 
reference body parts should define the acceptable dispositions for the 
body parts that are referenced.

If a message contains a body part with type and disposition that defines 
how it is processed without need of a reference, and there *also* is a 
reference to it, then it should be processed both ways. (This however 
should happen rarely or never.)

- What Content-Disposition type should multipart bodies have?

When you have a multipart body, it has a disposition, and each of its 
contained body parts also has a disposition. I have never seen any 
specification of what disposition the multipart itself should have. None 
of the examples I have seen have had a Content-Disposition header in the 
multipart. According to the sip defaulting rules, a multipart body 
without a C-D header has disposition "render", which seems a bit weird.

In the case of multipart/alternative, I think the disposition type of 
all the contained body parts should be identical. I think it would also 
make sense for the multipart/alternative itself to contain the same 
disposition. That would simplify processing, because the whole thing 
could be ignored if the disposition has a type that will be ignored.

In the case of multipart/mixed, the disposition types of the contained 
body parts will typically vary. The type of the mixed body simply needs 
to be something that causes it to be processed. Using the default of 
"render" seems weird to me. It would make sense to me to have some 
special C-D type for this purpose. Potentially it could be defined as 
the default C-D for multipart/mixed in the same way that "session" is 
the default for type application/sdp.

- Must the recipient of a message process all multipart bodies and their 
contents? Recursively?

Note that a multipart body can contain other multipart body parts, thus 
potentially forming a tree of body parts of arbitrary shape and depth.

So, the developer of a UA will want to know: do I have to parse all of that?

I think the answer is: like anything else, you make this decision based 
on the disposition type and handling. (If you understand multipart/mixed 
(and you should) then you also understand that multipart/X where you 
don't know X should be processed the same as multipart/mixed.)

If handling is optional and the disposition type and content type are 
known to you, then you must parse it. Each contained body part is then 
processed based on its own disposition. If the handling is optional and 
the disposition type or content type are not known to you then you can 
ignore it.

(This puts a premium on having an agreed to disposition type that is 
typically used for multipart/mixed and which everyone that supports 
multipart is expected to support.)

- What "handling" value should be used for multipart bodies and the 
contained body parts?

If a body part is referenced by a cid: url in a header (or in another 
body part I suppose), then the handling of the body part should be required.

Contained, non-multipart body parts that aren't referenced by cid: can 
have handling required or optional as appropriate for their use.

A multipart body should have handling of required if any of the parts it 
contains are required. Otherwise it may have optional handling.

Multipart/alternative is tricky. Only one alternative is to be used, and 
it is assumed that some alternatives may not be understood. So it seems 
that all except the first contained body part should have optional 
handling. The first may be required or optional depending on whether its 
ok to handle none. And the handling of the multipart/alternative 
container is as above.

- What about "gratuitous" nesting of multiparts?

It seems that it is technically valid to wrap a body part, such as an 
SDP offer, in one or many levels of multipart wrappers. A recipient who 
receives such a thing, and processes it according to what Gonzalo has 
specified and what I have suggested above, should be able to deal with this.

But its not a good thing.

So I think we ought to at least state that the sender of a request 
SHOULD NOT use a multipart wrapper when there is only one part, and 
SHOULD NOT nest one multipart/mixed within another unless there is a 
*reference* to the nested one. (Instead of nesting, include all the 
parts in the outer multipart.) And a sender SHOULD NOT nest one 
multipart/alternative within another.

	Thanks,
	Paul

Gonzalo Camarillo wrote:
> Hi,
> 
> I have taken a stab at writing a quick draft about both issues (I agree 
> it makes sense to tackle them in a single document). Until it appears in 
> the archives, you can fetch it from:
> 
> http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-handling-00.txt 
> 
> 
> I have marked a few open issues so that we can continue discussions 
> around those on the list (this is, of course, just an initial draft).
> 
> Cheers,
> 
> Gonzalo
> 
> 
> Francois Audet wrote:
>> My preference is one document.
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:[e-mail]] Sent: Wednesday, May 
>>> 16, 2007 05:18
>>> To: Gonzalo Camarillo
>>> Cc: Audet, Francois (SC100:3055); [e-mail]; Dan Wing; Christer 
>>> Holmberg (JO/LMF)
>>> Subject: Re: [Sip] Support for Multipart/MIME
>>>
>>> Hi Gonzalo,
>>>
>>> I guess the question is whether we want to write a document 
>>> specifically focused on Content-Disposition, or if we want to combine 
>>> work on that with work on specifying use of multipart.
>>>
>>> They aren't the same thing, but content-disposition becomes more 
>>> significant when there are multiple body parts, so there is some 
>>> justification for combining the work.
>>>
>>>     Paul
>>>
>>> Gonzalo Camarillo wrote:
>>>> Hi,
>>>>
>>>> yes, Paul and I talked about writing a draft to clarify a 
>>> few issues
>>>> that relate to content dispositions in SIP a while ago. We 
>>> were quite
>>>> busy at that point and did not have time to write it, but 
>>> maybe it is
>>>> time to do it now.
>>>>
>>>> Cheers,
>>>>
>>>> Gonzalo
> 


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