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 isclear, once we define what "+" means. We could try to outlaw thatexpression and "expressions like it", but there's no sensible boundary to enforce -- Do we ban expressions with more than five addends? Howabout 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 isvalid and what is not, and what the valid cases mean. Just like we'vedone 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/alternativeshould have handling=optional and that the processor should ignore thehandling 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 mightdo otherwise, and we don't know under what circumstances that mighthappen. So if somebody sets all the parts to handling=required, it seemsthat 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 howmultipart/alternative is to be processed, and that algorithm does notlook at the handling parameters of components of multipart/alternatives.Suppose I want to send a MESSAGE, and I require that some form of thebody 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 Ireturn? 415? In the first case it seems a little odd to return an errorif 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
