[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] Comments on draft-ietf-sip-body-handling-02





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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip