Hi Adam,
the problem with redefining stuff that was already defined in email is
that we may lose the ability to use it as originally defined. For
example, if I want to send you a MESSAGE request with the html page in
your example (which includes images), I would probably use
multipart/related (as in the email in your example). If we redefine
multipart/related, we may face problems because I may not be able to use
it like that any longer.
In any case, do we have any existing extension that sends
multipart/related in a different context than the one above?... because
we may not need to use it in other contexts after all.
The real question is whether or not we need the ability to have
extensions that use multipart/related where the content disposition of
the multipart/related plus the content types of the body parts are not
enough to understand how to process the extension.
The thing is that, when I talked with the apps folks (they reviewed the
draft), they stressed the fact that they do not like it when we redefine
stuff that they had previously defined because they expect it to work in
a certain way when it actually works in a different way. The guideline
we got was that, if we need to define something new, we should really do
that instead of redefining an old mechanism. So, if we really have the
requirement above, maybe it is better to define something new than to
reuse multipart/related.
Cheers,
Gonzalo
Adam Roach wrote:
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
