Re: So where are we at with WGLC of draft-ietf-sip-body-handling?

Hi,

I have revised the draft per my email below. The new rules (per our 
mailing list discussions) can be found on Section 7.2:

http://www.ietf.org/internet-drafts/draft-ietf-sip-body-handling-04.txt

Cheers,

Gonzalo

Gonzalo Camarillo wrote:
> Hi Dale,
> 
> thanks for all your comments and for putting your time on analyzing
> these issues. Let's agree on how to resolve the open issues, which you
> list below in your summary:
> 
>> There is an open discussion point on the precise semantics of 
>> 'required' -- in the SIP context, it is probably more convenient to 
>> mean "required for processing of the containing body part", but in
>> the e-mail gateway context, it is used to mean "required for the
>> overall message to be processed".  (The two are equivalent for
>> non-nested multiparts.)
> 
> yes, the current I-D specifies the latter; what has been called "global"
> in the email threads. The idea was to be consistent with email. However,
> I agree with the conclusions of the email discussions. That is, using
> the "local" approach probably makes more sense in a SIP context.
> 
> So, if nobody objects, I suggest we specify the following:
> 
> multipart/mixed:
> 
> o the handling of a multipart/mixed is 'required' if its processing as a
> whole is required.
> 
> o the handling parameter of a given component inside the multipart/mixed
> is set regardless of the handling parameter of the multipart/mixed.
> 
>   This rules means that we can have an optional multipart/mixed that has
>   required parts in it. *If* and only if the processor decides to
>   process the multipart/mixed, then it needs to process the required
>   parts.
> 
>   It can also happen that we have a required multipart/mixed with all
>   its components being optional. This is not a big deal. The only thing
>   that could happen is that the processor decides to process the
>   multipart/mixed and then it decides not to process any of its parts.
>   This of course relates to Paul's point on what it takes to process a
>   body part.
> 
> 
> multipart/alternative:
> 
> o the handling of a multipart/alternative is 'required' if its
> processing as a whole is required.
> 
> o the handling parameter of a given component inside the
> multipart/alternative is irrelevant. We can still recommend that it is
> set to optional.
> 
>   This rules means that now the multipart/alternative can contain
>   multipart/mixed parts that contain required components. This was not
>   possible with the rules in the current I-D.
> 
> multipart/related:
> 
> o the handling of a multipart/related is 'required' if its processing as
>   a whole is required.
> 
> o the handling of the root element within a multipart/related should
>   probably always be required. However, since we support required
>   multipart/mixed bodies with only optional components, I suggest we do
>   not bother specifying anything here.
> 
> 
>> My elaborate algorithm is, IMHO, a direct expression of the rules in 
>> the I-D, although I've probably added some "it could only mean this" 
>> assumptions which should be made explicit.  Whether the algorithm 
>> itself is given in the I-D is a presentation issue.
> 
> I tend to agree with others in that I prefer a declarative
> specification. My suggestion would be not to include the algorithm in
> the draft.
> 
>> If the algorithm it too complex to implement, we must simplify the I-D.
>>
>> I think we should make some statement that multipart/related should 
>> not be used unless it is "protected" by some extension-requirement 
>> that ensures the recipient can process multipart/related.
> 
> the draft already states that. In any case, in one of your previous
> emails, you suggested to strengthen the text. I suggest we do this:
> 
> OLD:
>    Authors wishing
>    to make use of 'multipart/related' bodies should keep in mind that
>    UAs that do not understand 'multipart/related' will treat it as
>    'multipart/mixed'.
> 
> 
> NEW:
>    Authors wishing
>    to make use of 'multipart/related' bodies should keep in mind that
>    UAs that do not understand 'multipart/related' will treat it as
>    'multipart/mixed'. If such treatment by a recipient is not acceptable
>    for a particular extension, the authors of such extension would need
>    to make sure (e.g., by using an option-tag or by other means) that
>    entities receiving the 'multipart/related' body were able to
>    correctly process them.
> 
> 
> Cheers,
> 
> Gonzalo
> 
> _______________________________________________
> 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
> 

_______________________________________________
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