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
