Eric Burger wrote:
I do not think one can say what the Content-Disposition of a multipart/*
body part should be. From RFC 2183:
If a Content-Disposition header is used on a multipart body part, it
applies to the multipart as a whole, not the individual subparts.
The disposition types of the subparts do not need to be consulted
until the multipart itself is presented. When the multipart is
displayed, then the dispositions of the subparts should be respected.
I've been looking for somebody who understands how this was intended to
work in MIME. I guess you are that somebody.
The quote above starts with an "if". That makes sense for
multipart/alternative. But what about a multipart/mixed where the
individual subparts have different dispositions? We need some content
disposition that results in the subparts being investigated in an
appropriate way. But what would that be for sip?
We already have a compatible-with-MIME solution. Mark the
Content-Disposition of the multipart/* as render, session, or inline with
the needed handling parameter, and have the Content-Disposition of the
sub-parts be whatever they really need to be (if not render). The logic is
simply to say what you mean.
Consider the SDP+ISUP case. The sdp disposition is "session" and the
ISUP disposition is "signal". What should the disposition of the
multipart be?
In the case of mail it seems that "render" works, because the multipart
itself can be rendered. But that doesn't make sense for sip.
It really is just a suggestion. If we are
talking about a multipart/alternative describing sessions, then the
Content-Disposition should be session. Of course, you could have
Content-Disposition be foobar (or, better yet, inline), so long as (1) the
UAS does not barf and (2) the real Content-Dispositions are present on all
of the sub-parts.
I don't fully know what "inline" means. If we interpreted it to mean
"inline with the sip processing" then it would be reasonable.
As best I understand it, any part that does not have its own
content-disposition header has a default that is determined in a
context-free way, (the default disposition for content-type
application/sdp is "session" and the for application/isup is "signal")
and the default-default is "render". I haven't seen any indication that
the content-disposition is ever inherited from the enclosing body.
So, unless I've missed something, the default disposition for
multipart/* is "render". But unless we define what it means to "render"
a multipart in sip then I think this is nonsense.
It may be that for reasons of backward compatibility we should define
"render" for sip, at least for multipart. But that would be a bit ugly.
Paul
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the individual or entity
named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete
it.
_______________________________________________
Sip mailing list https://www1.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
_______________________________________________
Sip mailing list https://www1.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
