Gonzalo Camarillo wrote:
Hi Paul,
Regarding Content-Disposition in multiparts:
While it seems "wrong" to me, I can live with using "render" as the
normal disposition for multipart, *if* we can do a careful job of
defining what "render" actually means for SIP. Used this way it
clearly doesn't always mean to display the content to a user.
An entity receiving a 'multipart/mixed' body will process its body parts
based on their disposition types.If the disposition type of a particular
body part is not understood, it will be displayed to the user because
the default disposition type is 'render'.
There is a bigger problem with 'render' than just multipart.
We have many uses of body parts that never mention Content-Disposition
at all. The related examples don't use it, and so they all get a default
of 'render'. This is particularly the case with events. E.g.
- the notification for REFER contains type application/sipfrag.
Its probably not intended to be "rendered" in any literal sense,
though some conclusion about success or failure may be.
- usage of filter bodies in presence subscriptions (RFC 4660)
doesn't have a specified disposition, so it implicitly uses render.
Its hard for me to convince myself that what the presence server
does with these can be described as rendering.
- In fact, the only place I can think of where 'render' is (implicitly)
used in sip and has the appropriate connotation is in MESSAGE.
I think we just have to grandfather the use of 'refer' in SIP, and
document that the usage in sip does not mean "render", but rather means
that the usage must be determined by other context - specifically the
type of message or response and the content type. IOW, 'render' in sip
can be thought of as a peculiar spelling for 'by-context'. It might be
helpful to give guidance for development of future specs about when
'render' should be used vs defining a new disposition.
Therefore, the 'multipart/mixed' body will never be processed based on
its disposition type.
Based on my discussion above, I would consider this a case of the
multipart being processed according to its context *because* its
content-disposition is 'refer'. If it had some other content-disposition
then that might mean that it should be processed specially. E.g. if a
multipart/mixed had disposition 'by-reference' then that needs to be
taken into account, and the processing of the multipart becomes
conditional on the reference.
Also, there are only certain contexts in which multipart should be
processed "normally". Consider a NOTIFY from a REFER, with a
Content-Type of message/sipfrag, which happened to include a body as
part of the fragment. (This is legal.) That body might contain a
multipart/mixed, and that might contain other stuff. But I think the
processing of all of that is dependent on processing of the sipfrag. For
instance, if something inside that had handling=required, I don't think
that means that processing of the NOTIFY fails because the recipient
can't handle that.
This means that it does not make much sense to
talk about its disposition type as a whole.
Counterexample above.
However, we need to have one
in order to be able to set its handling parameter. That's why we can
either keep 'render' explaining that it is actually never used or define
a new disposition type.
I can go either way on that. But because there is existing usage, and
because 'render' semantics are already so messed up, I think it makes
more sense to stick with 'render' and just clarify its meaning.
Since existing implementations will not understand our newly defined
disposition type, they will treat it as 'render' anyway... but the
resulting behavior would be the same. That's why it may make sense to
keep using 'render'.
Yup.
On the other hand, semantically, it would make more sense to define a
new disposition type.
Also, if we decide to define the 'by-reference' disposition type (per a
different email thread), it could be used here as well.
It could be used when there is actually a reference to it. But it would
not be an appropriate disposition to use when there is no reference to
the multipart.
Thanks,
Paul
Cheers,
Gonzalo
Gonzalo Camarillo wrote:
Folks,
here you have the slides I have put together for the body (MIME)
handling presentation on Monday:
http://users.piuha.net/gonzalo/temp/ietf69-sip-camarillo-body-handling.ppt
These slides relate to this draft:
http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-handling-01.txt
The slides discuss all the open issues that have been brought up in
the list in the last months.
Comments are welcome.
Thanks,
Gonzalo
_______________________________________________
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
