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

Ok, ok, UNCLE!!!

I'd still like to know if email clients need to do this two pass 
approach - first searching for all the references to determine if all 
the handling requirements can be met, and then actually doing the 
processing of the referenced parts?

Also, it *is* legal for proxies to process bodies. But its obviously not 
required (by the protocol) for them to do so. Do we have a clue how the 
handling parameter applies to proxies? I assume in effect they can just 
ignore it and consider handling to be optional for all parts. Also, I 
presume a proxy that cares about body parts might want to investigate 
all the alternatives of a multipart/alternative, since it can't know 
which one the recipient will choose.

	Thanks,
	Paul

Eric Burger wrote:
> 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
_______________________________________________
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