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

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