Hi Paul,
Section 9 of the draft contains the following text:
Authors of SIP extensions making use of 'multipart/related' bodies
have to explicitly address the handling of the disposition types of
the body parts within the 'multipart/related' body. Authors wishing
to make use of 'multipart/related' bodies should keep in mind that
UAs that do not understand 'multipart/related' will treat it as
'multipart/mixed'.
Let me know whether or not you think this text is enough and, if not,
please propose the additions, removals, or modifications to the current
text that you think are needed.
Thanks,
Gonzalo
Paul Kyzivat wrote:
> I took a look at this (actually just the diffs), and it looks fine.
>
> I have one question after reading the additions about multipart/related:
>
> There is talk about extensions that use multipart/related, and what they
> must do. This implies an assumption that it cannot be used *without* an
> exception. Is that the case? If so, is it also the case for other kinds
> of multipart?
>
> My assumption is that, at least for multipart/mixed, no extension is
> required. E.g. I can just put a multipart/mixed body in my INVITE, make
> one body part be SDP, and others be anything I like, whether the
> recipient can make use of them or not.
>
> Similarly for multipart/alternative. I *think* I should be able to take
> any request that currently expects a body part of some type, and put a
> multipart/alternative in, with one part being the expected type, and one
> or more other contained body parts containing what *I* consider to be
> alternatives. E.g. a MESSAGE with a multipart/alternative containing
> text/plain and text/html. And it shouldn't require any extension to
> MESSAGE to support that. Right?
>
> With multipart/related I am inclined to agree that it makes no sense
> without some specification of what the collection is for.
>
> Would it be good to put some words about what is/isn't required into the
> document?
>
> Thanks,
> Paul
_______________________________________________
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