[Standards-JIG] JEP-0171 (Translation): One successful upon-receipt model

Peter Saint-Andre stpeter at jabber.org
Wed Feb 22 03:15:58 UTC 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

JEP-0079?

> 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.

<snip/>

> 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.

<snip/>

> 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
> context.

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).

Peter

- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD+9duNF1RSzyt3NURAny4AKCyBu/ErQ9fwBtwL4resbmlhRetAQCffdpm
tJrKyybmiu40OffEbaajB+4=
=jiCR
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060221/6041f27f/attachment.bin>


More information about the Standards mailing list