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

Eric Burger wrote:
> 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].

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?

> Section 12.1 makes it clear that for multipart/alternative, only the 
> 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.
> 
> Does this help, or did I miss the question?

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

> 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