Re: Body handling draft
Gonzalo Camarillo <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
Hi Paul,
answers inline:
Paul Kyzivat wrote:
> I think these changes generally look good. I'm now troubled by one thing:
>
> In section 8.2 (UA Behavior to Set the 'handling' Parameter) the
> following statement is repeated:
>
> "If the handling of a 'multipart/*' body as a whole is required for
> processing its enclosing body part or message" where * is {mixed,
> alternative, related}.
>
> For alternative and related this makes sense to me. But I don't know
> what this means for 'mixed'. How would I know if I had to process this
> *as a whole*, since there is no "as a whole" behavior of such a thing.
> AFAIK the mixed container has no significance of its own - it is *only*
> a container for its parts, each of which has its own significance.
>
> I'm just trying to understand from an operational perspective how I
> would make a decision between optional and required for a mixed body
> part. The only things I can think of are:
> - for some reason the mixed container is *referenced* from something.
> E.g. a cid: uri referencing the content-id header in the mixed itself.
> But I can't think of a reason to do that. It would seem to me that
> if I need to do that then the parts must be related in some way,
> so that I would be using multipart/related.
>
> - one or more of the *contained* parts of the mixed are required,
> and the container is being marked required to ensure that the
> required contained parts will indeed be processed.
> This seems the most sensible situation here.
>
> Am I missing something that makes this easier to understand?
yes, your understanding is correct. Those are the typical situations
where you would want to mark your mixed container as required.
Cheers,
Gonzalo
_______________________________________________
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