Qian Sun wrote:
Hi,
If we define a new Content Disposition type "advertisement" so that the operator or service
provider may insert advertisement in the all kinds of message body. And we want the advertisement content
'render' to the users. Could we use multiple content dispositions ("advertisement" and 'render')
for a single content part? Or only define a new Content Disposition Parameters "advertisement"
instead?
I'm quite certain that there may be only one content disposition per
body part, just as there can be only one content type per body part.
This is a real requirement, OMA and GSM is developing the mobile advertisement spec. the current
advertisement way in Email or Webpage is very "evil", it is difficult for the user's
client to distinguish the real content from advertisement, sometimes this is very disgusting or
confusing. A new Content Disposition type "advertisement" or something else could be
helpful, the advertisement may be displayed in a place different from the content.
I don't think I want to think or talk about "advertisement".
Paul
Cheers,
Qian
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: Friday, July 20, 2007 2:15 AM
To: Gonzalo Camarillo
Cc: sip
Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for
body (MIME) handling)
Gonzalo Camarillo wrote:
Hi,
yes, I agree there is a bigger issue with 'render'. Even though this
bigger issue does not directly relate to multipart, we can also tackle
it in the same draft and clarify how 'render' is used and what it means.
Sounds good. Maybe its just a matter of changing the title of the draft
to match the scope. Something like:
draft-sipping-content-type-disp-clarification-nn.txt
Paul
Cheers,
Gonzalo
Paul Kyzivat wrote:
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
_______________________________________________
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
