Unfortunately, I don't particularly like this document, as it gives a lot of discussion of various cases, but doesn't present a clear and unified description of the semantics of multipart body part handling. So much so that it would take me a long time to verify that the various rules in the document covered all cases and were not mutually contradictory.
In a lot of situations, it seems that the rule is "the designer of the software should be able to figure out what is meant in each particular situation". Which inevitably leads to "No, he can't." or rather "He will think he can, but he'll get it wrong." But I don't know that we have time to fix that now. More specifically: There seems to be no clear statement that "required" and "optional" mean "required/optional for successful processing of the enclosing body/body part" -- after all, the enclosing body part may itself be optional, so "required" and "optional" can only be relative to the necessity of understanding of the enclosing body part. Or alternatively, maybe we don't want this degree of complexity. But to avoid it, we would have to ban nested multiparts, or at least, all but certain specific usages of nested multiparts. There are a lot of mentions of the 415 response in passing. As far as I can tell, it is expected that the Accept header in a 415 response will contain all the media types that the UA understands *in any context whatsoever*, but that doesn't seem to be stated clearly anywhere. (E.g., it would be reasonable for a designer to think that the Accept should only list media types understood for the particular request method.) In section 5.1 the description is not really correct, as the "This way..." sentence doesn't follow from the preceding sentence. A better phrasing is: Each body part within a 'multipart/alternative' carries an alternative version of the same information. The body parts SHOULD be ordered in increasing richness of representation of the information. More exactly, the UAS MUST process the last body part that it understands, and the UAC MUST order the body parts so that the this rule causes the UAS to behave as the UAC desires. In section 6.1, I see: If the parameter [...] has the value 'required', the UAS returns a 415 (Unsupported Media Type) response. This is incorrect. Of course, what is meant is, "If the parameter has the value 'required', and the body part must be processed in order to process the entire SIP message, then the UAS returns...", but that's not what it says. In section 6.2 there is various discussion of the handling parameter for parts within a multipart/alternative body part. But the discussion could be made clearer by starting with the statement that the handling parameter is not significant: "The handling parameters of the parts of a multipart/alternative part are ignored in processing (the processing is determined by the type multipart/alternative), and SHOULD be set to optional." Or should we just omit 'handling' on parts of a multipart/alternative? The sentence before that one is peculiar: "If the handling of a 'multipart/alternative' body is required, the UA MUST set the 'handling' parameter of the 'multipart/alternative' body to 'required'." This seems tautological -- why is it stated? In section 7.3, it is stated that "If the SIP message contains a reference to the body part, the UA processes the body part according to the reference.", but in the next paragraph, it says "Note that, following the rules in [RFC3204], if a UA does not understand a body part whose handling is optional, it ignores it." But these are contradictory if the part containing the reference is required but the part that is referenced is marked optional. In effect, the referenced part becomes required (or rather, required under any circumstances where the referencing part is required). This can conflict with the desire that all parts of a multipart/alternative are effectively optional within that part. What is really intended here? Dale _______________________________________________ Sip mailing list https://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
