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

Hi,

The current work focuses on HTTP as the default protocol for OPES services. 

thanks
abbie

-----Original Message-----
From: bindignavile(_dot_)srinivas(_at_)nokia(_dot_)com 
[mailto:bindignavile(_dot_)srinivas(_at_)nokia(_dot_)com] 
Sent: Wednesday, November 13, 2002 10:24 AM
To: eburger(_at_)snowshore(_dot_)com; 
Jose(_dot_)Costa-Requena(_at_)nokia(_dot_)com; 
Stephane(_dot_)Coulombe(_at_)nokia(_dot_)com; 
jon(_dot_)peterson(_at_)neustar(_dot_)biz; 
Markus(_dot_)Isomaki(_at_)nokia(_dot_)com; 
dean(_dot_)willis(_at_)softarmor(_dot_)com; 
drage(_at_)lucent(_dot_)com; rohan(_at_)cisco(_dot_)com; 
Gonzalo(_dot_)Camarillo(_at_)lmf(_dot_)ericsson(_dot_)se
Cc: sipping(_at_)ietf(_dot_)org; 
simple(_at_)mailman(_dot_)dynamicsoft(_dot_)com; 
Pekka(_dot_)Pessi(_at_)nokia(_dot_)com; ietf-openproxy(_at_)imc(_dot_)org; 
um(_at_)snowshore(_dot_)com
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(_at_)snowshore(_dot_)com]
Sent: Tuesday, November 12, 2002 9:49 AM
To: Costa-Requena Jose (NMP/Helsinki); Coulombe Stephane

(NRC/Dallas);

jon(_dot_)peterson(_at_)neustar(_dot_)biz; Isomaki Markus (NRC/Helsinki); 
dean(_dot_)willis(_at_)softarmor(_dot_)com; drage(_at_)lucent(_dot_)com; 
rohan(_at_)cisco(_dot_)com; 
Gonzalo(_dot_)Camarillo(_at_)lmf(_dot_)ericsson(_dot_)se
Cc: sipping(_at_)ietf(_dot_)org; 
simple(_at_)mailman(_dot_)dynamicsoft(_dot_)com; 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(_dot_)Costa-Requena(_at_)nokia(_dot_)com

[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(_dot_)peterson(_at_)neustar(_dot_)biz]
Sent: Friday, November 08, 2002 6:58 AM
To: Isomaki Markus (NRC/Helsinki); 
dean(_dot_)willis(_at_)softarmor(_dot_)com; 
drage(_at_)lucent(_dot_)com; rohan(_at_)cisco(_dot_)com;

Gonzalo(_dot_)Camarillo(_at_)lmf(_dot_)ericsson(_dot_)se

Cc: sipping(_at_)ietf(_dot_)org; 
simple(_at_)mailman(_dot_)dynamicsoft(_dot_)com
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(_dot_)Isomaki(_at_)nokia(_dot_)com 
[mailto:Markus(_dot_)Isomaki(_at_)nokia(_dot_)com]
Sent: Friday, November 08, 2002 3:47 AM
To: dean(_dot_)willis(_at_)softarmor(_dot_)com; 
drage(_at_)lucent(_dot_)com;

rohan(_at_)cisco(_dot_)com;

Gonzalo(_dot_)Camarillo(_at_)lmf(_dot_)ericsson(_dot_)se
Cc: sipping(_at_)ietf(_dot_)org; 
simple(_at_)mailman(_dot_)dynamicsoft(_dot_)com
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(_dot_)willis(_at_)softarmor(_dot_)com]
Sent: 08 November, 2002 5:11
To: Drage, Keith (Keith)
Cc: sipping(_at_)ietf(_dot_)org; 
simple(_at_)mailman(_dot_)dynamicsoft(_dot_)com
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(_at_)lucent(_dot_)com

-----Original Message-----
From: Pekka Pessi [mailto:Pekka(_dot_)Pessi(_at_)nokia(_dot_)com]
Sent: 06 November 2002 18:24
To: sipping(_at_)ietf(_dot_)org; 
simple(_at_)mailman(_dot_)dynamicsoft(_dot_)com
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(_dot_)Pessi(_at_)nokia(_dot_)com> 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(_at_)mailman(_dot_)dynamicsoft(_dot_)com 
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(_at_)cs(_dot_)columbia(_dot_)edu for questions on

current sip

Use sip(_at_)ietf(_dot_)org for new developments of core SIP


_______________________________________________
simple mailing list
simple(_at_)mailman(_dot_)dynamicsoft(_dot_)com 
http://mailman.dynamicsoft.com/mailman/listinfo/simple

_______________________________________________
simple mailing list
simple(_at_)mailman(_dot_)dynamicsoft(_dot_)com 
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(_at_)cs(_dot_)columbia(_dot_)edu for questions on 
current sip Use 
sip(_at_)ietf(_dot_)org for new developments of core SIP 
_______________________________________________
simple mailing list
simple(_at_)mailman(_dot_)dynamicsoft(_dot_)com 
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(_at_)cs(_dot_)columbia(_dot_)edu for questions on 
current sip Use 
sip(_at_)ietf(_dot_)org for new developments of core SIP

_______________________________________________
simple mailing list
simple(_at_)mailman(_dot_)dynamicsoft(_dot_)com 
http://mailman.dynamicsoft.com/mailman/listinfo/simple