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

["Eric Burger" <eburger@xxxxxxxxxxxxx>]

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
>