Hi Gonzalo, I have been going through draft-ietf-sip-body-handling-01 and noticed something that is either en error or counter-intuitive.
Section 5.1 states: The body parts are ordered so that the last one is the richest representation of the information. This way, the recipient of a 'multipart/alternative' body chooses the last body part it understands. Section 6.2 states: If the handling of a 'multipart/alternative' body is required, the UA MUST set the 'handling' parameter of the 'multipart/alternative' body to 'required'. The UA MUST also set the 'handling' parameter of the last body part within the 'multipart/alternative' to 'required'. Why the last body part? Somehow, I would have expected that the 'handling' parameter of first body part to be set to 'required', not the last one, as the last one should hold the richest representation of the information, and possibly the one most difficult to understand/implement... And thinking about it a little bit more, I think that an application should always set the 'handling' parameter in the internal parts of a 'multipart/alternative' to 'optional', as this is pretty much what 'multipart/alternative' is. If 'multipart/alternative' itself is has its 'handling' set to 'required', then it means at least one of its internal part must be understood and handled. The sender cannot really decide which one has to be understood. Maybe my suggestion is going against things already defined in MIME or somewhere else. If this is the case, I think a simple clarification in the draft would do, something in the line: Even though the last part of the 'multipart/alternative' has its 'handling' parameter set to 'required', the receiving UA (or UAS) does not necessarly have to be able to handle this specific body part, it only has to be able to handle any body part within the 'multipart/alternative' body parts. Best Regards, EricT
_______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
