Re: Comments on draft-ietf-sip-body-handling-02

Either it's MIME or it's not.

By the time we work this out, SDP-NG might be real :-)

On Sep 29, 2008, at 11:43 AM, Paul Kyzivat wrote:

> I agree it would be straightforward to define a rule that says one  
> must recursively unwrap all multipart/mixed bodies in order to find  
> other parts to process. But we ought to think if we really want to  
> do that.
>
> Potentially this could introduce a lot of extra processing. Its  
> especially a problem if there are middle boxes that want to process  
> SDP. They don't know if a given message contains SDP at all. And  
> they perhaps don't want to process anything *except* SDP. But they  
> will be forced to recursively open all the mixed parts to determine  
> if there is an sdp for them.
>
> (Or maybe this is a good thing because it will discourage middle  
> boxes from looking at sdp.)
>
> 	Thanks,
> 	Paul
>
> [email protected] wrote:
>>   From: Paul Kyzivat <[email protected]>
>>   > But thinking about this, I suspect we define no semantics
>>   > anywhere (please correct me if I am wrong) about what nesting
>>   > means. Does a nested body require different interpretation to a
>>   > multipart body, and if so, how do I discover what that difference
>>   > is. All the nesting would seem to tell me is that there might be
>>   > a different relationship, but it does not tell me what that
>>   > relationship is.
>>   I agree that the current loose wording leaves something to be  
>> desired.
>>   I just don't know how to fix it.
>> ISTM that the solution to the problem of nesting is to enunciate a  
>> set
>> of recursive rules for processing an arbitary tree of nested body
>> parts.
>> The advantage of recursive rules is that stating rules recursively
>> acutally reduces the number of interpretations that seem reasonably  
>> at
>> first glance -- it helps one identify plausible solutions faster.  If
>> one looks at specific situations, it's very easy to state rules that
>> can't be properly generalized -- and such rules usually lead to
>> trouble (or at least, non-extensibility) later.
>>   Let me give a concrete example:
>>   Is an INVITE valid if it contains a body of:
>> 	   multipart/mixed {
>> 	      multipart/mixed {
>> 		 multipart/mixed {
>> 		    application/sdp
>> 	   }}}
>>   Must the UAS keep unwrapping multiparts, looking for its SDP?
>> It seems that a multipart/mixed means "unwrap and process these body
>> parts".  Hence, the UAS must continue until it gets to the "leaf"  
>> body
>> parts.
>> If you think about it, there does not appear to be any other
>> processing rule that makes sense.
>>   And while we are discussing weird cases, what about:
>> 	   multipart/mixed {
>> 	      multipart/mixed {
>> 		 multipart/mixed {
>> 		    application/sdp-1
>> 		 }
>> 		 application/sdp-2
>> 	   }}
>>   If the latter is legal at all, which sdp is the offer? And what  
>> should    happen to the other one?
>> This is, pretty much, equivalent to:
>> 	   multipart/mixed {
>> 	      application/sdp-1
>>              application/sdp-2
>> 	   }
>> So the question is "If the sender provides us with two SDP bodies,
>> what should we do?"
>> Given that we envision a multipart/mixed might contain two
>> descriptions of the session in two different languages (with  
>> different
>> MIME types), it seems that a UA could either:
>> - pick one SDP and ignore the other, or
>> - reject the body as invalid (because two descriptions have the  
>> same type)
>> Dale
>> _______________________________________________
>> 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
> _______________________________________________
> 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

_______________________________________________
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