Can you propose a simpler way to unambiguously identify the body part with a mechanism other than Content-ID? That will help me see a way how one would have to add work to handle multiple body parts, as demanded by RFC 3261.
On Nov 17, 2008, at 11:14 AM, Jonathan Rosenberg wrote:
Eric Burger wrote:SUBSCRIBE/NOTIFY didn't specify it because (1) the Event: header as specifies ensures only a single payload and (2) implementations may find themselves hopelessly broken when a legal, RFC 3261, multipart payload shows up.INFO has to specify it so we do not barf.This is bogus.We do not *NEED* to define what happens when INFO has multiple info packages in it. If the syntax allows just one, and the spec allows just one, there can only be one.And I will reiterate that, this is a separate question from whether an INFO can contain multipart, where one body is an INFO package object and the other is for a different reason (AIB). We are debating whether the INFO framework itself allows for multiple packages per INFO.Less is more. We don't need more features just because they are 'free' from a hypothetical standards perspective. This argument is also bogus.-Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group [EMAIL PROTECTED] http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Sip mailing list https://www.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
