> From: Moberg Dale [[email protected]]
>
> RFC 1521 is obsoleted by RFC 2045, 2046 and others
Um, yes. I looked at the headers of RFC 1521:
Network Working Group N. Borenstein
Request for Comments: 1521 Bellcore
Obsoletes: 1341 N. Freed
Category: Standards Track Innosoft
September 1993
and assumed that since it listed the RFCs that 1521 obsoletes, it
would also list the RFCs that obsolete it. But that's not true, the
rfc-index.txt entry is:
1521 MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms
for Specifying and Describing the Format of Internet Message Bodies.
N. Borenstein, N. Freed. September 1993. (Format: TXT=187424,
PS=393670, PDF=205091 bytes) (Obsoletes RFC1341) (Obsoleted by
RFC2045, RFC2046, RFC2047, RFC2048, RFC2049) (Updated by RFC1590)
(Status: DRAFT STANDARD)
The current definition is in RFC 2045.
> 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-"
However, SIP's header syntax is not defined to be a superset of HTTP's
header syntax. Rather, there are many references from RFC 3261 to RFC
2616 regarding various specific points. It turns out that section
20.14, regarding Content-Length, does not have one of those
references.
> 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.
> [...]
>
> 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.
A messy point... Although RFC 2616 section 14.13 says that
Content-Length is an entity-header, the description of its use seems
to consider only applying it to an entire HTTP response.
> 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.
The most liberal interpretation is that Content-Length is allowed in
multipart bodies, and its value must equal the length of the body
part, as determined by the MIME framing mechanism. The most
conservative interpretation is that Content-Length is only allowed in
"top level" bodies.
Probably a better question to ask is what is the best practice
regarding Content-Length headers on body parts?
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
