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

From: [email-masked]
Date: Fri, 26 Sep 2008 17:08:31 -0400 (EDT)

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
   > > 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.
   > 
   > 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.

Why don't we say "UAs SHOULD minimize nesting of body parts."?

    minimize --verb
	1. to reduce to the smallest possible amount or degree.

Dale
_______________________________________________
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: [email-masked]
Date: Fri, 26 Sep 2008 17:08:41 -0400 (EDT)

From: Paul Kyzivat <[email-masked]>

   > 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

---

From: Eric Burger <[email-masked]>
Date: Sun, 28 Sep 2008 21:32:11 -0400

Because it is still missing the "SHOULD minimize nesting, unless X".  
What is the sensible X guidance to give?

---

From: Eric Burger <[email-masked]>
Date: Sun, 28 Sep 2008 21:36:41 -0400

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Sep 2008 11:43:23 -0400

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

---

From: Eric Burger <[email-masked]>
Date: Mon, 29 Sep 2008 15:00:21 -0400

Either it's MIME or it's not.

By the time we work this out, SDP-NG might be real :-)

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.
>
> 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
>
>>   If the latter is legal at all, which sdp is the offer? And what  
>> should    happen to the other one?

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Sep 2008 16:29:58 -0400

> 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

>> other parts to process. But we ought to think if we really want to do 
>> that.
>>
>> 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.
>>

---

From: [email-masked]
Date: Mon, 29 Sep 2008 23:09:45 -0400 (EDT)

What alternative rule do you propose as the meaning of
multipart/mixed?

   Potentially this could introduce a lot of extra processing.

That's sort of like saying that "x = 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0"
involves a lot of extra processing.  Yes, it does.  But it meaning is
clear, once we define what "+" means.  We could try to outlaw that
expression and "expressions like it", but there's no sensible boundary
to enforce -- Do we ban expressions with more than five addends?  How
about more than one addend which is "0"?  Any possible solution to
this problem is worse than the problem itself.

What I am advocating is that we explicitly abandon the attempt to
define only the situations that intuitively make sense, and instead
define a set of simple, well-defined rules that make clear what is
valid and what is not, and what the valid cases mean.  Just like we've
done with arithmetic expressions.  Otherwise we'll never escape the
swamp of trying to discern which ones make intuitive sense.

   > RFC 3459 uses multiparts in a somewhat different way that SIP does.
   > In SIP, the I-D suggests that components of a multipart/alternative
   > should have handling=optional and that the processor should ignore the
   > handling parameter:
   > 
   > 	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 receiver SHOULD ignore the handling parameters of the body
   > 	parts within the 'multipart/ alternative'.

   Right. But the SHOULD without qualification suggests that somebody might 
   do otherwise, and we don't know under what circumstances that might 
   happen. So if somebody sets all the parts to handling=required, it seems 
   that the handling of the unselected parts will still be ignored.

Yes, I see the problem there.  I'd replace that last SHOULD with MUST.
Actually, I argue that MUST is implied, as the RFCs define how
multipart/alternative is to be processed, and that algorithm does not
look at the handling parameters of components of
multipart/alternatives.

   Suppose I want to send a MESSAGE, and I require that some form of the 
   body be processed. I will offer it in two forms: text/enhanced and 
   text/html. How do I encode that?

	   C-T: multipart/alternative
	   C-D: render;handling=required
		   C-T: text/enhanced
		   C-D: render;handling=optional
		   ===
		   C-T: text/html
		   C-D: render;handling=optional
   or
	   C-T: multipart/alternative
	   C-D: render;handling=required
		   C-T: text/enhanced
		   C-D: render;handling=required
		   ===
		   C-T: text/html
		   C-D: render;handling=required

C-T: multipart/alternative
C-D: render;handling=required
	C-T: text/enhanced
	===
	C-T: text/html

'render' is inherited from the parent, and the handling of the
components is ignored.  We could also take it that MESSAGE implies
that the body is 'required', so the handling specification of the
parent is also optional.

   And if I don't support either of those text types, what error do I 
   return? 415? In the first case it seems a little odd to return an error 
   if I selected a part that is optional.

415.  The I-D is clear that 415 is how you respond to messages which
are not processable due to a failure of these MIME tests.

   And if I didn't require either part to be understood, would I just 
   change to handling=optional for the multipart/alternative itself?

Intuitively, I'd say that MESSAGE demands that the entire body be
processable, so handling=required is implicit for the entire body.
But assuming that we did not make such a deduction from the SIP
context of the message, if the body had handling=optional, it would
have the effect that the request could succeed even if the requester
did not understand the body.  (Hmmm...  That's another clause of the
algorithm I overlooked.)

(Note that there are cases where understanding the body is optional.
E.g., a sipfrag of the request in a failure response.)

Dale