From owner-um@snowshore.com Thu Nov 7 09:10:51 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id gA7EAaN20407 for um-outgoing; Thu, 7 Nov 2002 09:10:36 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id gA7EAYF20403 for ; Thu, 7 Nov 2002 09:10:34 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: [UM] FW: Introducing the ID tracker Date: Thu, 7 Nov 2002 09:10:35 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D555C@zoe.office.snowshore.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Introducing the ID tracker Thread-Index: AcKEUw+RWE9av4N9STGUHDi6qb3+ygAdCtsQ From: "Eric Burger" To: "IETF SPEECHSC (E-mail)" , "IETF LEMONADE (E-mail)" , "Vpim Mail List (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by flyingfox.snowshore.com id gA7EAZF20404 Sender: owner-um@snowshore.com Precedence: bulk Excellent news from Harald! This is an excellent tool; use it if you are wondering where your draft is. -----Original Message----- From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] Sent: Monday, November 04, 2002 4:44 PM Subject: Introducing the ID tracker Hello, The IESG is always trying to work better. We have gotten a number of comments from the community that it is sometimes very hard to find out what the IESG is doing to documents, why documents take a long time to process, who makes comments, what the comments are and so on, and that this is a significant source of frustration for the community. For the last year or so, the secretariat has been working on a tool to help us keep track of what documents are on our plate, what state they are in and who is responsible for them; we call it the "ID tracker". It's been in use for about 6 months now, and has definitely improved our ability to keep track. For several months, the "status of items" pages on the IESG web pages have been generated from this tool, showing the high-order bit of who we think is responsible. In order to help you know more about what we are doing, we've decided to open up a public view of the ID tracker itself. This will allow you to search for the documents you want to look at, and for each document see: - What its current state is - What the history of IESG processing is - AD and IESG comments on the document - For documents in IESG consideration for standards track, what the individual ADs have indicated as their opinion on the document, and if they think there are problems with it, what the comments are. The last point is a revision of previous IESG policy, based on the feedback from the Yokohama plenary; we are now telling you the names that go with each comment from the IESG members. The system is far from perfect - you can tell from the history of documents that we've been changing this as we go along - but we hope that it will be a useful tool for people to figure out what the IESG is doing with their documents, and for them to have an easier time talking to the relevant ADs in order to get what we all want out of the process - relevant, high quality standards for the Internet. The tool and its documentation is found at https://datatracker.ietf.org/public/pidtracker.cgi The link to it is also visible on the IESG Web page. Welcome! The IESG - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Tue Nov 12 09:49:36 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id gACEnL005502 for um-outgoing; Tue, 12 Nov 2002 09:49:21 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id gACEnGF05497 for ; Tue, 12 Nov 2002 09:49:16 -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: [UM] RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Date: Tue, 12 Nov 2002 09:49:15 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D55A7@zoe.office.snowshore.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: 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 flyingfox.snowshore.com id gACEnGF05498 Sender: owner-um@snowshore.com Precedence: bulk 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 > - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Wed Nov 13 01:26:41 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id gAD6QXk22760 for um-outgoing; Wed, 13 Nov 2002 01:26:33 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from s31xu4.systems.smu.edu (s31xu4.systems.smu.edu [129.119.70.133]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id gAD6QTF22756 for ; Wed, 13 Nov 2002 01:26:31 -0500 (EST) 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: [UM] RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Message-ID: <4A3384433CE2AB46A63468CB207E209D55A7@zoe.office.snowshore.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: 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-um@snowshore.com Precedence: bulk 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 - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Thu Nov 14 09:17:55 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id gAEEHgx01307 for um-outgoing; Thu, 14 Nov 2002 09:17:42 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id gAEEHfF01303 for ; Thu, 14 Nov 2002 09:17:41 -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="utf-8" Subject: [UM] RE: [Sipping] Multimedia message adaptationInternet-Drafts Date: Thu, 14 Nov 2002 09:17:40 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D097B6C@zoe.office.snowshore.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: 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 flyingfox.snowshore.com id gAEEHfF01304 Sender: owner-um@snowshore.com Precedence: bulk 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 - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Fri Nov 15 02:54:28 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id gAF7sJJ27912 for um-outgoing; Fri, 15 Nov 2002 02:54:19 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id gAF7sHF27900 for ; Fri, 15 Nov 2002 02:54:17 -0500 (EST) Content-Class: urn:content-classes:message Subject: [UM] RE: [Sipping] Multimedia message adaptation Internet-Drafts Date: Fri, 15 Nov 2002 02:54:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-ID: <4A3384433CE2AB46A63468CB207E209D55B3@zoe.office.snowshore.com> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts thread-index: AcKL2DsO6cWYXZciS8qGVAN+WtLnQQADogetAAZUTyAAG4kAkA== From: "Eric Burger" To: , Cc: , "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by flyingfox.snowshore.com id gAF7sHF27904 Sender: owner-um@snowshore.com Precedence: bulk There are two areas, and I admit I was only addressing one. Event filtering does belong in sipping. It's part of events. Content adaptation, whether for mailbox retrieval (IMAP/3GPP(2)) or multimedia push (WAP) is essentially the same problem space. You are correct: the original intention for lemonade was mailbox retrieval (the 3GPP/3GPP2 case, specifically). However, given how close the problem spaces are, I would propose lemonade is where the research, requirements, and initial proposals should occur. > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Thursday, November 14, 2002 12:49 PM > 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 > Subject: RE: [Sipping] Multimedia message adaptationInternet-Drafts > > > Hi Eric, > > I think it's important to remember, that even though we're > talking about media adaptation and filtering here, we are > really talking about SIP features. > > The event filtering clearly is an (overdue) item for the > SIPPING group. AFAIK, the media adaptation I-Ds are mainly > about caller preferences and callee capabilities relating to > multimedia payloads, and thus clearly a SIPPING item in itself. > > Perhaps in addition to the above items, there is the media > transformation work, which is better suited for LEMONADE. > However, LEMONADE talks about Internet mailbox systems. Is > the expectation that this includes instant inboxes of SIMPLE > systems as well? > > Some comments inline. > > [...] > > 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. > > Well, the same can be said about a whole lot of other > SIP-items. SIP is certainly not a transport protocol, however > long its history in the Transport area is. > > > 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. > > Are we talking about a messaging system agnostic framework > for this media transformation? Perhaps this is actually a new > requirement for media transformation? > > > 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'm willing to agree with you, media transformation is > probably not a SIPPING issue. However, this doesn't include > caller-prefs and event filtering, which IMHO are in the scope > of SIPPING. > > > 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. > > The retrieval protocol in LEMONADE is IMAP -- in SIP/SIPPING > the whole notion of message retrieval has little meaning. The > closest thing we have in SIP is related to content > indirection. So I don't quite understand what the charter > should contain relating to SIP... > > Cheers, > Aki > - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Mon Nov 18 08:24:18 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id gAIDO2i15432 for um-outgoing; Mon, 18 Nov 2002 08:24:02 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id gAIDO1F15428 for ; Mon, 18 Nov 2002 08:24:01 -0500 (EST) Content-Class: urn:content-classes:message Subject: [UM] RE: [Sipping] Multimedia message adaptation Internet-Drafts MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Mon, 18 Nov 2002 08:24:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <4A3384433CE2AB46A63468CB207E209D55DE@zoe.office.snowshore.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Multimedia message adaptationInternet-Drafts thread-index: AcKOcsAB8dk0e109QFCUdTh1ojUHXAATN4yA From: "Eric Burger" To: "Drage, Keith (Keith)" Cc: "Sipping (E-mail)" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by flyingfox.snowshore.com id gAIDO1F15429 Sender: owner-um@snowshore.com Precedence: bulk I'm not advocating that app stuff "is not allowed" to be discussed in a transport area wg. I'm pointing out that the expertise for this particular issue (content adaptation) happens to already be gathered together, and they are not in the SIP/PING workgroups. > -----Original Message---- From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > SIPPING is in the transport area because SIP is. > > SIP is in the transport area because MMUSIC is. > > I assume that the transport area allocation was made because > of the http like origin of SIP. It would be hard to argue > that SIP acts like http today, or indeed is used like http. > > I have heard several people who matter argue that if SIP was > allocated to an area today it would be in the application > area, and certainly much of the aspects of the work are > application layer issues, not transport ones. > > I therefore see no reason to argue that application level > material cannot be discussed in either SIP or SIPPING. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Eric Burger [mailto:eburger@snowshore.com] > > Sent: 14 November 2002 14:18 > > 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 > > > > > > _______________________________________________ > > 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 > > > - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Mon Nov 18 15:37:40 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id gAIKbbG23651 for um-outgoing; Mon, 18 Nov 2002 15:37:37 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id gAIKbaF23647 for ; Mon, 18 Nov 2002 15:37:36 -0500 (EST) Content-Class: urn:content-classes:message Subject: [UM] Scribe and Transcriber Call for Participation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 18 Nov 2002 15:37:36 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D55E8@zoe.office.snowshore.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Scribe and Transcriber Call for Participation thread-index: AcKPFDV1nPpWr6aeRHy/s5e++V/k/g== From: "Eric Burger" To: "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by flyingfox.snowshore.com id gAIKbaF23648 Sender: owner-um@snowshore.com Precedence: bulk We need two volunteers for our meeting on Thursday. The first is a scribe. We would be happy to have two or three volunteers. We can split the load so you don't have to take notes for the entire meeting. The agenda is on line at http://www.ietf.org/ietf/02nov/speechsc.txt . If you are presenting open issues, you are probably NOT a candidate for being scribe. The second is a transcriber. All IETF WG sessions have a parallel Jabber (IRC) session. We need someone to write out what is going on in the session, as well as take questions from the Internet audience. You will need 802.11 access from your computer for this job. Again, we can take more than one person for this job. If you are presenting open issues, you are not a candidate for being transcriber. - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Tue Nov 19 04:49:06 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id gAJ9n2121815 for um-outgoing; Tue, 19 Nov 2002 04:49:02 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id gAJ9n0F21803 for ; Tue, 19 Nov 2002 04:49:00 -0500 (EST) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [UM] FW: text conferencing at the 55th IETF meeting in Atlanta X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 19 Nov 2002 04:48:59 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D09751D@zoe.office.snowshore.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: text conferencing at the 55th IETF meeting in Atlanta thread-index: AcKPpHVQwUmnwhA/TZaab7cYcNVYag== From: "Eric Burger" To: "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by flyingfox.snowshore.com id gAJ9n0F21804 Sender: owner-um@snowshore.com Precedence: bulk For the remote, Internet audience, we have two choices for a live text feed of the proceedings. The first is Jabber and the second is SIP. Note the SIP implementation is an Alpha version. I have no idea if it works. If either tool is broken, contact jabber.com or iptel.org, respectively. We will not have MBONE access or an audio conference bridge. For Jabber, the conference room is "lemonade" at conference.ietf.jabber.com . The recording is at http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/lemonade/ . For SIP, check out http://www.iptel.org/ietf55/ . Our conference is lemonade. As a reminder, out meeting is in the Salon IV room from 9:00am - 11:30am ET on Thursday November 21. -----Original Message----- From: Marshall Rose [mailto:mrose+mtr.netnews@dbc.mtview.ca.us] Sent: Monday, November 18, 2002 9:11 AM To: ietf@ietf.org Subject: text conferencing at the 55th IETF meeting in Atlanta Remote Access for the 55th IETF meeting in Atlanta: Text Conferencing At each IETF meeting, two of the working group meeting rooms are equipped for video multicast and remote participation. That is, for every IETF meeting slot, two of the working groups can see and hear the meeting. For the 55th IETF, in *addition* to the usual network A/V, text conferencing will be provided for every working group that meets. All of the conference rooms are hosted on conference.ietf.jabber.com and each is named using the official IETF abbreviation found in the agenda (e.g., "apparea", "dhc", "forces", and so on -- for all the examples that follow, we'll use "foobar" as the abbreviation). Each conference room also has a 'bot which records everything that gets sent: http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/ Enjoy! /mtr -----Original Message----- From: Jiri Kuthan [mailto:jiri@iptel.org] Sent: Monday, November 18, 2002 10:33 AM To: Marshall Rose; ietf@ietf.org Cc: serhelp@iptel.org Subject: Re: text conferencing at the 55th IETF meeting in Atlanta For those, who would like to use SIP for text conferencing, experimental operation of a SIP2Jabber gateway has been set up at iptel.org. See http://www.iptel.org/ietf55/ for guidelines how to join the IETF chat rooms. Better set your expectations low -- the gateway has not been tested with bigger user populations until now. -Jiri - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Thu Nov 21 10:06:44 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id gALF69H01058 for um-outgoing; Thu, 21 Nov 2002 10:06:09 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id gALF67w01052 for ; Thu, 21 Nov 2002 10:06:08 -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: [UM] Today's Slides Date: Thu, 21 Nov 2002 10:06:07 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D5656@zoe.office.snowshore.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Today's Slides thread-index: AcKRb1j1kPxfVOuQTfm1ewvWDS5TSA== From: "Eric Burger" To: "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by flyingfox.snowshore.com id gALF68w01053 Sender: owner-um@snowshore.com Precedence: bulk Are at the Lemonade Supplemental web page, Only PowerPoint right now; PDF's will come later (sorry). - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Mon Nov 25 13:16:28 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id gAPIG3W17698 for um-outgoing; Mon, 25 Nov 2002 13:16:03 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id gAPIG1w17694 for ; Mon, 25 Nov 2002 13:16:02 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAPIFYJ08768; Mon, 25 Nov 2002 13:15:34 -0500 (EST) Received: from zcard04k.ca.nortel.com ([47.129.242.84]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XJ9BDG4D; Mon, 25 Nov 2002 13:15:35 -0500 Received: from [47.129.42.35] (g3bronze.ca.nortel.com [47.129.42.35]) by zcard04k.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XJ7VDFC6; Mon, 25 Nov 2002 13:15:34 -0500 User-Agent: Microsoft-Entourage/9.0.2.4011 Date: Mon, 25 Nov 2002 13:01:18 -0500 Subject: [UM] IETF 55 VPIM WG minutes X-Sybari-Space: 00000000 00000000 00000000 From: Glenn Parsons To: CC: , Message-ID: Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3121074078_826789" Sender: owner-um@snowshore.com Precedence: bulk > 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. --B_3121074078_826789 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Folks, Please find the VPIM WG minutes from this week's IETF meeting. Let me know if you have any comments. Note the slides are available on http://www.vpim.org Cheers, Glenn. --B_3121074078_826789 Content-type: text/plain; name="VPIM WG minutes, IETF 55.txt"; x-mac-creator="522A6368"; x-mac-type="54455854" Content-disposition: attachment Content-transfer-encoding: x-uuencode begin 644 VPIM WG minutes, IETF 55.txt M5E!)32!71R!M965T:6YG+"`U-71H($E%5$8L($%T;&%N=&$L($=E;W)G:6$- M"CT]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T] M#0H-"D-H86ER("8@4V-R:6)E.B`@1VQE;FX@4&%R"!71RX-"@T*#0I6;VEC92!0'0^#0H@("`@(%1O;&P@475A;&ET>2!6;VEC92`M(#,R(&MB M:70O7!E(%)E9VES=')A=&EO;@T*("`@("`@ M("`@(#QD2!3=&%T=7,@3F]T M:69I8V%T:6]N7!E(&9O7-T M96T@4W1A='5S($-O9&5S#0H@("`@("`@("`@/&1R869T+79A=61R975I;"TQ M.#DS8FES+3`S+G1X=#X-"B`@("`@06X@17AT96YS:6)L92!-97-S86=E($9O M'0-"B`@("`@25-%1R!T96QE8VAA="!B969OF4@=&AE('-E6YT87@N("!4:'5I'0^("T@:6X@=&AE#0I21D,@161I=&]R)W,@<75E=64@=V%I=&EN9R!F;W(@ M4F5F97)E;F-E'1E;G-I;VYS('-T871U'1E;G-I;VX@/&1R869T+6YE2TP M-RYT>'0^("T@87!P'0^#0I)34%0-"!#:&%N;F5L(%5392!#87-E'0^#0HM(&%G'0^("T-"E1H:7,@5T<@:&%S M(&)E960@=')A8VMI;F<@=&AI'!R97-S960I M('=E65R71H:6YG(&%L:6=N960@=VET:"!T:&4@ M24531R!A;F0@4D9#($5D:71O