Subject: [Sip] draft-ietf-sip-body-handling-03

From: [email-masked]
Date: Tue, 23 Sep 2008 16:06:01 -0400 (EDT)

1.

First, a complete nit:  The title of section 6.2 is "UA Behavior to
Process 'multipart/alternative'", whereas it should be "UA Behavior to
Process 'multipart/related'".

2.

The handling of a multipart/mixed is 'required' if there is any
component whose handling is 'required'.  (My previous message stated
this incorrectly.)  This has the sense that handling is a "global"
property, in that any part is marked 'required' if any simple part
within it is marked 'required'.

This rule causes various problems.  One problem is that the parts of a
multipart/alternative are supposed to have handling 'optional'
(although the handling value is ignored), which requires that all
components of a part that is a component of a multipart/alternative
must be 'optional'.  This makes it impossible to convey the logic of
the following example and similar situations (which are likely to
happen in practice):

	X: multipart/alternative
	|
        |   A: multipart/mixed: A1 is required, A2 and A3 are optional
	|   |
	|   |   A1: simple
	|   |
	|   |   A2: simple
	|   |
	|   |   A3: simple
	|
        |   B: multipart/mixed: B1 is required, B2 and B3 are optional
	|   |
	|   |   B1: simple
	|   |
	|   |   B2: simple
	|   |
	|   |   B3: simple

That is, in order to process A correctly, A1 must be understood, and
similarly for processing B correctly.  But the recipient only needs to
understand A *or* B.

According to the current draft, A1 and B1 must be marked 'required',
which implies that A and B must be marked 'optional'.  That
contradicts the rule for multipart/alternative, but worse, it doesn't
express the logic of the situation.

A better rule (IMHO) would be that the 'handling' value is 'local',
that is, it tells whether understanding the component is necessary for
understanding the part that contains it.  Leaving the specification of
whether the containing part needs to be understood to the containing
part's handling value, and those of the parts that contain it.

This fix requires amending the draft by removing the prescription of
how the handling of a multipart/mixed part is determined by the
handling of its components.  I believe that (within the specifications
and implications of the draft) the draft's processing logic is not
modified.

3.

A processor that does not implement multipart/related is allowed to
process the part as if it was multipart/mixed.  It's not clear that
there are *any* circumstances under which this will result in useful
results.  The current draft hints at this, but the hint should
probably be strengthened into a warning that multipart/related should
not be used in any circumstance where the recipient is not constrained
by some mechanism to implement multipart/related.

Dale
_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Sep 2008 18:52:06 -0400

[email-masked] wrote:
> this incorrectly.) 

> This has the sense that handling is a "global"

What are you looking at to draw the above conclusion?
I didn't have that impression. I figured it was "local" as you describe 
below.

> the following example and similar situations (which are likely to

This is an area that also bothers me. Perhaps the handling of parts of a 
multipart/alternative are irrelevant, as they are for multipart/related, 
unless the recipient doesn't understand and treats it as 
multipart/mixed. Of course, if a multipart/alternative is processed as a 
multipart/mixed the result isn't likely to be good.

> similarly for processing B correctly.  But the recipient only needs to

Its my understanding that there is an assumption that the alternatives 
are increasingly rich, and it is assumed that you do the last one you 
understand, but that then you also understand all the prior ones. (So in 
effect you the last one before the first one you don't understand, 
rather than doing the last one you do understand.)

> by some mechanism to implement multipart/related.

This seems reasonable to me.

I would think that someone building a multipart/related should construct 
it such that something reasonable happens if it is processed as a 
multipart/mixed. But certainly it may be impossible to do that.

	Paul

---

From: [email-masked]
Date: Wed, 24 Sep 2008 18:22:54 -0400 (EDT)

From: Paul Kyzivat <[email-masked]>

>From this:

   7.2.  UA Behavior to Set the 'handling' Parameter

   [...]

   If at least one of the body parts within a 'multipart/mixed' body has
   a 'handling' value of 'required', the UA MUST set the 'handling'
   parameter of the 'multipart/mixed' body to 'required'.  If all the
   body parts within a 'multipart/mixed' body have a 'handling' value of
   'optional', the UA MUST set the 'handling' parameter of the
   'multipart/mixed' body to 'optional'.

The current draft states that the handling of components of a
multipart/alternative are to be ignored:

   7.3.  UA Behavior to Process 'multipart/alternative'

   The receiver of 'multipart/alternative' body MUST process the body
   based on its handling parameter.  The receiver SHOULD ignore the
   handling parameters of the body parts within the 'multipart/
   alternative'.

And that seems to be completely correct; which component should be
processed is completely determined by other factors.

   Its my understanding that there is an assumption that the alternatives 
   are increasingly rich, and it is assumed that you do the last one you 
   understand, but that then you also understand all the prior ones.

I don't see that that is required at all.  It would be devilishly
difficult to implement.

I expect that in practice, every situation where multipart/related is
used is protected by some extension mechanism to ensure that the
recipient understands it.  That's the case now with "resource list
events", with "Require: eventlist".

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Sep 2008 20:03:58 -0400

>    'multipart/mixed' body to 'optional'.

Oh, duh. Yeah, I agree this is a problem.

I agree the *useful* thing to do here is to have the handling be "local" 
- only relevant if the container is being processed. That's if we have 
the liberty to do that. There has been a desire not to diverge from the 
mime/email interpretations of these things. I don't know what is the 
case here.

> I don't see that that is required at all.  It would be devilishly

I just reviewed the def of multipart/alternative in RFC 2045, and I 
agree your interpretation is right. In fact, choosing the last supported 
one isn't required, but its more of a suggestion.

> events", with "Require: eventlist".

That would certainly be wise. I guess you could dispense with that *if* 
you can structure it so that processing it as a mixed is tolerable. Hard 
to predict if anybody would ever do that, but we needn't forbid it.

The key here for anyone sending *any* multipart/XYZ is that anyone 
capable of processing a multipart/mixed will consider themselves capable 
of supporting multipart/XYZ, as a multipart/mixed.

So, creating a multipart/alternative, where the contained parts are:
- text/plain
- multipart/mixed
- multipart/related

isn't going to be very helpful. Anybody who supports multipart/mixed 
will process the last part, not the second.

	Thanks,
	Paul

---

From: Eric Burger <[email-masked]>
Date: Thu, 25 Sep 2008 05:17:37 -0600

Let's go back to where handling was really defined.  RFC 3459 section  
12.3 really does give guidence here:

    Criticality only affects the outermost level of the message or, in
    the case of multipart/alternative, the outermost level of the
    selected alternative.  Specifically, the receiving system ignores
    criticality indicators in embedded body parts.  This avoids the
    situation of a forwarded message triggering or suppressing undesired
    reporting.  This simply implements the procedures described in  
[RFC 2183].

Section 12.1 makes it clear that for multipart/alternative, only the  
handling property for the selected alternative matters.

BTW, the handling property of multipart/related parts DOES matter.   
This is precisely where handling is most useful.  The example in RFC  
3459 is the data and resource fork of a Macintosh file; it is highly  
likely for the data fork to be REQUIRED whereas the resource fork may  
be OPTIONAL.  In the SIP world, although I would not suggest it, I  
could envision a multipart/related caller description, where the  
REQUIRED part has some identity information and the OPTIONAL part is a  
PNG of the caller.  [In the real world, the PNG would more likely be  
an optional part of the caller description, but bear with me for the  
analysis.]  Following the rules of Section 12.1 of RFC 3459, the UAS  
has to understand the identity part of the caller information, but can  
safely ignore the picture part of the caller information.

Does this help, or did I miss the question?

On Sep 24, 2008, at 6:03 PM, Paul Kyzivat wrote:

>>   > this incorrectly.)    > This has the sense that handling is a  
>> "global"
>>   I didn't have that impression. I figured it was "local" as you  
>> describe    below.
>>> From this:
> I agree the *useful* thing to do here is to have the handling be  
> "local" - only relevant if the container is being processed. That's  
> if we have the liberty to do that. There has been a desire not to  
> diverge from the mime/email interpretations of these things. I don't  
> know what is the case here.
>
>>   This is an area that also bothers me. Perhaps the handling of  
>> parts of a    multipart/alternative are irrelevant, as they are for  
>> multipart/related,    unless the recipient doesn't understand and  
>> treats it as    multipart/mixed. Of course, if a multipart/ 
>> alternative is processed as a    multipart/mixed the result isn't  
>> likely to be good.
>>   Its my understanding that there is an assumption that the  
>> alternatives    are increasingly rich, and it is assumed that you  
>> do the last one you    understand, but that then you also  
>> understand all the prior ones.
> agree your interpretation is right. In fact, choosing the last  
> supported one isn't required, but its more of a suggestion.
>
>>   > 3.
>>   I would think that someone building a multipart/related should  
>> construct    it such that something reasonable happens if it is  
>> processed as a    multipart/mixed. But certainly it may be  
>> impossible to do that.
> That would certainly be wise. I guess you could dispense with that  
> *if* you can structure it so that processing it as a mixed is  
> tolerable. Hard to predict if anybody would ever do that, but we  
> needn't forbid it.
>
> capable of processing a multipart/mixed will consider themselves  
> capable of supporting multipart/XYZ, as a multipart/mixed.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Sep 2008 20:36:43 -0400

Eric Burger wrote:
>    reporting.  This simply implements the procedures described in [RFC 
> 2183].

This doesn't exactly say what happens if you decide to start processing 
the innards of a multipart/mixed. But it seems to suggest the "local" 
interpretation that Dale is suggesting. Do you agree?

> handling property for the selected alternative matters.

So you are saying that a multipart/alternative may have several parts 
with handling=required, and that I only have to be capable of handling 
the part I choose?

Suppose I have a multipart/alternative with handling=requires, with 
several parts that have handling=required, and one that is optional; and 
I don't support the types of any of the parts. Can I select the one that 
is optional and then do nothing with it, because it is optional? Will 
that satisfy the requirement on the multipart/alternative?

> BTW, the handling property of multipart/related parts DOES matter.  This 
> is precisely where handling is most useful.  The example in RFC 3459 is 
> the data and resource fork of a Macintosh file; it is highly likely for 
> the data fork to be REQUIRED whereas the resource fork may be OPTIONAL.  
> In the SIP world, although I would not suggest it, I could envision a 
> multipart/related caller description, where the REQUIRED part has some 
> identity information and the OPTIONAL part is a PNG of the caller.  [In 
> the real world, the PNG would more likely be an optional part of the 
> caller description, but bear with me for the analysis.]  Following the 
> rules of Section 12.1 of RFC 3459, the UAS has to understand the 
> identity part of the caller information, but can safely ignore the 
> picture part of the caller information.
> 

I think the earlier comments do help, subject to my clarifying 
questions. For this last point about mp/related, I wasn't asking about 
it but your comments do suggest that changes in this document are called 
for.

	Thanks,
	Paul

>> "local" - only relevant if the container is being processed. That's if 
>> we have the liberty to do that. There has been a desire not to diverge 
>> from the mime/email interpretations of these things. I don't know what 
>> is the case here.
>>
>>>   This is an area that also bothers me. Perhaps the handling of parts 
>>> of a    multipart/alternative are irrelevant, as they are for 
>>> treats it as    multipart/mixed. Of course, if a 
>>> multipart/alternative is processed as a    multipart/mixed the result 
>>> isn't likely to be good.
>>> alternatives    are increasingly rich, and it is assumed that you do 
>>> the last one you    understand, but that then you also understand all 
>>> the prior ones.
>>> processed as a    multipart/mixed. But certainly it may be impossible 
>>> to do that.

---

From: [email-masked]
Date: Fri, 26 Sep 2008 13:09:26 -0400 (EDT)

The behavior of 'handling' is defined in RFC 3459, as Eric points out.
But interestingly, 3459 gives no guidance in regard to
multipart/mixed.  So I'd say that the I-D has freedom regarding
multipart/mixed.

If the processor doesn't know it doesn't support multipart/related, it
will assess the last component to see if it can process it.  But the
processor may discover that it can't process the last component
(according to the rules for multipart/mixed), e.g., if the component
contains a component of a type that the processor doesn't understand
but the component has handling=required.

The key to my summary is that, in general, the processor must parse
the body and walk the body-part tree to obtain enough information to
determine which body-parts it will process.  It is not a one-pass
process.

Dale

---

From: [email-masked]
Date: Fri, 26 Sep 2008 13:09:46 -0400 (EDT)

RFC 3459 uses multiparts in a somewhat different way that SIP does.
In SIP, the I-D suggests that components of a multipart/alternative
should have handling=optional and that the processor should ignore the
handling parameter:

	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 receiver SHOULD ignore the handling parameters of the body
	parts within the 'multipart/ alternative'.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Sep 2008 13:54:59 -0400

> 	parts within the 'multipart/ alternative'.

Right. But the SHOULD without qualification suggests that somebody might 
do otherwise, and we don't know under what circumstances that might 
happen. So if somebody sets all the parts to handling=required, it seems 
that the handling of the unselected parts will still be ignored.

Suppose I want to send a MESSAGE, and I require that some form of the 
body be processed. I will offer it in two forms: text/enhanced and 
text/html. How do I encode that?

	C-T: multipart/alternative
	C-D: render;handling=required
		C-T: text/enhanced
		C-D: render;handling=optional
		===
		C-T: text/html
		C-D: render;handling=optional
or
	C-T: multipart/alternative
	C-D: render;handling=required
		C-T: text/enhanced
		C-D: render;handling=required
		===
		C-T: text/html
		C-D: render;handling=required

And if I don't support either of those text types, what error do I 
return? 415? In the first case it seems a little odd to return an error 
if I selected a part that is optional.

And if I didn't require either part to be understood, would I just 
change to handling=optional for the multipart/alternative itself?