Let's see whether this gets through my email path...

My original intent was to avoid an "errata diversion" based on the idea that 
"content-length" header presence, in an interior body part of a multipart, was 
an error. After that, the tao says ignore it if you are a receiver. 

It is possible that for some exotic audit trail diagnostics of the future and 
for some yet to be defined SIP multipart, content-length will be helpful, for 
example. So I think the issue can and should be ignored. For future RFC 
examples, leave it out. 

Fwiw, and looking on the bright side of life, it now will serve as a useful 
piece of evidence for detecting "implementations by example," rather than by 
specification and parsimonious and rigorous design :-)


Dale Moberg

-----Original Message-----
From: Worley, Dale R (Dale) [mailto:[email protected]] 
Sent: Friday, March 30, 2012 6:26 AM
To: [email protected]; [email protected]; Moberg 
Dale
Subject: RE: Content-Length in multipart bodies -- What should we do?

> From: [email protected] [[email protected]]
> 
> My view is that these examples provide incorrect guidance to the
> reader as I'm in favour of the most conservative interpretation you
> have mentioned in one of your previous emails, i.e., that
> Content-Length is only allowed in "top level" bodies.
> 
> Strictly speaking I think Content-Length is a protocol header only
> (HTTP and SIP) rather than a MIME header.  It is not listed as a MIME
> header in
> http://www.iana.org/assignments/message-headers/perm-headers.html),
> contrary to e.g. Content-Disposition that is registered both as an
> HTTP header and a MIME header. Also, Content Length does not appear in
> RFC4021.
> 
> Also RFC3261 always refer to content-length as giving the length of
> the whole message body (e.g. clause 4, 7.5., 20.4).
> 
> So, I think, this header should just be ignored if received between
> body parts.

After thinking over the question, I agree with you.  Content-Length on
a body part is never needed, so providing it is redundant.  If its
value is different than the length of the body part as determined by
MIME framing, it seems that the MIME framing takes precedence, given
that is how the "body part" is defined.

Dale

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to