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

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

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.

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

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

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