From owner-ietf-openproxy@mail.imc.org Fri Nov 1 01:06:45 2002 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29432 for ; Fri, 1 Nov 2002 01:06:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA15YVf06232 for ietf-openproxy-bks; Thu, 31 Oct 2002 21:34:31 -0800 (PST) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA15YUW06225 for ; Thu, 31 Oct 2002 21:34:30 -0800 (PST) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout03.icomcast.net (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) with ESMTP id <0H4V006DIU57JW@mtaout03.icomcast.net> for ietf-openproxy@imc.org; Fri, 01 Nov 2002 00:34:20 -0500 (EST) Date: Fri, 01 Nov 2002 00:34:21 -0500 From: Markus Hofmann Subject: Agenda requests for Atlanta To: OPES Group Message-id: <3DC2125D.7070603@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Hi, as you might have seen, we're currently scheduled in Atlanta for Monday, 11/18, 13:00 - 15:00. We want to spend some time to address open issues with the currently (five) active WG drafts, and then start discussion on the next work items, namely the OPES protocol (main focus) and the methods for specification of policies/rules. For the discussion on protocol and policies/rules specification, we're now taking agenda/speaker requests. Please submit to Marshall and myself. -Markus ========================================================================= *TENTATIVE* AGENDA: - Introduction, minutes taker, blue sheets - Agenda bashing - Discussion of WG documents - Status of documents submitted to IESG - draft-ietf-opes-scenarios-00.txt - draft-ietf-opes-architecture-02.txt - draft-ietf-opes-protocol-reqs-01.txt - Security Threats and Risks for Open Pluggable Edge Services - draft-ietf-opes-threats-00.txt - Requirements for Policy, Authorization and Enforcement of OPES Services - draft-ietf-opes-authorization-00.txt - Summary and wrap up of the ICAP discussion to accompany possible informational publication of that protocol - draft-elson-icap-01.txt - draft-stecher-opes-icap-eval-00.txt - Next WG items to be worked on (main focus of the meeting!) - OPES protocol - Methods for spefification of rules/policies From owner-ietf-openproxy@mail.imc.org Wed Nov 6 00:32:04 2002 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11627 for ; Wed, 6 Nov 2002 00:32:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA654jv07912 for ietf-openproxy-bks; Tue, 5 Nov 2002 21:04:45 -0800 (PST) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA654iv07908 for ; Tue, 5 Nov 2002 21:04:44 -0800 (PST) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout05.icomcast.net (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) with ESMTP id <0H5500DCV2374L@mtaout05.icomcast.net> for ietf-openproxy@imc.org; Wed, 06 Nov 2002 00:04:19 -0500 (EST) Date: Wed, 06 Nov 2002 00:04:37 -0500 From: Markus Hofmann Subject: Re: Agenda requests for Atlanta In-reply-to: <3DC2125D.7070603@mhof.com> To: OPES Group Message-id: <3DC8A2E5.7060507@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 References: <3DC2125D.7070603@mhof.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Folks, so far, we only have *one* speaker each on the protocol issue and the policy/rules specification method. If there are no more folks with an opinion on these core items of our charter, I'm very concerned about the WG!! It's hard to imagine that no one else has some good thoughts on these issues. No one thought about maybe claiming HTTP is the solution to all protocol issues? Or stating that the current ICAP is all we need? Or the opposite - showing what ICAP is missing? Or maybe someone has thought of doing something over BEEP in this context? Or any other protocol? What about SOAP/XML, i.e. Web Services? We heard in the past this might solve all problems we have? Somebody any thoughts on that? If so, please get in touch with Marshall and myself so that we can set-up an appropriate agenda for Atlanta. If there's no interest at all, we can wrap up things very quickly... Thanks, Markus Markus Hofmann wrote: > > Hi, > > as you might have seen, we're currently scheduled in Atlanta for > Monday, > 11/18, 13:00 - 15:00. > > We want to spend some time to address open issues with the currently > (five) active WG drafts, and then start discussion on the next work > items, namely the OPES protocol (main focus) and the methods for > specification of policies/rules. > > For the discussion on protocol and policies/rules specification, we're > now taking agenda/speaker requests. Please submit to Marshall and > myself. > > -Markus > > ========================================================================= > *TENTATIVE* AGENDA: > - Introduction, minutes taker, blue sheets > - Agenda bashing > - Discussion of WG documents > - Status of documents submitted to IESG > - draft-ietf-opes-scenarios-00.txt > - draft-ietf-opes-architecture-02.txt > - draft-ietf-opes-protocol-reqs-01.txt > - Security Threats and Risks for Open Pluggable Edge Services > - draft-ietf-opes-threats-00.txt > - Requirements for Policy, Authorization and Enforcement of OPES > Services > - draft-ietf-opes-authorization-00.txt > - Summary and wrap up of the ICAP discussion to accompany possible > informational publication of that protocol > - draft-elson-icap-01.txt > - draft-stecher-opes-icap-eval-00.txt > - Next WG items to be worked on (main focus of the meeting!) > - OPES protocol > - Methods for spefification of rules/policies > > From owner-ietf-openproxy@mail.imc.org Wed Nov 6 13:16:32 2002 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05125 for ; Wed, 6 Nov 2002 13:16:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6HZek20318 for ietf-openproxy-bks; Wed, 6 Nov 2002 09:35:40 -0800 (PST) Received: from host070.webwasher.com ([217.146.159.51]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA6HZav20314 for ; Wed, 6 Nov 2002 09:35:39 -0800 (PST) Received: from hermes.webwasher.com [192.168.1.3] id GSGNVJ65; 06 Nov 2002 18:50:37 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C285BA.95B04084" Subject: LateClearance content encoding X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 6 Nov 2002 18:33:14 +0100 Message-ID: <72992B39BBD9294BB636A960E89AE02E8FCDCF@hermes.webwasher.com> Thread-Topic: LateClearance content encoding Thread-Index: AcKFuthA0gNMt5A7RvKp49OZBudyOw== From: "Martin Stecher" To: "OPES WG (E-Mail)" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C285BA.95B04084 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, in a prominent OPES scenario a virus filter is deployed as an OPES = service of an intermediate proxy. That filter belongs to the group of services that wants to see all data = of a file completly before it starts to respond. In HTTP this huge = latency effect results in an inacceptable surfing experience for the end = user when requesting large files; there is no feedback, no progress = dialog until the complete files has been received by the filter service. Today only workarounds are known to this problem that all have a bunch = of disadvantages. I created a draft about a new content encoding for HTTP which could = solve this problem for the majority of file types: http://www.ietf.org/internet-drafts/draft-stecher-lclr-encoding-00.txt It also explains the problem in more detail. I would appreciate very much if this group is interested in looking into = this and in starting a discussion about this problem and possible = solutions. Regards Martin ------_=_NextPart_001_01C285BA.95B04084 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LateClearance content encoding

Hi,

in a prominent OPES scenario a virus = filter is deployed as an OPES service of an intermediate proxy.
That filter belongs to the group of = services that wants to see all data of a file completly before it starts = to respond. In HTTP this huge latency effect results in an inacceptable = surfing experience for the end user when requesting large files; there = is no feedback, no progress dialog until the complete files has been = received by the filter service.

Today only workarounds are known to = this problem that all have a bunch of disadvantages.

I created a draft about a new content = encoding for HTTP which could solve this problem for the majority of = file types:
http://www.ietf.org/internet-drafts/draft-stecher-lclr-encoding-00= .txt
It also explains the problem in more = detail.

I would appreciate very much if this = group is interested in looking into this and in starting a discussion = about this problem and possible solutions.

Regards
Martin

------_=_NextPart_001_01C285BA.95B04084-- From owner-ietf-openproxy@mail.imc.org Wed Nov 6 14:45:10 2002 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09027 for ; Wed, 6 Nov 2002 14:45:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6JN5026691 for ietf-openproxy-bks; Wed, 6 Nov 2002 11:23:05 -0800 (PST) Received: from linux.royaleng.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA6JN3v26681 for ; Wed, 6 Nov 2002 11:23:03 -0800 (PST) Received: from localhost.localdomain ([192.168.6.22]) by linux.royaleng.com (8.11.2/8.11.2) with ESMTP id gA6JOv613095; Wed, 6 Nov 2002 12:24:57 -0700 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id gA6JKtC08216; Wed, 6 Nov 2002 12:20:55 -0700 Date: Wed, 6 Nov 2002 12:20:55 -0700 Message-Id: <200211061920.gA6JKtC08216@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: martin.stecher@webwasher.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <72992B39BBD9294BB636A960E89AE02E8FCDCF@hermes.webwasher.com> Subject: Re: LateClearance content encoding Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It's a nice solution, but it's important to know what the problem is. I'm unclear about why the data must be encrypted. The only point is to keep the enduser from using the data, so it would seem sufficient to just have the late clearance flag alone - let the client decide how it wants to handle data while it is in the uncleared state. Why is this insufficient? Hilarie From owner-ietf-openproxy@mail.imc.org Thu Nov 7 04:35:42 2002 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08244 for ; Thu, 7 Nov 2002 04:35:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA791Vk24614 for ietf-openproxy-bks; Thu, 7 Nov 2002 01:01:31 -0800 (PST) Received: from host070.webwasher.com ([217.146.159.51]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA791Rv24591 for ; Thu, 7 Nov 2002 01:01:28 -0800 (PST) Received: from hermes.webwasher.com [192.168.1.3] id B9ST6DT2; 07 Nov 2002 10:16:30 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: LateClearance content encoding X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 7 Nov 2002 09:59:02 +0100 Message-ID: <72992B39BBD9294BB636A960E89AE02E50C01F@hermes.webwasher.com> Thread-Topic: LateClearance content encoding Thread-Index: AcKFyZ3pKHykQ8UFTMCw+qjuO8R1GwAcObyw From: "Martin Stecher" To: Cc: "The Purple Streak, Hilarie Orman" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gA791Uv24608 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit It is all arround a possible virus that could be transfered. We could say that a client that supports this content encoding will delete and not execute the data if it does not receive the clearance but the error message even if the data itself is not encrypted. But I am concerned that this is not sufficient and too dangerous. The client may write the data to a file and cannot guarantee for other parts of the operating system not to access that data before it gets a chance to delete it again. It will it also make easier for an attacker to use vulnerabilities in the client's implementation to access the data which should not ne used. For example the attacker could just be able to add the Accept header to the request, and the data is then transfered, the client does its job and is not aware of the "do not use the data" flag. Maybe there are some other scenarios where the flag itself is sufficient so that encryption could be optional? Martin > -----Original Message----- > From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu] > Sent: Wednesday, November 06, 2002 8:21 PM > To: Martin Stecher > Cc: ietf-openproxy@imc.org > Subject: Re: LateClearance content encoding > > > It's a nice solution, but it's important to know what the problem is. > > I'm unclear about why the data must be encrypted. The only > point is to > keep the enduser from using the data, so it would seem sufficient to > just have the late clearance flag alone - let the client decide how it > wants to handle data while it is in the uncleared state. Why is this > insufficient? > > Hilarie > > From owner-ietf-openproxy@mail.imc.org Thu Nov 7 15:45:00 2002 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11414 for ; Thu, 7 Nov 2002 15:44:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7KNKA22798 for ietf-openproxy-bks; Thu, 7 Nov 2002 12:23:20 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA7KEcv22109; Thu, 7 Nov 2002 12:14:38 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: All IETF Working Groups: ; Subject: Note Well Statement x-msg: NoteWell Date: Thu, 07 Nov 2002 15:11:40 -0500 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From owner-ietf-openproxy@mail.imc.org Tue Nov 12 10:18:59 2002 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02460 for ; Tue, 12 Nov 2002 10:18:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gACEnVU24922 for ietf-openproxy-bks; Tue, 12 Nov 2002 06:49:31 -0800 (PST) Received: from snowshore.com (keeper.snowshore.com [216.57.133.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gACEnKg24916 for ; Tue, 12 Nov 2002 06:49:20 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Date: Tue, 12 Nov 2002 09:49:15 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D55A7@zoe.office.snowshore.com> Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Thread-Index: AcKHa5CNEMtfRz3cQRuNgd/C/YnuKwADld2AACYMJkAAi+Nw0A== From: "Eric Burger" To: , , , , , , , Cc: , , , "IETF OPES (E-mail)" , "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gACEnLg24917 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit 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@nokia.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.peterson@neustar.biz] > Sent: Friday, November 08, 2002 6:58 AM > To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com; > drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > Sent: Friday, November 08, 2002 3:47 AM > > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; > > Gonzalo.Camarillo@lmf.ericsson.se > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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.willis@softarmor.com] > > > Sent: 08 November, 2002 5:11 > > > To: Drage, Keith (Keith) > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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@lucent.com > > > > > > > > > -----Original Message----- > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > > Sent: 06 November 2002 18:24 > > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.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 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@mailman.dynamicsoft.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@cs.columbia.edu for questions on > current sip > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > _______________________________________________ > > > simple mailing list > > > simple@mailman.dynamicsoft.com > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.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@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.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@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > From owner-ietf-openproxy@mail.imc.org Wed Nov 13 02:19:07 2002 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13567 for ; Wed, 13 Nov 2002 02:19:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAD6Qot17469 for ietf-openproxy-bks; Tue, 12 Nov 2002 22:26:50 -0800 (PST) Received: from s31xu4.systems.smu.edu (s31xu4.systems.smu.edu [129.119.70.133]) by above.proper.com (8.11.6/8.11.3) with SMTP id gAD6QUg17394 for ; Tue, 12 Nov 2002 22:26:33 -0800 (PST) Received: from s31xu9b.systems.smu.edu ([129.119.70.81]) by s31xu4.systems.smu.edu with Microsoft SMTPSVC(5.0.2195.4905); Wed, 13 Nov 2002 00:26:22 -0600 Received: from mail pickup service by s31xu9b.systems.smu.edu with Microsoft SMTPSVC; Wed, 13 Nov 2002 00:26:22 -0600 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by s31xu9b.systems.smu.edu with Microsoft SMTPSVC(5.0.2195.5329); Tue, 12 Nov 2002 09:02:16 -0600 Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gACF025r005411; Tue, 12 Nov 2002 10:00:02 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05428; Tue, 12 Nov 2002 10:01:03 -0500 (EST) Received: from snowshore.com (keeper.snowshore.com [216.57.133.4]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05375 for ; Tue, 12 Nov 2002 09:49:15 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Message-ID: <4A3384433CE2AB46A63468CB207E209D55A7@zoe.office.snowshore.com> Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Thread-Index: AcKHa5CNEMtfRz3cQRuNgd/C/YnuKwADld2AACYMJkAAi+Nw0A== From: "Eric Burger" To: , , , , , , , Cc: , , , "IETF OPES (E-mail)" , "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA05375 X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 12 Nov 2002 09:49:15 -0500 X-OriginalArrivalTime: 12 Nov 2002 15:02:16.0378 (UTC) FILETIME=[7D4F79A0:01C28A5C] Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit 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@nokia.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.peterson@neustar.biz] > Sent: Friday, November 08, 2002 6:58 AM > To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com; > drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > Sent: Friday, November 08, 2002 3:47 AM > > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; > > Gonzalo.Camarillo@lmf.ericsson.se > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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.willis@softarmor.com] > > > Sent: 08 November, 2002 5:11 > > > To: Drage, Keith (Keith) > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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@lucent.com > > > > > > > > > -----Original Message----- > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > > Sent: 06 November 2002 18:24 > > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.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 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@mailman.dynamicsoft.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@cs.columbia.edu for questions on > current sip > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > _______________________________________________ > > > simple mailing list > > > simple@mailman.dynamicsoft.com > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.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@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.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@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From owner-ietf-openproxy@mail.imc.org Wed Nov 13 11:04:59 2002 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06154 for ; Wed, 13 Nov 2002 11:04:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADFO3G16011 for ietf-openproxy-bks; Wed, 13 Nov 2002 07:24:03 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADFNtg15998 for ; Wed, 13 Nov 2002 07:23:55 -0800 (PST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gADFObx26264 for ; Wed, 13 Nov 2002 09:24:38 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Nov 2002 09:23:53 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 13 Nov 2002 07:23:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Date: Wed, 13 Nov 2002 10:23:51 -0500 Message-ID: Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Thread-Index: AcKHa5CNEMtfRz3cQRuNgd/C/YnuKwADld2AACYMJkAAi+Nw0AA5bELA From: To: , , , , , , , , Cc: , , , , X-OriginalArrivalTime: 13 Nov 2002 15:23:53.0225 (UTC) FILETIME=[ACB45F90:01C28B28] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gADFNtg15999 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit 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@snowshore.com] > Sent: Tuesday, November 12, 2002 9:49 AM > To: Costa-Requena Jose (NMP/Helsinki); Coulombe Stephane (NRC/Dallas); > jon.peterson@neustar.biz; Isomaki Markus (NRC/Helsinki); > dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; > Gonzalo.Camarillo@lmf.ericsson.se > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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.Costa-Requena@nokia.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.peterson@neustar.biz] > > Sent: Friday, November 08, 2002 6:58 AM > > To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com; > > drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > > Sent: Friday, November 08, 2002 3:47 AM > > > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; > > > Gonzalo.Camarillo@lmf.ericsson.se > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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.willis@softarmor.com] > > > > Sent: 08 November, 2002 5:11 > > > > To: Drage, Keith (Keith) > > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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@lucent.com > > > > > > > > > > > -----Original Message----- > > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > > > Sent: 06 November 2002 18:24 > > > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.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 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@mailman.dynamicsoft.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@cs.columbia.edu for questions on > > current sip > > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > > > _______________________________________________ > > > > simple mailing list > > > > simple@mailman.dynamicsoft.com > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > _______________________________________________ > > > simple mailing list > > > simple@mailman.dynamicsoft.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@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.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@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From owner-ietf-openproxy@mail.imc.org Wed Nov 13 11:53:32 2002 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08131 for ; Wed, 13 Nov 2002 11:53:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADGGQU19025 for ietf-openproxy-bks; Wed, 13 Nov 2002 08:16:26 -0800 (PST) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADGGKg19010 for ; Wed, 13 Nov 2002 08:16:21 -0800 (PST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gADGFF019940; Wed, 13 Nov 2002 11:15:15 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Nov 2002 11:15:16 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD7540420D561@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: bindignavile.srinivas@nokia.com, eburger@snowshore.com, Jose.Costa-Requena@nokia.com, Stephane.Coulombe@nokia.com, jon.peterson@neustar.biz, Markus.Isomaki@nokia.com, dean.willis@softarmor.com, drage@lucent.com, rohan@cisco.com, Gonzalo.Camarillo@lmf.ericsson.se Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com, Pekka.Pessi@nokia.com, ietf-openproxy@imc.org, um@snowshore.com Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet- Drafts Date: Wed, 13 Nov 2002 11:15:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28B2F.D67BD55E" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C28B2F.D67BD55E Content-Type: text/plain Hi, The current work focuses on HTTP as the default protocol for OPES services. thanks abbie > -----Original Message----- > From: bindignavile.srinivas@nokia.com > [mailto:bindignavile.srinivas@nokia.com] > Sent: Wednesday, November 13, 2002 10:24 AM > To: eburger@snowshore.com; Jose.Costa-Requena@nokia.com; > Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz; > Markus.Isomaki@nokia.com; dean.willis@softarmor.com; > drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com; > Pekka.Pessi@nokia.com; ietf-openproxy@imc.org; um@snowshore.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@snowshore.com] > > Sent: Tuesday, November 12, 2002 9:49 AM > > To: Costa-Requena Jose (NMP/Helsinki); Coulombe Stephane > (NRC/Dallas); > > jon.peterson@neustar.biz; Isomaki Markus (NRC/Helsinki); > > dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; > > Gonzalo.Camarillo@lmf.ericsson.se > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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.Costa-Requena@nokia.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.peterson@neustar.biz] > > > Sent: Friday, November 08, 2002 6:58 AM > > > To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com; > > > drage@lucent.com; rohan@cisco.com; > Gonzalo.Camarillo@lmf.ericsson.se > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > > > Sent: Friday, November 08, 2002 3:47 AM > > > > To: dean.willis@softarmor.com; drage@lucent.com; > rohan@cisco.com; > > > > Gonzalo.Camarillo@lmf.ericsson.se > > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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.willis@softarmor.com] > > > > > Sent: 08 November, 2002 5:11 > > > > > To: Drage, Keith (Keith) > > > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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@lucent.com > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > > > > Sent: 06 November 2002 18:24 > > > > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.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 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@mailman.dynamicsoft.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@cs.columbia.edu for questions on > > > current sip > > > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > > > > > > _______________________________________________ > > > > > simple mailing list > > > > > simple@mailman.dynamicsoft.com > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > > > _______________________________________________ > > > > simple mailing list > > > > simple@mailman.dynamicsoft.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@cs.columbia.edu for questions on current sip Use > > > sip@ietf.org for new developments of core SIP > > > _______________________________________________ > > > simple mailing list > > > simple@mailman.dynamicsoft.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@cs.columbia.edu for questions on current sip Use > > > sip@ietf.org for new developments of core SIP > > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > ------_=_NextPart_001_01C28B2F.D67BD55E Content-Type: text/html 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.srinivas@nokia.com
> [mailto:bindignavile.srinivas@nokia.com]
> Sent: Wednesday, November 13, 2002 10:24 AM
> To: eburger@snowshore.com; Jose.Costa-Requena@nokia.com;
> Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz;
> Markus.Isomaki@nokia.com; dean.willis@softarmor.com;
> drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se
> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com;
> Pekka.Pessi@nokia.com; ietf-openproxy@imc.org; um@snowshore.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@snowshore.com]
> > Sent: Tuesday, November 12, 2002 9:49 AM
> > To: Costa-Requena Jose (NMP/Helsinki); Coulombe Stephane
> (NRC/Dallas);
> > jon.peterson@neustar.biz; Isomaki Markus (NRC/Helsinki);
> > dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com;
> > Gonzalo.Camarillo@lmf.ericsson.se
> > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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.Costa-Requena@nokia.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.peterson@neustar.biz]
> > > Sent: Friday, November 08, 2002 6:58 AM
> > > To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com;
> > > drage@lucent.com; rohan@cisco.com;
> Gonzalo.Camarillo@lmf.ericsson.se
> > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
> > > > Sent: Friday, November 08, 2002 3:47 AM
> > > > To: dean.willis@softarmor.com; drage@lucent.com;
> rohan@cisco.com;
> > > > Gonzalo.Camarillo@lmf.ericsson.se
> > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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.willis@softarmor.com]
> > > > > Sent: 08 November, 2002 5:11
> > > > > To: Drage, Keith (Keith)
> > > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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@lucent.com
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> > > > > > > Sent: 06 November 2002 18:24
> > > > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.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.Pessi@nokia.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@mailman.dynamicsoft.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@cs.columbia.edu for questions on
> > > current sip
> > > > > > Use sip@ietf.org for new developments of core SIP
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > simple mailing list
> > > > > simple@mailman.dynamicsoft.com
> > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > >
> > > > _______________________________________________
> > > > simple mailing list
> > > > simple@mailman.dynamicsoft.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@cs.columbia.edu for questions on current sip Use
> > > sip@ietf.org for new developments of core SIP
> > > _______________________________________________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.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@cs.columbia.edu for questions on current sip Use
> > > sip@ietf.org for new developments of core SIP
> > >
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> >
>

------_=_NextPart_001_01C28B2F.D67BD55E-- From owner-ietf-openproxy@mail.imc.org Thu Nov 14 09:58:51 2002 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20972 for ; Thu, 14 Nov 2002 09:58:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAEEHlr07247 for ietf-openproxy-bks; Thu, 14 Nov 2002 06:17:47 -0800 (PST) Received: from snowshore.com (keeper.snowshore.com [216.57.133.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAEEHfg07242 for ; Thu, 14 Nov 2002 06:17:41 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: [Sipping] Multimedia message adaptationInternet-Drafts Date: Thu, 14 Nov 2002 09:17:40 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D097B6C@zoe.office.snowshore.com> Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Thread-Index: AcKL2DsO6cWYXZciS8qGVAN+WtLnQQADoget From: "Eric Burger" To: Cc: , , , , , , , , , , , "UM list" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id gAEEHgg07243 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit 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@cisco.com] Sent: Wed 11/13/2002 9:00 PM To: Jose.Costa-Requena@nokia.com Cc: bindignavile.srinivas@nokia.com; Eric Burger; Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz; Markus.Isomaki@nokia.com; dean.willis@softarmor.com; drage@lucent.com; Gonzalo.Camarillo@lmf.ericsson.se; sipping@ietf.org; Pekka.Pessi@nokia.com; simple@mailman.dynamicsoft.com; ietf-openproxy@imc.org; 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@ietf.org. thanks, -rohan On Wednesday, November 13, 2002, at 07:35 AM, Jose.Costa-Requena@nokia.com 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@snowshore.com] >> 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@nokia.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.peterson@neustar.biz] >>> Sent: Friday, November 08, 2002 6:58 AM >>> To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com; >>> drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se >>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >>>> Sent: Friday, November 08, 2002 3:47 AM >>>> To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; >>>> Gonzalo.Camarillo@lmf.ericsson.se >>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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.willis@softarmor.com] >>>>> Sent: 08 November, 2002 5:11 >>>>> To: Drage, Keith (Keith) >>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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@lucent.com >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] >>>>>>> Sent: 06 November 2002 18:24 >>>>>>> To: sipping@ietf.org; simple@mailman.dynamicsoft.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 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@mailman.dynamicsoft.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@cs.columbia.edu for questions on >>> current sip >>>>>> Use sip@ietf.org for new developments of core SIP >>>>>> >>>>> >>>>> _______________________________________________ >>>>> simple mailing list >>>>> simple@mailman.dynamicsoft.com >>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple >>>>> >>>> _______________________________________________ >>>> simple mailing list >>>> simple@mailman.dynamicsoft.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@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP >>> _______________________________________________ >>> simple mailing list >>> simple@mailman.dynamicsoft.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@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP >>> >> _______________________________________________ >> simple mailing list >> simple@mailman.dynamicsoft.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@cs.columbia.edu for questions on current sip > Use sip@ietf.org 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@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From owner-ietf-openproxy@mail.imc.org Thu Nov 14 10:30:32 2002 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21714 for ; Thu, 14 Nov 2002 10:30:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAEElgY09121 for ietf-openproxy-bks; Thu, 14 Nov 2002 06:47:42 -0800 (PST) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAEElIg09097 for ; Thu, 14 Nov 2002 06:47:22 -0800 (PST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAEEkbZ11534; Thu, 14 Nov 2002 09:46:37 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Nov 2002 09:46:37 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD7540425FFB9@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Eric Burger , Jose.Costa-Requena@nokia.com Cc: bindignavile.srinivas@nokia.com, Stephane.Coulombe@nokia.com, jon.peterson@neustar.biz, Markus.Isomaki@nokia.com, dean.willis@softarmor.com, drage@lucent.com, Gonzalo.Camarillo@lmf.ericsson.se, sipping@ietf.org, Pekka.Pessi@nokia.com, simple@mailman.dynamicsoft.com, ietf-openproxy@imc.org, UM list , um@snowshore.com Subject: RE: [Sipping] Multimedia message adaptationInternet-Drafts Date: Thu, 14 Nov 2002 09:46:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28BEC.A0ADAA16" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C28BEC.A0ADAA16 Content-Type: text/plain 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@snowshore.com] > Sent: Thursday, November 14, 2002 9:18 AM > To: Jose.Costa-Requena@nokia.com > Cc: bindignavile.srinivas@nokia.com; > Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz; > Markus.Isomaki@nokia.com; dean.willis@softarmor.com; > drage@lucent.com; Gonzalo.Camarillo@lmf.ericsson.se; > sipping@ietf.org; Pekka.Pessi@nokia.com; > simple@mailman.dynamicsoft.com; ietf-openproxy@imc.org; UM > list; um@snowshore.com > 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@cisco.com] > Sent: Wed 11/13/2002 9:00 PM > To: Jose.Costa-Requena@nokia.com > Cc: bindignavile.srinivas@nokia.com; Eric Burger; > Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz; > Markus.Isomaki@nokia.com; dean.willis@softarmor.com; > drage@lucent.com; Gonzalo.Camarillo@lmf.ericsson.se; > sipping@ietf.org; Pekka.Pessi@nokia.com; > simple@mailman.dynamicsoft.com; ietf-openproxy@imc.org; 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@ietf.org. > > thanks, > -rohan > > On Wednesday, November 13, 2002, at 07:35 AM, > Jose.Costa-Requena@nokia.com 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@snowshore.com] > >> 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@nokia.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.peterson@neustar.biz] > >>> Sent: Friday, November 08, 2002 6:58 AM > >>> To: Isomaki Markus (NRC/Helsinki); > dean.willis@softarmor.com; > >>> drage@lucent.com; rohan@cisco.com; > Gonzalo.Camarillo@lmf.ericsson.se > >>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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.Isomaki@nokia.com > [mailto:Markus.Isomaki@nokia.com] > >>>> Sent: Friday, November 08, 2002 3:47 AM > >>>> To: dean.willis@softarmor.com; drage@lucent.com; > rohan@cisco.com; > >>>> Gonzalo.Camarillo@lmf.ericsson.se > >>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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.willis@softarmor.com] > >>>>> Sent: 08 November, 2002 5:11 > >>>>> To: Drage, Keith (Keith) > >>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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@lucent.com > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > >>>>>>> Sent: 06 November 2002 18:24 > >>>>>>> To: sipping@ietf.org; simple@mailman.dynamicsoft.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 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@mailman.dynamicsoft.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@cs.columbia.edu for questions on > >>> current sip > >>>>>> Use sip@ietf.org for new developments of core SIP > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> simple mailing list > >>>>> simple@mailman.dynamicsoft.com > >>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple > >>>>> > >>>> _______________________________________________ > >>>> simple mailing list > >>>> simple@mailman.dynamicsoft.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@cs.columbia.edu for questions > on current sip > >>> Use sip@ietf.org for new developments of core SIP > >>> _______________________________________________ > >>> simple mailing list > >>> simple@mailman.dynamicsoft.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@cs.columbia.edu for questions > on current sip > >>> Use sip@ietf.org for new developments of core SIP > >>> > >> _______________________________________________ > >> simple mailing list > >> simple@mailman.dynamicsoft.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@cs.columbia.edu for questions on > current sip > > Use sip@ietf.org 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@cs.columbia.edu for questions on > current sip > Use sip@ietf.org for new developments of core SIP > > > ------_=_NextPart_001_01C28BEC.A0ADAA16 Content-Type: text/html RE: [Sipping] Multimedia message adaptationInternet-Drafts

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@snowshore.com]
> Sent: Thursday, November 14, 2002 9:18 AM
> To: Jose.Costa-Requena@nokia.com
> Cc: bindignavile.srinivas@nokia.com;
> Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz;
> Markus.Isomaki@nokia.com; dean.willis@softarmor.com;
> drage@lucent.com; Gonzalo.Camarillo@lmf.ericsson.se;
> sipping@ietf.org; Pekka.Pessi@nokia.com;
> simple@mailman.dynamicsoft.com; ietf-openproxy@imc.org; UM
> list; um@snowshore.com
> 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@cisco.com]
>       Sent: Wed 11/13/2002 9:00 PM
>       To: Jose.Costa-Requena@nokia.com
>       Cc: bindignavile.srinivas@nokia.com; Eric Burger;
> Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz;
> Markus.Isomaki@nokia.com; dean.willis@softarmor.com;
> drage@lucent.com; Gonzalo.Camarillo@lmf.ericsson.se;
> sipping@ietf.org; Pekka.Pessi@nokia.com;
> simple@mailman.dynamicsoft.com; ietf-openproxy@imc.org; 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@ietf.org.
>      
>       thanks,
>       -rohan
>      
>       On Wednesday, November 13, 2002, at 07:35 AM,
>       Jose.Costa-Requena@nokia.com 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@snowshore.com]
>       >> 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@nokia.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.peterson@neustar.biz]
>       >>> Sent: Friday, November 08, 2002 6:58 AM
>       >>> To: Isomaki Markus (NRC/Helsinki);
> dean.willis@softarmor.com;
>       >>> drage@lucent.com; rohan@cisco.com;
> Gonzalo.Camarillo@lmf.ericsson.se
>       >>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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.Isomaki@nokia.com
> [mailto:Markus.Isomaki@nokia.com]
>       >>>> Sent: Friday, November 08, 2002 3:47 AM
>       >>>> To: dean.willis@softarmor.com; drage@lucent.com;
> rohan@cisco.com;
>       >>>> Gonzalo.Camarillo@lmf.ericsson.se
>       >>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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.willis@softarmor.com]
>       >>>>> Sent: 08 November, 2002 5:11
>       >>>>> To: Drage, Keith (Keith)
>       >>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.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@lucent.com
>       >>>>>>
>       >>>>>>> -----Original Message-----
>       >>>>>>> From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
>       >>>>>>> Sent: 06 November 2002 18:24
>       >>>>>>> To: sipping@ietf.org; simple@mailman.dynamicsoft.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.Pessi@nokia.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@mailman.dynamicsoft.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@cs.columbia.edu for questions on
>       >>> current sip
>       >>>>>> Use sip@ietf.org for new developments of core SIP
>       >>>>>>
>       >>>>>
>       >>>>> _______________________________________________
>       >>>>> simple mailing list
>       >>>>> simple@mailman.dynamicsoft.com
>       >>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>       >>>>>
>       >>>> _______________________________________________
>       >>>> simple mailing list
>       >>>> simple@mailman.dynamicsoft.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@cs.columbia.edu for questions
> on current sip
>       >>> Use sip@ietf.org for new developments of core SIP
>       >>> _______________________________________________
>       >>> simple mailing list
>       >>> simple@mailman.dynamicsoft.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@cs.columbia.edu for questions
> on current sip
>       >>> Use sip@ietf.org for new developments of core SIP
>       >>>
>       >> _______________________________________________
>       >> simple mailing list
>       >> simple@mailman.dynamicsoft.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@cs.columbia.edu for questions on
> current sip
>       > Use sip@ietf.org 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@cs.columbia.edu for questions on
> current sip
>       Use sip@ietf.org for new developments of core SIP
>      
>
>

------_=_NextPart_001_01C28BEC.A0ADAA16-- From owner-ietf-openproxy@mail.imc.org Sat Nov 16 02:30:24 2002 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12342 for ; Sat, 16 Nov 2002 02:30:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAG6jwF17575 for ietf-openproxy-bks; Fri, 15 Nov 2002 22:45:58 -0800 (PST) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAG6jog17570 for ; Fri, 15 Nov 2002 22:45:51 -0800 (PST) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout04.icomcast.net (iPlanet Messaging Server 5.1 HotFix 1.5 (built Sep 23 2002)) with ESMTP id <0H5N0058VPGCGM@mtaout04.icomcast.net> for ietf-openproxy@imc.org; Sat, 16 Nov 2002 01:45:49 -0500 (EST) Date: Sat, 16 Nov 2002 01:45:48 -0500 From: Markus Hofmann Subject: OPES document status To: OPES Group Message-id: <3DD5E99C.6020703@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT Hi, quick update on the current OPES document status. In August, we submitted three WG drafts on Architecture (draft-ietf-opes-architecture-03) Protocol Requirements (draft-ietf-opes-protocol-reqs-02) Scenarios (draft-ietf-opes-scenarios-01) to the IESG for consideration as informal RFCs. We've received feedback from the IESG discussion on all three documents, and we had an initial call of the author teams to discuss how we should address the issues. Thanks to Allison, who joined this call and explained/helped understanding the various issues. Below an attempt to summarize the IESG feedback and how we envision to incorprate it into all three drafts. (Thanks to Andre for the nice summary! Hope we didn't miss anything). The authors are currently working on updated draft versions, which we'll re-submit to the IESG after our discussion in Atlanta and on the mailing list. We want to do this shortly after the Atlanta meeting - so please read the comments carefully, participate in the upcoming meeting, and send your thoughts and comments to the mailing list. We also have initial versions of our documents on Enforcement/Authorization (draft-ietf-opes-authorization-00) Threats/Risk (draft-ietf-opes-threats-00) published. We'll discuss those in Atlanta with the goal of wrapping them up and submitting to IESG shortly. So, please also read those two drafts very carefully and provide feedback in the meeting and on the mailing list. Thanks, Markus ================= Summary of IESG Feedback =========================== Feedback: It was suggested that tracing/audit/authorization and other requirements from RFC 3238 were not properly addressed in the drafts. Solution: - We will list and address all OPES considerations in a separate section in the architecture document. - Solutions to some of these requirements might be beyond the group's current charter, in which case this will be spelled out explicitely. - WG will explain in the architecture and possibly other drafts what is needed to accomplish tracing/audit/ authorization. Feedback: It was suggested to remove all references to callout server chaining due to concerns over transitive trust issues. Solution: - We will revise drafts accordingly without ruling out callout server chaining performed within a single trusted domain (e.g. within an ISP’s data center) Feedback: Concern was expressed about the way the drafts address privacy issues. Solution: - We will add more details to discussion of privacy in architecture draft. - WG will add references to existing privacy solutions that could be applied to OPES (e.g. W3C P3P). Feedback: It was asked that protocol requirements draft clearly states that for transport issues such as congestion avoidance, ordered/unordered, reliability etc., OPES should rely on existing solutions on the transport layer, rather than defining separate mechanisms. Solution: Protocol requirements draft will be revised accordingly Feedback: Concern was expressed over requirement that the OPES callout protocol be application protocol-agnostic (since OPES charter is limited to HTTP/RTP) Solution: Being protocol-agnostic is still an important goal, but we will soften the protocol requirement ("SHOULD" instead of "MUST"). Feedback: The WG was discouraged to ask for a mechanism to negotiate the transport protocol to be used for OPES callout protocol transactions. Solution: We will drop this requirement and instead suggest a fixed mapping of a given application protocol (e.g. HTTP, RTP) to a certain transport protocol (e.g. TCP, UDP). Feedback: It was proposed proposed to link scenarios draft with threats draft Solution: - WG sub-teams expressed some doubt about this proposal - Allison will re-read both drafts and re-evaluate this comment Feedback: There was a complain about terminology not being aligned between scenarios and architecture draft Solution: Will be addressed in the next draft versions From owner-ietf-openproxy@mail.imc.org Mon Nov 18 09:05:04 2002 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21307 for ; Mon, 18 Nov 2002 09:05:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIDVlJ22787 for ietf-openproxy-bks; Mon, 18 Nov 2002 05:31:47 -0800 (PST) Received: from www.fastmail.fm (fastmail.fm [209.61.183.86]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIDVig22783 for ; Mon, 18 Nov 2002 05:31:45 -0800 (PST) Received: from www.fastmail.fm (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 1502C6DAB6; Mon, 18 Nov 2002 07:31:38 -0600 (CST) Received: from 127.0.0.1 ([127.0.0.1] helo=www.fastmail.fm) by fastmail.fm with SMTP; Mon, 18 Nov 2002 07:31:38 -0600 X-Mail-from: markus@mhof.com X-Spam-score: -0.2 X-Epoch: 1037626298 X-Sasl-enc: eNpHAnpAC0k6vDbFeETMQw Received: from mhof.com (p85.n-atpop05.stsn.com [12.129.84.85]) by www.fastmail.fm (Postfix) with ESMTP id 0246F6DB75; Mon, 18 Nov 2002 07:31:37 -0600 (CST) Message-ID: <3DD8EBB7.3000200@mhof.com> Date: Mon, 18 Nov 2002 08:31:35 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Detailed OPES Agenda Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Folks, since I didn't see the initial email coming through yet, here's another attempt... below a more detailed agenda with speakers and times for our OPES WG meeting tomorrow. -Markus ============================================================= AGENDA FOR OPES WG MEETING AT IETF 55: - Introduction, minutes taker, blue sheets [2 min] - Agenda bashing [3 min] - Discussion of WG documents - Status of documents submitted to IESG [M. Hofmann, 15 min] - draft-ietf-opes-scenarios-00.txt - draft-ietf-opes-architecture-02.txt - draft-ietf-opes-protocol-reqs-01.txt - Security Threats and Risks for Open Pluggable Edge Services [ S. Bindignavile, 20 min] - draft-ietf-opes-threats-00.txt - Requirements for Policy, Authorization and Enforcement of OPES Services [Andre/Reinaldo/Srini?, 20 min] - draft-ietf-opes-authorization-00.txt - Summary ICAP discussion [F. Berzau, 20 min] - draft-elson-icap-01.txt - draft-stecher-opes-icap-eval-00.txt - Next WG items to be worked on - Next steps on OPES protocols [M. Hofmann, 10 min] - Methods for spefification of rules/policies [A. Beck, 15 min] From owner-ietf-openproxy@mail.imc.org Tue Nov 19 13:58:55 2002 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13070 for ; Tue, 19 Nov 2002 13:58:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAJIVdh02349 for ietf-openproxy-bks; Tue, 19 Nov 2002 10:31:39 -0800 (PST) Received: from kalia.dbc.mtview.ca.us (kalia.dbc.mtview.ca.us.ietf55.ops.ietf.org [204.42.65.193]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAJIVag02342 for ; Tue, 19 Nov 2002 10:31:37 -0800 (PST) Received: from kalia.dbc.mtview.ca.us (localhost [127.0.0.1]) by kalia.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id gAJIVLKQ000981; Tue, 19 Nov 2002 13:31:27 -0500 (EST) Date: Tue, 19 Nov 2002 13:31:21 -0500 From: Marshall Rose To: ietf-openproxy@imc.org Subject: draft minutes from 55th IETF Message-Id: <20021119133121.47dd1439.mrose@dbc.mtview.ca.us> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.3claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Tue__19_Nov_2002_13:31:21_-0500_089bd200" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --Multipart_Tue__19_Nov_2002_13:31:21_-0500_089bd200 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit please comment. in the absence of substantive comments, the minutes get filed on wednesday, november 27th, close-of-business, us/pacific. /mtr --Multipart_Tue__19_Nov_2002_13:31:21_-0500_089bd200 Content-Type: text/plain; name="opes-minutes.txt" Content-Disposition: attachment; filename="opes-minutes.txt" Content-Transfer-Encoding: 7bit Monday, November 18 at 1300-1500 ================================= CHAIRS: Marshall Rose Markus Hofmann - Introduction, minutes taker, blue sheets Marshall Rose to take minutes. - Agenda bashing No comments. - Discussion of WG documents - Status of documents submitted to IESG (hofmann) - draft-ietf-opes-scenarios-00.txt - draft-ietf-opes-architecture-02.txt - draft-ietf-opes-protocol-reqs-01.txt The design teams met to address the IESG comments. Markus enumerated the issues, along with the suggested approach. Comments: Channels in the callout protocol: why are they there? they introduce security issues. They deal with state, but aren't clearly (enough) described. How many OPES callout protocols are there? How do you pick which one? There is one, but you can negotiate parameters when using it. More comments will be sent to mailing list/authors! - Security Threats and Risks for Open Pluggable Edge Services (bindignavile) - draft-ietf-opes-threats-00.txt Top-level taxonomy: in-band (datastream) and out-of-band (otherwise) threats. In-band threats: fundamentally, have to use hop-by-hop security to deal with opes flow network/application level threats. Authorization is also a large issue. Out-of-band threats: caused by weakness in implementation. Comments: There are other types of DOS besides overloading. The notion of "key manipulation" is puzzling. Why would an encrypted link have a generic threat in this area? It is not necessarily the case that keys will be sent across OPES, besides the notion of key distribution is out of scope. A reminder: we must focus only on threats introduced by OPES. - Requirements for Policy, Authorization and Enforcement of OPES Services (beck) - draft-ietf-opes-authorization-00.txt Top-level taxonomy: requirements for opes policy architecture and opes service authorization Comments: Reminder: look for a common solution to these requirements, instead of trying to come up with a specific solution. Does it matter if the intermediary is acting on behalf of the client or the origin server? Technically, no, in the sense that the requirements deal with OPES endpoints. Further, conflicting rules from different endpoints have to be dealt with, but that the actual algorithm for conflict resolution is out of scope for OPES. - Summary and wrap up of the ICAP discussion to accompany possible informational publication of that protocol (berzau) - draft-elson-icap-01.txt - draft-stecher-opes-icap-eval-00.txt The ICAP I-D is an individual specification that will be published as an RFC to document current practice. First there was ICAP 0.9, then 0.95, then 1.0 (Summer, 2001) which is stable and deployed. Various issues have arisen as a result of this experience. Comments: What about the "it's an RFC" problem? There's the "IESG note" to clarify the relationship of the draft to the standards track. - Next WG items to be worked on (hofmann) - OPES protocol Either we identify an existing protocol and declare victory, or we modify an existing protocol, or we create a new one. There are lots of things to choose from: HTTP, ICAP, SOAP, BEEP, etc., etc. Given the group's metabolism, have to be careful in terms of allocating resources. Let's start with the OPES Callout Protocol Requirements draft. Comments: Also include the OPES Policy/Authorization draft as a part of this. - Methods for specification of rules/policies (beck) How much can we learn from similar IETF efforts (e.g., CPL)? Also, what about IRML (an older individual I-D submission)? Is this a good start? Comments: Perhaps, but there are a lot of uses to be considered. Do we need more detailed requirements for a specification language? Perhaps this falls out of the policy requirements draft, (implying that we need to put more details into the policy requirements drafts, rather than having a separate document). - Adjourn. --Multipart_Tue__19_Nov_2002_13:31:21_-0500_089bd200-- From owner-ietf-openproxy@mail.imc.org Wed Nov 20 02:49:05 2002 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14147 for ; Wed, 20 Nov 2002 02:49:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAK6sXq16182 for ietf-openproxy-bks; Tue, 19 Nov 2002 22:54:33 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAK6sUg16177 for ; Tue, 19 Nov 2002 22:54:31 -0800 (PST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAK6sd523960; Wed, 20 Nov 2002 00:54:39 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Nov 2002 22:54:25 -0800 Message-ID: <0A11633F61BD9F40B43ABCC694004F93299EBD@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: Markus Hofmann , OPES Group Subject: RE: OPES document status Date: Tue, 19 Nov 2002 22:54:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29061.A5683494" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C29061.A5683494 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable So, we need to modify/come up with two protocols: callout and a in-path. The in-path have requirements such as tracing, notifications, authorizations, etc..We can modify HTTP (extra headers, or something = like it) to do it, or we can come up with a different out of band protocol. The advantages of an out of band signalling protocol is that it can be = used by all applications, and doesn't need to modify existing protocols. I think whatever NSIS produces might be a good out of band in-path = protocol for OPES. I wonder if somebody have some ideas on this... regards, Reinaldo =20 > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Saturday, November 16, 2002 1:46 AM > To: OPES Group > Subject: OPES document status >=20 >=20 >=20 > Hi, >=20 > quick update on the current OPES document status. >=20 > In August, we submitted three WG drafts on >=20 > Architecture (draft-ietf-opes-architecture-03) > Protocol Requirements (draft-ietf-opes-protocol-reqs-02) > Scenarios (draft-ietf-opes-scenarios-01) >=20 > to the IESG for consideration as informal RFCs. We've received=20 > feedback from the IESG discussion on all three documents, and we had=20 > an initial call of the author teams to discuss how we should address=20 > the issues. Thanks to Allison, who joined this call and=20 > explained/helped understanding the various issues. >=20 > Below an attempt to summarize the IESG feedback and how we=20 > envision to=20 > incorprate it into all three drafts. (Thanks to Andre for the nice=20 > summary! Hope we didn't miss anything). >=20 > The authors are currently working on updated draft versions, which=20 > we'll re-submit to the IESG after our discussion in Atlanta=20 > and on the=20 > mailing list. We want to do this shortly after the Atlanta meeting -=20 > so please read the comments carefully, participate in the upcoming=20 > meeting, and send your thoughts and comments to the mailing list. >=20 > We also have initial versions of our documents on >=20 > Enforcement/Authorization (draft-ietf-opes-authorization-00) > Threats/Risk (draft-ietf-opes-threats-00) >=20 > published. We'll discuss those in Atlanta with the goal of wrapping=20 > them up and submitting to IESG shortly. So, please also read=20 > those two=20 > drafts very carefully and provide feedback in the meeting and on the=20 > mailing list. >=20 > Thanks, > Markus >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Summary of IESG = Feedback = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Feedback: It was suggested that tracing/audit/authorization and other > requirements from RFC 3238 were not properly addressed in > the drafts. > Solution: - We will list and address all OPES considerations in a > separate section in the architecture document. > - Solutions to some of these requirements might be beyond > the group's current charter, in which case this will be > spelled out explicitely. > - WG will explain in the architecture and possibly other > drafts what is needed to accomplish tracing/audit/ > authorization. >=20 > Feedback: It was suggested to remove all references to callout server > chaining due to concerns over transitive trust issues. > Solution: - We will revise drafts accordingly without ruling out > callout server chaining performed within a single > trusted domain (e.g. within an ISP=92s data center) >=20 > Feedback: Concern was expressed about the way the drafts address > privacy issues. > Solution: - We will add more details to discussion of privacy in > architecture draft. > - WG will add references to existing privacy solutions = that > could be applied to OPES (e.g. W3C P3P). >=20 > Feedback: It was asked that protocol requirements draft clearly = states > that for transport issues such as congestion avoidance, > ordered/unordered, reliability etc., OPES should rely on > existing solutions on the transport layer, rather than > defining separate mechanisms. > Solution: Protocol requirements draft will be revised accordingly >=20 > Feedback: Concern was expressed over requirement that the OPES = callout > protocol be application protocol-agnostic (since OPES > charter is limited to HTTP/RTP) > Solution: Being protocol-agnostic is still an important goal, but we > will soften the protocol requirement ("SHOULD" instead of > "MUST"). >=20 > Feedback: The WG was discouraged to ask for a mechanism to negotiate > the transport protocol to be used for OPES callout = protocol > transactions. > Solution: We will drop this requirement and instead suggest a fixed > mapping of a given application protocol (e.g. HTTP, RTP) = to > a certain transport protocol (e.g. TCP, UDP). >=20 > Feedback: It was proposed proposed to link scenarios draft with > threats draft > Solution: - WG sub-teams expressed some doubt about this proposal > - Allison will re-read both drafts and re-evaluate this > comment >=20 > Feedback: There was a complain about terminology not being aligned > between scenarios and architecture draft > Solution: Will be addressed in the next draft versions >=20 >=20 >=20 ------_=_NextPart_001_01C29061.A5683494 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable RE: OPES document status

So,

we need to modify/come up with two protocols: callout = and a in-path.

The in-path have requirements such as tracing, = notifications, authorizations, etc..We can modify HTTP (extra headers, = or something like it) to do it, or we can come up with a different out = of band protocol.

The advantages of an out of band signalling protocol = is that it can be used by all applications, and doesn't need to modify = existing protocols.

I think whatever NSIS produces might be a good out of = band in-path protocol for OPES. I wonder if somebody have some ideas on = this...

regards,

Reinaldo



 

> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Saturday, November 16, 2002 1:46 = AM
> To: OPES Group
> Subject: OPES document status
>
>
>
> Hi,
>
> quick update on the current OPES document = status.
>
> In August, we submitted three WG drafts = on
>
>   Architecture = (draft-ietf-opes-architecture-03)
>   Protocol Requirements = (draft-ietf-opes-protocol-reqs-02)
>   Scenarios = (draft-ietf-opes-scenarios-01)
>
> to the IESG for consideration as informal RFCs. = We've received
> feedback from the IESG discussion on all three = documents, and we had
> an initial call of the author teams to discuss = how we should address
> the issues. Thanks to Allison, who joined this = call and
> explained/helped understanding the various = issues.
>
> Below an attempt to summarize the IESG feedback = and how we
> envision to
> incorprate it into all three drafts. (Thanks to = Andre for the nice
> summary! Hope we didn't miss anything).
>
> The authors are currently working on updated = draft versions, which
> we'll re-submit to the IESG after our = discussion in Atlanta
> and on the
> mailing list. We want to do this shortly after = the Atlanta meeting -
> so please read the comments carefully, = participate in the upcoming
> meeting, and send your thoughts and comments to = the mailing list.
>
> We also have initial versions of our documents = on
>
>    Enforcement/Authorization = (draft-ietf-opes-authorization-00)
>    Threats/Risk = (draft-ietf-opes-threats-00)
>
> published. We'll discuss those in Atlanta with = the goal of wrapping
> them up and submitting to IESG shortly. So, = please also read
> those two
> drafts very carefully and provide feedback in = the meeting and on the
> mailing list.
>
> Thanks,
>    Markus
>
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Summary of IESG = Feedback = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
>
> Feedback: It was suggested that = tracing/audit/authorization and other
>          = ;  requirements from RFC 3238 were not properly addressed = in
>          = ;  the drafts.
> Solution: - We will list and address all OPES = considerations in a
>          = ;    separate section in the architecture = document.
>          = ;  - Solutions to some of these requirements might be = beyond
>          = ;    the group's current charter, in which case this = will be
>          = ;    spelled out explicitely.
>          = ;  - WG will explain in the architecture and possibly other
>          = ;    drafts what is needed to accomplish = tracing/audit/
>          = ;    authorization.
>
> Feedback: It was suggested to remove all = references to callout server
>          = ;  chaining due to concerns over transitive trust issues.
> Solution: - We will revise drafts accordingly = without ruling out
>          = ;    callout server chaining performed within a = single
>          = ;    trusted domain (e.g. within an ISP=92s data = center)
>
> Feedback: Concern was expressed about the way = the drafts address
>          = ;  privacy issues.
> Solution: - We will add more details to = discussion of privacy in
>          = ;    architecture draft.
>          = ;  - WG will add references to existing privacy solutions = that
>          = ;    could be applied to OPES (e.g. W3C P3P).
>
> Feedback: It was asked that protocol = requirements draft clearly states
>          = ;  that for transport issues such as congestion avoidance,
>          = ;  ordered/unordered, reliability etc., OPES should rely on
>          = ;  existing solutions on the transport layer, rather than
>          = ;  defining separate mechanisms.
> Solution: Protocol requirements draft will be = revised accordingly
>
> Feedback: Concern was expressed over = requirement that the OPES callout
>          = ;  protocol be application protocol-agnostic (since OPES
>          = ;  charter is limited to HTTP/RTP)
> Solution: Being protocol-agnostic is still an = important goal, but we
>          = ;  will soften the protocol requirement ("SHOULD" = instead of
>          = ;  "MUST").
>
> Feedback: The WG was discouraged to ask for a = mechanism to negotiate
>          = ;  the transport protocol to be used for OPES callout = protocol
>          = ;  transactions.
> Solution: We will drop this requirement and = instead suggest a fixed
>          = ;  mapping of a given application protocol (e.g. HTTP, RTP) = to
>          = ;  a certain transport protocol (e.g. TCP, UDP).
>
> Feedback: It was proposed proposed to link = scenarios draft with
>          = ;  threats draft
> Solution: - WG sub-teams expressed some doubt = about this proposal
>          = ;  - Allison will re-read both drafts and re-evaluate this
>          = ;    comment
>
> Feedback: There was a complain about = terminology not being aligned
>          = ;  between scenarios and architecture draft
> Solution: Will be addressed in the next draft = versions
>
>
>

------_=_NextPart_001_01C29061.A5683494-- From owner-ietf-openproxy@mail.imc.org Sun Nov 24 14:30:13 2002 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01160 for ; Sun, 24 Nov 2002 14:29:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAOJAhB20743 for ietf-openproxy-bks; Sun, 24 Nov 2002 11:10:43 -0800 (PST) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAOJAeg20737 for ; Sun, 24 Nov 2002 11:10:40 -0800 (PST) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout03.icomcast.net (iPlanet Messaging Server 5.1 HotFix 1.5 (built Sep 23 2002)) with ESMTP id <0H6300B7UH9ONJ@mtaout03.icomcast.net> for ietf-openproxy@imc.org; Sun, 24 Nov 2002 14:10:37 -0500 (EST) Date: Sun, 24 Nov 2002 14:10:36 -0500 From: Markus Hofmann Subject: Call for Comments on OPES Drafts To: OPES Group Message-id: <3DE1242C.2010408@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Hi, as mentioned in Atlanta, we want to wrap-up and finish our two WG drafts on "Security Threats and Risks for Open Pluggable Edge Services" and on "Requirements for Policy, Authorization and Enforcement of OPES Services" *very* quickly and submit them to the IESG. However, it is really hard to believe that no one has to say anything about the drafts in their current form... As such, consider this a formal request for comments on those two drafts, please read them carefully and post any comments/suggestions you might have to the mailing list! We intend to consider feedback coming back until shortly after Thanksgiving, then publish new versions of those two rafts and issue WG last call following immediatelly. As such, I'd expect that issues with the currrent draft versions will be raised *before* we publish the new ones after Thanksgiving! Thanks, Markus From owner-ietf-openproxy@mail.imc.org Sun Nov 24 14:30:35 2002 Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01193 for ; Sun, 24 Nov 2002 14:30:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAOJ0n719749 for ietf-openproxy-bks; Sun, 24 Nov 2002 11:00:49 -0800 (PST) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAOJ0kg19742 for ; Sun, 24 Nov 2002 11:00:47 -0800 (PST) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout03.icomcast.net (iPlanet Messaging Server 5.1 HotFix 1.5 (built Sep 23 2002)) with ESMTP id <0H6300BUJGT6NJ@mtaout03.icomcast.net> for ietf-openproxy@imc.org; Sun, 24 Nov 2002 14:00:42 -0500 (EST) Date: Sun, 24 Nov 2002 14:00:42 -0500 From: Markus Hofmann Subject: Requirements for Rules Language To: OPES Group Message-id: <3DE121DA.7090704@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Hi, from the minutes of our meeting in Atlanta we've the following open issue: "Do we need more detailed requirements for a specification language? Perhaps this falls out of the policy requirements draft, (implying that we need to put more details into the policy requirements drafts, rather than having a separate document)." In general, if we need more detailed requirements, I think this should be part of the policy requirements drafts rather than having yet another separate document. Indeed, Section 3.2 of the "Requirements for Policy, Authorization and Enforcement" draft already spells out a few requirements, it seems natural to extend this section if necessary. Any thoughts on that? Also, please post if you've more detailed requirements for the rules language in mind that should be written down. Cheers, Markus