DRAGE, Keith (Keith) wrote:
I know we do have this paragraph in section 4.1:
Nested MIME bodies are yet another useful tool to build and combine
SIP extensions. Using the extensions in the previous examples, a UA
that supported a new session description format and that needed to
include a location object in an INVITE request would include a
'multipart/mixed' body with two body parts: a location object and a
'multipart/alternative'. The 'multipart/alternative' body part
would, in turn, have two body parts: a session description written in
SDP and a session description written in the newer session
description format.
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.
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?
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?
I know these are bizarre cases. I'm just pushing the envelope to
understand the implications for the sorts of decoding logic the stack
should be expected to use.
Thanks,
Paul
_______________________________________________
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
