Hi Dale, thanks for your comments. Answers inline:
[EMAIL PROTECTED] wrote:
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.
Section 6.2 explains exactly this. If you would like to propose some introductory text to clarify what is defined there, I will be happy to add it.
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.)
Paul already answered this one. There are issues with how different methods are routed. Describing the limitations of the Accept-* mechanism is the best thing we can do, IMO.
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.
the paragraph in the draft does not contain normative statements because it is simply giving background information (per the title of the section) about normative statements in other documents. Therefore, we cannot really use normative statements there.
However, I agree that "this way" is not a good link between both sentences. I will simply remove it.
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.
What do you have in mind? I guess you are thinking of a body whose handling is required but its "father's" handling was optional. But the rules in Section 6.2 intend to keep that from happening. Could you give us an example where this happens?
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?
Per RFC 4485, we are supposed to specify the behaviors of UACs and UASs separately. That is what the draft does. The note you are referring to is just an informative note.
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?
It is there for completeness. If you put that sentence in context, together with the next sentence in the text, it makes sense to state it like that so that the specification is not ambiguous, I think.
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?
Section 7.4 explains that we define the 'by-reference' disposition type to avoid that problem. The last paragraph on Section 7.4 explains that in the past, option tags have been used to avoid that same problem.
Thanks for your comments, Gonzalo _______________________________________________ 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
