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

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