Hi,
The current work focuses on HTTP as the default protocol for OPES services.
thanks
abbie
> -----Original Message-----
> From: bindignavile.srinivas@xxxxxxxxx
> [mailto:bindignavile.srinivas@xxxxxxxxx]
> Sent: Wednesday, November 13, 2002 10:24 AM
> To: eburger@xxxxxxxxxxxxx; Jose.Costa-Requena@xxxxxxxxx;
> Stephane.Coulombe@xxxxxxxxx; jon.peterson@xxxxxxxxxxx;
> Markus.Isomaki@xxxxxxxxx; dean.willis@xxxxxxxxxxxxx;
> drage@xxxxxxxxxx; rohan@xxxxxxxxx; Gonzalo.Camarillo@xxxxxxxxxxxxxxx
> Cc: sipping@xxxxxxxx; simple@xxxxxxxxxxxxxxxxxxxxxxx;
> Pekka.Pessi@xxxxxxxxx; ietf-openproxy@xxxxxxx; um@xxxxxxxxxxxxx
> 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]
> > 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
> >
>