From dmsp-bounces@ietf.org Mon Jul 17 08:38:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2SMa-0002i1-QL; Mon, 17 Jul 2006 08:38:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2SMZ-0002hw-9t for dmsp@ietf.org; Mon, 17 Jul 2006 08:38:15 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2SMX-0004uv-R7 for dmsp@ietf.org; Mon, 17 Jul 2006 08:38:15 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e36.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6HCcBre022949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 Jul 2006 08:38:11 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6HCcBAe218120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Jul 2006 06:38:11 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k6HCcAYm002005 for ; Mon, 17 Jul 2006 06:38:11 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6HCcA3K001994; Mon, 17 Jul 2006 06:38:10 -0600 In-Reply-To: <44B6B336.8060207@bbiw.net> To: Dave Crocker X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 Message-ID: From: Chris Cross Date: Mon, 17 Jul 2006 08:38:06 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 7.0.1HF123 | April 14, 2006) at 07/17/2006 06:38:10 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: Nathaniel Borenstein , dmsp@ietf.org Subject: [Dmsp] Re: Chris X-BeenThere: dmsp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Multimodal Synchronization Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1432163524==" Errors-To: dmsp-bounces@ietf.org --===============1432163524== Content-type: multipart/related; Boundary="0__=0ABBFB3DDFD0058A8f9e8a93df938690918c0ABBFB3DDFD0058A" --0__=0ABBFB3DDFD0058A8f9e8a93df938690918c0ABBFB3DDFD0058A Content-type: multipart/alternative; Boundary="1__=0ABBFB3DDFD0058A8f9e8a93df938690918c0ABBFB3DDFD0058A" --1__=0ABBFB3DDFD0058A8f9e8a93df938690918c0ABBFB3DDFD0058A Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Hi Dave, Thanks for coming to our BoF. I agree whole heartedly with your assertion that we need to educate the= ietf but I disagree that changing the nomenclature is the way to go. If= you google "multimodal" the first four hits and 8 of the first 10 refer to multimodal in the same way that we do. "User Interface Streams" doesn't quite catch the idea. While there are streams involved, they are at a lower level in the "multimodal stack", generally in the VoIP implementation. Synchronization in multimodal applications occur at the "dialog level", directly concerning the event= queues of User Agents. While multimodal synch has impact on the implementation of VoIP streams, that is an implementation detail. I notice you're subscribed to the dmsp list. Please continue the discus= sion there. I certainly welcome your input. thanks, chris = Dave Crocker = = To Chris Cross/West Palm = 07/13/2006 04:55 Beach/IBM@IBMUS, Jonathan Engels= ma PM = = cc Nathaniel Borenstein = = Subj= ect Chris = = = = = = = So, I decided to play around with possible, alternative acronyms, if on= ly to clarify my own lack of understanding about what DMSP does. >From that perspective, what is inaccurate or inappropriate about: [Protocol for] Synchronizing User Interface Streams (SUIS) (possibly pronounced "swees") d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net = --1__=0ABBFB3DDFD0058A8f9e8a93df938690918c0ABBFB3DDFD0058A Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Hi Dave,
Thanks for coming to our BoF.

I agree whole heartedly with your assertion that we need to educate the= ietf but I disagree that changing the nomenclature is the way to go. I= f you google "multimodal" the first four hits and 8 of the fi= rst 10 refer to multimodal in the same way that we do.

"User Interface Streams" doesn't quite catch the idea. While = there are streams involved, they are at a lower level in the "mult= imodal stack", generally in the VoIP implementation. Synchronizati= on in multimodal applications occur at the "dialog level", di= rectly concerning the event queues of User Agents. While multimodal syn= ch has impact on the implementation of VoIP streams, that is an impleme= ntation detail.

I notice you're subscribed to the dmsp list. Please continue the discus= sion there. I certainly welcome your input.

thanks,
chris



3D"InactiveDave Crocker <dcrocker@bbiw.net&g= t;


=
          Dave Crocker <dcrocker@bbiw.net>

          07/13/2006 04:55 PM

 =
3D=
To
3D""
Chris Cross/West Palm Beach/IBM@IBMUS, Jonathan Engels= ma <Jonathan.Engelsma@motorola.com>
3D=
cc
3D""
Nathaniel Borenstein <nsb@guppylake.com><= /td>
3D=
Subject
3D""
Chris
3D=3D""

So, I decided to play around with possible, alternative acronyms, i= f only to
clarify my own lack of understanding about what DMSP does.

>From that perspective, what is inaccurate or inappropriate about:

  [Protocol for] Synchronizing  User Interface Streams (SUIS= )

(possibly pronounced "swees")

d/
--

 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net

= --1__=0ABBFB3DDFD0058A8f9e8a93df938690918c0ABBFB3DDFD0058A-- --0__=0ABBFB3DDFD0058A8f9e8a93df938690918c0ABBFB3DDFD0058A Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFB3DDFD0058A8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFB3DDFD0058A8f9e8a93df938690918c0ABBFB3DDFD0058A Content-type: image/gif; name="pic21638.gif" Content-Disposition: inline; filename="pic21638.gif" Content-ID: <2__=0ABBFB3DDFD0058A8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=0ABBFB3DDFD0058A8f9e8a93df938690918c0ABBFB3DDFD0058A Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=0ABBFB3DDFD0058A8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBFB3DDFD0058A8f9e8a93df938690918c0ABBFB3DDFD0058A-- --===============1432163524== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Dmsp mailing list Dmsp@ietf.org https://www1.ietf.org/mailman/listinfo/dmsp --===============1432163524==-- From dmsp-bounces@ietf.org Mon Jul 17 18:04:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2bCI-00021C-Pr; Mon, 17 Jul 2006 18:04:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2bCH-000217-0d for dmsp@ietf.org; Mon, 17 Jul 2006 18:04:13 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2bCG-000750-DC for dmsp@ietf.org; Mon, 17 Jul 2006 18:04:12 -0400 Received: from [192.168.0.2] (adsl-67-127-57-9.dsl.pltn13.pacbell.net [67.127.57.9]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k6HM4Pvo025082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jul 2006 15:04:26 -0700 Message-ID: <44BC094C.6040204@dcrocker.net> Date: Mon, 17 Jul 2006 15:03:56 -0700 From: Dave Crocker User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Chris Cross 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: Clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: dmsp@ietf.org Subject: [Dmsp] The "intuitive" meaning of DMSP X-BeenThere: dmsp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Multimodal Synchronization Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dmsp-bounces@ietf.org Chris, et al, Chris Cross wrote: > I agree whole heartedly with your assertion that we need to educate the > ietf but I disagree that changing the nomenclature is the way to go. If I am hoping that my actual words were a tad different from what you heard. My experience is that having two technical cultures attempt to collaborate requires "education" in *both* directions. In fact I prefer to view is more interms of being a mutual "negotiation", not just for a solution, but for the basis that will be used to explore the problem space and the solution space. Each educating the other is certainly part of the effort, but the mutuality of the activity is key. It is easy to view my focus on the name of the work as being nothing more than quibbling. (I'm not saying that is what you are doing, but that it does happen and is easy to understand.) Please be assured that that is most certainly not my intent. Since I view much of the hard work of standardization as figuring out how to communicate and agree to needs and benefits -- the technical work is far from minor, but oddly it is often the easiest part of the effort -- then I think it important to have title and descriptions that help those who are *not* part of the pre-existing, inside community. > you google "multimodal" the first four hits and 8 of the first 10 refer > to multimodal in the same way that we do. The nature of the google algorithms means that this is a good way to establish that there really is a community of interest that uses the term consistently. Of course, that is helpful to know. However my concern is about the nature and size of that established community, as compared against the increasingly larger community that you hope to recruit to this activity. (As I mentioned privately, I see standardization as developing an expanding spiral of community support for an effort.) Does that larger population find the term intuitive or helpful? To find this out requires a rather different methodology. So I decided to do a small bit of survey research, today, to find out. I sent out a note to a variety of folk who have not contact with your effort, although by accident I did include one person who attended last week's BOF. There is nothing "random" about this sampling, of course, but I was careful to seek variety in their expertise. Those surveyed are all quite senior in their work, ranging across different types of Internet protocol development, executive-level technical management, technical marketing, and even human-computer research. See "Survey Request Note", below, for the text of what I sent. I've received 8 responses, so far. The results are quite consistent. "Sampling of Responses", below, contains useful bits of text from the notes folks sent back. The bottom line is that folks really do not understand what the term means. Some folks came close, but usually by accident or as one of several guesses. Note that even the BOF attendee is still confused! So if you want to start including folks from outside the existing community of workers, we need a label that has more meaning. While one might claim that the issue is merely one of teaching these folks what the current definition is, that would presume that their various, pre-existing views on the language are irrelevant. My own view is that there is significant benefit in having a term that has more natural and obvious meaning, than one that begins by being ambiguous. > "User Interface Streams" doesn't quite catch the idea. While there are > streams involved, they are at a lower level in the "multimodal stack", > generally in the VoIP implementation. Synchronization in multimodal "generally in the VoIP implementation" suggests a particular focus on VOIP. If that is, indeed, an essential part of the work, then it needs to be stated explicitly. My own understanding is that the work is very much NOT tailored to a particular medium or mode. > applications occur at the "dialog level", directly concerning the event > queues of User Agents. While multimodal synch has impact on the > implementation of VoIP streams, that is an implementation detail. Hmmm. User/System Dialog Event Synchronization? (We need to be careful that the name does not sound like human-to-human conversation, which would *really* be at the wrong level of the stack...) That's why the word "interface" is helpful, since "user interface" has a clear and consistent reference to the system component that conducts exchanges with a human user of the system. I've suggested user/system, above, just for variation. And let me stress that I have no concern for whether any names I suggest be adopted. My concerns are that a) the current name does not help your cause and that any b) alternative that is chosen fix this. My suggestions are merely... suggestions. d/ SURVEY REQUEST NOTE ------------------- > I am having a discussion about the terminology used, to label some Internet > protocol standardization work that is starting. My concern is that the label > have a reasonable degree of intuitive (and correct) meaning for people who are > new to the activity. I believe this should include direct Internet protocol > designers, software engineers, technical managers, product marketing staff, and > industry reporters. > > If you are willing to be a subject in an informal survey, please respond by > telling me what topic you believe the following label covers: > > Distributed Multimodal Synchronization Protocol > > Thanks. SAMPLING OF RESPONSES --------------------- 1. >The term does not instantly convey anything recognizable to me. I spent a few seconds parsing the words and trying to imagine what might be meant. "Multimodal?" I'm trying to imagine multiple modes. Hearing and seeing? Multiple forms of transport? Nothing is clicking. Sorry. > Alternate guess: > > [A colleague] and I have been sending email back and forth all day. All of > sudden I got a bounce message with an error I've never seen before and which > didn't make any sense. I talked to him over Jabber to alert him and then > pasted in the bounce message so he could see it. He acked and is working on > the problem. I think this is an instance of distributed multimodal > synchronization via an ad hoc protocol ;) 2. > It is a protocol that is distribued (e.g., no servers), works in many modes > (e.g., different network types and speeds) and synchronized data between the > participating nodes. "Multimodal" is the least clear part to me. > > Sounds like that database distribution part of a routing protocol. Close? > > Second guess is some sort of extension to one of the sync protocols (like OMA > standardizes) to make it work better for different media types. 3. > Dave -- Those terms are so general and so widely used I would not even > venture a guess what it is meant to cover when you put them all > together. 4. > If someone asked me what "Distributed Multimodal Synchronization Protocol" > is, I would guess it is a protocol to synchronize data types/formats used in > various modes of communication (email, IM, SMS, VOP, XML?, etc.). I would > also guess the applications that use the data, and the actual data, can be > and are widely and broadly distributed. If my guesses so far are correct, I > would then assume one aspect the protocol would need to account for is > synchronizing with data that is behind corporate firewalls. 5. > I was at DMSP, but I have only a vague idea how the name relates to the work they are doing. 6. > I do multimodal work, that is, eyetracking and speech input, touch and speech > input, etc. So my guess is that distributed multimodal syncrhonization is a > problem like what we faced in working with our eye tracker and MIT's speech > engine which had a time lag because of the internet delays that made our > efforts to build anything workable laughable. And protocol, well thats just > people trying to agree on some standard that actually makes this all work. > 7. > Beats me. When I see Multimodal I think of things like TOFC (trucks on flat > cars) so my assumption would be that it has something to do with ensuring > that the right truck drivers are there when the train arrives at the yard or > the ship arrives at the pier. 8. > So, in laymans terms, suppose I have an address book or a database or > some other dynamic file that I want to be up-to-date on my cellphone, > my iPod, my laptop, my desktop and somehow in synch with data from > YOUR address book or file. I can imagine a synch protocol to > accomplish this, I can imagine doing it over TCP, UPD, Bluetooth, > WiFi, FireWire, USB and so on. The synch protocol remains constant, > the modes change, the speed changes and so on. > > Is this at all what you are talking about?? _______________________________________________ Dmsp mailing list Dmsp@ietf.org https://www1.ietf.org/mailman/listinfo/dmsp From dmsp-bounces@ietf.org Mon Jul 31 14:25:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7cRx-0004Ul-D3; Mon, 31 Jul 2006 14:25:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7cRv-0004T3-Sw for dmsp@ietf.org; Mon, 31 Jul 2006 14:25:07 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7cRt-0003Xs-WA for dmsp@ietf.org; Mon, 31 Jul 2006 14:25:07 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id k6VIOvSs009455 for ; Mon, 31 Jul 2006 11:25:01 -0700 (MST) Received: from de01exm66.ds.mot.com (de01exm66.am.mot.com [10.176.8.17]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k6VIOuVP028308 for ; Mon, 31 Jul 2006 13:24:57 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dmsp] The "intuitive" meaning of DMSP Date: Mon, 31 Jul 2006 14:24:55 -0400 Message-ID: In-Reply-To: <44BC094C.6040204@dcrocker.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dmsp] The "intuitive" meaning of DMSP Thread-Index: Acap7PnCa27qd2qNTfuyFHULvAF6yAK3j1gA From: "Ferrans James-JFERRAN1" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e X-BeenThere: dmsp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Multimodal Synchronization Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dmsp-bounces@ietf.org Hi Dave, Your survey results are quite interesting! I do agree completely with the need for a common vocabulary. In the early days of database systems one of ANSI's earliest steps was simply to codify a common nomenclature. (And my father-in-law once showed me an early ANSI standard that simply named the parts of ordinary hammers!) We shouldn't use "multimodal" without qualification, since there are multimodal treatment regimens in medicine, and multimodal transport (container) shipping systems. "Multimodal interfaces" and "multimodal interaction" are the terms most used in academe and industry. For example, the ACM has a yearly International Conference on Multimodal Interfaces (http://www.acm.org/icmi/2006/), and the W3C has a Multimodal Interaction Activity (http://www.w3.org/2002/mmi/). =20 We should see if we can find a more descriptive name for marketing purposes. Jim Ferrans Motorola Labs =20 -----Original Message----- From: Dave Crocker [mailto:dhc2@dcrocker.net]=20 Sent: Monday, July 17, 2006 5:04 PM To: Chris Cross Cc: dmsp@ietf.org Subject: [Dmsp] The "intuitive" meaning of DMSP Chris, et al, Chris Cross wrote: > I agree whole heartedly with your assertion that we need to educate the > ietf but I disagree that changing the nomenclature is the way to go. If I am hoping that my actual words were a tad different from what you heard. My experience is that having two technical cultures attempt to collaborate requires "education" in *both* directions. In fact I prefer to view is more interms of being a mutual "negotiation", not just for a solution, but for the basis that will be used to explore the problem space and the solution space. Each educating the other is certainly part of the effort, but the mutuality of the activity is key. It is easy to view my focus on the name of the work as being nothing more than quibbling. (I'm not saying that is what you are doing, but that it does happen and is easy to understand.) Please be assured that that is most certainly not my intent. Since I view much of the hard work of standardization as figuring out how to communicate and agree to needs and benefits -- the technical work is far from minor, but oddly it is often the easiest part of the effort -- then I think it important to have title and descriptions that help those who are *not* part of the pre-existing, inside community. > you google "multimodal" the first four hits and 8 of the first 10 refer > to multimodal in the same way that we do. The nature of the google algorithms means that this is a good way to establish that there really is a community of interest that uses the term consistently. Of course, that is helpful to know. However my concern is about the nature and size of that established community, as compared against the increasingly larger community that you hope to recruit to this activity. (As I mentioned privately, I see standardization as developing an expanding spiral of community support for an effort.) Does that larger population find the term intuitive or helpful? To find this out requires a rather different methodology. So I decided to do a small bit of survey research, today, to find out. I sent out a note to a variety of folk who have not contact with your effort, although by accident I did include one person who attended last week's BOF. There is nothing "random" about this sampling, of course, but I was careful to seek variety in their expertise. Those surveyed are all quite senior in their work, ranging across different types of Internet protocol development, executive-level technical management, technical marketing, and even human-computer research. See "Survey Request Note", below, for the text of what I sent. I've received 8 responses, so far. The results are quite consistent. "Sampling of Responses", below, contains useful bits of text from the notes folks sent back. The bottom line is that folks really do not understand what the term means. Some folks came close, but usually by accident or as one of several guesses. Note that even the BOF attendee is still confused! So if you want to start including folks from outside the existing community of workers, we need a label that has more meaning. While one might claim that the issue is merely one of teaching these folks what the current definition is, that would presume that their various, pre-existing views on the language are irrelevant. My own view is that there is significant benefit in having a term that has more natural and obvious meaning, than one that begins by being ambiguous. > "User Interface Streams" doesn't quite catch the idea. While there are > streams involved, they are at a lower level in the "multimodal stack", > generally in the VoIP implementation. Synchronization in multimodal "generally in the VoIP implementation" suggests a particular focus on VOIP. If that is, indeed, an essential part of the work, then it needs to be stated explicitly. My own understanding is that the work is very much NOT tailored to a particular medium or mode. > applications occur at the "dialog level", directly concerning the event > queues of User Agents. While multimodal synch has impact on the > implementation of VoIP streams, that is an implementation detail. Hmmm. User/System Dialog Event Synchronization? (We need to be careful that the name does not sound like human-to-human conversation, which would *really* be at the wrong level of the stack...) That's why the word "interface" is helpful, since "user interface" has a clear and consistent reference to the system component that conducts exchanges with a human user of the system. I've suggested user/system, above, just for variation. And let me stress that I have no concern for whether any names I suggest be adopted. My concerns are that a) the current name does not help your cause and that any b) alternative that is chosen fix this. My suggestions are merely... suggestions. d/ SURVEY REQUEST NOTE ------------------- > I am having a discussion about the terminology used, to label some Internet > protocol standardization work that is starting. My concern is that the label > have a reasonable degree of intuitive (and correct) meaning for people who are > new to the activity. I believe this should include direct Internet protocol > designers, software engineers, technical managers, product marketing staff, and > industry reporters. >=20 > If you are willing to be a subject in an informal survey, please respond by > telling me what topic you believe the following label covers: >=20 > Distributed Multimodal Synchronization Protocol >=20 > Thanks. SAMPLING OF RESPONSES --------------------- 1. >The term does not instantly convey anything recognizable to me. I spent a few seconds parsing the words and trying to imagine what might be meant. "Multimodal?" I'm trying to imagine multiple modes. Hearing and seeing? Multiple forms of transport? Nothing is clicking. Sorry. > Alternate guess: > > [A colleague] and I have been sending email back and forth all day. All of > sudden I got a bounce message with an error I've never seen before and which > didn't make any sense. I talked to him over Jabber to alert him and then > pasted in the bounce message so he could see it. He acked and is working on > the problem. I think this is an instance of distributed multimodal > synchronization via an ad hoc protocol ;) 2. > It is a protocol that is distribued (e.g., no servers), works in many modes > (e.g., different network types and speeds) and synchronized data between the > participating nodes. "Multimodal" is the least clear part to me. >=20 > Sounds like that database distribution part of a routing protocol. Close? > > Second guess is some sort of extension to one of the sync protocols (like OMA > standardizes) to make it work better for different media types. 3. > Dave -- Those terms are so general and so widely used I would not even > venture a guess what it is meant to cover when you put them all > together. 4. > If someone asked me what "Distributed Multimodal Synchronization Protocol" > is, I would guess it is a protocol to synchronize data types/formats used in > various modes of communication (email, IM, SMS, VOP, XML?, etc.). I would > also guess the applications that use the data, and the actual data, can be > and are widely and broadly distributed. If my guesses so far are correct, I > would then assume one aspect the protocol would need to account for is > synchronizing with data that is behind corporate firewalls. 5. > I was at DMSP, but I have only a vague idea how the name relates to the work they are doing. 6. > I do multimodal work, that is, eyetracking and speech input, touch and speech > input, etc. So my guess is that distributed multimodal syncrhonization is a > problem like what we faced in working with our eye tracker and MIT's speech > engine which had a time lag because of the internet delays that made our > efforts to build anything workable laughable. And protocol, well thats just > people trying to agree on some standard that actually makes this all work. >=20 7. > Beats me. When I see Multimodal I think of things like TOFC (trucks on flat > cars) so my assumption would be that it has something to do with ensuring > that the right truck drivers are there when the train arrives at the yard or > the ship arrives at the pier. 8. > So, in laymans terms, suppose I have an address book or a database or=20 > some other dynamic file that I want to be up-to-date on my cellphone,=20 > my iPod, my laptop, my desktop and somehow in synch with data from > YOUR address book or file. I can imagine a synch protocol to=20 > accomplish this, I can imagine doing it over TCP, UPD, Bluetooth,=20 > WiFi, FireWire, USB and so on. The synch protocol remains constant, > the modes change, the speed changes and so on. >=20 > Is this at all what you are talking about?? _______________________________________________ Dmsp mailing list Dmsp@ietf.org https://www1.ietf.org/mailman/listinfo/dmsp _______________________________________________ Dmsp mailing list Dmsp@ietf.org https://www1.ietf.org/mailman/listinfo/dmsp