[Standards-JIG] JEP-0171 (Translation): One successful upon-receipt model
stpeter at jabber.org
Wed Feb 22 03:15:58 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
Thanks for the explanation. Comments below.
Jay Carlson wrote:
> In order to explain what we're concerned about with JEP-0171 (Translation),
> I'm going to back up a little bit and talk about the architecture of the
> TrIM system. Translingual Instant Messaging is a prototype IM system MITRE
> built to explore the viability, deployability, and utility of automatic
> machine translation coupled to text chat. TrIM's spent a couple years
> touring various coalition military exercises and operations, so I believe we
> have a pretty good feel for at least one model we know works.
> Since we're lazy---uh, I mean thrifty---TrIM is implemented on top of the
> SIMP protocol, which was a strawman standard we did way back when the IMPP
> working group hadn't quite made it to specifics yet, and Jabber didn't have
> a real specification. You can read about SIMP at http://simp.mitre.org/ and
> download an Open Source implementation, but it's probably not worth it at
> this point. It's a bit Neanderthal in how it uses XML, and for the purposes
> of this discussion, there are only two significant differences between XMPP
> and SIMP.
> The first is that you get an end-to-end confirmation of message delivery.
> This potentially allows faster failure when translators fall over, but is
> not all that relevant in practice due to asynchrony, covered below.
> The second is that presence data has arbitrary key/value pairs. This allows
> us to stuff a preferred language field into each user's profile in a
> distinguished spot.
In XMPP you can include an xml:lang attribute anywhere you want -- doing
that in all the presence stanzas you send would be good.
> Because of both NIH and a thorough understanding of the positive and
> negative security issues of the existing TrIM architecture, the tools we
> have tend to replicate the exact TrIM message exchange patterns, except now
> over a standard protocol. Aside from discovery, they look a lot like what's
> in JEP-0171; this should come as no surprise, as there aren't all that many
> reasonable ways to phrase an RPC service for machine translation.
> What 0171 is missing is a reliable way of associating translation requests
> and translation replies. In a translation-on-receipt model, it's much more
> likely that multiple requests are outstanding at any given time.
Sure, makes sense.
> In any case, anybody with a translation-on-receipt model needs to have a
> reliable way of having multiple translation requests in the air, and
> returned in indeterminate order. The simplest way we can think of to
> support this is to allow requestors to specify a thread id on request, and
> have the response include it.
> I think the JEP should be modified to state that translation responses will
> echo the thread id of the request, and that will solve the showstopper for
> us. This doesn't deal with the issue of providing continuing context to a
> translation engine, but I think it's much closer. I don't know enough XMPP
> to figure out how to solve both the need for a unique ID for a
> request/response pair, and an association with an ongoing translation
That seems reasonable to me. Your two options for tracking would be the
'id' attribute or the message <thread/> element. The ThreadID seems more
useful in this context, since it seems that you want to track that a
received message is related to the original message (where you might
receive multiple translated messages for the reasons you state).
Jabber Software Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards