Good work and almost done! General =======Many of the rules for multipart/mumble say things like "all parts must be foo." This construction is not strictly correct. For example, in multipart/alternative, I could have a multipart/mixed. Saying something like "all parts in a multipart/alternative must be marked foo" means that ALL parts, including walking down the multipart/mixed contained therein, must be marked foo. What we really want to say is "all top-level parts in a multipart/alternative must be marked foo." That means, for example, if one of the parts is a multipart/mixed, the multipart/mixed needs to have the foo marking, but things within the multipart/mixed, I presume, will follow the appropriate rules for multipart/mixed and the body's context.
Section 3.2 ===========Please make clear that binary *SIP* message body parts MUST be binary, as the text currently says. However, it is quite possible, and should be legal, to encode application parts transported in SIP, such as INFO or NOTIFY bodies. For example, one might forward a base64 e-mail or a uuencoded file. Since that would be an application-level message, there is no reason to burden the application with decoding the body part to get it to binary, just for the other side to re-encode it.
Section 6.2 ===========What confused me is section 6.2 starts with what looks like a normative statement, but it really is a forward reference. To me, there is no reference to which 'same' we are referring to. The text then seems to jump to what looks like a special case for 'session' and 'early-session'. I would suggest the following:
6.2. UA Behavior to Generate 'multipart/alternative' Message BodiesSection 8.2 mandates all top-level body parts within a 'multipart/ alternative' have the same disposition type as the enclosing 'multipart/alternative'.
The 'session' and 'early-session' [RFC3959] disposition types require that all body parts of a 'multipart/alternative' body have different content types. Consequently, for the 'session' and 'early- session' disposition types, each top-level body type within the 'multipart/alternative' body MUST be different. Otherwise, the rules for the specific disposition type apply. NOTE: One could envision situations where a UA presents multiple alternatives with the same body type, where the receiving UA picks the best or richest alternative it can use.
Section 6.3 ===========Ah, but there ARE handling rules for multipart/alternative. I would replace this section with:
When a UA receives a message with a 'multipart/alternative' body part, if the body part has a 'required' handling, then the UA MUST pick the best alternative body part to use. If the UA is unable to use any of the body parts, the UA MUST reject the request with a 415 error response. This could occur if the UA did not understand any of the top-level body parts within the 'multipart/alternative'.
The handling marking for top-level body parts in a 'multipart/ alternative' has no meaning. Therefore, the UA MUST ignore any 'handling' tags in the top-level body parts of the 'multipart/ alternative' body part. Once the UA picks one of the top-level body parts to use, then the UA MUST use the appropriate processing rules for the 'handling' tags within the selected top-level body part.
Section 8.2 ===========For multipart/alternative, a top-level body type with 'handling=required' makes no sense. By definition, using multipart/ alternative means we expect the UA to not be able to handle one or more of the body parts - we just do not know which one. I would remove the note and incorporate the gist into the text:
If the sending UA requires the handling of a 'multipart/ alternative' body as a whole, the UA MUST set the 'handling' parameter of the 'multipart/alternative' body to 'required'. Otherwise, the UA MUST set the 'handling' parameter to 'optional'. The sending UA MUST set all the top-level body parts within the 'multipart/alternative' to 'handling=optional'.
Section 8.2 ===========For multipart/related, I disagree that if any part is required, the / related is required. The last sentence is a non-sequitur. Either I mandate doing something with the 'multipart/related' body or I do not. I could see, for example, saying that processing the multipart/ related is optional, but if you do process it, one or more of the sub- parts is required. In this case, the multipart/related is optional, yet one of the sub-parts is required.
How about:If the sending UA requires the handling of a 'multipart/related' body as a whole, the UA MUST set the 'handling' parameter of the 'multipart/related' body to 'required'. Otherwise, the UA MUST set the handling to 'optional'. The UA sets the 'handling' parameters of the body parts within the 'multipart/related' body independently from the 'handling' parameter o the 'multipart/related' body. If the sending UA requires the handling of a particular body, the UA MUST set the 'handling' parameter of that body part 'required'. Otherwise, the UA MUST set the parameter to 'optional'.
Section 8.2 ===========General: I really do not like the construction "If the UA requires the handling of foo the UA MUST mark it with 'handling=required'." The reason I do not like this is this is precisely what RFC 3459 says to do. All this draft does is repeat what is in that draft. Saying "You MUST do what you MUST do" seems redundant and error prone.
Section 8.3 ===========This section is redundant with section 6.3. Remove section 8.3, as section 6.3 talks about processing.
Section 8.4 ===========OK, I'll bite: what if I do not feel like returning a 415? Either enumerate the situation where I MUST return a 415 or enumerate the situations where I would return something other than 415.
Section 9.2 =========== Nit in last line of Note: s/constrain/constraint/ Section 9.4 ===========Since RFC 3459 updated 3204, would not the normative current reference be to 3459?
Section 11 ==========I would offer we point out the potential for DoS attacks from complex MIME bodies. UA's need to be aware of potential stack depth overflow, line length overflow, pointers to missing content, incorrect content- lengths, correct content-lengths that span what a parser that does not look at content-lengths might consider to be content boundaries with other body parts snuck in.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
