XEP-0171: Language Translation

Abstract:This specification defines an XMPP protocol extension for providing language translation facilities over XMPP. It supports human, machine, client-based, and server-based translations.
Authors:Boyd Fletcher, Daniel LaPrade, Keith Lirette, Brian Raymond
Copyright:© 1999 - 2011 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:Draft
Type:Standards Track
Version:1.1rc1
Last Updated:in progress, last updated 2010-06-09

NOTICE: The protocol defined herein is a Draft Standard of the XMPP Standards Foundation. Implementations are encouraged and the protocol is appropriate for deployment in production systems, but some changes to the protocol are possible before it becomes a Final Standard.

Table of Contents


1. Introduction
2. Glossary
3. Requirements
4. Use Cases
    4.1. Message Delivery
       4.1.1. Direct Translation
       4.1.2. Translation With Pivot
       4.1.3. Translation With Pivot Specifying Details
    4.2. Discovering Translation Providers
       4.2.1. Discovering Translation Providers On a Server
       4.2.2. Discovering Identity of Providers
       4.2.3. Discovering Language Support
    4.3. Requesting a Translation from a Service
       4.3.1. Requesting a Basic Translation
       4.3.2. Requesting a Translation With Multiple Destination Languages
       4.3.3. Requesting a Translation With a Specific Dictionary
5. Implementation Notes
6. Internationalization Considerations
7. Security Considerations
8. IANA Considerations
9. XMPP Registrar Considerations
    9.1. Protocol Namespaces
    9.2. Service Discovery Identities
10. XML Schema
    10.1. langtrans
    10.2. langtrans:items

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History

1. Introduction

There currently exists no standard for describing language translations over a text chat protocol. While numerous products and services exist to provide translation of text, there exists no standardized protocol extension for requesting a translation and expressing the details of the translation over XMPP (see XMPP Core [1]). This document describes how to express a translation and its components in an XMPP message as well as a method to request translation.

Direct translation can be realized by either client-side translation before sending or transparent components translating messages on the fly. Discovering XMPP entities capable of translation allows for clients to request translation from them based on their capabilities. The remote XMPP entity could be either an automated translation service or a human providing translation.

2. Glossary

Original Text
This is the message text that was originally created by the sender. This is the text that is translated.
Translated Text
This is the message text that has been translated by the language translation engines. This also called the destination text. For any given message there can be multiple destination text message bodies.
Pivot Language
Pivoting is the process of using one or more intermediate languages to translate from a given source language to a specific destination language. For example, if you needed to translate from English to Russian but only had translators that went from English to French and French to Russian then you could use French as a pivot language.
Pivot Text
This is the translated text of the original message in a pivot language. For any given destination language, there can be zero or more pivot text bodies. The ordering of pivoting is required to be specified for the destination language.
Language Translation Engine
Since not all language translation engines are the same quality it is important to some classes of users that they know what translation engine was used. It is equally important to also be able to select a specific translation engine for a given language pairing if more than one engine is available.
Language Translation Character Set
Some language translation engines can only translate text between languages if certain character sets (or code pages) are used.
Language Translation Dictionary
In order to enhance the accuracy of translation engines most support the concept of mission specific dictionaries.

3. Requirements

The protocol defined herein addresses the following requirements:

  1. Enable an XMPP entity to request a translation from a remote XMPP entity.

  2. Enable an XMPP entity to express the following mandatory elements of a translation for any receiving entities.

    1. Identification of Original Text
    2. Identification of Translated Text
    3. Identification of any Pivot Language(s) and Text
    4. Identification of the method and order of translation

  3. Enable an XMPP entity to express the following optional elements of a translation for any receiving entities.

    1. Identification of Language Translation Engines used.
    2. Identification of Location of the translation.
    3. Identification of Sender and Destination language of choice.
    4. Discovery of Server support for translation including which language pair, dictionaries, and engines are available.
    5. Identification of desire to text to be translated or not to be translated.

The following methods of translation are supported:

  1. Manual or Human
  2. Machine or Automated
  3. Machine with Human Review

4. Use Cases

The following use cases illustrate simple scenarios for translation of expressions as well as requesting a translation from remote entities.

4.1 Message Delivery

A message directly translated by the originating XMPP entity or a transparent XMPP entity delivered to a remote entity with only the required elements of source and destination language; this is the simplest case for a translation from one language to another. The source language is known because there is no <translation/> tag describing it. Three translation methods are supported by doing the following:

  1. If no 'engine' attribute is present, then manual (or human) translation was performed.
  2. If an 'engine' attribute is present then machine (or automated) translation was performed, where the translation engine is identified by the value of the 'engine' attribute. If the 'engine' attribute is present its value is an empty string, then the name of the translation engine was not available.
  3. If the 'engine' attribute and the 'reviewed' attribute are present, then machine translation was performed but the message text was reviewed and possibly modified by a human.

4.1.1 Direct Translation

Example 1. Entity sends a message translated from English to French

<message xml:lang='en' from='bard@shakespeare.lit/globe' to='playwright@marlowe.lit/theatre'>
  <subject xml:lang='en'>Hello</subject>
  <subject xml:lang='fr'>Bonjour</subject>
  <body xml:lang='en'>How are you?</body>
  <body xml:lang='fr'>comment allez-vous?</body>
  <x xmlns='urn:xmpp:langtrans'>
    <translation destination_lang='fr' source_lang='en'/>
  </x>
</message>

4.1.2 Translation With Pivot

A message translated by the originating XMPP entity or a transparent XMPP entity delivered to a remote entity with the pivot languages used to accomplish the translation. The source language is known because there is no translation tag describing it. When a translation is done via a pivot language, the pivot languages and their order of use MUST be specified.

Example 2. Entity sends a message translated from French to Russian via English using human translators

<message xml:lang='fr' from='bard@shakespeare.lit/globe' to='playwright@marlowe.lit/theatre'>
  <subject xml:lang='fr'>Bonjour</subject>
  <subject xml:lang='en'>Hello</subject>
  <subject xml:lang='ru'>x443;&#x43B;&#x442;&#x435;</subject>
  <body xml:lang='fr'>comment allez-vous?</body>
  <body xml:lang='en'>How are you?</body>
  <body xml:lang='ru'>&#x41A;&#x430;&#x43A; &#x432;&#x44B;?</body>
  <x xmlns='urn:xmpp:langtrans'>
    <translation destination_lang='en' source_lang='fr'/>
    <translation destination_lang='ru' source_lang='en'/>
  </x>
</message>

4.1.3 Translation With Pivot Specifying Details

A message translated by the originating XMPP entity or a transparent XMPP entity delivered to a remote entity using pivot languages and machine translation. The source language is known because there is no <x/> translation tag describing it.

Example 3. Entity sends a message translated from French to Russian via English using a machine translation engine.


<message xml:lang='fr' from='bard@shakespeare.lit/globe' to='playwright@marlowe.lit/theatre'>
  <subject xml:lang='fr'>Bonjour</subject>
  <subject xml:lang='en'>Hello</subject>
  <subject xml:lang='ru'>x443;&#x43B;&#x442;&#x435;</subject>
  <body xml:lang='fr'>comment allez-vous?</body>
  <body xml:lang='en'>How are you?</body>
  <body xml:lang='ru'>&#x41A;&#x430;&#x43A; &#x432;&#x44B;?</body>
  <x xmlns='urn:xmpp:langtrans'>
    <translation destination_lang='en' engine='SYSTRANS' source_lang='fr'/>
    <translation destination_lang='ru' engine='SYSTRANS' source_lang='en'/>
  </x>
</message>

4.2 Discovering Translation Providers

4.2.1 Discovering Translation Providers On a Server

When connected to a server, a XMPP entity can locate translation providers by asking a server which translation providers are attached to the server; this MUST be done using Service Discovery [2]. The server SHOULD return the availability of of translation providers and language pairings for which the user has rights to use.

Example 4. Entity sends discovery request to server

<iq type='get' id='disco1' to='shakespeare.lit'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>

Example 5. Server returns items, including translation providers

<iq type='result' id='disco1' from='shakespeare.lit' to='bard@shakespeare.lit/globe'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    ...
    <item jid='towerofbabel@shakespeare.lit'
          name='Tower of Babel Translation Bot'/>
    <item jid='translation.shakespeare.lit'
          name='Translation Provider Service'/>
    ...
  </query>
</iq>

4.2.2 Discovering Identity of Providers

Service Discovery is used to determine if a JID provides translation services. The JID can also be a bot (e.g., <towerofbabel@shakespeare.lit>) or a server component (e.g., <translation.shakespeare.lit>).

Example 6. Entity queries service regarding identity

<iq type='get' to='translation.shakespeare.lit' from='bard@shakespeare.lit/globe'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

Example 7. Service reports identity

<iq type='result' to='bard@shakespeare.lit/globe' from='translation.shakespeare.lit'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <identity category='automation' type='translation'/>
    <feature var='urn:xmpp:langtrans'/>
    ...
  </query>
</iq>

4.2.3 Discovering Language Support

The supported languages and other details for the service must be known to use it. It is permissible for a translation service to provide multiple translation engines for the same language pairing -- if this is done, then a separate <item/> tag MUST be used for each pairing. A 'dictionary' attribute MAY be used to specify the dictionary for a specific <item/>. In order to specify more than one dictionary for a given language pairing then a separate <item/> tag MUST be used for each dictionary specification for that language pairing.

Example 8. Entity queries service for further information

<iq type='get' to='translation.shakespeare.lit' from='bard@shakespeare.lit/globe'>
  <query xmlns='urn:xmpp:langtrans:items'/>
</iq>

Example 9. Service replies with language details

<iq type='result' to='bard@shakespeare.lit/globe' from=' translation.shakespeare.lit'>
  <query xmlns='urn:xmpp:langtrans:items'>
    <item source_lang='en' jid='translation.shakespeare.lit' destination_lang='fr' 
          engine='SYSTRANS 2005 Release 2' pivotable='true'/>
    <item source_lang='en' jid='translation.shakespeare.lit' destination_lang='ko' 
          engine='SYSTRANS 2005 Release 2' pivotable='true'/>
    <item source_lang='en' jid='translation.shakespeare.lit' destination_lang='ru' 
          engine='SYSTRANS 2005 Release 2' pivotable='true'/>
    <item source_lang='en' jid='translation.shakespeare.lit' destination_lang='ru' 
          engine='SYSTRANS 2005 Release 2' pivotable='true' dictionary='medical'/>
    <item source_lang='fr' jid='translation.shakespeare.lit' destination_lang='en' 
          engine='SYSTRANS 2005 Release 2' pivotable='true' dictionary='standard'/>
    <item source_lang='ru' jid='translation.shakespeare.lit' destination_lang='en' 
          engine='SYSTRANS 2005 Release 2' pivotable='true' dictionary='Medical 1.0'/>
    <item source_lang='ko' jid='translation.shakespeare.lit' destination_lang='en' 
          engine='SYSTRANS 2005 Release 2' pivotable='true'/>
  </query>
</iq>

4.3 Requesting a Translation from a Service

4.3.1 Requesting a Basic Translation

To request service from a translation provider you can send a message to a provider requesting translations. The lack of a 'source_lang' attribute in the <translation/> element indicates a request for a translation.

Example 10. Entity requests a translation from English to French

<iq from='bard@shakespeare.lt/globe' id='translationReq_2' to='translation.shakespeare.lit' type='get'>
  <x xmlns='urn:xmpp:langtrans'>
    <source xml:lang='en'>How are you?</source>
    <translation destination_lang='fr'/>
  </x>
</iq>

Example 11. Translation is returned from translation provider

<iq type='result' id='translationReq_2' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'>
  <x xmlns='urn:xmpp:langtrans'>
    <source xml:lang='en'>hello, how are you?</source>
    <translation destination_lang='fr' source_lang='en' engine='default'>comment allez-vous?</translation>
  </x>
</iq>

4.3.2 Requesting a Translation With Multiple Destination Languages

Example 12. bard requests a translation from English to Italian and German

<iq from='bard@shakespeare.lt/globe' id='translationReq_4' to='translation.shakespeare.lit' type='get'>
  <x xmlns='urn:xmpp:langtrans'>
    <source xml:lang='en'>How are you?</source>
    <translation destination_lang='it'/>
    <translation destination_lang='de'/>
  </x>
</iq>

Example 13. Translation is returned from translation provider

<iq type='result' id='translationReq_4' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'>
  <x xmlns='urn:xmpp:langtrans'>
    <source xml:lang='en'>How are you?</source>
    <translation destination_lang='it' source_lang='en' engine='default'>Come siete?</translation>
    <translation destination_lang='de' source_lang='en' engine='default'>Wie geht es Ihnen?</translation>
  </x>
</iq>

4.3.3 Requesting a Translation With a Specific Dictionary

If a specific dictionary is required you MAY request a dictionary. This SHOULD have been returned when discoing the server although a dictionary MAY be requested which was not. The dictionaries are translation engine specific and are free form text.

Example 14. Requests a translation from English to French using the 'medical' dictionary

<iq from='bard@shakespeare.lt/globe' id='translationReq_6' to='translation.shakespeare.lit' type='get'>
  <x xmlns='urn:xmpp:langtrans'>
    <source xml:lang='en'>How are you?</source>
    <translation destination_lang='fr' dictionary='medical'/>
  </x>
</iq>

Example 15. Translation provider returns translation with dictionary details

<iq type='result' id='translationReq_6' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'>
  <x xmlns='urn:xmpp:langtrans'>
    <source xml:lang='en'>hello, how are you?</source>
    <translation 
        destination_lang='fr' 
        dictionary='medical' 
        engine='default'
        source_lang='en'>comment allez-vous?</translation>
  </x>
</iq>

If the translation service cannot complete the translation it SHOULD return a error indicating some part of the translation request was problematic, unless doing so would violate the privacy and security considerations in XMPP Core and XMPP IM, or local security and privacy policies.

Example 16. Translation could not be completed

<iq type='error' id='translationReq_7' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'>
  <x xmlns='urn:xmpp:langtrans'>
    <source xml:lang='en'>How are you?</source>
    <translation destination_lang='dy'/>
  </x>
  <error type='modify'>
    <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

If privacy or security considerations make returning an error not feasible it SHOULD return a error.

Example 17. Service unavailable

<iq type='error' id='translationReq_7' from='translation.shakespeare.lit' to='bard@shakespeare.lt/globe'>
  <x xmlns='urn:xmpp:langtrans'>
    <source xml:lang='en'>How are you?</source>
    <translation destination_lang='dy'/>
  </x>
  <error type='cancel'>
    <service-unavailable xmlns='urn:ietf:xml:params:ns:xmpp-stanzas'/>
  </error>
</iq>

5. Implementation Notes

In order to reduce user confusion and misunderstanding of a translated message body, it is RECOMMENDED that implementations of langtran implement the following user interface features.

  1. Translated messages should be clearly identified as being a translation.
  2. The display of translated message should clearly show how (automated, manual, automated with human review) a messaged was translated.
  3. The display of a message should clearly show if the translation is the destination, original or pivot language.
  4. If pivoting is used, the destination message text should be marked in such a way as to indicate that it was translated on one or more pivot languages, what those language are, in what order they were used, and the actual pivot language text should be accessible to the user.
  5. It is recommended that only one level of pivoting be used as quality of the destination translation degrades significantly after each pivot.

Note: The 'reviewed' and 'pivotable' attributes are of type "boolean" and MUST be handled accordingly. [3]

6. Internationalization Considerations

In order to properly process multi-language messages, clients MUST implement support for multiple message bodies differentiated by the 'xml:lang' attribute as described in RFC 6120.

7. Security Considerations

Potential attacks may be easier against services that implement translation because of the potential disclosure of information regarding language pairings, engines, and dictionaries used however no specific vulnerabilities are introduced.

This possible weakness can be mitigated by not returning specifics to requesting entities and the responding entity MAY perform authorization checks in order to determine how to respond.

8. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [4].

9. XMPP Registrar Considerations

9.1 Protocol Namespaces

The XMPP Registrar [5] includes 'urn:xmpp:langtrans' and 'urn:xmpp:langtrans:items' within its registry of protocol namespaces (see <http://xmpp.org/registrar/namespaces.html>).

Note: Before version 1.1 of this specification, the name of the items namespace was urn:xmpp:langtrans#items, however the '#' character is not recommended in URN syntax (see RFC 2141 [6]) so the name was changed to urn:xmpp:langtrans:items.

9.2 Service Discovery Identities

The XMPP Registrar includes type of "translation" in the "automation" category within its registry of service discovery identities (see <http://xmpp.org/registrar/disco-categories.html>).

10. XML Schema

10.1 langtrans

<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
    xmlns='urn:xmpp:langtrans' 
    xmlns:xs='http://www.w3.org/2001/XMLSchema' 
    targetNamespace='urn:xmpp:langtrans' 
    elementFormDefault='qualified'>
    
  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-0171: http://www.xmpp.org/extensions/xep-0171.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='x'>
    <xs:complexType>
      <xs:element ref='source' use='required'/>
      <xs:sequence>
        <xs:element ref='translation' use='required' minOccurs='1'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='source'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='xs:string'>
          <xs:attribute ref='xml:lang' use='required'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='translation'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='charset' type='xs:string' use='optional'/>
          <xs:attribute name='source_lang' type='xs:language' use='optional' />
          <xs:attribute name='destination_lang' type='xs:string' use='required'/>
          <xs:attribute name='dictionary' type='xs:string' use='required'/>
          <xs:attribute name='engine' type='xs:string' use='optional' />
          <xs:attribute name='reviewed' type='xs:boolean' use='optional' default='false'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>
        
  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>

10.2 langtrans:items

<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
    xmlns='urn:xmpp:langtrans:items' 
    xmlns:xs='http://www.w3.org/2001/XMLSchema' 
    targetNamespace='urn:xmpp:langtrans:items' 
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-0171: http://www.xmpp.org/extensions/xep-0171.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='query'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='item' minOccurs='0' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='item'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='dictionary' type='xs:string'/>
          <xs:attribute name='destination_lang' type='xs:language'/>
          <xs:attribute name='engine' type='xs:string' use='optional'/>
          <xs:attribute name='jid' type='xs:string' use='required'/>
          <xs:attribute name='name' type='xs:string' use='optional'/>
          <xs:attribute name='pivotable' type='xs:boolean' use='optional' default='false'/>
          <xs:attribute name='source_lang' type='xs:language' use='required'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>
        
  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>

Appendices

Appendix A: Document Information

Series: XEP
Number: 0171
Publisher: XMPP Standards Foundation
Status: Draft
Type: Standards Track
Version: 1.1rc1
Last Updated: in progress, last updated 2010-06-09
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP IM, XEP-0030
Supersedes: None
Superseded By: None
Short Name: langtrans
XML Schema for langtrans namespace: <http://www.xmpp.org/schemas/langtrans.xsd>
XML Schema for langtrans:items namespace: <http://www.xmpp.org/schemas/langtrans-items.xsd>
Source Control: HTML  RSS
This document in other formats: XML  PDF

Appendix B: Author Information

Boyd Fletcher

Email: boyd.fletcher@us.army.mil

Daniel LaPrade

Email: dlaprade@echostorm.net

Keith Lirette

Email: keith.lirette@tridsys.com

Brian Raymond

Email: braymond@echostorm.net

Appendix C: Legal Notices

Copyright

This XMPP Extension Protocol is copyright © 1999 - 2011 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <http://xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XMPP Standards Foundation, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

1. RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>.

2. XEP-0030: Service Discovery <http://xmpp.org/extensions/xep-0030.html>.

3. In accordance with Section 3.2.2.1 of XML Schema Part 2: Datatypes, the allowable lexical representations for the xs:boolean datatype are the strings "0" and "false" for the concept 'false' and the strings "1" and "true" for the concept 'true'; implementations MUST support both styles of lexical representation.

4. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

5. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://xmpp.org/registrar/>.

6. RFC 2141: URN Syntax <http://tools.ietf.org/html/rfc2141>.

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

Version 1.1rc1 (in progress, last updated 2010-06-09)

With author approval, the XMPP Registrar changed the items namespace from urn:xmpp:langtrans#items to urn:xmpp:langtrans:items because # is not recommended in URN syntax.

(psa)

Version 1.0 (2008-05-09)

Per a vote of the XMPP Council, advanced status to Draft.

(psa)

Version 0.3 (2008-02-01)

Modified semantics to use IQ stanzas for communication with servers; changed dst_lang to destination_lang and src_lang to source_lang; changed destination to destination_lang and derived_from to source_lang.

(kl/bf)

Version 0.2 (2006-04-24)

Added text about use of Thread IDs.

(psa)

Version 0.1 (2006-01-24)

Initial version.

(psa)

Version 0.0.4 (2006-01-17)

Converted to XML format, cleaned up text, modified examples, changed pivotable and reviewed attributes to xs:boolean, corrected schema.

(psa)

Version 0.0.3 (2006-01-16)

Changed xml:lang to destination, derived to derived_from; added service discovery identity.

(bf)

Version 0.0.2 (2005-12-28)

Miscellaneous edits.

(bf)

Version 0.0.1 (2005-12-21)

First draft.

(bf)

END