Something was bothering me with the discussion of Content-Transfer-Encoding in Chicago, but I could not put my finger on it.
I just figured it out. I very much agree that *today*, if you have binary data in a SIP MIME part, and most of it is binary data, then one MUST use BINARY Content-Transfer-Encoding. That is fine and very well and good. What bothers me is that people might take a short-cut and never specify the Content-Transfer-Encoding. What happens if someone comes up with a really cool and useful Content-Transfer-Encoding? If we say *all* SIP message body parts that are MIME have a Content-Transfer-Encoding of BINARY, then we could never use that new C-T-E. What I could go for is saying the default C-T-E for SIP is BINARY, but that user agents MUST parse for C-T-E, and take the appropriate action if they find a C-T-E header. For today's parsers, that most likely would be to barf if the encoding is something other than 7bit, 8bit, or binary. That is fine - you are allowed to not understand a C-T-E. However, what would be "less than ideal" would be to have a parser that barfs on *any* C-T-E specification, including binary. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ 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
