Hi Eric,
yes, making the last one required was an error. The intention was to
make the first one required. In any case, after some conversation with a
few people, the best way forward seems to be processing the
multipart/alternative base on its handling parameter and ignoring the
handling parameters of the body parts within the multipart/alternative.
Specification wise, this would mean that the sender SHOULD set the
handling parameter of all the body parts to optional and the receiver
MUST ignore them.
I will make the following changes to the draft:
In Section 6.2:
OLD:
If the handling of a 'multipart/alternative' body is required, the UA
MUST set the 'handling' parameter of the 'multipart/alternative' body
to 'required'. The UA MUST also set the 'handling' parameter of the
last body part within the 'multipart/alternative' to 'required'.
Additionally, the UA MUST set the 'handling' parameter of all body
parts within the 'multipart/alternative' except the last one to
'optional'. The UA MUST use the same disposition type for the
'multipart/alternative' body and all its body parts.
NEW:
If the handling of a 'multipart/alternative' body is required, the UA
MUST set the 'handling' parameter of the 'multipart/alternative' body
to 'required'. 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 UA MUST use the same
disposition type for the 'multipart/alternative' body and all its body
parts.
6.3. UA Behavior to Process 'multipart/alternative'
The receiver of 'multipart/alternative' body MUST process it based on
its handling parameter. The receiver SHOULD ignore the handling
parameters of the body parts within the 'multipart/alternative'.
Cheers,
Gonzalo
Eric Tremblay wrote:
> Hi Gonzalo,
>
> I have been going through draft-ietf-sip-body-handling-01 and noticed
> something that is either en error or counter-intuitive.
>
> Section 5.1 states:
> The body parts are
> ordered so that the last one is the richest representation of the
> information. This way, the recipient of a 'multipart/alternative'
> body chooses the last body part it understands.
>
> Section 6.2 states:
> If the handling of a 'multipart/alternative' body is required, the UA
> MUST set the 'handling' parameter of the 'multipart/alternative' body
> to 'required'. The UA MUST also set the 'handling' parameter of the
> last body part within the 'multipart/alternative' to 'required'.
>
> Why the last body part? Somehow, I would have expected that the
> 'handling' parameter of first body part to be set to 'required', not the
> last one, as the last one should hold the richest representation of the
> information, and possibly the one most difficult to understand/implement…
>
> And thinking about it a little bit more, I think that an application
> should always set the 'handling' parameter in the internal parts of a
> 'multipart/alternative' to 'optional', as this is pretty much what
> 'multipart/alternative' is. If 'multipart/alternative' itself is has its
> 'handling' set to 'required', then it means at least one of its internal
> part must be understood and handled. The sender cannot really decide
> which one has to be understood.
>
> Maybe my suggestion is going against things already defined in MIME or
> somewhere else. If this is the case, I think a simple clarification in
> the draft would do, something in the line:
>
> Even though the last part of the 'multipart/alternative' has its
> 'handling' parameter set to 'required', the receiving UA (or UAS) does
> not necessarly have to be able to handle this specific body part, it
> only has to be able to handle any body part within the
> 'multipart/alternative' body parts.
>
> Best Regards,
>
> EricT
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Sip mailing list http://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
