Technical: - Related to Open Issue 3, there is also the question of what the Content-Disposition of a response body is. For SDP answers, "session" makes sense, but the body may contain control information that doesn't fall under "session" or "render" cleanly.
- Section 4.1: "If the handling of a 'multipart/alternative' body is required, the UA MUST set the 'handling' parameter of the 'multipart/alternative' body and to the last body part within the 'multipart/alternative' to 'required'." Is there a typo here? The whole point of multipart/alternative is that one need only understand one component, and tagging the last component 'required' contradicts this. It would seem that even if the whole body was "required", any individual component would be "optional". (Though of course, the reader is obliged to understand at least one component.) Indeed, the handling of any component of a multipart/alternative is implied by its membership in the multipart/alternative and need not be stated. - In regard to error reporting, perhaps we should use the Warning header and describe the problem in natural language, rather than trying to provide errors that can be processed automatically. - In regard to other multipart types: This specification recommends support for 'multipart/mixed' and 'multipart/alternative'. At present, there are no SIP extensions that use different 'multipart' subtypes such as parallel [RFC2046], digest [RFC2046], or related [RFC2387]. If such extensions were to be defined in the future, their authors would need to make sure (e.g., by using an option-tag or by other means) that entities receiving those 'multipart' subtypes were able to process them. As stated earlier, UAs treat unknown 'multipart' subtypes as 'multipart/ mixed'. Since there is a standard fallback, an extension does not need to provide an option-tag as long as it is willing to have its multipart type processed as multipart/mixed. So it would be more accurate to say "If such extensions were to be defined in the future, their authors might need to provide UAs a way (e.g., by using an option-tag) to make sure that entities receiving those 'multipart' subtypes were able to process them as such." Editorial: - There is a tendency of the terminology to overlook the fact that all SIP bodies are MIME bodies, and to use "MIME body" as synonymous with "MIME multipart body". E.g., in section 1, "Multipart message bodies are encoded using the MIME (Multipurpose Internet Mail Extensions) [RFC2045] format." is literally correct but suggests that non-multipart message bodies somehow aren't encoded using MIME. In reality, Content-Type is a MIME header, etc. Dale _______________________________________________ Sip mailing list https://www1.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
