Message Body Handling in the Session Initiation Protocol (SIP)
RFC 5621

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

Lars Eggert No Objection

(Alexey Melnikov; former steering group member) Yes

Yes (2009-06-23)
No email
send info
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 steering group member) Yes

Yes ()
No email
send info

(Magnus Westerlund; former steering group member) Yes

Yes ()
No email
send info

(Robert Sparks; former steering group member) Yes

Yes ()
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection ()
No email
send info

(Dan Romascanu; former steering group member) No Objection

No Objection ()
No email
send info

(Lisa Dusseault; former steering group member) No Objection

No Objection ()
No email
send info

(Ralph Droms; former steering group member) No Objection

No Objection ()
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ()
No email
send info

(Ross Callon; former steering group member) No Objection

No Objection ()
No email
send info

(Tim Polk; former steering group member) No Objection

No Objection ()
No email
send info