From: Paul Kyzivat <[EMAIL PROTECTED]> > 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. The behavior of 'handling' is defined in RFC 3459, as Eric points out. But interestingly, 3459 gives no guidance in regard to multipart/mixed. So I'd say that the I-D has freedom regarding multipart/mixed. 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. If the processor doesn't know it doesn't support multipart/related, it will assess the last component to see if it can process it. But the processor may discover that it can't process the last component (according to the rules for multipart/mixed), e.g., if the component contains a component of a type that the processor doesn't understand but the component has handling=required. The key to my summary is that, in general, the processor must parse the body and walk the body-part tree to obtain enough information to determine which body-parts it will process. It is not a one-pass process. 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
