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

I'm trolling my e-mail contacts (pardon the pun) on how they do MIME  
decoding.

On the second paragraph: if you are a proxy that is actually doing  
something with the body, *and you are going to hack the body*, then I  
would offer you've created something that most likely will be some  
kind of B2BUA.

In the e-mail world, the ;handling property was created for gateways  
(B2BUA's), so the gateway could know whether dropping a body part,  
because the connected network/protocol could not handle that body  
part, would render the message useless. For example, if I am using an  
old version of Outlook, and I send you a Word file, the Word body part  
is required for the relay, but the application/tnef (proprietary  
Outlook stuff) is optional and the gateway can silently drop the part.

On Oct 1, 2008, at 12:51 PM, Paul Kyzivat wrote:

> 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