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 mustrecursively unwrap all multipart/mixed bodies in order to find otherparts 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/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 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 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
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
