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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.