> 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 PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Eric Burger > Sent: Monday, July 28, 2008 6:58 AM > To: [EMAIL PROTECTED]; Gonzalo Camarillo > Cc: [email protected] 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 PROTECTED] 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 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 > > _______________________________________________ > 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
