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
