This document largely looks good to me. I have only one substantive
comment to make.
Section 8 has the following text:
The situation with 'multipart/related' is similar. Per [RFC2387], a
UA processing a 'multipart/related' body processes it as a compound
object ignoring the disposition types of the body parts within it.
This is, indeed, consistent with RFC 2387. However, RFC2387 is geared
towards content in email messages. The constraint, in that context,
makes a lot of sense -- it would be bizarre to, for example, have an
HTML page (disposition inline) with subservient images tagged as
attachments. In an email context, it makes sense to treat the whole
multipart/related document as monolithic.
When we consider the kinds of things we're doing with
content-disposition in SIP lately, this logic falls apart. We're no
longer simply indicating whether something should be shown as part of an
email or saved as a local file; we're indicating fairly complex
semantics that help disambiguate uses of MIME types that might otherwise
be confused with each other -- see, for example, my message a few hours
ago talking about how we disambiguate ad-hoc list subscriptions from
XCAP diff subscriptions (which use the same MIME type by default).
In that context, the use of Content-Disposition on individual parts of a
multipart/related document makes a *huge* amount of sense. I think the
sip-body-handling document needs to take into consideration the needs of
the SIP protocol in this case, rather than reinforcing restrictions from
RFC 2387 that really only make sense for email.
/a
_______________________________________________
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
