[Dmsp] The "intuitive" meaning of DMSP

Dave Crocker <dhc2@dcrocker.net> Mon, 17 July 2006 22:04 UTC

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 <dhc2@dcrocker.net>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Chris Cross <xcross@us.ibm.com>
References: <OF4D94A35B.C0E20B38-ON852571AE.0043831A-852571AE.00456854@us.ibm.com>
In-Reply-To: <OF4D94A35B.C0E20B38-ON852571AE.0043831A-852571AE.00456854@us.ibm.com>
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 <dmsp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dmsp>, <mailto:dmsp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dmsp>
List-Post: <mailto:dmsp@ietf.org>
List-Help: <mailto:dmsp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dmsp>, <mailto:dmsp-request@ietf.org?subject=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