Dale Moberg is having trouble sending this to sip-implementors, so I am forwarding it for him.
Dale ________________________________________ From: Moberg Dale [[email protected]] Sent: Tuesday, March 27, 2012 8:17 PM To: Worley, Dale R (Dale) Subject: RE: Content-Length in multipart bodies Hi I have some doubts concerning the following remark on the Sip-implementors list. (I have had trouble posting to sim-implementors for unknown reasons so am just sending this directly.) ================================================================== > However, I have recently eared different opinions as to whether > additional Content-Length header fields may also be associated to > individual parts of the multi-part body and inserted between the > different parts. > I don't see any need for adding such fields but I'm wondering whether > doing that should even be > considered an error? The syntax and semantics of a multipart body is governed by RFC 1521. The relevant part seems to be section 7.2. Within RFC 1521, the "Content-Length" header is not defined. Section 7.2 says that only a very few headers on body parts are meaningful (and Content-Length is not among them). The section implies that other, meaningless headers are expected to be see and should be ignored. > Meantime I have also noticed that some of the examples in section 12.2.2 > of RFC6086 contain multiple content-length header fields and I'm > therefore wondering whether this should be considered an error! Since there is no defined meaning for such a Content-Length header, it seems to be incorrect that the header was shown in the examples. Dale ========================================================== RFC 1521 is obsoleted by RFC 2045, 2046 and others In [2045] section 9, it is noted that: Additional MIME Header Fields Future documents may elect to define additional MIME header fields for various purposes. Any new header field that further describes the content of a message should begin with the string "Content-" to allow such fields which appear in a message header to be distinguished from ordinary RFC 822 message header fields. MIME-extension-field := <Any RFC 822 header field which begins with the string "Content-"> Likewise [2045] defines part-headers as follows: MIME-part-headers := entity-headers [ fields ] ; Any field not beginning with ; "content-" can have no defined ; meaning and may be ignored. Now because SIP MIME is based on HTTP MIME, it is important to note that RFC 2616 [HTTPRFC], does provide some extensions such as the "Content-Length" header which can occur in a MIME-part-header as far as 2045 is concerned because the string begins with "Content-" Here is how HTTP extends 2045 headers. 14.13 Content-Length The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET. Content-Length = "Content-Length" ":" 1*DIGIT An example is Content-Length: 3495 Applications SHOULD use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in section 4.4. Any Content-Length greater than or equal to zero is a valid value. Section 4.4 describes how to determine the length of a message-body if a Content-Length is not given. Note that the meaning of this field is significantly different from the corresponding definition in MIME, where it is an optional field used within the "message/external-body" content-type. In HTTP, it SHOULD be sent whenever the message's length can be determined prior to being transferred, unless this is prohibited by the rules in section 4.4. The term "entity" was defined in 2045 (see below) and can designate "one of the parts in the body of a multipart entity" So HTTP's entity header "Content-Length" can apply to one of the parts in a multipart body in virtue of being an entity header. And because SIP says it follows HTTP MIME conventions, SIP MIME should allow Content-Length it seems to me. [2045] definition of Entity in section 2.4. Entity The term "entity", refers specifically to the MIME-defined header fields and contents of either a message or one of the parts in the body of a multipart entity. The specification of such entities is the essence of MIME. Since the contents of an entity are often called the "body", it makes sense to speak about the body of an entity. Any sort of field may be present in the header of an entity, but only those fields whose names begin with "content-" actually have any MIME-related meaning. Note that this does NOT imply thay they have no meaning at all... I am uncertain what the use would be for supplying these content-length headers for constituent body parts in a multipart, but I am thinking that these headers are probably not errors. I agree with you that it is likely that they would be ignored. Dale Moberg _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
