Eric Burger wrote:
Either it's MIME or it's not.
By the time we work this out, SDP-NG might be real :-)
OK. I'm willing to accept that as an answer if that is the way it is.
Those people making proxies that gate media flows had better get to work!
Or, more likely, we will just find out that some usages don't work in
some network configurations. So we will end up with more restrictive
rules if you want to work in all environments.
Thanks,
Paul
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
