Subject: [Sip] C-T-E and MIME Body Handling

From: Eric Burger <[email-masked]>
Date: Thu, 02 Aug 2007 18:01:49 -0400

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip