On 07/04/2008 02:26 AM, Gonzalo Camarillo wrote:
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.
I'm not proposing that we redefine it -- I'm proposing that we relax a
restriction that makes sense for email but not for SIP.
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.
RFC 4662 does.
The need for clear Content-Disposition differentiation is highlighted by
the exchange Robert and I had a few days ago (subject line "Possible
semantic confusion w/ bodies in subscribes"); in particular, look at the
examples in
<http://www.ietf.org/internet-drafts/draft-roach-sip-list-subscribe-bodies-00.txt>.
If we can't put content dispositions on the individual parts of
multipart/related documents, the disambiguation of
application/resource-lists+xml bodies becomes tricky.
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.
I believe that the draft I cite above provides an existence proof of a
case in which that is necessary.
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.
In practice, the thing that SIP has redefined here to be substantially
different from MIME isn't the use of multipart/related -- it's the use
of Content-Disposition. Because Content-Disposition really does mean
something quite different in SIP than it does in email, the
email-specific restrictions on it just don't make any sense here. If we
could go back and do it over, I would suggest that the proper thing to
do would be defining a new MIME header -- something like
"Content-Context" -- but that ship has sailed.
/a
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
