Hi Keith,
per our conversation, I guess we can just leave the text as it is right
now. The thing is that nesting was already defined for email and we do
not really want to change those definitions and recommendations. The
only thing we are doing here is stressing that you should not just
perform nesting for fun. You need a reason to do that.
Thanks,
Gonzalo
Paul Kyzivat wrote:
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
