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 setof recursive rules for processing an arbitary tree of nested body parts. The advantage of recursive rules is that stating rules recursivelyacutally reduces the number of interpretations that seem reasonably atfirst 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 bodyparts". Hence, the UAS must continue until it gets to the "leaf" bodyparts. 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 twodescriptions of the session in two different languages (with differentMIME 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
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
