RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts

[<bindignavile.srinivas@xxxxxxxxx>]

Hi,

As Eric has indicated, the OPES WG is considering transcoding issues! However, presently, rather than being protocol-agnostic, it is being designed for HTTP and RTP only. SIP is not being considered here.

-Srini

> -----Original Message-----
> From: ext Eric Burger [mailto:eburger@xxxxxxxxxxxxx]
> Sent: Tuesday, November 12, 2002 9:49 AM
> To: Costa-Requena Jose (NMP/Helsinki); Coulombe Stephane (NRC/Dallas);
> jon.peterson@xxxxxxxxxxx; Isomaki Markus (NRC/Helsinki);
> dean.willis@xxxxxxxxxxxxx; drage@xxxxxxxxxx; rohan@xxxxxxxxx;
> Gonzalo.Camarillo@xxxxxxxxxxxxxxx
> Cc: sipping@xxxxxxxx; simple@xxxxxxxxxxxxxxxxxxxxxxx; Pessi Pekka
> (NRC/Helsinki); IETF OPES (E-mail); IETF LEMONADE (E-mail)
> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> adaptationInternet-Drafts
> 
> 
> 
> There are already TWO work groups that are considering 
> EXACTLY these transcoding requirements.
> 
> They are OPES and LEMONADE.
> 
> I would offer that discussion of these capabilities happen in 
> those groups.  If SIP is the appropriate mechanism, then 
> those groups will submit the appropriate drafts to SIPPING, 
> outlining the requirements.
> 
> > -----Original Message----- From: Jose.Costa-Requena@xxxxxxxxx 
> [snip]
> > Nevertheless, "content adaptation" I-D has a wider scope 
> > since it is considering any content-type and it is taking 
> > into account the terminal/user preferences. So I would say 
> > that  it fits into SIPPING WG while the filtering I-D is 
> > mainly dealing with presence and I think it should be handled 
> > at SIMPLE WG.
> > BR
> > Jose
> > 
> > -----Original Message----- From: Coulombe Stephane (NRC/Dallas) 
> > > At a high level, these drafts also argue that capability
> > > negotiation should be administered by intermediaries rather 
> > than through an
> > > end-to-end process; this approach may attract some similar 
> > controversy.
> > 
> > Proposed capability negotiation can be used both ways (end-to-end or
> > administered by intermediaries).
> > 1) end-to-end: Someone who wants to send an Instant Message 
> > to another user
> > 	can send an OPTION query to learn about its terminal 
> > capabilities and
> > 	then create a message within its capabilities.
> > 	
> > 	I guess this is not controversial. However how 
> > realistic and usable is it in practice?
> > 	When composing a message, would a user really want to 
> > take into consideration 
> > 	the image formats to use, message size limitation, etc? 
> > 
> > 	For instance, you want to send a PNG image to a friend 
> > and his terminal only supports 
> > 	GIF format. What are you supposed to do? Find an image 
> > conversion tool to convert to GIF?
> > 	This is annoying if you are using a PC, imagine with a 
> > mobile phone or handheld?
> > 	
> > 	For usability reasons, the user wants to send a message 
> > without caring "too much" about 
> > 	what the other end is supporting.
> >  
> > 2)administered by intermediaries: this is discussed in detail 
> > in one of the drafts. 
> > 
> > 	Performing adaptation in the network is controversial 
> > but this is the only way to support
> > 	interoperability and good user experience. 
> > 
> > > the applicability and impact of this mechanism is larger 
> > than the problem of
> > > instant messaging and presence. While clearly, from the 
> > framework, instant
> > > messaging and presence cases are driving this work, it is 
> > applicable to the
> > > general use of SIP events (messaging, I think, is something 
> > of a corner case). 
> > 
> > Yes, applicability and impact is larger than IM and presence. 
> > It applies to many other
> > applications including the case of audio/video conferencing 
> > (for instance when there is 
> > no common audio or video codec between two ends).  
> > 
> > The drafts use the "corner case" of SIP IM for a few reasons:
> > 1) In SIP IM, there is no concept of capability negotiation 
> > (unlike the case of sessions using SDP).
> > 	A user sends a message without knowing anything about 
> > the recipient's terminal capabilities.
> > 2) In SIP IM, it easier to argue that there will be 
> > interoperability problems because of the variety of content 
> > types that could be sent (in audio/video session codecs are 
> > typically more agreed on). Right now text is mostly used but 
> > richer content will soon be used as is the case in Multimedia 
> > Messaging Service (MMS). By the way, message adaptation is a 
> > serious issue in MMS because of fast product capability 
> > evolution. It's hard to keep interoperability while not 
> > restricting new phones to send just "low-end" content.
> > 3) It is easier to explain the problem and propose a solution 
> > with a smaller well-defined problem.
> > 
> > Once we agree that SIP message adaptation is required, the 
> > requirements and solutions should be established from global 
> > perspective; not just SIP IM. For that reason, SIPPING may be 
> > the most appropriate place to initiate this activity.
> > 
> > Stephane
> > 
> > -----Original Message-----
> > From: ext Peterson, Jon [mailto:jon.peterson@xxxxxxxxxxx]
> > Sent: Friday, November 08, 2002 6:58 AM
> > To: Isomaki Markus (NRC/Helsinki); dean.willis@xxxxxxxxxxxxx;
> > drage@xxxxxxxxxx; rohan@xxxxxxxxx; Gonzalo.Camarillo@xxxxxxxxxxxxxxx
> > Cc: sipping@xxxxxxxx; simple@xxxxxxxxxxxxxxxxxxxxxxx
> > Subject: RE: [Sipping] RE: [Simple] Multimedia message
> > adaptationInternet-Drafts
> > 
> > 
> > 
> > It seems to me that these filtering drafts concern the 
> > modification of MIME
> > bodies in SIP messages by intermediaries. This is not exactly an
> > uncontroversial topic in SIP circles, and therefore I don't 
> > think it is a
> > foregone conclusion that this is work that some SIP-related 
> WG should
> > charter. At a high level, these drafts also argue that capability
> > negotiation should be administered by intermediaries rather 
> > than through an
> > end-to-end process; this approach may attract some similar 
> > controversy.
> > 
> > Provided that this is work the community would like to pursue, the
> > applicability and impact of this mechanism is larger than the 
> > problem of
> > instant messaging and presence. While clearly, from the 
> > framework, instant
> > messaging and presence cases are driving this work, it is 
> > applicable to the
> > general use of SIP events (messaging, I think, is something 
> > of a corner
> > case). While SIMPLE could certainly spend some time refining 
> > the framework
> > and requirements related to IM & presence, I imagine that at 
> > a mechanism
> > stage this work would need to take place in SIPPING.
> > 
> > Jon Peterson
> > NeuStar, Inc.
> > 
> > > -----Original Message-----
> > > From: Markus.Isomaki@xxxxxxxxx [mailto:Markus.Isomaki@xxxxxxxxx]
> > > Sent: Friday, November 08, 2002 3:47 AM
> > > To: dean.willis@xxxxxxxxxxxxx; drage@xxxxxxxxxx; rohan@xxxxxxxxx;
> > > Gonzalo.Camarillo@xxxxxxxxxxxxxxx
> > > Cc: sipping@xxxxxxxx; simple@xxxxxxxxxxxxxxxxxxxxxxx
> > > Subject: RE: [Sipping] RE: [Simple] Multimedia message
> > > adaptationInternet-Drafts
> > > 
> > > 
> > > Hi,
> > > 
> > > Actually this thread is about two separate things:
> > > - Event filtering
> > > - Multimedia message adaptation
> > > 
> > > Neither of them appears currently on any sippish WG charter 
> > > currently. 
> > > 
> > > Event filtering has been discussed several times and it is 
> > > even mentioned in (but out of scope of) SIP Events RFC. My 
> > > impression has been that people think that it is needed, but 
> > > there has been debate about scope and feasibility. I hope the 
> > > requirements draft will help in that discussion. My own 
> > > opinion is that what is concretely needed in short term is 
> > > some simple filtering definitions for Presence event package. 
> > > More wide-scoped and complex things could be worked upon as 
> > > the understanding accumulates.
> > > 
> > > Multimedia message adaptation hasn't been yet discussed much. 
> > > I think it is in general a desirable feature, especially for 
> > > relatively small and dumb terminals, which are not easily 
> > > upgradable and may not understand all media formats.
> > > 
> > > So I propose the WG chairs think where these items would be 
> > > appropriate, and if there is enough interest for them, let's 
> > > put them on the charters.
> > > 
> > > Markus
> > > 
> > > > -----Original Message-----
> > > > From: ext Dean Willis [mailto:dean.willis@xxxxxxxxxxxxx]
> > > > Sent: 08 November, 2002 5:11
> > > > To: Drage, Keith (Keith)
> > > > Cc: sipping@xxxxxxxx; simple@xxxxxxxxxxxxxxxxxxxxxxx
> > > > Subject: Re: [Sipping] RE: [Simple] Multimedia message
> > > > adaptationInternet-Drafts
> > > > 
> > > > 
> > > > Well, I'd like to hear opinions from the participants here . . .
> > > > 
> > > > Clearly they aren't explicitly on the charter for either 
> > > > group. Do we as
> > > > yet have a consensus that we need to work on these 
> > > problems? If so, we
> > > > can consider WHERE to work on them. I suspect SIPPING is 
> > closer to a
> > > > matching scope than is SIMPLE, but the relevant ADs may have 
> > > > suggestions
> > > > to make there as well.
> > > > 
> > > > --
> > > > Dean
> > > > 
> > > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> > > > > I am getting a bit confused as to which group should be 
> > > > discussing these filtering issues.
> > > > > 
> > > > > Could we have a statement from the WG chairs of SIPPING or 
> > > > SIMPLE as to whether this, and the moran drafts, are part of 
> > > > the scope of SIPPING or SIMPLE.
> > > > > 
> > > > > And before you say these are both author drafts, I think we 
> > > > do need to charter one of the WGs to do some work in this 
> > > > area - I am just not sure of the exact scope yet.
> > > > > 
> > > > > Keith
> > > > > 
> > > > > Keith Drage
> > > > > Lucent Technologies
> > > > > Tel: +44 1793 776249
> > > > > Email: drage@xxxxxxxxxx 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@xxxxxxxxx]
> > > > > > Sent: 06 November 2002 18:24
> > > > > > To: sipping@xxxxxxxx; simple@xxxxxxxxxxxxxxxxxxxxxxx
> > > > > > Subject: [Simple] Multimedia message adaptation 
> > Internet-Drafts
> > > > > > 
> > > > > > 
> > > > > > 	While these drafts concern event filtering, 
> > > too, the subject was
> > > > > > 	a bit misleading because I lazily just followed 
> > > up Tim's e-mail.
> > > > > > 
> > > > > > 					Pekka
> > > > > > 
> > > > > > 
> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > > ptation-framework-00.txt
> > > > > > 
> > > > > > 
> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > > ptation-requirements-00.txt
> > > > > > 
> > > > > > Pekka Pessi <Pekka.Pessi@xxxxxxxxx> writes:
> > > > > > >We have submitted two drafts regarding multimedia message
> > > > > > >adaptation. A multimedia message is typically a message
> > > > > > >containing images, audio or video clips and their 
> > presentation
> > > > > > >information, e.g., smil. Also, even XML-formatted text may
> > > > > > >require adaptation in some cases.
> > > > > > 
> > > > > > >Our goal is to have a framework using SIP, HTTP 
> and MIME that
> > > > > > >allows a person sending multimedia message to adapt 
> > the message
> > > > > > >contents suitable to all the recipients. In some cases the
> > > > > > >adaptation can be done by the sending terminal, but 
> > we also see
> > > > > > >that an adaptation service would be very useful in 
> > many cases. 
> > > > > > >Such an adaptation mechanism is used by MMS service 
> > provided by
> > > > > > >cellular networks nowadays.
> > > > > > 
> > > > > > >The message adaptation work concerns both SIPPING 
> and SIMPLE,
> > > > > > >the requirements I-D lists use cases and requirements for
> > > > > > >multimedia messaging and message adaptation 
> solutions and the
> > > > > > >framework I-D tries to explore possible solutions.
> > > > > > 
> > > > > > _______________________________________________
> > > > > > simple mailing list
> > > > > > simple@xxxxxxxxxxxxxxxxxxxxxxx
> > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > > > 
> > > > > _______________________________________________
> > > > > Sipping mailing list  
> > > https://www1.ietf.org/mailman/listinfo/sipping
> > > > > This list is for NEW development of the application of SIP
> > > > > Use sip-implementors@xxxxxxxxxxxxxxx for questions on 
> > current sip
> > > > > Use sip@xxxxxxxx for new developments of core SIP
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > simple mailing list
> > > > simple@xxxxxxxxxxxxxxxxxxxxxxx
> > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > 
> > > _______________________________________________
> > > simple mailing list
> > > simple@xxxxxxxxxxxxxxxxxxxxxxx
> > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
> > Use sip@xxxxxxxx for new developments of core SIP
> > _______________________________________________
> > simple mailing list
> > simple@xxxxxxxxxxxxxxxxxxxxxxx
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
> > Use sip@xxxxxxxx for new developments of core SIP
> > 
> _______________________________________________
> simple mailing list
> simple@xxxxxxxxxxxxxxxxxxxxxxx
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>