Subject: Re: [Sip] Comments on draft-ietf-sip-body-handling-05

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 09 Mar 2009 23:30:37 +0200

Hi Eric,

thanks for your comments. We had already agreed to request the 
publication of 05. We were just waiting for the chairs to do or get 
someone to do the PROTO write up for the draft (the PROTO write up has 
already been done at this point).

In any case, I will revise the draft so that the revision we use for the 
publication request (06) will include your comments. My answers inline:

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

Good point. I have fixed it.

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

I have added the following:

"The only
case where a UA MAY use a different encoding is when transferring
application data between applications that only handle a different
encoding (e.g., base64)."

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

I have split the paragraphs as you suggest. I agree it makes the text 
clearer. However, I have stick to using the active voice for normative 
text, which is the trend nowadays (e.g., the UA MUST set the parameters 
to different values instead of the values of the parameters MUST be 
different).

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

Rules about the handling parameter are given in Section 8.3. Below, you 
suggest to remove Section 8.3 and keep this one instead. The thing is 
that we had discussions on the structure of the document and this is the 
structure we agreed to have, including having sections like 6,3 for 
completeness. At this point, I do not want to reopen that agreement.

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

the draft already said this. I have added the clarification about 
"top-level" body parts.

> Section 8.2
> ===========
> For multipart/related, I disagree that if any part is required, the 
> /related is required.

the text talks about the "root body part", not about the 
multipart/related body. The text in the draft already says what you 
propose below.

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

the feedback we got is that people found this section useful to clarify 
what to do in each case.

> 
> Section 8.3
> ===========
> This section is redundant with section 6.3.  Remove section 8.3, as 
> section 6.3 talks about processing.

See my comments above about this issue.

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

When specifying response codes, we typically use SHOULD because the 
request may have some other problem the UAS needs to report using a 
different error response. Specifying all those cases would be something 
like "go and read RFC 3261" :o)... I think using SHOULD in this context 
is clear enough.

> Section 9.2
> ===========
> Nit in last line of Note: s/constrain/constraint/
> 

Fixed.

> 
> Section 9.4
> ===========
> Since RFC 3459 updated 3204, would not the normative current reference 
> be to 3459?

both references are listed as normative because the draft also 
references the parts of RFC 3204 that deal with signalling transport.

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

If you provide me with a reference to a discussion of this attack, I 
will be glad to add it to this section. In any case, I will add it to 
the next revision of the draft, because I intend to submit 06 in a while.

Thanks for your comments,

Gonzalo