Message Body Handling in the Session Initiation Protocol (SIP)
draft-ietf-sip-body-handling-06
Yes
(Cullen Jennings)
(Magnus Westerlund)
(Robert Sparks)
No Objection
Lars Eggert
(Adrian Farrel)
(Dan Romascanu)
(Lisa Dusseault)
(Ralph Droms)
(Ron Bonica)
(Ross Callon)
(Tim Polk)
Note: This ballot was opened for revision 06 and is now closed.
Lars Eggert
No Objection
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
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