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

From: [email-masked]
Date: Fri, 8 Nov 2002 13:46:36 +0200

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:[email-masked]]
> Sent: 08 November, 2002 5:11
> To: Drage, Keith (Keith)
> Cc: [email-masked]; [email-masked]
> 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: [email-masked] 
> > 
> > > -----Original Message-----
> > > From: Pekka Pessi [mailto:[email-masked]]
> > > Sent: 06 November 2002 18:24
> > > To: [email-masked]; [email-masked]
> > > 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 <[email-masked]> 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
> > > [email-masked]
> > > 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 [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> > 
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: [email-masked]
Date: Fri, 8 Nov 2002 16:29:29 +0200

Hi,

Is this analogous to media transcoding within a session? Maybe these two cases should be handled somewhat similarly. The general framework is something like this:
- There is a UA supporting media type X/Y (content in SIP message bodies, media setup with SDP offer-answer) 
- There is another UA supporting media type X/Z
- There is a resource somewhere which can convert X/Y to X/Z and vice versa

The things to consider:
- Should it be a proxy or a UA who needs to detect the need for the conversion?
- If it is a UA, how can it manage to discover and use a suitable converter?
- If it is a proxy, what information can it use to do the detection?
- What about end-to-end security and trust models?
- What is the efficiency in the access network, i.e. how many times the content needs to be sent from UA to proxy or proxy to UA? (In theory only once, but in end-to-end scenarios trial and error may the way, and that may not be acceptable.)

Are there any BCP-type-of call flows somewhere how media transcoding can or should be handled using current SIP and SDP specifications, taking also into account the possible use of S/MIME? Are similar practices applicaple to SIP payload adaptation?

Markus

> From: ext Peterson, Jon [mailto:[email-masked]]
> Sent: 08 November, 2002 14:58
> To: Isomaki Markus (NRC/Helsinki); [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> 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.
> 
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Friday, November 08, 2002 3:47 AM
> > To: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]
> > Subject: RE: [Sipping] RE: [Simple] Multimedia message
> > 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
> > 
> > > > Sipping mailing list  
> > https://www1.ietf.org/mailman/listinfo/sipping

---

From: [email-masked]
Date: Fri, 8 Nov 2002 16:29:29 +0200

Hi,

The things to consider:

Markus

---

From: [email-masked]
Date: Fri, 8 Nov 2002 13:46:36 +0200

Hi,

Markus

---

From: [email-masked]
Date: Fri, 8 Nov 2002 17:50:08 -0600

Hi,

> 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:[email-masked]]
Sent: Friday, November 08, 2002 6:58 AM
To: Isomaki Markus (NRC/Helsinki); [email-masked];

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.

---

From: [email-masked]
Date: Sat, 9 Nov 2002 19:21:04 +0200

Hi,

In addition to Stephane's clarification about the "content adaptation" I-D, I would like to remark the difference between this draft (from Coulombe et al.) and the "filtering" draft (from Tim Moran et al).
The aim of "filtering" draft is to define a framework for building the appropriate mechanism within the semantics of SUBS/NOTIF for presence information filtering.
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) 
Sent: 09. November 2002 1:50
To: ext Peterson, Jon; Isomaki Markus (NRC/Helsinki);
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; Pessi Pekka
(NRC/Helsinki); Costa-Requena Jose (NMP/Helsinki)
Subject: RE: [Sipping] RE: [Simple] Multimedia message
adaptationInternet-Drafts

Hi,

	

 

Stephane

-----Original Message-----
From: ext Peterson, Jon [mailto:[email-masked]]
Sent: Friday, November 08, 2002 6:58 AM
To: Isomaki Markus (NRC/Helsinki); [email-masked];

Jon Peterson
NeuStar, Inc.

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 12 Nov 2002 09:49:15 -0500

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: [email-masked] 
[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) 
> of a corner case). 
> 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.
> 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
>

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 14 Nov 2002 09:17:40 -0500

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:[email-masked]] 
	Sent: Wed 11/13/2002 9:00 PM 
	To: [email-masked] 
	Cc: [email-masked]; Eric Burger; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; 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
	[email-masked].
	
	thanks,
	-rohan
	
	On Wednesday, November 13, 2002, at 07:35 AM,
	[email-masked] 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
	>
	> From: Srinivas Bindignavile (NRC/Boston)
	> 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
	>
	>> From: ext Eric Burger [mailto:[email-masked]]
	>> 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.
	>>

---

From: "Abbie Barbir" <[email-masked]>
Date: Thu, 14 Nov 2002 09:46:34 -0500

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

> From: Eric Burger [mailto:[email-masked]] 
> Sent: Thursday, November 14, 2002 9:18 AM
> Cc: [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; UM 
> list; [email-masked]
> 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.
> 
> 	Cc: [email-masked]; Eric Burger; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; UM list 
> 	>>> 2)administered by intermediaries: this is discussed 
> in detail
> 	>>> in one of the drafts.
> 	>>>
> 	>>> Yes, applicability and impact is larger than IM and 
> presence.
> 	>>> It applies to many other
> 	>>> 3) It is easier to explain the problem and propose 
> a solution
> 	>>> with a smaller well-defined problem.
> 	>>>
> 	> This 
> list is for NEW development of the application of SIP
> 	This 
> list is for NEW development of the application of SIP

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Sun, 17 Nov 2002 19:51:29 -0000

SIPPING is in the transport area because SIP is.

SIP is in the transport area because MMUSIC is.

I assume that the transport area allocation was made because of the http like origin of SIP. It would be hard to argue that SIP acts like http today, or indeed is used like http.

I have heard several people who matter argue that if SIP was allocated to an area today it would be in the application area, and certainly much of the aspects of the work are application layer issues, not transport ones.

I therefore see no reason to argue that application level material cannot be discussed in either SIP or SIPPING.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> Sent: 14 November 2002 14:18
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; UM list; [email-masked]