Subject: Re: [Sip] WGLC for draft-ietf-sip-body-handling

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 01 Aug 2008 12:46:35 +0300

Hi,

the handling parameter appears registered as defined by RFC 3261:
http://www.iana.org/assignments/sip-parameters

I will look into this and add the appropriate IANA actions so that the 
IANA's register is correct.

Thanks,

Gonzalo

DRAGE, Keith (Keith) wrote:
>> On Keith's point that body-handling updates 3204, that works 
>> for me if this draft updates the rules for ISUP.  However, if 
>> it updates the meaning of "handling", then it is 3459 that 
>> gets the update, as 3459 updates 3204 already.
> 
> Well if this is the case, then it should have added its own reference to
> the IANA registration of the handling parameter, which it did not.
> Suggest therefore that sip-body-handling also updates the IANA registry
> to include RFC 3459 as well as its own RFC number.
> 
> Regards
> 
> Keith
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Eric Burger
>> Sent: Monday, July 28, 2008 6:58 AM
>> To: [email-masked]; Gonzalo Camarillo
>> Cc: [email-masked] List
>> Subject: Re: [Sip] WGLC for draft-ietf-sip-body-handling
>>
>> Last I looked, RFC 3459 fully specifies what to do with 
>> multipart/ alternative and multipart/related. We did not 
>> bother to enumerate what to do with multipart/mixed, as it is 
>> painfully obvious: one has to look at everything to figure 
>> out what to do. Sometimes, life is "less than ideal."
>>
>> Like all things Mail (and SIP), handling does not require  
>> understanding.  What part of the original intention is not clear?   
>> Both 3204 and 3459 are gateway (B2BUA) scenarios.  3204 is a 
>> particular instance, while 3459 is the generic use case; mail 
>> focused, true, but appropriate for SIP, too.
>>
>> On Keith's point that body-handling updates 3204, that works 
>> for me if this draft updates the rules for ISUP.  However, if 
>> it updates the meaning of "handling", then it is 3459 that 
>> gets the update, as 3459 updates 3204 already.
>>
>> Unfortunately for me, I only have a copy of draft-ietf-sip-body-
>> handling-01 handy, so I cannot comment on -02 until this week.
>>
>>
>> On Jul 14, 2008, at 5:21 PM, Paul Kyzivat wrote:
>>
>>>
>>> [email-masked] wrote:
>>>> Unfortunately, I don't particularly like this document, as 
>> it gives a
>>>> lot of discussion of various cases, but doesn't present a clear and
>>>> unified description of the semantics of multipart body 
>> part handling.
>>>> So much so that it would take me a long time to verify that the
>>>> various rules in the document covered all cases and were 
>> not mutually
>>>> contradictory.
>>>> In a lot of situations, it seems that the rule is "the 
>> designer of  
>>>> the
>>>> software should be able to figure out what is meant in each  
>>>> particular
>>>> situation".  Which inevitably leads to "No, he can't." or 
>> rather "He
>>>> will think he can, but he'll get it wrong."
>>>> But I don't know that we have time to fix that now.
>>> Well...
>>>
>>> This was WGLC, and you did get your comment in before the 
>> WGLC closed.
>>> If the draft isn't right, its better to fix it now than later.
>>>
>>> Like a lot of things, it seems that they only get noticed 
>> by a small  
>>> number of people until it is almost "too late".
>>>
>>>> More specifically:
>>>> There seems to be no clear statement that "required" and "optional"
>>>> mean "required/optional for successful processing of the enclosing
>>>> body/body part" -- after all, the enclosing body part may itself be
>>>> optional, so "required" and "optional" can only be relative to the
>>>> necessity of understanding of the enclosing body part.  Or
>>>> alternatively, maybe we don't want this degree of 
>> complexity.  But to
>>>> avoid it, we would have to ban nested multiparts, or at 
>> least, all  
>>>> but
>>>> certain specific usages of nested multiparts.
>>> Well, the handling parameter wasn't invented for sip. So 
>> presumably  
>>> we should try to stick with its intended definition if we can.  
>>> Assuming we knew what that was.
>>>
>>> ISTM that if a part has handling=optional, and you choose not to  
>>> handle it, then you won't notice the handling parameter of any  
>>> enclosed parts. But that is an ISTM, not a normative reference.
>>>
>>>> There are a lot of mentions of the 415 response in 
>> passing.  As far  
>>>> as
>>>> I can tell, it is expected that the Accept header in a 415 response
>>>> will contain all the media types that the UA understands *in any
>>>> context whatsoever*, but that doesn't seem to be stated clearly
>>>> anywhere.  (E.g., it would be reasonable for a designer to 
>> think that
>>>> the Accept should only list media types understood for the 
>> particular
>>>> request method.)
>>> IMO this is a huge problem with all Accept-* headers. There is a  
>>> fairly good chance that the 415 will only list those 
>> supported in a  
>>> particular context. Consider for instance a case where a proxy for  
>>> an AOR routes SUBSCRIBE requests for presence to one UA, 
>> and INVITE  
>>> requests to a different UA. Those two UAs will most likely support  
>>> different content types.
>>>
>>> Even within a single UA there may be routing to different  
>>> "applications" and that may result in different indications 
>> of what  
>>> is accepted.
>>>
>>> One might argue that this only makes sense within a dialog, but  
>>> there are plenty of examples where the dialog is the wrong 
>> scope for  
>>> this. I don't know a good answer here, but I expect that in 
>> practice  
>>> the 415 may only reflect "this is what I can support here 
>> and now in  
>>> this context."
>>>
>>>> In section 5.1 the description is not really correct, as the "This
>>>> way..." sentence doesn't follow from the preceding sentence.  A  
>>>> better
>>>> phrasing is:
>>>>  Each body part within a 'multipart/alternative' carries an
>>>>  alternative version of the same information.  The body 
>> parts SHOULD
>>>>  be ordered in increasing richness of representation of the
>>>>  information.  More exactly, the UAS MUST process the last 
>> body part
>>>>  that it understands, and the UAC MUST order the body parts so
>>>>  that the this rule causes the UAS to behave as the UAC desires.
>>>> In section 6.1, I see:
>>>>  If the parameter [...] has the value 'required', the UAS returns a
>>>>  415 (Unsupported Media Type) response.
>>>> This is incorrect.  Of course, what is meant is, "If the 
>> parameter  
>>>> has
>>>> the value 'required', and the body part must be processed 
>> in order to
>>>> process the entire SIP message, then the UAS returns...", 
>> but that's
>>>> not what it says.
>>> This is just the tip of an iceberg. The iceberg is the meaning of  
>>> "handle".
>>>
>>> IMO, "handle" has to mean "process in a way compliant according to  
>>> the specifications for this C-T and C-D in the current context.  
>>> (Which includes the current message type and the processing of any  
>>> containing body parts, referencing headers, etc., as well as the  
>>> role (UAC, UAS, proxy, ...) of the processor.) In many cases,  
>>> "ignore" may be a valid form of processing.
>>>
>>>> In section 6.2 there is various discussion of the handling 
>> parameter
>>>> for parts within a multipart/alternative body part.  But the
>>>> discussion could be made clearer by starting with the 
>> statement that
>>>> the handling parameter is not significant: "The handling 
>> parameters  
>>>> of
>>>> the parts of a multipart/alternative part are ignored in processing
>>>> (the processing is determined by the type 
>> multipart/alternative), and
>>>> SHOULD be set to optional."  Or should we just omit 'handling' on
>>>> parts of a multipart/alternative?
>>> The specification of C-D states that the default for the handling  
>>> parameter is "handling=required", so omitting it solves nothing.
>>>
>>>> The sentence before that one is peculiar: "If the handling of a
>>>> 'multipart/alternative' body is required, the UA MUST set the
>>>> 'handling' parameter of the 'multipart/alternative' body to
>>>> 'required'."  This seems tautological -- why is it stated?
>>> Goes back to the meaning of "required".  I don't think it is  
>>> tautological, but maybe it could be stated better. The goal here  
>>> would be define the relationship between 
>> "handling=required" in the  
>>> header to desired behavior in the recipient of the body part.
>>>
>>>> In section 7.3, it is stated that "If the SIP message contains a
>>>> reference to the body part, the UA processes the body part 
>> according
>>>> to the reference.", but in the next paragraph, it says "Note that,
>>>> following the rules in [RFC3204], if a UA does not 
>> understand a body
>>>> part whose handling is optional, it ignores it."  But these are
>>>> contradictory if the part containing the reference is 
>> required but  
>>>> the
>>>> part that is referenced is marked optional.  In effect, the  
>>>> referenced
>>>> part becomes required (or rather, required under any circumstances
>>>> where the referencing part is required).  This can 
>> conflict with the
>>>> desire that all parts of a multipart/alternative are effectively
>>>> optional within that part.  What is really intended here?
>>> We discussed this a lot, and I thought we finally got something  
>>> workable.
>>>
>>> As I understand it, processing based on a reference and processing  
>>> based on presence are more-or-less independent.
>>>
>>> Assume for the moment that the type and disposition are 
>> understood.  
>>> If there is some implied processing based on the type and  
>>> disposition, then it will be done. If there is also a reference to  
>>> it via CID from one or more headers (or other body parts), then  
>>> those may also be performed based on the rules for those 
>> references.  
>>> If the goal is to include a body part solely so that it can be  
>>> referenced from elsewhere, then it ought to have a C-T/C-D that  
>>> doesn't result in any unexpected processing.
>>>
>>> If a part has handling=required, but is not understood, then  
>>> references to it aren't going to work.
>>>
>>> This is all pretty hard to explain. Expecially if you include  
>>> references from other body parts. After listening to Adam, 
>> I suspect  
>>> that maybe reference between body parts should be within a 
>> multipart/ 
>>> related, which will get us into the other discussion of C-D with  
>>> multipart/related. But I think there are cases where multipart/ 
>>> related isn't appropriate.
>>>
>>> Consider the following:
>>>
>>> An INVITE that contains both sdp and a body part referenced by a  
>>> Geoloc header. Those two parts aren't related to one another, so  
>>> they go into a multipart/mixed in the INVITE. The reference 
>> is from  
>>> the headers of the sip message to one of the body parts within the  
>>> multipart/mixed.
>>>
>>> Something similar could occur in a response to an INVITE as well,  
>>> though probably not with geoloc. For instance there could be an  
>>> Alert-Info header referencing a body part containing a picture of  
>>> the callee.
>>>
>>> Now suppose a REFER causes an INVITE that has such a response. And  
>>> the entire response is returned in sipfrag in a NOTIFY to the  
>>> referror. So then you have: A REFER with a body of type 
>> sipfrag. The  
>>> body in turn contains a body of type multipart/mixed. The 
>> multipart/ 
>>> mixed contains an SDP part and an image part. The sip 
>> headers in the  
>>> sipfrag reference the image part in the contained multipart/mixed.
>>>
>>> Now *probably* the image part in the response to the invite would  
>>> have handling=optional. Or it could have had handling=required if  
>>> the callee felt strongly about presenting its image. I don't know  
>>> what should happen to the INVITE if the image body part wasn't  
>>> understood. Nor do I understand what should happen to the 
>> NOTIFY if  
>>> the recipient doesn't understand the image.
>>>
>>> 	Paul
>>>
>>>> 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
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> 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
>>

_______________________________________________
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