From xcon-bounces@ietf.org Wed Aug 01 18:48:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGMz5-0005lp-O7; Wed, 01 Aug 2007 18:48:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGMz4-0005lj-R0 for xcon@ietf.org; Wed, 01 Aug 2007 18:48:02 -0400 Received: from estacado-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:266::2] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGMz4-0003zC-8x for xcon@ietf.org; Wed, 01 Aug 2007 18:48:02 -0400 Received: from orthrus.local ([172.17.1.56]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l71Mluif008623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Aug 2007 17:47:57 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <46B10D9F.6090800@estacado.net> Date: Wed, 01 Aug 2007 17:47:59 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: XCON-IETF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [XCON] Validating Consensus: and children X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org [As Chair] Currently, the XCON data model defines several children elements to , each of which is specific to the access technology used to reach the conference. At the face-to-face meeting in Chicago, there was strong agreement in the room that we desire to collapse these into a single kind of child, containing a URI. The scheme of the URI will be used to indicate the access method. Presumably, all sub-items to these children, such as "", will become children of the unified element. If anyone disagrees with this direction, please speak up immediately. Thanks. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Aug 01 19:00:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGNAi-0002Lr-81; Wed, 01 Aug 2007 19:00:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGNAh-0002Lm-7L for xcon@ietf.org; Wed, 01 Aug 2007 19:00:03 -0400 Received: from estacado-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:266::2] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGNAg-0004Dn-KW for xcon@ietf.org; Wed, 01 Aug 2007 19:00:03 -0400 Received: from orthrus.local ([172.17.1.56]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l71N01gP009838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Aug 2007 18:00:01 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <46B11074.4000304@estacado.net> Date: Wed, 01 Aug 2007 18:00:04 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: XCON-IETF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [XCON] Updated Meeting Minutes (and summary) X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org I have uploaded what should be the final version of the XCON minutes to the IETF materials web page: http://www3.ietf.org/proceedings/07jul/minutes/xcon.txt Highlights from the meeting that the group should be aware of are: * We have a team of 7 dedicated reviewers for the data model document (draft-ietf-xcon-common-data-model-05.txt); they have committed to perform a detailed review and comment on the document by September 7th. After revisions from these reviews (and my gap analysis; see below) have been incorporated into the document, we will enter a two-week working group last-call period, after which the chairs will request publication. The chairs are also seeking input from the APPS area regarding the use of XML and MIME in this document. * All participants should review draft-srinivasan-xcon-eventpkg-extension-01, with an eye towards whether it is a suitable basis for our event package deliverable. Simon Romano has volunteered to craft some introductory and additional explanatory text for this document. * I will be completing a gap analysis prior to August 17th; this document will attempt to identify areas in which additional standardization work is necessary for the mechanisms currently being defined in the IETF to provide the same features as are found in currently deployed chat-room solutions. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Aug 02 10:35:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGbln-0005jG-2J; Thu, 02 Aug 2007 10:35:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGblm-0005jA-1B for xcon@ietf.org; Thu, 02 Aug 2007 10:35:18 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGbll-0002zI-Ae for xcon@ietf.org; Thu, 02 Aug 2007 10:35:17 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1781820A30; Thu, 2 Aug 2007 16:35:15 +0200 (CEST) X-AuditID: c1b4fb3c-aee7cbb0000007e1-e0-46b1eba38bc4 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0985220956; Thu, 2 Aug 2007 16:35:15 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 16:35:14 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 16:35:14 +0200 Received: from [131.160.126.122] (rvi2-126-122.lmf.ericsson.se [131.160.126.122]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 46C842339; Thu, 2 Aug 2007 17:35:14 +0300 (EEST) Message-ID: <46B1EBA3.8040403@ericsson.com> Date: Thu, 02 Aug 2007 17:35:15 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Adam Roach Subject: Re: [XCON] Updated Meeting Minutes (and summary) References: <46B11074.4000304@estacado.net> In-Reply-To: <46B11074.4000304@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Aug 2007 14:35:14.0306 (UTC) FILETIME=[56A3EE20:01C7D512] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Adam, the acronym 'GC' should be expanded at the end of the minutes, as all the other acronyms. Cheers, Gonzalo Adam Roach wrote: > I have uploaded what should be the final version of the XCON minutes to > the IETF materials web page: > > http://www3.ietf.org/proceedings/07jul/minutes/xcon.txt > > Highlights from the meeting that the group should be aware of are: > > * We have a team of 7 dedicated reviewers for the data model > document (draft-ietf-xcon-common-data-model-05.txt); they have > committed to perform a detailed review and comment on the document > by September 7th. After revisions from these reviews (and my gap > analysis; see below) have been incorporated into the document, we > will enter a two-week working group last-call period, after which > the chairs will request publication. The chairs are also seeking > input from the APPS area regarding the use of XML and MIME in this > document. > > * All participants should review > draft-srinivasan-xcon-eventpkg-extension-01, with an eye towards > whether it is a suitable basis for our event package deliverable. > Simon Romano has volunteered to craft some introductory and > additional explanatory text for this document. > > * I will be completing a gap analysis prior to August 17th; this > document will attempt to identify areas in which additional > standardization work is necessary for the mechanisms currently > being defined in the IETF to provide the same features as are > found in currently deployed chat-room solutions. > > > /a > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Aug 06 16:15:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1II8yn-0005sv-GH; Mon, 06 Aug 2007 16:15:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II8yk-0005sY-4N; Mon, 06 Aug 2007 16:15:02 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1II8yj-0003gi-Nt; Mon, 06 Aug 2007 16:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 985892AC6B; Mon, 6 Aug 2007 20:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1II8yj-0007qQ-CM; Mon, 06 Aug 2007 16:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 06 Aug 2007 16:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-framework-09.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : A Framework for Centralized Conferencing Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-framework-09.txt Pages : 63 Date : 2007-8-6 This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber, Q.931 or ISUP, to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions, along with a high level conferencing data model. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-xcon-framework-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-framework-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-6150930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-framework-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-framework-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-6150930.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --NextPart-- From xcon-bounces@ietf.org Fri Aug 17 19:48:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMBWF-0001LW-7A; Fri, 17 Aug 2007 19:46:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMBWC-0001KO-6C; Fri, 17 Aug 2007 19:46:16 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMBW5-0003jg-PK; Fri, 17 Aug 2007 19:46:16 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l7HNk8n7039168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 18:46:09 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46C6334B.2030806@nostrum.com> Date: Fri, 17 Aug 2007 18:46:19 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: XCON-IETF , "'simple@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.1/3976/Fri Aug 17 18:21:11 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [XCON] Chatroom Gap Analysis X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org As we discussed in Chicago, I have produced a gap analysis document that discusses the features available in currently deployed chatroom systems and which of these can be achieved using protocols defined by or currently under definition within the IETF. Until it appears in the archives, you can grab a copy from: http://www.nostrum.com/~adam/ids/draft-roach-xcon-chatroom-analysis-00.txt or http://www.nostrum.com/~adam/ids/draft-roach-xcon-chatroom-analysis-00.html (The document isn't as polished as I'd like, but I think it gets all the important information across). /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Aug 17 23:38:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMF7e-0007yn-OR; Fri, 17 Aug 2007 23:37:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMF7c-0007yP-5b; Fri, 17 Aug 2007 23:37:08 -0400 Received: from pne-smtpout1-sn2.hy.skanova.net ([81.228.8.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMF7b-0001CV-FN; Fri, 17 Aug 2007 23:37:07 -0400 Received: from GunnarH (213.64.232.214) by pne-smtpout1-sn2.hy.skanova.net (7.2.075) id 46BFEA480017EF5C; Sat, 18 Aug 2007 05:36:59 +0200 Message-ID: <46BFEA480017EF5C@pne-smtpout1-sn2.hy.skanova.net> (added by postmaster@pne.skanova.net) From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "'Adam Roach'" , "'XCON-IETF'" , Date: Sat, 18 Aug 2007 05:37:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <46C6334B.2030806@nostrum.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 thread-index: AcfhKPZEqX3D1fIqQbiooRh724SFhQAHIs/Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Subject: [XCON] RE: [Simple] Chatroom Gap Analysis - Media and mode aspects X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Adam, The draft gives a good overview over many chatroom features. However, I would like to see more on media and mode aspects. Now, the only place I found saying anything about contents is=20 "2.1.9. Sending Files and Images to a Chatroom." saying that you can = send anything to a chatroom. Questions: 1. In your analysis of existing chat-room applications, have you found = more orderly support for audio, video and images in addition to the default support for text? 2. Have you found planned support for text messages in other writing = systems than left-to right? 3. Have you found support for the media to be transmitted and displayed = in real-time as they are created? 4. Have you found support for ordered transition between message mode = and real time mode? I think it would be valuable to cover such aspects as well.=20 Gunnar Hellstr=F6m ------------------------------------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se Tel: +46708204288 www.omnitor.se -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Saturday, August 18, 2007 1:46 AM To: XCON-IETF; 'simple@ietf.org' Subject: [Simple] Chatroom Gap Analysis As we discussed in Chicago, I have produced a gap analysis document that discusses the features available in currently deployed chatroom systems = and which of these can be achieved using protocols defined by or currently = under definition within the IETF. Until it appears in the archives, you can grab a copy from: http://www.nostrum.com/~adam/ids/draft-roach-xcon-chatroom-analysis-00.tx= t or http://www.nostrum.com/~adam/ids/draft-roach-xcon-chatroom-analysis-00.ht= ml (The document isn't as polished as I'd like, but I think it gets all the important information across). /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple __________ NOD32 2468 (20070817) Information __________ Detta meddelande =E4r genoms=F6kt av NOD32 Antivirus. http://www.nod32.com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Aug 20 04:11:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN2Kg-0008Fe-U1; Mon, 20 Aug 2007 04:09:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN2Kf-0008FZ-L2 for xcon@ietf.org; Mon, 20 Aug 2007 04:09:53 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN2Kc-0000G1-H0 for xcon@ietf.org; Mon, 20 Aug 2007 04:09:53 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JN2002YBBZ7EE@szxga03-in.huawei.com> for xcon@ietf.org; Mon, 20 Aug 2007 16:09:07 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JN200BDMBZ47N@szxga03-in.huawei.com> for xcon@ietf.org; Mon, 20 Aug 2007 16:09:07 +0800 (CST) Received: from t39207 ([10.110.28.65]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JN2009R2BYXSJ@szxml03-in.huawei.com> for xcon@ietf.org; Mon, 20 Aug 2007 16:09:04 +0800 (CST) Date: Mon, 20 Aug 2007 16:08:57 +0800 From: tang Subject: [XCON] Some Comments on conference reservation.//Re: [XCON] I-D ACTION:draft-ietf-xcon-framework-09.txt To: mary.barnes@nortel.com, cboulton@ubiquitysoftware.com, oritl@microsoft.com Message-id: <013a01c7e301$5bbb4320$411c6e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.6 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb Cc: XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1090836873==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1090836873== Content-type: multipart/alternative; boundary="Boundary_(ID_2ksYZtyfgHsiGd9pEn2Ymw)" This is a multi-part message in MIME format. --Boundary_(ID_2ksYZtyfgHsiGd9pEn2Ymw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi ,Mary,Chris and Orit In my understanding, resources on media server are reserved when creates the reserved conferences, but not allocated. The resources are allocated at the scheduled start time. It will cause a huge waste of resources if allocation takes place when booking the reserved conference. But in section 6.3, the related description is: The selected blueprint with its default values is cloned by the client into a newly created conference object, referred to as a conference reservation, that specifies the resources needed from the system for this conference instance. At this point the conference reservation becomes independent from its blueprint. The client can also change the default values, within the system ranges, and add additional information, such as the list of participants and the conference start time, to the conference reservation. At this point the client can ask the conference server to create new conference reservations by attaching the conference reservation to the request. As a result, the server can allocate the needed resources, create the additional conference objects for the child conference reservations and allocate the conference object identifiers for all - the original conference reservation and for each child conference reservation. ..... If my understanding is correct, just resources on focus like conference identifier are allotaed when booking. If so, more clear description of resource management is poposed to be given. Thanks for your patience and regards, Tang Tingfang (Tagna) Huawei Technologies tagna_online@huawei.com tel: +8610 59722012 ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ****************************************************************************************** ----- Original Message ----- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: xcon@ietf.org Sent: Tuesday, August 07, 2007 4:15 AM Subject: [XCON] I-D ACTION:draft-ietf-xcon-framework-09.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : A Framework for Centralized Conferencing Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-framework-09.txt Pages : 63 Date : 2007-8-6 This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber, Q.931 or ISUP, to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions, along with a high level conferencing data model. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-xcon-framework-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-framework-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------------------------------------------------------------------------------ _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --Boundary_(ID_2ksYZtyfgHsiGd9pEn2Ymw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi ,Mary,Chris and Orit
 
In my understanding,  resources on media server are reserved when creates the reserved conferences, but not allocated.
The resources are allocated at the scheduled start time.
It will cause a huge waste of resources if allocation takes place when booking the reserved conference.
       
      But in section 6.3, the related description is:
 
     The selected blueprint with its default values is cloned by the
     client into a newly created conference object, referred to as a
     conference reservation, that specifies the resources needed from the
     system for this conference instance.  At this point the conference
     reservation becomes independent from its blueprint.  The client can
     also change the default values, within the system ranges, and add
     additional information, such as the list of participants and the
     conference start time, to the conference reservation.
     
     At this point the client can ask the conference server to create new
     conference reservations by attaching the conference reservation to
     the request.  As a result, the server can allocate the needed
     resources, create the additional conference objects for the child
     conference reservations and allocate the conference object
     identifiers for all - the original conference reservation and for
     each child conference reservation.
     .....
 
If my understanding is correct, just resources on focus like conference identifier are allotaed when booking.
If so, more clear description of resource management is poposed to be given.
 
 
Thanks for your patience and regards,
 
Tang Tingfang (Tagna)
Huawei Technologies
tagna_online@huawei.com <mailto:tagna_online@huawei.com>
tel: +8610 59722012
******************************************************************************************
This email and its attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address
is listed above. Any use of the information contained herein in any
way (including, but not limited to, total or partial disclosure,
reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error,
please notify the sender by phone or email immediately and delete it!
******************************************************************************************
----- Original Message -----
Sent: Tuesday, August 07, 2007 4:15 AM
Subject: [XCON] I-D ACTION:draft-ietf-xcon-framework-09.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Centralized Conferencing Working Group of the IETF.

Title : A Framework for Centralized Conferencing
Author(s) : M. Barnes, et al.
Filename : draft-ietf-xcon-framework-09.txt
Pages : 63
Date : 2007-8-6

This document defines the framework for Centralized Conferencing.
   The framework allows participants using various call signaling
   protocols, such as SIP, H.323, Jabber, Q.931 or ISUP, to exchange
   media in a centralized unicast conference.  The Centralized
   Conferencing Framework defines logical entities and naming

   conventions, along with a high level conferencing data model.  The
   framework also outlines a set of conferencing protocols, which are
   complementary to the call signaling protocols, for building advanced
   conferencing applications.  The framework binds all the defined
   components together for the benefit of builders of conferencing
   systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-09.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-ietf-xcon-framework-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-xcon-framework-09.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility.  To use this
feature, insert the command "ENCODING mime" before the "FILE"
command.  To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader.  Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon
--Boundary_(ID_2ksYZtyfgHsiGd9pEn2Ymw)-- --===============1090836873== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============1090836873==-- From xcon-bounces@ietf.org Mon Aug 20 11:52:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN9WE-0005W4-9N; Mon, 20 Aug 2007 11:50:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN9WD-0005Vz-HO for xcon@ietf.org; Mon, 20 Aug 2007 11:50:17 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN9WC-00031J-P1 for xcon@ietf.org; Mon, 20 Aug 2007 11:50:17 -0400 Received: from rly29b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly29b.srv.mailcontrol.com (MailControl) with ESMTP id l7KFnueF003122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Aug 2007 16:50:11 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly29b.srv.mailcontrol.com (MailControl) id l7KFn7Dh030885 for xcon@ietf.org; Mon, 20 Aug 2007 16:49:07 +0100 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly29b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id l7KFmX6G028050; Mon, 20 Aug 2007 16:49:06 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] Some Comments on conference reservation.//Re: [XCON] I-DACTION:draft-ietf-xcon-framework-09.txt Date: Mon, 20 Aug 2007 16:48:39 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Some Comments on conference reservation.//Re: [XCON] I-DACTION:draft-ietf-xcon-framework-09.txt Thread-Index: AcfjAdXhHkyY/2TYRt6QRqzaBbyIdAAPvbsg References: <013a01c7e301$5bbb4320$411c6e0a@china.huawei.com> From: "Chris Boulton" To: "tang" , X-Scanned-By: MailControl A-07-08-00 (www.mailcontrol.com) on 10.66.1.139 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a331e4a192f4d33f18e6f8376287cf6 Cc: XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0274695032==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0274695032== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E341.93BC0260" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E341.93BC0260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi ,Mary,Chris and Orit =20 In my understanding, resources on media server are reserved when creates the reserved conferences, but not allocated. The resources are allocated at the scheduled start time.=20 =20 [Chris Boulton] Media Sever resources and the decision on when and how to reserve them is way out of scope of this document and Work Group. =20 It will cause a huge waste of resources if allocation takes place when booking the reserved conference. =20=20=20=20=20=20=20=20 [Chris Boulton] Agreed - and this really is an implementation decision. =20 But in section 6.3, the related description is: =20 The selected blueprint with its default values is cloned by the client into a newly created conference object, referred to as a conference reservation, that specifies the resources needed from the system for this conference instance. At this point the conference reservation becomes independent from its blueprint. The client can also change the default values, within the system ranges, and add additional information, such as the list of participants and the conference start time, to the conference reservation. =20=20=20=20=20 [Chris Boulton] 'specifies the resources needed' not that they are actually reserved - this is again implementation specific. At this point the client can ask the conference server to create new conference reservations by attaching the conference reservation to the request. As a result, the server can allocate the needed resources, create the additional conference objects for the child conference reservations and allocate the conference object identifiers for all - the original conference reservation and for each child conference reservation. =20 [Chris Boulton] 'The server CAN allocate the needed resources' NOT 'The server MUST/WILL allocated the needed resources'.=20 =20=20=20=20 If my understanding is correct, just resources on focus like conference identifier are allotaed when booking. If so, more clear description of resource management is poposed to be given. =20 =20 =20 =20 Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribut= ion is strictly prohibited. If you are not the addressee, please notify th= e sender immediately and destroy all copies of this email. Ubiquity Softwar= e Corporation plc, a company registered under the laws of England and Wales= , Registration 2719723, registered offices at Eastern Business Park, Buildi= ng 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom. ------_=_NextPart_001_01C7E341.93BC0260 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi ,Mary,Chris and Orit

 

In my understanding,  resources on media server are reserved when creates the reserved conferences, but not allocated.

The resources are allocated at the scheduled start time.

 

[Chris Boulton] Media Sever resources and the decision on when and how to reserve them is way out of scope of this document and Work Group.

 

It will cause a huge waste of resources if allocation takes place when booking the reserved conference.

       

[Chris Boulton] Agreed – and this really is an implementation decision.

 

      But in section 6.3, = the related description is:

 

     The selected blueprint with its default values is cloned by the
     client into a newly created conference object, referred to= as a
     conference reservation, that specifies the resources needed from the
     system for this conference instance.  At this point the conference
     reservation becomes independent from its blueprint.  The client can
     also change the default values, within the system ranges, and add
     additional information, such as the list of participants and the
     conference start time, to the conference reservati= on.
     

[Chris Boulton] ‘specifies the resources needed= 217; not that they are actually reserved – this is again implementation specific.


     At this point the client can ask the conference se= rver to create new
     conference reservations by attaching the conference reservation to
     the request.  As a result, the server can al= locate the needed
     resources, create the additional conference objects for the chi= ld
     conference reservations and allocate the conference object
     identifiers for all - the original conference reservation and for
     each child conference reservation.

 

[Chris Boulton] ‘The server CAN allocate the needed resources’ NOT ‘The server MUST/WILL allocated the needed resou= rces’.

    

If my understanding is correct, just resources on focus = like conference identifier are allotaed when booking.

If so, more clear description of resource management is poposed to be given.

 

 

 

 



Information contained in this e-mail and any attachments are intended fo= r the use of the addressee only, and may contain confidential information o= f Ubiquity Software Corporation. All unauthorized use, disclosure or distri= bution is strictly prohibited. If you are not the addressee, please notify = the sender immediately and destroy all copies of this email. Ubiquity Softw= are Corporation plc, a company registered under the laws of England and Wal= es, Registration 2719723, registered offices at Eastern Business Park, Buil= ding 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom= .

 ------_=_NextPart_001_01C7E341.93BC0260-- --===============0274695032== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0274695032==-- From xcon-bounces@ietf.org Mon Aug 20 13:19:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INAtK-0006Ck-V7; Mon, 20 Aug 2007 13:18:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INAtJ-0006CA-5Y; Mon, 20 Aug 2007 13:18:13 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INAtI-0003Kb-IZ; Mon, 20 Aug 2007 13:18:13 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l7KHI8Po025953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2007 12:18:09 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46C9CCD9.7080002@nostrum.com> Date: Mon, 20 Aug 2007 12:18:17 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= References: <46BFEA480017EF5C@pne-smtpout1-sn2.hy.skanova.net> (added by postmaster@pne.skanova.net) In-Reply-To: <46BFEA480017EF5C@pne-smtpout1-sn2.hy.skanova.net> (added by postmaster@pne.skanova.net) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.1/4011/Mon Aug 20 07:21:32 2007 on shaman.nostrum.com X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by nostrum.com id l7KHI8Po025953 X-Spam-Score: -1.4 (-) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: 'XCON-IETF' , simple@ietf.org Subject: [XCON] Re: [Simple] Chatroom Gap Analysis - Media and mode aspects X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org On 8/17/07 10:37 PM, Gunnar Hellstr=F6m wrote: > Questions: > > 1. In your analysis of existing chat-room applications, have you found = more > orderly support for audio, video and images in addition to the default > support for text? > =20 Not so much -- pretty much anything that isn't text tends to result in=20 some variation on a dialog box popping up asking where you want to save=20 the content. MSRP actually does a bit better (in theory, at least),=20 since you can specify an "inline" disposition for (e.g.) images, which=20 *should* cause clients to render the image in the chat window instead of=20 saving it to disk. Exactly how this ends up being implemented is yet to be seen. > 2. Have you found planned support for text messages in other writing sy= stems > than left-to right? > =20 To the same degree as we have support in XMPP/SIMPLE -- the use of=20 UTF-8, in theory, provides all the support necessary for RTL text. In=20 practice, what different clients do when they see an RTL mark varies=20 widely and is often inexplicable. That is: the protocol gets this right, but implementors do random things. > 3. Have you found support for the media to be transmitted and displayed= in > real-time as they are created? > =20 Not in chatroom scenarios, no -- at least, not since ytalk. Do you know=20 of a modern chatroom system that supports this? That said, there's nothing stopping clients from setting up RFC 4103=20 streams towards a mixer -- the tricky part is rendering such mixed=20 streams in a coherent fashion. > 4. Have you found support for ordered transition between message mode a= nd > real time mode? > =20 Not in existing systems, no. All four items you mention above appear to be supported by IETF=20 protocols, although it may not be immediately clear to implementors how=20 a user interface might present them -- perhaps there's room for a=20 document that address, in particular, the interaction of real-time text=20 with multi-user conferences. A "best current practice" of sorts. Is that=20 something you might be interested in tackling? /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Aug 20 21:15:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INIJ2-00044w-W0; Mon, 20 Aug 2007 21:13:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INIJ1-00044l-Bc for xcon@ietf.org; Mon, 20 Aug 2007 21:13:15 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INIIx-0008K8-MS for xcon@ietf.org; Mon, 20 Aug 2007 21:13:15 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JN300E52NCRJH@szxga03-in.huawei.com> for xcon@ietf.org; Tue, 21 Aug 2007 09:12:27 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JN300B8HNCJ7G@szxga03-in.huawei.com> for xcon@ietf.org; Tue, 21 Aug 2007 09:12:27 +0800 (CST) Received: from t39207 ([10.110.28.65]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JN300LB4NCIIV@szxml04-in.huawei.com> for xcon@ietf.org; Tue, 21 Aug 2007 09:12:19 +0800 (CST) Date: Tue, 21 Aug 2007 09:12:18 +0800 From: tang Subject: Re: [XCON] Some Comments on conference reservation.//Re: [XCON] I-DACTION:draft-ietf-xcon-framework-09.txt To: Chris Boulton , mary.barnes@nortel.com Message-id: <008301c7e390$51aee280$411c6e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <013a01c7e301$5bbb4320$411c6e0a@china.huawei.com> X-Spam-Score: 3.4 (+++) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Cc: XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0830060214==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0830060214== Content-type: multipart/alternative; boundary="Boundary_(ID_Oz049zTVsHVJ3lZKNM785A)" This is a multi-part message in MIME format. --Boundary_(ID_Oz049zTVsHVJ3lZKNM785A) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT OK Chris. I can't find anything to argue with in your response. Thanks for you patience and regards, Tang Tingfang (Tagna) Huawei Technologies tagna_online@huawei.com tel: +8610 59722012 ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ****************************************************************************************** ----- Original Message ----- From: Chris Boulton To: tang ; mary.barnes@nortel.com Cc: XCON-IETF Sent: Monday, August 20, 2007 11:48 PM Subject: RE: [XCON] Some Comments on conference reservation.//Re: [XCON] I-DACTION:draft-ietf-xcon-framework-09.txt Hi ,Mary,Chris and Orit In my understanding, resources on media server are reserved when creates the reserved conferences, but not allocated. The resources are allocated at the scheduled start time. [Chris Boulton] Media Sever resources and the decision on when and how to reserve them is way out of scope of this document and Work Group. It will cause a huge waste of resources if allocation takes place when booking the reserved conference. [Chris Boulton] Agreed - and this really is an implementation decision. But in section 6.3, the related description is: The selected blueprint with its default values is cloned by the client into a newly created conference object, referred to as a conference reservation, that specifies the resources needed from the system for this conference instance. At this point the conference reservation becomes independent from its blueprint. The client can also change the default values, within the system ranges, and add additional information, such as the list of participants and the conference start time, to the conference reservation. [Chris Boulton] 'specifies the resources needed' not that they are actually reserved - this is again implementation specific. At this point the client can ask the conference server to create new conference reservations by attaching the conference reservation to the request. As a result, the server can allocate the needed resources, create the additional conference objects for the child conference reservations and allocate the conference object identifiers for all - the original conference reservation and for each child conference reservation. [Chris Boulton] 'The server CAN allocate the needed resources' NOT 'The server MUST/WILL allocated the needed resources'. If my understanding is correct, just resources on focus like conference identifier are allotaed when booking. If so, more clear description of resource management is poposed to be given. Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Ubiquity Software Corporation plc, a company registered under the laws of England and Wales, Registration 2719723, registered offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom. --Boundary_(ID_Oz049zTVsHVJ3lZKNM785A) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjkwMC4zMTMyIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglm b250LWZhbWlseTogU2ltU3VuOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEBTaW1T dW47DQp9DQpAcGFnZSBTZWN0aW9uMSB7c2l6ZTogNjEyLjBwdCA3OTIuMHB0OyBtYXJnaW46IDcy LjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCUZPTlQtU0laRTog MTJwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4i DQp9DQpMSS5Nc29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lOOiAwY20gMGNtIDBw dDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iDQp9DQpESVYuTXNvTm9ybWFsIHsNCglG T05ULVNJWkU6IDEycHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMg TmV3IFJvbWFuIg0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1 bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNP UkFUSU9OOiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVD T1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xP UjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClAgew0KCUZPTlQtU0laRTog MTJwdDsgTUFSR0lOLUxFRlQ6IDBjbTsgTUFSR0lOLVJJR0hUOiAwY207IEZPTlQtRkFNSUxZOiAi VGltZXMgTmV3IFJvbWFuIg0KfQ0KU1BBTi5FbWFpbFN0eWxlMjAgew0KCUNPTE9SOiBuYXZ5OyBG T05ULUZBTUlMWTogQXJpYWwNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjENCn0N CjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9EWSBsYW5nPUVOLVVTIHZMaW5rPWJsdWUgbGluaz1ibHVl IGJnQ29sb3I9d2hpdGU+DQo8RElWPk9LIENocmlzLiBJIGNhbid0IGZpbmQgYW55dGhpbmcgdG8g YXJndWUgd2l0aCBpbiB5b3VyIHJlc3BvbnNlLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+VGhhbmtzIGZvciB5b3UgcGF0aWVuY2UgYW5kIHJlZ2FyZHMsPC9ESVY+DQo8RElWPjxGT05U IGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj5U YW5nIFRpbmdmYW5nIChUYWduYSk8QlI+SHVhd2VpIFRlY2hub2xvZ2llczxCUj48QSANCmhyZWY9 Im1haWx0bzp0YWduYV9vbmxpbmVAaHVhd2VpLmNvbSI+dGFnbmFfb25saW5lQGh1YXdlaS5jb208 L0E+ICZsdDs8QSANCmhyZWY9Im1haWx0bzp0YWduYV9vbmxpbmVAaHVhd2VpLmNvbSI+bWFpbHRv OnRhZ25hX29ubGluZUBodWF3ZWkuY29tPC9BPiZndDs8QlI+dGVsOiANCis4NjEwIA0KNTk3MjIw MTI8QlI+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPEJSPlRoaXMgDQplbWFpbCBh bmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb208 QlI+SFVBV0VJLCB3aGljaCANCmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50 aXR5IHdob3NlIGFkZHJlc3M8QlI+aXMgbGlzdGVkIGFib3ZlLiBBbnkgDQp1c2Ugb2YgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55PEJSPndheSAoaW5jbHVkaW5nLCBidXQg bm90IA0KbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbCBkaXNjbG9zdXJlLDxCUj5yZXByb2R1 Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IA0KcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRl bmRlZDxCUj5yZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgDQp0aGlz IGUtbWFpbCBpbiBlcnJvciw8QlI+cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHBob25lIG9y IGVtYWlsIGltbWVkaWF0ZWx5IA0KYW5kIGRlbGV0ZSANCml0ITxCUj4qKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKio8L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFE RElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9S REVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYg c3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiA5 cHQgJiMyMzQzNTsmIzIwMzA3OzsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAg PEEgdGl0bGU9Y2JvdWx0b25AdWJpcXVpdHkubmV0IGhyZWY9Im1haWx0bzpjYm91bHRvbkB1Ymlx dWl0eS5uZXQiPkNocmlzIA0KICBCb3VsdG9uPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9O VDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlRvOjwvQj4gPEEgdGl0bGU9dGFnbmFfb25saW5l QGh1YXdlaS5jb20gDQogIGhyZWY9Im1haWx0bzp0YWduYV9vbmxpbmVAaHVhd2VpLmNvbSI+dGFu ZzwvQT4gOyA8QSANCiAgdGl0bGU9bWFyeS5iYXJuZXNAbm9ydGVsLmNvbSANCiAgaHJlZj0ibWFp bHRvOm1hcnkuYmFybmVzQG5vcnRlbC5jb20iPm1hcnkuYmFybmVzQG5vcnRlbC5jb208L0E+IDwv RElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+Q2M6PC9C PiA8QSB0aXRsZT14Y29uQGlldGYub3JnIA0KICBocmVmPSJtYWlsdG86eGNvbkBpZXRmLm9yZyI+ WENPTi1JRVRGPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMy MDMwNzsiPjxCPlNlbnQ6PC9CPiBNb25kYXksIEF1Z3VzdCAyMCwgMjAwNyAxMTo0OCBQTTwvRElW Pg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U3ViamVjdDo8 L0I+IFJFOiBbWENPTl0gU29tZSBDb21tZW50cyBvbiANCiAgY29uZmVyZW5jZSByZXNlcnZhdGlv bi4vL1JlOiBbWENPTl0gDQogIEktREFDVElPTjpkcmFmdC1pZXRmLXhjb24tZnJhbWV3b3JrLTA5 LnR4dDwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJViBjbGFzcz1TZWN0aW9uMT4NCiAg PERJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwi PkhpICxNYXJ5LENocmlzIGFuZCANCiAgT3JpdDwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8 RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBz aXplPTM+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjwvU1BBTj48L0ZPTlQ+Jm5i c3A7PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBBcmlhbCI+SW4gbXkgDQogIHVuZGVyc3RhbmRpbmcsJm5ic3A7Jm5ic3A7cmVzb3VyY2VzIG9u IG1lZGlhIHNlcnZlciBhcmUgcmVzZXJ2ZWQgd2hlbiBjcmVhdGVzIA0KICB0aGUgcmVzZXJ2ZWQg Y29uZmVyZW5jZXMsIGJ1dCBub3QgYWxsb2NhdGVkLjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0K ICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQ QU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+VGhlIHJl c291cmNlcyBhcmUgYWxsb2NhdGVkIGF0IA0KICB0aGUmbmJzcDtzY2hlZHVsZWQgc3RhcnQgdGlt ZS4gPC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Qj48ST48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6 IGJvbGQ7IEZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtU1RZTEU6IGl0YWxpYzsg Rk9OVC1GQU1JTFk6IEFyaWFsIj48L1NQQU4+PC9GT05UPjwvST48L0I+Jm5ic3A7PC9QPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWw+PEI+PEk+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9 Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkOyBGT05ULVNJWkU6IDEwcHQ7IENP TE9SOiBuYXZ5OyBGT05ULVNUWUxFOiBpdGFsaWM7IEZPTlQtRkFNSUxZOiBBcmlhbCI+W0Nocmlz IA0KICBCb3VsdG9uXSBNZWRpYSBTZXZlciByZXNvdXJjZXMgYW5kIHRoZSBkZWNpc2lvbiBvbiB3 aGVuIGFuZCBob3cgdG8gcmVzZXJ2ZSANCiAgdGhlbSBpcyB3YXkgb3V0IG9mIHNjb3BlIG9mIHRo aXMgZG9jdW1lbnQgYW5kIFdvcmsgDQogIEdyb3VwLjwvU1BBTj48L0ZPTlQ+PC9JPjwvQj48L1A+ DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0y PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1J TFk6IEFyaWFsIj48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPkl0IHdpbGwgY2F1c2UgYSBodWdl IHdhc3RlIG9mIA0KICByZXNvdXJjZXMgaWYgYWxsb2NhdGlvbiZuYnNwO3Rha2VzIHBsYWNlJm5i c3A7d2hlbiBib29raW5nIHRoZSByZXNlcnZlZCANCiAgY29uZmVyZW5jZS48L1NQQU4+PC9GT05U PjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog QXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9T UEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Qj48ST48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7 IEZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtU1RZTEU6IGl0YWxpYzsgRk9OVC1G QU1JTFk6IEFyaWFsIj5bQ2hyaXMgDQogIEJvdWx0b25dIEFncmVlZCCWIGFuZCB0aGlzIHJlYWxs eSBpcyBhbiBpbXBsZW1lbnRhdGlvbiANCiAgZGVjaXNpb24uPC9TUEFOPjwvRk9OVD48L0k+PC9C PjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBz aXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05U LUZBTUlMWTogQXJpYWwiPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPjwvRElWPg0KICA8RElWPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QnV0IA0KICBpbiBzZWN0aW9uIDYuMywgdGhlIHJlbGF0ZWQg ZGVzY3JpcHRpb24gaXM6PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNs YXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiAN CiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+PC9ESVY+ DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48 U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj4mbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7VGhlIA0KICBzZWxlY3RlZCBibHVlcHJpbnQgd2l0aCBpdHMg ZGVmYXVsdCB2YWx1ZXMgaXMgY2xvbmVkIGJ5IHRoZTxCUj4mbmJzcDsmbmJzcDsgDQogICZuYnNw OyZuYnNwO2NsaWVudCBpbnRvIGEgbmV3bHkgY3JlYXRlZCBjb25mZXJlbmNlIG9iamVjdCwgPEVN PjxCPjxJPjxGT05UIA0KICBmYWNlPUFyaWFsPjxTUEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9s ZDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5yZWZlcnJlZCB0byBhcyANCiAgYTwvU1BBTj48L0ZPTlQ+ PC9JPjwvQj48L0VNPjxCPjxJPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZP TlQtU1RZTEU6IGl0YWxpYyI+PEJSPjxFTT48ST48Rk9OVCANCiAgZmFjZT1BcmlhbD48U1BBTiBz dHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsIj4mbmJzcDsmbmJzcDsgDQogICZuYnNwOyZuYnNwO2Nv bmZlcmVuY2UgcmVzZXJ2YXRpb24sIHRoYXQgc3BlY2lmaWVzIHRoZSByZXNvdXJjZXMgbmVlZGVk IGZyb20gDQogIHRoZTwvU1BBTj48L0ZPTlQ+PC9JPjwvRU0+PEJSPjxFTT48ST48Rk9OVCBmYWNl PUFyaWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsIj4mbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7c3lzdGVtIGZvciB0aGlzIGNvbmZlcmVuY2UgDQogIGluc3RhbmNlLiZuYnNw OyA8L1NQQU4+PC9GT05UPjwvST48L0VNPjwvU1BBTj48L0k+PC9CPkF0IHRoaXMgcG9pbnQgdGhl IA0KICBjb25mZXJlbmNlPEJSPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDtyZXNlcnZhdGlvbiBi ZWNvbWVzIGluZGVwZW5kZW50IGZyb20gDQogIGl0cyBibHVlcHJpbnQuJm5ic3A7IFRoZSBjbGll bnQgY2FuPEJSPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDthbHNvIGNoYW5nZSANCiAgdGhlIGRl ZmF1bHQgdmFsdWVzLCB3aXRoaW4gdGhlIHN5c3RlbSByYW5nZXMsIGFuZCBhZGQ8QlI+Jm5ic3A7 Jm5ic3A7IA0KICAmbmJzcDsmbmJzcDthZGRpdGlvbmFsIGluZm9ybWF0aW9uLCBzdWNoIGFzIHRo ZSBsaXN0IG9mIHBhcnRpY2lwYW50cyBhbmQgDQogIHRoZTxCUj4mbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7Y29uZmVyZW5jZSBzdGFydCB0aW1lLCB0byB0aGUgY29uZmVyZW5jZSANCiAgcmVzZXJ2 YXRpb24uPEJSPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDs8L1NQQU4+PC9GT05UPjwvUD4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxJPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXpl PTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiAxMHB0OyBD T0xPUjogbmF2eTsgRk9OVC1TVFlMRTogaXRhbGljOyBGT05ULUZBTUlMWTogQXJpYWwiPltDaHJp cyANCiAgQm91bHRvbl0gkXNwZWNpZmllcyB0aGUgcmVzb3VyY2VzIG5lZWRlZJIgbm90IHRoYXQg dGhleSBhcmUgYWN0dWFsbHkgcmVzZXJ2ZWQgDQogIJYgdGhpcyBpcyBhZ2FpbiBpbXBsZW1lbnRh dGlvbiBzcGVjaWZpYy48L1NQQU4+PC9GT05UPjwvST48L0I+PC9QPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PEJSPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDtB dCANCiAgdGhpcyBwb2ludCB0aGUgY2xpZW50IGNhbiBhc2sgdGhlIGNvbmZlcmVuY2Ugc2VydmVy IHRvIGNyZWF0ZSANCiAgbmV3PEJSPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDtjb25mZXJlbmNl IHJlc2VydmF0aW9ucyBieSBhdHRhY2hpbmcgdGhlIA0KICBjb25mZXJlbmNlIHJlc2VydmF0aW9u IHRvPEJSPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDt0aGUgcmVxdWVzdC4mbmJzcDsgDQogIDxF TT48Qj48ST48Rk9OVCBmYWNlPUFyaWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJv bGQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+QXMgYSByZXN1bHQsIHRoZSBzZXJ2ZXIgY2FuIA0KICBh bGxvY2F0ZSB0aGUgbmVlZGVkPC9TUEFOPjwvRk9OVD48L0k+PC9CPjwvRU0+PEI+PEk+PFNQQU4g DQogIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1TVFlMRTogaXRhbGljIj48QlI+PEVN PjxJPjxGT05UIA0KICBmYWNlPUFyaWFsPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogQXJpYWwi PiZuYnNwOyZuYnNwOyANCiAgJm5ic3A7Jm5ic3A7cmVzb3VyY2VzLCBjcmVhdGUgdGhlIGFkZGl0 aW9uYWwgY29uZmVyZW5jZSBvYmplY3RzIGZvciB0aGUgDQogIGNoaWxkPC9TUEFOPjwvRk9OVD48 L0k+PC9FTT48QlI+PEVNPjxJPjxGT05UIGZhY2U9QXJpYWw+PFNQQU4gDQogIHN0eWxlPSJGT05U LUZBTUlMWTogQXJpYWwiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDtjb25mZXJlbmNlIHJlc2Vy dmF0aW9ucyANCiAgYW5kIGFsbG9jYXRlIHRoZSBjb25mZXJlbmNlIG9iamVjdDwvU1BBTj48L0ZP TlQ+PC9JPjwvRU0+PEJSPjxFTT48ST48Rk9OVCANCiAgZmFjZT1BcmlhbD48U1BBTiBzdHlsZT0i Rk9OVC1GQU1JTFk6IEFyaWFsIj4mbmJzcDsmbmJzcDsgDQogICZuYnNwOyZuYnNwO2lkZW50aWZp ZXJzIGZvciBhbGwgPC9TUEFOPjwvRk9OVD48L0k+PC9FTT48L1NQQU4+PC9JPjwvQj4tIHRoZSAN CiAgb3JpZ2luYWwgY29uZmVyZW5jZSByZXNlcnZhdGlvbiBhbmQgZm9yPEJSPiZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDtlYWNoIGNoaWxkIA0KICBjb25mZXJlbmNlIHJlc2VydmF0aW9uLjwvU1BB Tj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PC9TUEFOPjwvRk9OVD4mbmJz cDs8L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Qj48ST48Rk9OVCBmYWNlPUFyaWFsIGNvbG9y PW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0la RTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtU1RZTEU6IGl0YWxpYzsgRk9OVC1GQU1JTFk6IEFy aWFsIj5bQ2hyaXMgDQogIEJvdWx0b25dIJFUaGUgc2VydmVyIENBTiBhbGxvY2F0ZSB0aGUgbmVl ZGVkIHJlc291cmNlc5IgTk9UIJFUaGUgc2VydmVyIA0KICBNVVNUL1dJTEwgYWxsb2NhdGVkIHRo ZSBuZWVkZWQgcmVzb3VyY2Vzki4gPC9TUEFOPjwvRk9OVD48L0k+PC9CPjwvUD4NCiAgPFAgY2xh c3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IEZPTlQtRkFNSUxZOiBBcmlhbCI+SWYgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCANCiAg anVzdCByZXNvdXJjZXMgb24gZm9jdXMgbGlrZSBjb25mZXJlbmNlIGlkZW50aWZpZXIgYXJlIGFs bG90YWVkIHdoZW4gDQogIGJvb2tpbmcuPC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogIDxESVY+ DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5JZiBzbywgbW9yZSBj bGVhciBkZXNjcmlwdGlvbiBvZiANCiAgcmVzb3VyY2UgbWFuYWdlbWVudCBpcyBwb3Bvc2VkIHRv IGJlIGdpdmVuLjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1N c29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEycHQiPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPg0KICA8UCBjbGFz cz1Nc29Ob3JtYWw+PEI+PEk+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BB TiANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkOyBGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBu YXZ5OyBGT05ULVNUWUxFOiBpdGFsaWM7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PC9TUEFOPjwvRk9O VD48L0k+PC9CPiZuYnNwOzwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxJPjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVdFSUdIVDog Ym9sZDsgRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1TVFlMRTogaXRhbGljOyBG T05ULUZBTUlMWTogQXJpYWwiPjwvU1BBTj48L0ZPTlQ+PC9JPjwvQj4mbmJzcDs8L1A+DQogIDxQ IGNsYXNzPU1zb05vcm1hbD48Qj48ST48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0y PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogMTBwdDsgQ09M T1I6IG5hdnk7IEZPTlQtU1RZTEU6IGl0YWxpYzsgRk9OVC1GQU1JTFk6IEFyaWFsIj48L1NQQU4+ PC9GT05UPjwvST48L0I+Jm5ic3A7PC9QPjwvRElWPjwvRElWPjwvRElWPjxCUj48QlI+PEZPTlQg DQogIGZhY2U9VmVyZGFuYSBzaXplPTEgY29sb3VyPSIjY2NjY2NjIj48Rk9OVCBzaXplPTI+DQog IDxQPkluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIGFyZSBpbnRlbmRlZCBmb3IgDQogIHRoZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZSBvbmx5LCBh bmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIG9mIA0KICBVYmlxdWl0eSBT b2Z0d2FyZSBDb3Jwb3JhdGlvbi4gQWxsIHVuYXV0aG9yaXplZCB1c2UsIGRpc2Nsb3N1cmUgb3Ig DQogIGRpc3RyaWJ1dGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgYWRkcmVzc2VlLCBwbGVhc2UgDQogIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFu ZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhpcyBlbWFpbC4gVWJpcXVpdHkgDQogIFNvZnR3YXJl IENvcnBvcmF0aW9uIHBsYywgYSBjb21wYW55IHJlZ2lzdGVyZWQgdW5kZXIgdGhlIGxhd3Mgb2Yg RW5nbGFuZCBhbmQgDQogIFdhbGVzLCBSZWdpc3RyYXRpb24gMjcxOTcyMywgcmVnaXN0ZXJlZCBv ZmZpY2VzIGF0IEVhc3Rlcm4gQnVzaW5lc3MgUGFyaywgDQogIEJ1aWxkaW5nIDMsIFdlcm4gRmF3 ciBMYW5lLCBTdC4gTWVsbG9ucywgQ2FyZGlmZiBDRjMgNUVBLCBXYWxlcywgVW5pdGVkIA0KICBL aW5nZG9tLjwvUD48L0JMT0NLUVVPVEU+PC9GT05UPjwvRk9OVD48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_Oz049zTVsHVJ3lZKNM785A)-- --===============0830060214== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0830060214==-- From xcon-bounces@ietf.org Tue Aug 21 01:03:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INLsV-00067h-JO; Tue, 21 Aug 2007 01:02:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INLsT-00067I-Kv; Tue, 21 Aug 2007 01:02:05 -0400 Received: from pne-smtpout1-sn1.fre.skanova.net ([81.228.11.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INLsS-0003sA-5m; Tue, 21 Aug 2007 01:02:05 -0400 Received: from GunnarH (213.64.232.214) by pne-smtpout1-sn1.fre.skanova.net (7.2.076.2) id 46BB50DE002DA78F; Tue, 21 Aug 2007 07:01:56 +0200 Message-ID: <46BB50DE002DA78F@pne-smtpout1-sn1.fre.skanova.net> (added by postmaster@pne.skanova.net) From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "'Adam Roach'" Date: Tue, 21 Aug 2007 07:01:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <46C9CCD9.7080002@nostrum.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcfjTkDz6kiOZausS6qpAOE9qCLFfQAXoTQg X-Spam-Score: -1.0 (-) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: 'XCON-IETF' , simple@ietf.org Subject: [XCON] RE: [Simple] Chatroom Gap Analysis - Media and mode aspects X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Adam, You say "All four items you mention above appear to be supported by IETF = protocols, although it may not be immediately clear to implementors how a user interface might present them -- perhaps there's room for a document that address, in particular, the interaction of real-time text with = multi-user conferences. A "best current practice" of sorts. Is that something you = might be interested in tackling?" I have started on a document in that direction.=20 See:=20 http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-01.txt It describes a way to present real-time text that feels very familiar = for the IM and chatroom user. It just adds the opportunity to see the = entries from selected parties in the session while they are created. It says that RFC 4103 would be the natural transport protocol for the = text, while also MSRP would be suitable if you take care to not transmit more = than at most once per second from parties actively composing entries.=20 You are right in that real-time text mixer for multi-user conferences = may need further elaboration. Especially the requirement to allow remote = erasure of already transmitted text is a challenge for a real-time text mixer. Do you see XCON or SIMPLE to be a suitable group for further work on = this draft? ---- My question had not only real-time text background. I am equally = interested in for example seeing good support for video in chat rooms, where the = video entries are not seen just as attachments to the text entry, but are = handled with full support for easy recording, entry and display in the chatroom. = So, I would appreciate if you could expand the media section a bit with more = on planned handling of multimedia contents.=20 -Gunnar -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Monday, August 20, 2007 7:18 PM To: Gunnar Hellstr=F6m Cc: 'XCON-IETF'; simple@ietf.org Subject: Re: [Simple] Chatroom Gap Analysis - Media and mode aspects On 8/17/07 10:37 PM, Gunnar Hellstr=F6m wrote: > Questions: > > 1. In your analysis of existing chat-room applications, have you found = > more orderly support for audio, video and images in addition to the=20 > default support for text? > =20 Not so much -- pretty much anything that isn't text tends to result in = some variation on a dialog box popping up asking where you want to save the content. MSRP actually does a bit better (in theory, at least), since = you can specify an "inline" disposition for (e.g.) images, which *should* cause clients to render the image in the chat window instead of saving it to disk. Exactly how this ends up being implemented is yet to be seen. > 2. Have you found planned support for text messages in other writing=20 > systems than left-to right? > =20 To the same degree as we have support in XMPP/SIMPLE -- the use of = UTF-8, in theory, provides all the support necessary for RTL text. In practice, = what different clients do when they see an RTL mark varies widely and is = often inexplicable. That is: the protocol gets this right, but implementors do random = things. > 3. Have you found support for the media to be transmitted and=20 > displayed in real-time as they are created? > =20 Not in chatroom scenarios, no -- at least, not since ytalk. Do you know = of a modern chatroom system that supports this? That said, there's nothing stopping clients from setting up RFC 4103 = streams towards a mixer -- the tricky part is rendering such mixed streams in a coherent fashion. > 4. Have you found support for ordered transition between message mode=20 > and real time mode? > =20 Not in existing systems, no. All four items you mention above appear to be supported by IETF = protocols, although it may not be immediately clear to implementors how a user interface might present them -- perhaps there's room for a document that address, in particular, the interaction of real-time text with = multi-user conferences. A "best current practice" of sorts. Is that something you = might be interested in tackling? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple __________ NOD32 2470 (20070819) Information __________ Detta meddelande =E4r genoms=F6kt av NOD32 Antivirus. http://www.nod32.com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Aug 21 11:35:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INVjN-0004yt-Ah; Tue, 21 Aug 2007 11:33:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INVjL-0004xy-4r; Tue, 21 Aug 2007 11:33:19 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INVjJ-0005rj-QR; Tue, 21 Aug 2007 11:33:19 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l7LFXBui096148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 10:33:12 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46CB05C3.5030909@nostrum.com> Date: Tue, 21 Aug 2007 10:33:23 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= References: <46BB50DE002DA78F@pne-smtpout1-sn1.fre.skanova.net> (added by postmaster@pne.skanova.net) In-Reply-To: <46BB50DE002DA78F@pne-smtpout1-sn1.fre.skanova.net> (added by postmaster@pne.skanova.net) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.1/4019/Tue Aug 21 06:37:05 2007 on shaman.nostrum.com X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by nostrum.com id l7LFXBui096148 X-Spam-Score: -1.4 (-) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'XCON-IETF' , simple@ietf.org Subject: [XCON] Re: [Simple] Chatroom Gap Analysis - Media and mode aspects X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org On 8/21/07 12:01 AM, Gunnar Hellstr=F6m wrote: > You are right in that real-time text mixer for multi-user conferences m= ay > need further elaboration. Especially the requirement to allow remote er= asure > of already transmitted text is a challenge for a real-time text mixer. > > Do you see XCON or SIMPLE to be a suitable group for further work on th= is > draft? > =20 The draft you currently have isn't conference specific -- it seems aimed=20 at one-to-one chat sessions. Between the two groups, I'd say SIMPLE is=20 the more appropriate, if you want to drive it through a working group. As a personal observation, this kind of work has generally received low=20 participation in SIMPLE, so you might be able to save yourself some=20 process overhead by publishing it as informational. I would contact the=20 RAI ADs for advice on the topic, though. > My question had not only real-time text background. I am equally intere= sted > in for example seeing good support for video in chat rooms, where the v= ideo > entries are not seen just as attachments to the text entry, but are han= dled > with full support for easy recording, entry and display in the chatroom= . So, > I would appreciate if you could expand the media section a bit with mor= e on > planned handling of multimedia contents.=20 > =20 What I think I hear you describing isn't as much "video in a chatroom"=20 as it is "multimodal conferencing", where the modes include (1) a text=20 chatroom, and (2) a video RTP stream. Correct me if that's not what you=20 mean. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Aug 21 14:35:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INYY8-0002Nf-TW; Tue, 21 Aug 2007 14:33:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INYY6-0002NE-JT; Tue, 21 Aug 2007 14:33:54 -0400 Received: from pne-smtpout2-sn2.hy.skanova.net ([81.228.8.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INYY5-0008C5-Tp; Tue, 21 Aug 2007 14:33:54 -0400 Received: from GunnarH (213.64.232.214) by pne-smtpout2-sn2.hy.skanova.net (7.2.075) id 46245DE101DDE54C; Tue, 21 Aug 2007 20:33:44 +0200 Message-ID: <46245DE101DDE54C@pne-smtpout2-sn2.hy.skanova.net> (added by postmaster@pne.skanova.net) From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "'Adam Roach'" Date: Tue, 21 Aug 2007 20:33:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <46CB05C3.5030909@nostrum.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcfkCJq4j5nYR/e0T9O9e+JAUv1VJQAEhyKA X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: 'XCON-IETF' , simple@ietf.org Subject: [XCON] RE: [Simple] Chatroom Gap Analysis - Media and mode aspects X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Adam, You say: "What I think I hear you describing isn't as much "video in a chatroom"=20 as it is "multimodal conferencing", where the modes include (1) a text chatroom, and (2) a video RTP stream. Correct me if that's not what you mean."=20 No, I mean well integrated multimedia chat-rooms, where for example = video entries may come up as for example a thumbnail picture that strts to = play when you click on it. Text and audio and images belonging to such = entries are also displayed, on request. About the draft-hellstrom-text-preview, you say: "The draft you currently have isn't conference specific -- it seems = aimed at one-to-one chat sessions. Between the two groups, I'd say SIMPLE is the = more appropriate, if you want to drive it through a working group." It talks about hiding and displaying preview from different = participants, and labelling entries depending on the source etc. So, it is = definitively aiming at the multi-participant situation, with the minimum number of participants being two.=20 With this real-time preview, the border between a real-time conference = and a chat-room is disappearing. . Another item: I also have experienced that some chat roomms may have one audio stream playing in order to present an attractive environment for the room. The = same could be defined for video and text. Gunnar -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Tuesday, August 21, 2007 5:33 PM To: Gunnar Hellstr=F6m Cc: 'XCON-IETF'; simple@ietf.org Subject: Re: [Simple] Chatroom Gap Analysis - Media and mode aspects On 8/21/07 12:01 AM, Gunnar Hellstr=F6m wrote: > You are right in that real-time text mixer for multi-user conferences=20 > may need further elaboration. Especially the requirement to allow=20 > remote erasure of already transmitted text is a challenge for a = real-time text mixer. > > Do you see XCON or SIMPLE to be a suitable group for further work on=20 > this draft? > =20 The draft you currently have isn't conference specific -- it seems aimed = at one-to-one chat sessions. Between the two groups, I'd say SIMPLE is the = more appropriate, if you want to drive it through a working group. As a personal observation, this kind of work has generally received low participation in SIMPLE, so you might be able to save yourself some = process overhead by publishing it as informational. I would contact the RAI ADs = for advice on the topic, though. > My question had not only real-time text background. I am equally=20 > interested in for example seeing good support for video in chat rooms, = > where the video entries are not seen just as attachments to the text=20 > entry, but are handled with full support for easy recording, entry and = > display in the chatroom. So, I would appreciate if you could expand=20 > the media section a bit with more on planned handling of multimedia contents. > =20 What I think I hear you describing isn't as much "video in a chatroom"=20 as it is "multimodal conferencing", where the modes include (1) a text chatroom, and (2) a video RTP stream. Correct me if that's not what you mean. /a __________ NOD32 2472 (20070821) Information __________ Detta meddelande =E4r genoms=F6kt av NOD32 Antivirus. http://www.nod32.com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Aug 27 14:18:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPj91-0001ax-86; Mon, 27 Aug 2007 14:16:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPj90-0001ZX-2G for xcon@ietf.org; Mon, 27 Aug 2007 14:16:58 -0400 Received: from estacado-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:266::2] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPj8y-0000YO-N2 for xcon@ietf.org; Mon, 27 Aug 2007 14:16:58 -0400 Received: from orthrus.local ([172.17.1.56]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l7RIGlSt031839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2007 13:16:48 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <46D31510.2000807@estacado.net> Date: Mon, 27 Aug 2007 13:16:48 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: XCON-IETF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Cullen Jennings , Alan Johnston Subject: [XCON] XCON Common Data Model/Event Package MIME Type X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org [as chair] As a follow-up to the MIME-type discussions we had in Chicago, I have spoken with Ted Hardie (Apps area AD) regarding an appropriate MIME type to use for our extended data format. His advice was to choose an entirely new MIME type; the deciding factor in doing this (as opposed to attempting to, for example, use a versioning mechanism) is the transition from schema to relax for the XML schema definition. His explanation included the observation that, while it is theoretically possible to make a perfect conversion from schema to relax, the chances of making a mistake in doing so are not zero; consequently, the transition to a new definition syntax makes the use of a new MIME type advisable. Consequently, the chairs recommend that the working group's earlier decision -- to use a new MIME type in the revised conference event package -- should stand. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Aug 31 13:09:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR9yL-0007yJ-RY; Fri, 31 Aug 2007 13:07:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR9yK-0007yA-QL for xcon@ietf.org; Fri, 31 Aug 2007 13:07:52 -0400 Received: from mail7.exchange.microsoft.com ([131.107.1.27] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR9yJ-00040J-Je for xcon@ietf.org; Fri, 31 Aug 2007 13:07:52 -0400 Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft SMTP Server (TLS) id 8.1.192.0; Fri, 31 Aug 2007 10:07:50 -0700 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.10]) by df-bhd-02.exchange.corp.microsoft.com ([157.54.71.155]) with mapi; Fri, 31 Aug 2007 10:07:50 -0700 From: Srivatsa Srinivasan To: "xcon@ietf.org" Date: Fri, 31 Aug 2007 10:07:49 -0700 Thread-Topic: Updated draft-srinivasan-xcon-eventpkg-extensions-02 Thread-Index: Acfr8XWM3OWRPYjoR52vfABqA25e3A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -104.0 (---------------------------------------------------) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: "roni.even@polycom.co.il" Subject: [XCON] Updated draft-srinivasan-xcon-eventpkg-extensions-02 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org There is an updated XCON event package extensions draft that has been poste= d. These extensions contain the following changes based on the feedback fro= m Chicago. - Changes to further align to text in RFC 3265 and RFC 4575 - Changes to include examples Feedback welcome, Srivatsa. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon