[EMAIL PROTECTED] wrote:
From: Paul Kyzivat <[EMAIL PROTECTED]>
> Section 12.1 makes it clear that for multipart/alternative, only the
> handling property for the selected alternative matters.
So you are saying that a multipart/alternative may have several parts
with handling=required, and that I only have to be capable of handling
the part I choose?
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.
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
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.
And if I didn't require either part to be understood, would I just
change to handling=optional for the multipart/alternative itself?
_______________________________________________
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
