Eric,
Thanks
We have to be careful here, since some of the work would also fit or is being done in W3C and other bodies.
abbie
> -----Original Message-----
> From: Eric Burger [mailto:eburger@xxxxxxxxxxxxx]
> Sent: Thursday, November 14, 2002 9:18 AM
> To: Jose.Costa-Requena@xxxxxxxxx
> Cc: bindignavile.srinivas@xxxxxxxxx;
> Stephane.Coulombe@xxxxxxxxx; jon.peterson@xxxxxxxxxxx;
> Markus.Isomaki@xxxxxxxxx; dean.willis@xxxxxxxxxxxxx;
> drage@xxxxxxxxxx; Gonzalo.Camarillo@xxxxxxxxxxxxxxx;
> sipping@xxxxxxxx; Pekka.Pessi@xxxxxxxxx;
> simple@xxxxxxxxxxxxxxxxxxxxxxx; ietf-openproxy@xxxxxxx; UM
> list; um@xxxxxxxxxxxxx
> Subject: RE: [Sipping] Multimedia message adaptationInternet-Drafts
>
>
>
> I understand the sentiment. Neither opes nor lemonade are
> perfect fits for the current proposals. However, I would
> offer that the proper home for media adaptation is either
> opes or lemonade.
>
> My rationale is simple. Sipping is a transport area work
> group. The experts in the group are transport experts. The
> AD's are transport AD's. Media transformation is an
> application. Opes and lemonade are application work groups.
> The experts in the groups are application experts. The AD's
> are application AD's.
>
> I agree that there may be refinement or conventions that will
> be needed in SIP to support real-time media transformation.
> The correct place for that to happen is sipping. However,
> the right people with expertise in media transformation are
> in the opes and lemonade groups.
>
> From a charter point of view, media transformation (IMHO) is
> way out of scope for sipping. We've heard from Abbie that it
> is sort of out of scope for opes, as opes is focusing on
> HTTP. On the other hand, the mechanism being proposed is
> rather close to the lemonade work.
>
> I think this work fits into lemonade charter items 1
> (retrieval protocols) and 5 (translation services). We can
> refine the language to explicitly contain the real-time
> adaptation work items, if that would make everyone happy.
>
> --
> - Eric
>
>
>
>
> SIPPING is for SIP. OPES and LEMONADE are specifically for
> media transformation. Said differently, we have transport
> experts in SIPPING and application experts in OPES and LEMONADE.
>
> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@xxxxxxxxx]
> Sent: Wed 11/13/2002 9:00 PM
> To: Jose.Costa-Requena@xxxxxxxxx
> Cc: bindignavile.srinivas@xxxxxxxxx; Eric Burger;
> Stephane.Coulombe@xxxxxxxxx; jon.peterson@xxxxxxxxxxx;
> Markus.Isomaki@xxxxxxxxx; dean.willis@xxxxxxxxxxxxx;
> drage@xxxxxxxxxx; Gonzalo.Camarillo@xxxxxxxxxxxxxxx;
> sipping@xxxxxxxx; Pekka.Pessi@xxxxxxxxx;
> simple@xxxxxxxxxxxxxxxxxxxxxxx; ietf-openproxy@xxxxxxx; UM list
> Subject: Re: [Sipping] RE: [Simple] Multimedia message
> adaptationInternet-Drafts
>
>
>
> hello,
>
> please cease an desist cross posting when you reply.
> sipping seems
> like the default wg, so please send your comments only to
> sipping@xxxxxxxxx
>
> thanks,
> -rohan
>
> On Wednesday, November 13, 2002, at 07:35 AM,
> Jose.Costa-Requena@xxxxxxxxx wrote:
>
> > Hi,
> >
> > According to LEMONADE requirements, it is considering
> mainly messaging
> > systems and I agree that this proposal could fit into
> that context at
> > some extent. Nevertheless, the actual proposal deals
> with content
> > adaptation based on UA capabilities registered with
> SIP. Thus, I
> > consider that it is within SIPPING scope, as well.
> > Comments?
> > BR
> > Jose
> >
> > -----Original Message-----
> > From: Srinivas Bindignavile (NRC/Boston)
> > Subject: RE: [Sipping] RE: [Simple] Multimedia message
> > adaptationInternet-Drafts
> >
> >
> > 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]
> >> 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
> >>
> > _______________________________________________
> > 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
>
> _______________________________________________
> 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
>
>
>