Comments on draft-ietf-sip-body-handling-05

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 Bodies

   Section 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.

_______________________________________________
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