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'. > 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. > 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". 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
