> Now, as far as I know (please correct me if I am wrong) Content-Length > is NOT a MIME header.
Right, it isn't. It could be argued that SIP's Content-Length was taken from HTTP (RFC1945) rather than MIME. It could be argued HTTP took the idea from email -- Content-Length used to be common in email headers a decade or two ago (but Content-Length didn't work too well for email for a variety of reasons). RFC2076 (February 1997) lists it, and says it was not a standard email header at the time. > If so, I guess it shouldn't be used as a MIME > header (together with Content-Type, Content-Transfer-Encoding etc)? RFC2045 does say: 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. but of course Content-Length doesn't have any meaning to MIME (neither would Content-Crayon). But neither of those headers do harm to a MIME parser, because a MIME parser ignores fields it doesn't understand. I guess you're saying SIP should have used something like "Length:" instead of "Content-Length:" to avoid collision with MIME's self-claimed ownership of all field names that begin with "Content-"? -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
