Subject: [Sip] So where are we at with WGLC of draft-ietf-sip-body-handling?

From: Dean Willis <[email-masked]>
Date: Thu, 16 Oct 2008 18:54:01 -0500

There was a lot of discussion around the first of the month.

Where are we now?

--
Dean
_______________________________________________
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

---

From: [email-masked]
Date: Sun, 19 Oct 2008 22:50:44 -0400 (EDT)

From: Dean Willis <[email-masked]>

   Where are we now?

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.)

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.

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.

Dale

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 22 Oct 2008 11:11:06 +0300

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:

> 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.

> 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.

> 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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 29 Oct 2008 21:46:55 +0200

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:
>> If the algorithm it too complex to implement, we must simplify the I-D.
>>