Skip to main content

Message Body Handling in the Session Initiation Protocol (SIP)
draft-ietf-sip-body-handling-06

Yes

(Cullen Jennings)
(Magnus Westerlund)
(Robert Sparks)

No Objection

(Adrian Farrel)
(Dan Romascanu)
(Lars Eggert)
(Lisa Dusseault)
(Ralph Droms)
(Ron Bonica)
(Ross Callon)
(Tim Polk)

Note: This ballot was opened for revision 06 and is now closed.

Alexey Melnikov Former IESG member
Yes
Yes (2009-06-23) Unknown
This is a good document.

Some minor comments:

3.1.  Background on Message Body Encoding

 [...]

   SIP uses S/MIME [RFC3850] to protect message bodies.  As specified in

Here and in one other place: I think you really meant RFC 3851:

 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1
 Message Specification

and not RFC 3850:

 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1
 Certificate Handling

   [RFC3261], UASs that cannot decrypt a message body or a body part can
   use the 493 (Undecipherable) response to report the error.

I think explicit statement that support for multipart/signed is OPTIONAL
by UAS and UAC would benefit the document.


3.2.  UA Behavior to Encode Binary Message Bodies

   SIP messages can carry binary message bodies such as legacy
   signalling objects [RFC3204].  SIP proxy servers are 8-bit safe.
   That is, they are able to handle binary bodies.  Therefore, there is
   no need to use encodings such as base64 to transport binary bodies in
   SIP messages.  Consequently, UAs SHOULD use the binary transfer
   encoding

I think this needs a reference to [RFC4289] where the "binary" content transfer
encoding is defined.

   for all payloads in SIP, including binary payloads.  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).

4.2.  Mandatory Support for 'multipart' Message Bodies

 [...]

      It has been observed on the field that a number of legacy SIP UAs

I think it should be "in the field".

      without support for 'multipart' bodies simply ignored those bodies
      when they were received.  These UAs did not return any error



4.3.  UA Behavior to Generate 'multipart' Message Bodies

 [...]

      Note that UAs receiving unnecessarily nested body parts treat them
      as if they were not nested.

I think this sentence is a bit ambiguous, so you should consider clarifying it.


10.  Guidelines to Authors of SIP Extensions

   These guidelines are intended for authors of SIP extensions that
   involve, in some way, message bodies or body parts.  These guidelines
   discuss aspects authors of such extensions need to consider when
   design them.

s/design/designing
Cullen Jennings Former IESG member
Yes
Yes () Unknown

                            
Magnus Westerlund Former IESG member
Yes
Yes () Unknown

                            
Robert Sparks Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Ralph Droms Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
No Objection
No Objection () Unknown