Re: draft-ietf-sip-body-handling-03

[email protected] wrote:
> 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'.

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.

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

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.

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

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

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

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