From discuss-bounces@apps.ietf.org Thu Mar 02 08:20:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEnin-0000Vr-Bq; Thu, 02 Mar 2006 08:19:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEivn-00081n-Ss for discuss@apps.ietf.org; Thu, 02 Mar 2006 03:13:03 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FEivk-0001Wg-EM for discuss@apps.ietf.org; Thu, 02 Mar 2006 03:13:03 -0500 Received: (qmail invoked by alias); 02 Mar 2006 08:12:59 -0000 Received: from p508FB4A1.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.180.161] by mail.gmx.net (mp031) with SMTP; 02 Mar 2006 09:12:59 +0100 X-Authenticated: #1915285 Message-ID: <4406A8D3.5000602@gmx.de> Date: Thu, 02 Mar 2006 09:12:03 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: HTTP Working Group , WebDAV , discuss@apps.ietf.org Subject: Re: I-D ACTION:draft-whitehead-http-etag-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-Mailman-Approved-At: Thu, 02 Mar 2006 08:19:56 -0500 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi, while working on the revision of RFC2518 (WebDAV), the WebDAV working group came to the conclusion that what HTTP says about returning ETag headers in write operations (such as PUT) is insufficient. Jim's draft summarizes the various issues and also contains some thoughts about what to do, from which we'd like to start a discussion on the HTTP mailing list (). Feedback appreciated, Julian Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Design Considerations for State Identifiers in HTTP and WebDAV > Author(s) : J. Whitehead > Filename : draft-whitehead-http-etag-00.txt > Pages : 13 > Date : 2006-3-1 > > This document discusses design considerations for state identifiers > in the Hypertext Transfer Protocol (HTTP) and related protocols such > as WebDAV. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-whitehead-http-etag-00.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-whitehead-http-etag-00.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-whitehead-http-etag-00.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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce From discuss-bounces@apps.ietf.org Thu Mar 02 18:18:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEx4K-0003UC-FK; Thu, 02 Mar 2006 18:18:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEx4J-0003T3-3M for discuss@apps.ietf.org; Thu, 02 Mar 2006 18:18:47 -0500 Received: from exprod6og5.obsmtp.com ([64.18.1.125]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FEx4H-0003Dl-NE for discuss@apps.ietf.org; Thu, 02 Mar 2006 18:18:47 -0500 Received: from source ([192.150.11.134]) by exprod6ob5.obsmtp.com ([64.18.5.12]) with SMTP; Thu, 02 Mar 2006 15:18:44 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k22NI3Bl003286 for ; Thu, 2 Mar 2006 15:18:03 -0800 (PST) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k22NIfru014437 for ; Thu, 2 Mar 2006 15:18:42 -0800 (PST) Received: from calsj-dev (localhost [127.0.0.1]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IVI0054JWR493@mailsj-v1.corp.adobe.com> for discuss@apps.ietf.org; Thu, 02 Mar 2006 15:18:40 -0800 (PST) Received: from MasinterT43p (c-131-70.corp.adobe.com [153.32.131.70]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IVI00E7AWR4XS@mailsj-v1.corp.adobe.com> for discuss@apps.ietf.org; Thu, 02 Mar 2006 15:18:40 -0800 (PST) Date: Thu, 02 Mar 2006 15:18:20 -0800 From: Larry Masinter Subject: RE: I-D ACTION:draft-whitehead-http-etag-00.txt In-reply-to: <4406A8D3.5000602@gmx.de> To: "'Julian Reschke'" , "'HTTP Working Group'" , "'WebDAV'" , discuss@apps.ietf.org Message-id: <000301c63e4f$988cca60$46832099@corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcY9/AMeH+TliMw7R4GW9jON/UhTAQAUVM7w X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > Jim's draft summarizes the various issues=20 Looking through this for the issues, this is what I come up with: It looks like the HTTP spec doesn't say enough about ETag headers in 200 and 204 responses to PUT.=20 And there is a question, when a HTTP server accepts a PUT but will modify the octet stream before a subsequent GET of whether it can return a strong ETag (presumably for the data it has, not for what was sent). But doing so wouldn=92t be useful -- the client stored something, but gets back a strong etag for data that it doesn't have. So, I'd suggest a couple of things: (a) any server response for a successful PUT may contain an ETag header (200 and 204 as well as 201). (b) If a strong ETag is returned, then the client can=20 assume that the data was stored exactly as sent. (c) If the server modifies the data before storing it in a way that it cannot guarantee a byte-for-byte copy in a subsequent GET, it shouldn't use strong eTags. Larry --=20 http://larry.masinter.net From discuss-bounces@apps.ietf.org Fri Mar 03 00:27:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF2pM-0001S8-W3; Fri, 03 Mar 2006 00:27:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF2pL-0001RB-Ul for discuss@apps.ietf.org; Fri, 03 Mar 2006 00:27:43 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF2pI-0003tF-CL for discuss@apps.ietf.org; Fri, 03 Mar 2006 00:27:43 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k235Qtd17971; Fri, 3 Mar 2006 14:26:55 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 09fd_53f166de_aa76_11da_8e21_0014221fa3c9; Fri, 03 Mar 2006 14:26:55 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id k235P4BL018742; Fri, 3 Mar 2006 14:25:47 +0900 Message-Id: <6.0.0.20.2.20060303111728.09199410@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 03 Mar 2006 11:19:24 +0900 To: Larry Masinter , "'Julian Reschke'" , "'HTTP Working Group'" , "'WebDAV'" , discuss@apps.ietf.org From: Martin Duerst Subject: RE: I-D ACTION:draft-whitehead-http-etag-00.txt In-Reply-To: <000301c63e4f$988cca60$46832099@corp.adobe.com> References: <4406A8D3.5000602@gmx.de> <000301c63e4f$988cca60$46832099@corp.adobe.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org A very tiny adjustment below. But since HTTP (RFC 2616) is still at Draft Standard, couldn't this kind of clarification be added in when going to Standard? Or is that the plan? At 08:18 06/03/03, Larry Masinter wrote: >So, I'd suggest a couple of things: > >(a) any server response for a successful PUT may contain > an ETag header (200 and 204 as well as 201). >(b) If a strong ETag is returned, then the client can > assume that the data was stored exactly as sent. I think that should read "If a strong ETag is returned, then the client can assume that the data will subsequently be served exactly as sent." How the data is stored is purely the server's business (and (c) uses the right language). Regards, Martin. >(c) If the server modifies the data before storing it > in a way that it cannot guarantee a byte-for-byte > copy in a subsequent GET, it shouldn't use strong eTags. From discuss-bounces@apps.ietf.org Wed Mar 08 08:37:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGyqx-0006Ni-ND; Wed, 08 Mar 2006 08:37:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGhNm-0001Hl-0E for discuss@apps.ietf.org; Tue, 07 Mar 2006 13:58:06 -0500 Received: from e34.co.us.ibm.com ([32.97.110.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGhEr-0006Fa-Qc for discuss@apps.ietf.org; Tue, 07 Mar 2006 13:48:56 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k27ImraB007354 for ; Tue, 7 Mar 2006 13:48:53 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k27IpgLf168480 for ; Tue, 7 Mar 2006 11:51:42 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k27Imqm2003829 for ; Tue, 7 Mar 2006 11:48:52 -0700 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k27ImqbX003801; Tue, 7 Mar 2006 11:48:52 -0700 Subject: Distributed Multimodal Synchronization Protocol [dmsp] To: speechsc@ietf.org, discuss@apps.ietf.org, ietf@ietf.org X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 Message-ID: From: Chris Cross Date: Tue, 7 Mar 2006 13:48:12 -0500 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.53HF654 | July 22, 2005) at 03/07/2006 11:51:26 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFBB9DFCFEDF48f9e8a93df938690918c0ABBFBB9DFCFEDF4" Content-Disposition: inline X-Spam-Score: 0.5 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f X-Mailman-Approved-At: Wed, 08 Mar 2006 08:37:22 -0500 Cc: dmsp@ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --0__=0ABBFBB9DFCFEDF48f9e8a93df938690918c0ABBFBB9DFCFEDF4 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Hi Everyone, I'm sending a note to your list to make the members aware of this activ= ity. The I-D "Distributed Multimodal Synchronization Protocol " (dmsp) can b= e found at http://www.ietf.org/internet-drafts/draft-engelsma-dmsp-01.txt= . We have a mailing list at dmsp@ietf.org and a twice monthly phone conferen= ce. Dmsp is being developed to enable distributed multimodal systems. I've = been invited to present an overview at both the apps and rai general meeting= s in Dallas. We welcome your attendance at these presentations and intereste= d individuals' participation in our mail list and conference calls. At the bottom of this note is a draft charter we've discussed on the li= st that gives a more detailed description of dmsp. thanks, chris Chris Cross Multimodal Browser Architect _________________________ IBM Boca Raton xcross@us.ibm.com voice 561.862.2102 mobile 561.317.0700 fax 501.641.6727 The convergence of wireless communications with information technology = and the miniaturization of computing platforms have resulted in advanced mo= bile devices that offer high resolution displays, application programs with graphical user interfaces, and access to the internet through full func= tion web browsers. Mobile phones now support most of the functionality of a laptop compute= r. However the miniaturization that has made the technology possible and commercially successful also puts constraints on the user interface. Ti= ny displays and keypads significantly reduce the usability of application programs. Multimodal user interfaces, UIs that offer multiple modes of interactio= n, have been developed that greatly improve the usability of mobile device= s. In particular multimodal UIs that combine speech and graphical interact= ion are proving themselves in the marketplace. However, not all mobile devices provide the computing resources to perf= orm speech recognition and synthesis locally on the device. For these devic= es it is necessary to distribute the speech modality to a server in the network. The Distributed Multimodal Working Group will develop the protocols necessary to control, coordinate, and synchronize distributed modalitie= s in a distributed Multimodal system. There are several protocols and standa= rds necessary to implement such a system including DSR and AMR speech compression, session control, and media streaming. However, the DM WG w= ill focus exclusively on the synchronization of modalities being rendered across a network, in particular Graphical User Interface and Voice Serv= ers. The DM WG will develop an RFC for a Distributed Multimodal Synchronizat= ion Protocol that defines the logical message set to effect synchronization= between modalities and enough background on the expected multimodal sys= tem architecture (or reference architecture defined elsewhere in W3C or OMA= ) to present a clear understanding of the protocol. It will investigate exis= ting protocols for the transport of the logical synchronization messages and= develop an RFC detailing the message format for commercial alternatives= , including, possibly, HTTP and SIP. While not being limited to these, for simplicity of the scope the proto= col will assume RTP for carriage of media, SIP and SDP for session control,= and DSR and AMR for speech compression. The working group will not consider= the authoring of applications as it will be assumed that this will be done = with existing W3C markup standards such as XHTML and VoiceXML and commercial= programming languages like Java and C/C++. It is expected that we will coordinate our work in the IETF with the W3= C Multimodal Interaction Work Group. The following are our goals for the Working Group. Date Milestone TBD Submit Internet Draft Describing DMSP (standards track) TBD Submit Drafts to IESG for publication TBD 2006 Submit DMSP specification to IESG= --0__=0ABBFBB9DFCFEDF48f9e8a93df938690918c0ABBFBB9DFCFEDF4 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Hi Everyone,
I'm sending a note to your list to make the members aware of this activ= ity. The I-D "Distributed Multimodal Synchronization Protocol &quo= t; (dmsp) can be found at http://www.ietf.org/internet-drafts/draft= -engelsma-dmsp-01.txt. We have a mailing list at dmsp@ietf.org and = a twice monthly phone conference.

Dmsp is being developed to enable distributed multimodal systems. I've = been invited to present an overview at both the apps and rai general me= etings in Dallas. We welcome your attendance at these presentations and= interested individuals' participation in our mail list and conference = calls.

At the bottom of this note is a draft charter we've discussed on the li= st that gives a more detailed description of dmsp.

thanks,
chris


Chris Cross
Multimodal Browser Architect
_________________________
IBM Boca Raton
xcross@us.ibm.com
voice 561.862.2102
mobile 561.317.0700
fax 501.641.6727


The convergence of wireless commu= nications with information technology and the miniaturization of comput= ing platforms have resulted in advanced mobile devices that offer high = resolution displays, application programs with graphical user interface= s, and access to the internet through full function web browsers.

Mobile phones now support most of the functionality of a laptop compute= r. However the miniaturization that has made the technology possible an= d commercially successful also puts constraints on the user interface. = Tiny displays and keypads significantly reduce the usability of applica= tion programs.

Multimodal user interfaces, UIs that offer multiple modes of interactio= n, have been developed that greatly improve the usability of mobile dev= ices. In particular multimodal UIs that combine speech and graphical in= teraction are proving themselves in the marketplace.

However, not all mobile devices provide the computing resources to perf= orm speech recognition and synthesis locally on the device. For these d= evices it is necessary to distribute the speech modality to a server in= the network.

The Distributed Multimodal Working Group will develop the protocols nec= essary to control, coordinate, and synchronize distributed modalities i= n a distributed Multimodal system. There are several protocols and stan= dards necessary to implement such a system including DSR and AMR speech= compression, session control, and media streaming. However, the DM WG = will focus exclusively on the synchronization of modalities being rende= red across a network, in particular Graphical User Interface and Voice = Servers.

The DM WG will develop an RFC for a Distributed Multimodal Synchronizat= ion Protocol that defines the logical message set to effect synchroniza= tion between modalities and enough background on the expected multimoda= l system architecture (or reference architecture defined elsewhere in W= 3C or OMA) to present a clear understanding of the protocol. It will in= vestigate existing protocols for the transport of the logical synchroni= zation messages and develop an RFC detailing the message format for com= mercial alternatives, including, possibly, HTTP and SIP.

While not being limited to these, for simplicity of the scope the proto= col will assume RTP for carriage of media, SIP and SDP for session cont= rol, and DSR and AMR for speech compression. The working group will not= consider the authoring of applications as it will be assumed that this= will be done with existing W3C markup standards such as XHTML and Voic= eXML and commercial programming languages like Java and C/C++.

It is expected that we will coordinate our work in the IETF with the W3= C Multimodal Interaction Work Group.

The following are our goals for the Working Group.

Date Milestone
TBD Submit Internet Draft Describing DMSP (standards track)
TBD Submit Drafts to IESG for publication
TBD 2006 Submit DMSP specification to IESG = --0__=0ABBFBB9DFCFEDF48f9e8a93df938690918c0ABBFBB9DFCFEDF4-- From discuss-bounces@apps.ietf.org Wed Mar 08 12:59:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH2wv-0001OZ-MA; Wed, 08 Mar 2006 12:59:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH2wu-0001OM-9K for discuss@apps.ietf.org; Wed, 08 Mar 2006 12:59:48 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH2wr-0002OL-PT for discuss@apps.ietf.org; Wed, 08 Mar 2006 12:59:48 -0500 Received: from [127.0.0.1] (mail.songbird.com [208.184.79.10]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k28I03g6023535; Wed, 8 Mar 2006 10:00:04 -0800 Message-ID: <440F1908.3070408@ninebynine.org> Date: Wed, 08 Mar 2006 17:48:56 +0000 From: Graham Klyne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Chris Cross Subject: Re: Distributed Multimodal Synchronization Protocol [dmsp] References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: gk@ninebynine.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: speechsc@ietf.org, dmsp@ietf.org, discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Chris Cross wrote: > Hi Everyone, > I'm sending a note to your list to make the members aware of this > activity. The I-D "Distributed Multimodal Synchronization Protocol " > (dmsp) can be found at > http://www.ietf.org/internet-drafts/draft-engelsma-dmsp-01.txt. Chris, Very interesting to see this pop up... I'm thinking about the web view synchronization problem in a couple of completely different contexts, and I note that the diagram on page 7 of your Internet draft is almost exactly what I have been proposing in another context [1]. But this draft seems to combine the basic event propagation model with details of the specific events used for media synchronization, and I'd like to suggest that, if this work goes ahead, that the event distribution protocol be defined separately from the details of the events themselves (e.g. like SMTP/RFC2822 for email). Then other applications could use the same event distribution model for completely different purposes. (E.g. I have some similar event distribution requirements for web-based home-control applications.) I also note that existing work on publish/subscribe systems and/or instant messaging presence protocols might be used for the protocol. Turning to the events themselves, I think that to deploy in a Web context it would be sensible for event types to be identified by URIs rather than binary codes. In my own private work to date, I am using a simple event model that consists of event type and event source, both URIs, and arbitrary additional payload based on the event type. Unfortunately, I shall not be present in Dallas to participate in the debate. I do think that the requirement that this proposal addresses is symptomatic of a wider gap in Web/Internet application architecture, and it would be good to see a simple common solution emerge. I seem to recall that, some time ago, Lisa Dussault was discussing some thoughts about notification systems for Internet applications, which may well have a part to play in this debate. #g -- [1] http://wiki.oss-watch.ac.uk/InterPortletCommunicationConsideredHarmful Chris Cross wrote: > Hi Everyone, > I'm sending a note to your list to make the members aware of this > activity. The I-D "Distributed Multimodal Synchronization Protocol " > (dmsp) can be found at > http://www.ietf.org/internet-drafts/draft-engelsma-dmsp-01.txt. We have > a mailing list at dmsp@ietf.org and a twice monthly phone conference. > > Dmsp is being developed to enable distributed multimodal systems. I've > been invited to present an overview at both the apps and rai general > meetings in Dallas. We welcome your attendance at these presentations > and interested individuals' participation in our mail list and > conference calls. > > At the bottom of this note is a draft charter we've discussed on the > list that gives a more detailed description of dmsp. > > thanks, > chris > > > Chris Cross > Multimodal Browser Architect > _________________________ > IBM Boca Raton > xcross@us.ibm.com > voice 561.862.2102 > mobile 561.317.0700 > fax 501.641.6727 > > > The convergence of wireless communications with information technology > and the miniaturization of computing platforms have resulted in advanced > mobile devices that offer high resolution displays, application programs > with graphical user interfaces, and access to the internet through full > function web browsers. > > Mobile phones now support most of the functionality of a laptop > computer. However the miniaturization that has made the technology > possible and commercially successful also puts constraints on the user > interface. Tiny displays and keypads significantly reduce the usability > of application programs. > > Multimodal user interfaces, UIs that offer multiple modes of > interaction, have been developed that greatly improve the usability of > mobile devices. In particular multimodal UIs that combine speech and > graphical interaction are proving themselves in the marketplace. > > However, not all mobile devices provide the computing resources to > perform speech recognition and synthesis locally on the device. For > these devices it is necessary to distribute the speech modality to a > server in the network. > > The Distributed Multimodal Working Group will develop the protocols > necessary to control, coordinate, and synchronize distributed modalities > in a distributed Multimodal system. There are several protocols and > standards necessary to implement such a system including DSR and AMR > speech compression, session control, and media streaming. However, the > DM WG will focus exclusively on the synchronization of modalities being > rendered across a network, in particular Graphical User Interface and > Voice Servers. > > The DM WG will develop an RFC for a Distributed Multimodal > Synchronization Protocol that defines the logical message set to effect > synchronization between modalities and enough background on the expected > multimodal system architecture (or reference architecture defined > elsewhere in W3C or OMA) to present a clear understanding of the > protocol. It will investigate existing protocols for the transport of > the logical synchronization messages and develop an RFC detailing the > message format for commercial alternatives, including, possibly, HTTP > and SIP. > > While not being limited to these, for simplicity of the scope the > protocol will assume RTP for carriage of media, SIP and SDP for session > control, and DSR and AMR for speech compression. The working group will > not consider the authoring of applications as it will be assumed that > this will be done with existing W3C markup standards such as XHTML and > VoiceXML and commercial programming languages like Java and C/C++. > > It is expected that we will coordinate our work in the IETF with the W3C > Multimodal Interaction Work Group. > > The following are our goals for the Working Group. > > Date Milestone > TBD Submit Internet Draft Describing DMSP (standards track) > TBD Submit Drafts to IESG for publication > TBD 2006 Submit DMSP specification to IESG > -- Graham Klyne For email: http://www.ninebynine.org/#Contact From discuss-bounces@apps.ietf.org Thu Mar 09 08:11:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKuz-0006Q0-5q; Thu, 09 Mar 2006 08:11:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH2wm-0001OE-8a for discuss@apps.ietf.org; Wed, 08 Mar 2006 12:59:40 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH2wk-0002OL-Tx for discuss@apps.ietf.org; Wed, 08 Mar 2006 12:59:40 -0500 Received: from [127.0.0.1] (mail.songbird.com [208.184.79.10]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k28HxuBC023518 for ; Wed, 8 Mar 2006 09:59:57 -0800 Message-ID: <440F1246.4060105@oucs.ox.ac.uk> Date: Wed, 08 Mar 2006 17:20:06 +0000 From: Graham Klyne Organization: Oxford University Computing Services User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: discuss@apps.ietf.org Subject: Mailing list archive References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: graham.klyne@oucs.ox.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Thu, 09 Mar 2006 08:11:00 -0500 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Folks, The purported archive of this mailing list cited at http://www.apps.ietf.org/mailing-lists.html seems to be missing. Where is the list archive, please? #g -- Graham Klyne Research Technology Service Oxford University Computing Services From discuss-bounces@apps.ietf.org Thu Mar 09 08:14:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKyA-00006Q-RC; Thu, 09 Mar 2006 08:14:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKy9-0008Vf-Gq for discuss@apps.ietf.org; Thu, 09 Mar 2006 08:14:17 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHKy8-0001AZ-Af for discuss@apps.ietf.org; Thu, 09 Mar 2006 08:14:17 -0500 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Thu, 09 Mar 2006 08:13:27 -0500 id 01588154.441029F7.00005BD1 From: "Scott Hollenbeck" To: "'Graham Klyne'" , discuss@apps.ietf.org Subject: RE: Mailing list archive Date: Thu, 9 Mar 2006 08:14:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcZDeyu19Lu/d31HTzCRU/IA90LMmAAABJAA In-Reply-To: <440F1246.4060105@oucs.ox.ac.uk> Message-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > -----Original Message----- > From: Graham Klyne [mailto:graham.klyne@oucs.ox.ac.uk] > Sent: Wednesday, March 08, 2006 12:20 PM > To: discuss@apps.ietf.org > Subject: Mailing list archive > > Folks, > > The purported archive of this mailing list cited at > > http://www.apps.ietf.org/mailing-lists.html > > seems to be missing. Where is the list archive, please? http://www1.ietf.org/mail-archive/web/discuss/current/index.html -Scott-