Adam,
Its pretty unsatisfying to end up with the manner of processing C-D
varying from one use of multipart/related to another. This seems like
the kind of thing that one would like to implement *once*.
If it is important to take C-D into account when processing
multipart/related, can we define exactly *how* it should be taken into
account? Does it supercede that of the container? Does it get merged
with that of the container? Does it get merged (in a well defined way)
with some default that the application is expected to provide for each part?
Thanks,
Paul
Adam Roach wrote:
On 7/10/08 3:09 PM, Gonzalo Camarillo wrote:
Hi Adam,
this is the paragraph we are talking about (in Section 8):
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.
However, UAs that do not understand 'multipart/related' will treat it
as 'multipart/mixed'. These UAs will not be able to process the body
as a compound object. Instead, they will process the body parts
according to their disposition type.
What you are asking for is not to ignore the disposition types of the
body parts within the multipart/related. If we go down that path, we
will need to describe how multipart/related will be different from
multipart/mixed. That is, we would need to clarify what we mean by
"processing the body as a compound object" if the body parts are still
processed per their respective disposition types, as if they were in a
multipart/mixed instead of in a multipart/related.
Following the "propose text" principle, could you please edit the
paragraph above so that we have a concrete proposal on how to describe
the processing of multipart/related bodies and how it would differ
from the processing of multipart/mixed bodies?
It's a bit wordy, but my first attempt at addressing the situation came
out like this:
The situation with 'multipart/related' is similar. In [RFC2387],
email clients processing a 'multipart/related' body are expected to
processes it as a monolithic object, ignoring the disposition types
of the body parts within it. Because SIP's use of
Content-Disposition varies markedly from that of email, this
constraint may not always make sense in SIP. Authors of SIP
extensions making use of 'multipart/related' bodies are advised to
explicitly address the handling of Content-Disposition on
'multipart/related' body parts. 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',
including the handling of Content-Disposition headers on body parts.
/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
