Hi,
I agree with Paul that having a common way for handling
multipart/related would be good.
In any case, if we decided to use the disposition types of the body
parts in a multipart/related instead of ignoring them, we would need to
understand what would be the difference between:
- a multipart/mixed where body parts are treated according to their
disposition types, and
- a multipart/related where body parts would also be treated according
to their disposition types.
If we do not explicitly explain what the difference in processing is,
implementers are going to be confused.
Cheers,
Gonzalo
Paul Kyzivat wrote:
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
