Subject: Re: [Sip] Clarification for multipart/alternative handling

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 20 May 2008 11:35:47 +0300

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-masked] for questions on current sip
> Use [email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip