Re: comments on draft-ietf-sip-info-events-01

It is not a theory. Once you have to explicitly identify the body part  
for an Info Package, you can identify the body part for ANY Info  
Package.

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

_______________________________________________
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