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

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:

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

_______________________________________________
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