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

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 24 Jul 2008 22:03:41 +0200

In reviewing the document I have the following comments. In general I
found the document appropriately complete and ready for submission.

1)	Does the document update RFC 3261. The particular normative
statement I am thinking of is:

   For all MIME-based extensions to work, the recipient needs to be able
   to decode the multipart bodies.  Therefore, SIP UAs MUST be able to
   parse 'multipart' MIME bodies, including nested body parts.  In
   particular, UAs MUST support the 'multipart/mixed' and 'multipart/
   alternative' MIME types.

My understanding is that we do not want to regard this as an extenision,
i.e. we wish all RFC 3261 implementations to abide by it. Does that
therefore not mean an "updates".

2)	Does the document update RFC 3204. Here the particular
requirements I am thinking of is:

   If at least one of the body parts within a 'multipart/mixed' body has
   a 'handling' value of 'required', the UA MUST set the 'handling'
   parameter of the 'multipart/mixed' body to 'required'.  If all the
   body parts within a 'multipart/mixed' body have a 'handling' value of
   'optional', the UA MUST set the 'handling' parameter of the
   'multipart/mixed' body to 'optional'.

   If the handling of a 'multipart/alternative' body is required, the UA
   MUST set the 'handling' parameter of the 'multipart/alternative' body
   to 'required'.  The UA SHOULD also set the 'handling' parameter of
   all the body part within the 'multipart/alternative' to 'optional'
   (the receiver will process the body parts based on the handling
   parameter of the 'multipart/alternative' body; the receiver will
   ignore the handling parameters of the body parts).  The UA MUST use
   the same disposition type for the 'multipart/alternative' body and
   all its body parts.

Again this seems to be further specifying the handling parameter defined
in RFC 3204 rather than defining an extension.

3)	Section 4.3: 

   UAs SHOULD avoid unnecessarily nesting body parts because doing so
   would, unnecessarily, make processing the body more laborious for the
   receiver.

I had some problem with this because it seems an impossible statement to
determine conformance to. Is the RFC 2119 language therefore
appropriate.

4)	Section 11, IANA considerations.

Should the following registry not be updated to add a reference to this
draft (in addition to [RFC3261]):

Registry Name: Header Field Parameters and Parameter Values
Reference: [RFC3968]
Registration Procedures: Published RFC (A standards-track RFC is NOT
required)

Registry:
                                                           Predefined
Header Field                  Parameter Name               Values
Reference
----------------------------  ---------------------------  ----------
---------                                     
Content-Disposition           handling                     Yes
[RFC3261]

I also had a number of editorial comments which I have sent directly to
Gonzalo.

Regards

Keith
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Jul 2008 16:31:55 -0400

IMO this MUST be an update to 3204. It is tightening down incomplete 
specification. Without it being mandatory it isn't helpful.

IMO this SHOULD be an update to 3261. There are just too many needed 
uses of multipart that just won't work if you can't count on it being 
supported. The alternative is to try it, and if it fails, try again 
without the multipart. That presumes it makes sense to leave something 
out to get down to one part, and you can guess *which* part to fall back 
to. OTOH, making it mandatory won't make it happen. But I think that may 
just be a matter of giving some time, as long as it has been made mandatory.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 25 Jul 2008 10:45:22 +0300

Hi Keith,

thanks for your comments. Answers inline:

> therefore not mean an "updates".

yes, I think this document should update RFC 3261. I will add that to 
the draft.

> in RFC 3204 rather than defining an extension.

Yes, I will also add to the draft that it updates RFC 3204.

> determine conformance to. Is the RFC 2119 language therefore

Well, you are right that the "unnecessarily" makes it sound like a 
motherhood-and-apple-pie statement. But you could actually check 
conformance to it. If an implementation nests a body part without having 
a specific reason to do it, then it is not conformant. Any implementer 
should know why he or she is doing something. So, I would like to keep 
the capitalized SHOULD. In any case, if you have a strong opinion on 
this, it would not be a big deal for me to make the statement 
non-normative instead.

> Header Field                  Parameter Name               Values

yes, that is probably be a good idea. I will add that to the draft.

> I also had a number of editorial comments which I have sent directly to

Yes, I will introduce those editorial changes in the next revision of 
the draft.

Thanks,

Gonzalo

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 25 Jul 2008 16:49:55 +0200

Responding further on:

> > I had some problem with this because it seems an impossible 
> statement 
> > to determine conformance to. Is the RFC 2119 language therefore 
> > appropriate.
> 
> Well, you are right that the "unnecessarily" makes it sound 
> like a motherhood-and-apple-pie statement. But you could 
> actually check conformance to it. If an implementation nests 
> a body part without having a specific reason to do it, then 
> it is not conformant. Any implementer should know why he or 
> she is doing something. So, I would like to keep the 
> capitalized SHOULD. In any case, if you have a strong opinion 
> on this, it would not be a big deal for me to make the 
> statement non-normative instead.

The key thing we need to do is write a statement where we clearly understand whether the implementor has chosen not to apply the constraint.

Is it possible to write "SHOULD NOT nest" in this case, and then give some examples of where we might expect that to be broken. That then gives a clear test of conformance to the requirement, and the assessor of conformance can then decide whether breaking the SHOULD was acceptable or not.

If there are key aspects where be know nesting are best used, then maybe we should bring those out as separate requirements in RFC 2119 language, i.e. if <condition> then MUST nest else SHOULD NOT nest. But I suspect that we do not actually have anything specific for this. Speak up if anyone knows of any.

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.

Regards

Keith

Regards

Keith

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Friday, July 25, 2008 8:45 AM
> To: DRAGE, Keith (Keith)
> Cc: SIP IETF
> Subject: Re: Comments on draft-ietf-sip-body-handling-02
> 
> Hi Keith,
> 
> > My understanding is that we do not want to regard this as an 
> > extenision, i.e. we wish all RFC 3261 implementations to 
> abide by it. 
> > Does that therefore not mean an "updates".
> 
> yes, I think this document should update RFC 3261. I will add 
> that to the draft.
> 
> > 
> > Again this seems to be further specifying the handling parameter 
> > defined in RFC 3204 rather than defining an extension.
> 
> > I had some problem with this because it seems an impossible 
> statement 
> > to determine conformance to. Is the RFC 2119 language therefore 
> > appropriate.
> 
> Well, you are right that the "unnecessarily" makes it sound 
> like a motherhood-and-apple-pie statement. But you could 
> actually check conformance to it. If an implementation nests 
> a body part without having a specific reason to do it, then 
> it is not conformant. Any implementer should know why he or 
> she is doing something. So, I would like to keep the 
> capitalized SHOULD. In any case, if you have a strong opinion 
> on this, it would not be a big deal for me to make the 
> statement non-normative instead.
> 
> > Should the following registry not be updated to add a reference to 
> > this draft (in addition to [RFC3261]):
> > 
> > I also had a number of editorial comments which I have sent 
> directly 
> > to Gonzalo.
> 
> Yes, I will introduce those editorial changes in the next 
> revision of the draft.
> 
> Thanks,
> 
> Gonzalo
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 Jul 2008 11:26:19 -0400

> 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 bod…

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