Re: Comments on draft-ietf-sip-body-handling-02

Agreed. And, echoing what Keith said, what Dale has done is prove  
(from a Computer Science perspective) that complete evaluation of  
unfettered MIME is *possible*. It is up to the implementor to figure  
out whether they want to take short-cuts (and risk barfing on  
legitimate messages) or do the whole thing.

The point is doing the Full Monte *is* practical on small, memory and  
CPU constrained devices. So the argument "We can't do the real thing  
because it hurts" is provably not legitimate.

On Sep 29, 2008, at 11:09 PM, [email protected] wrote:

>   From: Paul Kyzivat <[email protected]>
>
>   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.
>
> 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.
>
>   From: Paul Kyzivat <[email protected]>
>
>> 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
> _______________________________________________
> 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

_______________________________________________
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