Re: [Sip] Support for Multipart/MIME

[Gonzalo Camarillo <[e-mail]>]

Hi Paul,

thanks for your comments. Answers inline:

Paul Kyzivat wrote:
> 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.

what do you mean by a reason code? Do you mean a Warning code?... 
because Reason header fields are not allowed in responses.

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

I have added more structure to the draft (i.e., a few new sections) that 
I believe make it easier to read. You can fetch a working version from:

http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-handling-01.txt

The points above are covered in Sections 4.2, 4.3, and 5. I have added a 
few guidelines to authors of future extensions so that folks writing 
specs are also aware of all these issues and take them into 
consideration when writing new extensions.


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

That's now covered in Section 4.1

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

That's OPEN ISSUE 3 now. We may indeed need to define a new disposition 
type.


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

I think that is now clear in the new version... but let me know if you 
do not think so.


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

That's now covered in Section 4.1


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

That's now covered in Section 3.2


I have numbered the OPEN ISSUES. Now the draft contain 4 of them. I 
would like to discuss how to close them.

Thanks,

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