commit 2ac91f50c862f5ebccba409789c4a1c2f8dac461 Author: Peter Saint-Andre Date: Mon Oct 2 22:22:13 2006 +0000 Initial revision git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2 4b5297f7-1745-476d-ba37-a9c6900126ab diff --git a/all.sh b/all.sh new file mode 100755 index 00000000..192295e1 --- /dev/null +++ b/all.sh @@ -0,0 +1,31 @@ +#!/bin/sh +# for each XEP, generates HTML file and IETF reference, then copies XML file +# also generates HTML for the README and template +# finally, copies the stylesheet, DTD, and schema +# usage: ./all.sh + +xeppath=/var/www/stage.xmpp.org/extensions + +ls xep-0*.xml > tmp.txt +sed s/xep-\(.*\).xml/\1/ tmp.txt > nums.txt +rm tmp.txt + +while read f +do + xsltproc xep.xsl xep-$f.xml > $xeppath/xep-$f.html + xsltproc ref.xsl xep-$f.xml > $xeppath/refs/reference.JSF.XEP-$f.xml + cp xep-$f.xml $xeppath/ +done < nums.txt + +rm nums.txt + +xsltproc xep.xsl xep-README.xml > $xeppath/README.html +xsltproc xep.xsl xep-template.xml > $xeppath/template.html + +cp xep.dtd $xeppath/ +cp xep.ent $xeppath/ +cp xep.xsd $xeppath/ +cp xep.xsl $xeppath/ + +# END + diff --git a/announce.py b/announce.py new file mode 100755 index 00000000..113aa6ad --- /dev/null +++ b/announce.py @@ -0,0 +1,187 @@ +#!/usr/bin/env python + +# File: announce.py +# Version: 0.8 +# Description: a script for announcing XEPs +# Last Modified: 2006-10-03 +# Author: Peter Saint-Andre (stpeter@jabber.org) +# License: public domain +# HowTo: ./announce.py xepnum dbuser dbpw 'cvsmodsurl' +# NOTE: the cvsmodsurl MUST be in quotes! + +# IMPORTS: +# +import glob +import MySQLdb +import os +from select import select +import smtplib +import socket +from string import split,strip,join,find +import sys +import time +from xml.dom.minidom import parse,parseString,Document + +def getText(nodelist): + thisText = "" + for node in nodelist: + if node.nodeType == node.TEXT_NODE: + thisText = thisText + node.data + return thisText + +# get the seconds in the Unix era +now = int(time.time()) + +# READ IN ARGS: +# +# 1. XEP number +# 2. database user +# 3. database password + +xepnum = sys.argv[1]; +dbuser = sys.argv[2]; +dbpw = sys.argv[3]; +mods = sys.argv[4]; + +xepfile = 'xep-' + xepnum + '.xml' + +# PARSE XEP HEADERS: +# +# - title +# - abstract +# - version +# - date +# - initials +# - remark + +thexep = parse(xepfile) +xepNode = (thexep.getElementsByTagName("xep")[0]) +headerNode = (xepNode.getElementsByTagName("header")[0]) +titleNode = (headerNode.getElementsByTagName("title")[0]) +title = getText(titleNode.childNodes) +abstractNode = (headerNode.getElementsByTagName("abstract")[0]) +abstract = getText(abstractNode.childNodes) +statusNode = (headerNode.getElementsByTagName("status")[0]) +xepstatus = getText(statusNode.childNodes) +typeNode = (headerNode.getElementsByTagName("type")[0]) +xeptype = getText(typeNode.childNodes) +revNode = (headerNode.getElementsByTagName("revision")[0]) +versionNode = (revNode.getElementsByTagName("version")[0]) +version = getText(versionNode.childNodes) +dateNode = (revNode.getElementsByTagName("date")[0]) +date = getText(dateNode.childNodes) +initialsNode = (revNode.getElementsByTagName("initials")[0]) +initials = getText(initialsNode.childNodes) +remNode = (revNode.getElementsByTagName("remark")[0]) +# could be

or

+ + +

Implementations may wish to restrict who is allowed to join workgroups as users and agents. Details concerning the implementation of this feature is outside the scope of this document.

+ + +

This document requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; shall include 'http://jabber.org/protocol/workgroup' in its registry of protocol namespaces.

+ + +

The Jabber Registrar shall add a Service Discovvery type of "workgroup" to the existing "collaboration" category. The registry submission is as follows:

+ + collaboriation + + workgroup + A workgroup component. + JEP-0142 + + + ]]> + + + + + + + + + + The allowable root elements for the namespace defined + herein are: + - agent-status + - agent-status-request + - depart-queue + - join-queue + - notify-agents + - notify-queue + - notify-queue-details + - offer + - offer-accept + - offer-reject + - offer-revoke + - queue-status + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + +

The author would like to thank Iain Shigeoka for his work on the first version of this document, and Derek DeMoro and Gaston Dombiak for their comments.

+ + diff --git a/xep-0143.xml b/xep-0143.xml new file mode 100644 index 00000000..a9a08db6 --- /dev/null +++ b/xep-0143.xml @@ -0,0 +1,244 @@ + + +%ents; +]> + + +
+ Guidelines for JEP Authors + This JEP provides information intended to assist authors of Jabber Enhancement Proposals. + &LEGALNOTICE; + 0143 + Active + Procedural + Standards JIG + Council + + JEP-0001 + + + + N/A + &stpeter; + + 1.0 + 2004-12-09 + psa +

Per a vote of the Jabber Council, advanced status to Active.

 + + + 0.4 + 2004-10-22 + psa +

Further clarifications.

 + + + 0.3 + 2004-10-12 + psa +

Minor clarifications throughout.

 + + + 0.2 + 2004-09-16 + psa +

Described JEP metadata elements.

 + + + 0.1 + 2004-09-15 + psa +

Initial version (adapted from JEP template).

 + +
+ +

The &JSF; receives a significant number of proposals for defining extensions to the core XMPP protocols specified in &xmppcore;. However, it is not always clear to authors how to best structure a proposal in order for it to be accepted as a Jabber Enhancement Proposal (JEP) and then advance through the JSF's standards process. Therefore, this JEP provides guidelines that are intended to help authors write better JEPs.

+

These guidelines assume that the reader is familiar with the JEP series of documents and the processes for handling them within the JSF, as defined in &jep0001;.

+ + +

The prospective author is strongly encouraged to complete some research before submitting a proposal for consideration as a JEP. In particular, the author should do the following:

+
    +
  • Review the XMPP RFCs and experimental or approved JSF JEPs to determine if the proposed protocol extension is truly needed in order to fill a gap in existing Jabber/XMPP technologies and protocols.
    • +
  • Review rejected and deferred JEPs to determine if similar extensions have been proposed in the past but not approved by the &COUNCIL;.
    • +
  • Review protocols developed within other standards development organizations, such as the &IETF; and &W3C;, to determine if they might be more appropriate than a new XMPP extension.
    • +
  • Review discussions within the &SJIG; to determine if similar functionality has been discussed in the past or is currently under discussion.
    • +
+

After completing this research, the prospective author may conclude that a new protocol extension is needed. If so, the author is strongly advised to do the following:

+
    +
  1. Review JEP-0001 and the &jep0134;.
    2. +
  2. Understand the Submission Process.
    3. +
  3. Become familiar with the JEP XML Format.
    4. +
  4. Then and only then write a proposal that includes all of the appropriate Sections of a JEP.
    5. +
  5. Review the content to ensure that it conforms to the JEP Styleguide.
    6. +
+ + +

The process for submitting a JEP is straightforward:

+
    +
  1. Contact the &EDITOR; so that he knows to expect your submission.
    2. +
  2. Write your proposal following the guidelines described herein.
    3. +
  3. Make sure you read, understand, and agree to the &JSFIPR; before you submit your proposal.
    4. +
  4. Send your XML file (or a URL for the file) to the JEP Editor.
    5. +
+ + +

The JEP XML format is substantially similar to a reduced set of XHTML. This is intentional: it makes authoring JEPs easier. In fact, if you use the JEP template file with its associated XSLT stylesheet, you should be able to view your proposal in most modern web browsers (see below). The following subsections explain how to get started with JEP authoring and describe the XML format used for JEPs (see the jep.xsd or jep.dtd file for a formal description).

+ +

The best way to start working on your proposal is to retrieve all of the existing JEPs and associated stylesheets from source control. These files are stored using the CVS system, in a CVS module labelled 'jeps' at the jabberstudio.org CVS repository. Instructions for accessing these files are provided at <http://www.jabberstudio.org/cvs.php>. The document structure is formally defined by both a DTD and an XML schema, but you do not need to understand the formal descriptions in order to author a JEP. In addition, a handy template file is included under the 'templates/' directory in the 'jeps' module, providing a quick starting point for JEP authoring.

+

To create your proposal, do a CVS checkout of the 'jeps' module, create a new directory (e.g., 'tmp/') for your JEP within the existing 'jeps/' directory, copy the template file from the 'template/' directory to your new directory, and start editing the file using either a basic text editor or a specialized XML editing application such as XML Spy or XMLmind.

+

Even if you use a basic text editor, you should be able to view your JEP in most modern web browsers as an XML file as long as you have jep.xsl and jep.dtd in the 'jeps/' directory (i.e., the parent of the directory for your specific JEP). Because of inconsistencies in browser XSLT implementations, certain formatting (e.g., table layouts and the numbering of tables, examples, and footnotes) may not be perfect. Don't panic; it will look fine in the HTML output produced by the JEP Editor. If your XML file doesn't render at all (i.e., it's just one big text blob), you are using the wrong browser. If you see only the bare outline generated by jep.xsl but none of your text, you have an error in your XML. You can check your XML syntax at xml.com <http://www.xml.com/pub/a/tools/ruwf/check.html>.

+

To programatically convert your XML file into HTML, we recommend using Daniel Veillard's xsltproc program, which will give you helpful error messages regarding XML syntax problems. However, the JEP Editor will do the final rendering of XML into HTML as well as posting of your HTML file to the JSF website, so you do not need to generate HTML files for submission to the JEP Editor (in fact, the JEP Editor requires that you submit your proposal in the JEP XML format, not HTML).

+

Finally, the jep.ent file contains convenient "external entities" that provide shortcuts for including references to JEPs, RFCs, and other common strings. Unfortunately, most browsers do not correctly process external entities, so you cannot include entities from jep.ent if you need to view your XML source file in a browser. However, the JEP Editor reserves the right to convert your markup to external entities, since it makes his life easier. Also, please do not add items to the jep.ent file; instead, ask the JEP Editor to add them for you.

+ + +

This section describes the metadata elements contained in the <header/> element of a JEP file (see below for the file contents).

+

The XML character data of the <title/> element is the title of your JEP. Choose a descriptive title that is less than five words long. The JEP Editor may change this in consultation with the author.

+

The XML character data of the <abstract/> element SHOULD be one sentence that captures the essence of your proposal (usually beginning "This JEP defines a protocol that..."). The JEP Editor has been known to modify the abstract so that it accurately describes the proposal.

+

The XML character data of the <legal/> element MUST be as follows:

+

This Jabber Enhancement Proposal is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy (http://jabber.org/jsf/ipr-policy.php). This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/).

+

The XML character data of the <number/> element SHOULD be "xxxx"; this will be changed to the next sequential JEP number by the JEP Editor if the Jabber Council accepts the proposal as a JEP.

+

The XML character data of the <status/> element SHOULD be "ProtoJEP" since all proposals start out as "proto-JEPs"; this will be changed to "Experimental" if the Jabber Council accepts the proposal as a JEP.

+

The XML character data of the <type/> element SHOULD be either "Standards Track" or "Informational" (there are also Historical, Humorous, and Procedural JEPs, but these are uncommon and usually written by the JEP Editor). A Standards Track JEP is basically any JEP that defines a protocol to be used in the Jabber community. An Informational JEP defines best practices or a usage profile related to an existing protocol (e.g., &jep0126;).

+

The XML character data of the <approver/> element SHOULD be "Council".

+

The <dependencies/> element is used to specify JEPs, RFCs, and other specifications on which your proposal depends in a normative fashion (i.e., specifications that MUST or SHOULD be understood in order to implement your proposed protocol). Each specification MUST be identified by a distinct <spec/> child element (see existing JEPs for clues regarding document identifiers, or consult with the JEP Editor).

+

The <supersedes/>, <supersededby/>, <shortname/>, and <schemaloc/> elements are for use by the JEP Editor; however, if your JEP supersedes an existing JEP, feel free to include a <spec/> child element specifying the document identifier (e.g., JEP-0093) for the protocol that is being superseded.

+

Include one <author/> element for each co-author. Note well that the <firstname/>, <surname/>, <email/>, and <jid/> elements are all REQUIRED per JEP-0001.

+

Include one <revision/> element for each revision of your JEP. The XML character data of the <version/> element SHOULD be "0.0.1" for your initial submission to the JEP Editor, and the <remark/> SHOULD be "Initial version."; for each revision, you will include another <revision/> element (place it before the existing <revision/> elements) and iterate the <version/> element (e.g., "0.2" after "0.1"). The format for the <date/> element is yyyy-mm-dd. Please do not include the characters ' or " in your revision remarks.

+ + +

Aside from the metadata in the JEP <header/> element (see above), a JEP file is a series of sections, arranged in a hierarchy (<section1/> is a top-level section, within which you can nest <section2/> sections, and so on down to <section4/>). The title of a section is captured in the 'topic' attribute. You should also include an 'anchor' element so that you can link to page fragments from within your JEP. The allowable elements within a section element probably look familiar from XHTML: <p/> for paragraphs, <ol/> and <ul/> for ordered and unordered lists, and so on.

+

The <example/> and <code/> elements are used to show protocol snippets; the <example/> element SHOULD possess a 'caption' attribute that describes the example, whereas the <code/> element does not. Define an XML CDATA section within both of these elements so that you do not need to escape the '<' and '>' characters in your sample XML stanzas, since this makes life much easier for author and editor alike (see the markup in existing JEPs).

+

The <p/> and <li/> elements can also contain more markup that is familiar from XHTML, such as the <img/> element. Note that hyperlinks are of the form <link url='foo'>bar</link> rather than <a href='foo'>bar</a>; the reasons for this are lost in the mists of time and it is too late to change it now, so you'll just have to adjust. If needed, you can also use inline structural and presentational markup such as <em/>, <strong/>, <tt/>, <cite/>, and <span/> within the <p/> and <li/> elements.

+

You may also include tables (these are helpful for listing error codes and such). The <table/> element SHOULD possess a 'caption' attribute that describes the table's contents. Standard XHTML table structure applies (<tr/> defines a row, which contains <th/> elements for header rows and <td/> elements for data rows), and the 'colspan' and 'rowspan' attributes are also available if you need them. Table presentation (such as cellpadding and cellspacing) is handled by the XSLT and CSS stylesheets.

+

In fact, the jep.xsl file performs all sorts of magic in converting your XML file into HTML, including creation of the front matter, table of contents, section numbering, notes, and revision history. Feel free to submit patches for this file, but do not commit your modified version to CVS.

+ + + +

Most JEPs will have most of the following sections, usually in something like the order shown. Other sections may be appropriate (e.g., &jep0071; has a section for W3C Considerations). Use your best judgment regarding the sections you need in order to make your argument, or consult with the JEP Editor regarding your needs.

+ +

The introduction to a JEP is quite important since it provides the rationale for considering the proposal. In particular, the introduction SHOULD include information such as the following:

+
    +
  1. Tasks that users currently cannot complete because we are lacking the protocol you propose. (Note: Users are not just IM users, but any person, system, or application that could gain value from interacting with other entities over Jabber/XMPP networks.)
    2. +
  2. Other projects or protocols and how Jabber/XMPP technologies could interface with them because of your proposed protocol (e.g., XML-RPC, SOAP).
    3. +
  3. A comparison between Jabber/XMPP technologies and "the competition" (e.g., other IM systems or messaging protocols) that describes holes in the Jabber/XMPP protocols that need to be filled in order to offer similar functionality.
    4. +
  4. The relevant history of thinking within the Jabber/XMPP community.
    5. +
  5. Real-world examples of problems the protocol can solve.
    6. +
+ + +

Every JEP SHOULD include a section describing the requirements being addressed by the JEP. This information is critically important, because it clearly defines the scope of the proposal as well as any relevant constraints on the protocol design.

+ + +

If your JEP uses terms that may not be familiar to the reader, please define them in a glossary.

+ + +

It is recommended that JEP authors structure their proposals according to the use cases that the proposal will address. A good introduction to use cases may be found at <http://www.pols.co.uk/usecasezone/>. We have found that use cases force JEP authors to focus on functionality rather than "protocol for the sake of protocol". It is also helpful to sort use cases by actor, as is done in &jep0045;, for example. Include one subsection for each use case.

+

When writing use cases and the associated protocols, make sure to:

+
    +
  • Clearly define the success scenarios, alternate flows, and possible errors.
    • +
  • Describe the expected behavior of Jabber clients, servers, and components when using this protocol.
    • +
  • Include lots of protocol examples.
    • +
+

We just said so, but we will repeat ourselves: include lots of protocol examples. Examples help not only implementors but also those who will review your proposal in the Standards JIG and Jabber Council. You get extra credit with the JEP Editor if you follow Jabber tradition by using characters and situations from the plays of Shakespeare:

+ + Wherefore art thou, Romeo? + + ]]> + + +

If your proposal defines a number of error and status codes (as is done in JEP-0045), it is a good idea to include a table of all the codes defined in your document.

+ + +

You may want to include a section describing various business rules (essentially, a variety of MUSTs, SHOULDs, and MAYs regarding application behavior). This is not required but can be helpful to implementors.

+ + +

You may want to include a section devoted to implementation notes. Again, this is not required but can be helpful to implementors.

+ + +

If there are any internationalization or localization issues related to your proposal (e.g., whether to include the 'xml:lang' attribute), define them in this optional section.

+ + +

Your proposal MUST include a section entitled "Security Considerations". Even if there are no security features or concerns related to your proposal, you MUST note that fact. For helpful guidelines, refer to &rfc3552;.

+ + +

This section is REQUIRED. The IANA is the Internet Assigned Numbers Authority, the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. Most proposals do not require interaction with the IANA, in which case the text of this section SHOULD read "This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA)." If your proposal requires interaction with the IANA, discuss the matter with the JEP Editor. Do not contact the IANA on your own!

+ + +

This section is REQUIRED. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. If your proposal does not require interaction with the Jabber Registrar, the text of this section SHOULD read "No namespaces or parameters need to be registered with the Jabber Registrar as a result of this JEP." Refer to Draft or Final JEPs for appropriate text in other cases, or consult with the JEP Editor.

+ + +

An XML Schema is required in order for a protocol JEP to be approved by the Jabber Council. The JEP Editor can assist you in defining an XML Schema for the protocol you are proposing.

+ + +

Some JEPs end with a section thanking non-authors who have made significant contributions to the specification; if that is true of your JEP, feel free to include this section.

+ + + +

Note: JEP authors can consider this section as a kind of "Implementation Notes". :-)

+

JEPs are written in English. It is not expected that you will be a fine prose writer, but try to write in a clear, easily-understood fashion. The JEP Editor will correct any errors of grammar, spelling With all due respect to authors in other parts of the world, JEPs follow American spelling conventions; thus "authorisation" will be changed to "authorization" and such., punctuation, and usage he may find in your proposal, but may not do so until your proposal is in the Jabber Council's queue for consideration. In addition, the JEP Editor reserves the right to improve phrases that are unclear or infelicitous, move sections around, modify examples to use Shakespearean characters, and otherwise improve the argument and logical flow of your proposal (naturally, without changing the meaning).

+

The following styleguide is provided to supplement the standard English styleguides, such as The Elements of Style See <http://en.wikipedia.org/wiki/The_Elements_of_Style>. and The Chicago Manual of Style See <http://en.wikipedia.org/wiki/The_Chicago_Manual_of_Style>.; please refer to those resources for information about common English (especially American English) usage and to this styleguide for JEP-specific guidelines.

+ +

When talking about an attribute by name, refer to it in single quotes. Example: the 'to' attribute.

+

When talking about the value of an attribute, refer to it in double quotes. Example: the value of the 'subscription' attribute is "both".

+

Elements possess attributes and contain character data and/or child elements; do not confuse these terms.

+ + +

In examples, use single quotes rather than double quotes; they are more readable.

+

To show the hierarchy of XML elements, indent two spaces for every level.

+

If an element possesses a large number of attributes, include a line break before each attribute and indent them so that they are vertically aligned for readability.

+

If the XML character data of an element is long, include line breaks and indent by two spaces.

+

Examples are the major source of right-scrolling in our HTML output files. Right-scrolling is evil. Therefore, adjust your example layouts accordingly (line widths should be no more than 110 characters or so).

+

Example:

+ + + + Configuration for "darkcave" Room + + Please complete this form to make changes to the configuration + of your room; to add room owners and administrators, use the + appropriate room commands rather than this form. + + + http://jabber.org/protocol/muc#roomconfig + + + + ]]> +

Some examples (e.g., SASL examples) include strings that are encoded using Base64 (see &rfc3548;). An easy way to generate these is to place the source text in a file and use the OpenSSL "enc" command to generate the base64-encoded equivalent. For example, if the file "tmp.txt" contains the string "bard@shakespeare.lit" then the command 'openssl enc -base64 -in tmp.txt' will generate the base64-encoded string "YmFyZEBzaGFrZXNwZWFyZS5saXQK".

+

Some examples (e.g., avatar examples) include strings that are SHA-1 hashes (see &rfc3174;). An easy way to generate these is to place the source text in a file and use the OpenSSL "dgst" command to generate the SHA-1 hash. For example, if the file "tmp.txt" contains the string "bard@shakespeare.lit" then the command 'openssl dgst -sha1 tmp.txt' will generate the SHA-1 hash "e87f5008d779053ac53b29b335b7be8820d5c303".

+ + +

Conformance terms (e.g,, "MUST" and "SHOULD") are specified in RFC 2119. Use them. When such terms are not in ALL CAPS, the special conformance sense does not apply (this should be obvious but may not be to all authors).

+ + +

When talking about an element by name, refer to it as an empty XML element. Example: the <query/> element.

+

The top-level &MESSAGE;, &PRESENCE;, and &IQ; elements are actually XML stanzas (see RFC 3920); refer to them as such.

+

Elements possess attributes and contain character data and/or child elements; do not confuse these terms.

+

Do not use the term "tag" when you mean "element".

+

Do not add a possessive to the element itself. Negative example: the <body/>'s character data. Positive example: the <body/> element's character data.

+

Note: There are shortcuts for stanza names and some common element names in the jep.ent file.

+ + +

When talking about an error condition, use the XML element names defined in RFC 3920 rather than the old HTTP-style code numbers. Example: the <feature-not-implemented/> error.

+

Note: There are shortcuts for the stanza errors in the jep.ent file.

+ + +

When talking about a namespace by name, refer to it in single quotes. Example: the 'jabber:iq:roster' namespace.

+

An element or attribute is qualified by (rather than "scoped by" or "in") a particular namespace.

+ + +

For precision, the JSF follows IETF usage by placing all punctuation outside the quotation marks unless one is quoting text that includes the punctuation. Example: the port used for Jabber client communications is "5222".

+ + + diff --git a/xep-0144.xml b/xep-0144.xml new file mode 100644 index 00000000..82795485 --- /dev/null +++ b/xep-0144.xml @@ -0,0 +1,323 @@ + + +%ents; +]> + + +
+ Roster Item Exchange + This JEP defines a protocol for exchanging roster items, including the ability to suggest whether the item is to be added, deleted, or modified. + &LEGALNOTICE; + 0144 + Draft + Standards Track + Standards JIG + + XMPP Core + XMPP IM + + + JEP-0093 + + + rosterx + + http://jabber.org/protocol/rosterx/rosterx.xsd + + &stpeter; + + 1.0 + 2005-08-26 + psa + Per a vote of the Jabber Council, advanced status to Draft. + + + 0.6 + 2005-07-28 + psa + Incorporated Council feedback: specified that a body MAY be included when sending a message stanza; changed prohibition on mixing of additions, deletions, and modifications from SHOULD NOT to MUST NOT; clarified status of bots as sending entities. + + + 0.5 + 2005-07-26 + psa + Reverted roster item deletion changes. + + + 0.4 + 2005-07-21 + psa + Simplified processing of roster item deletions. + + + 0.3 + 2004-10-27 + psa + Clarified the nature of sending entities (users, gateways, and group services); specified "directory/group" service discovery identity for shared group services. + + + 0.2 + 2004-10-04 + psa + Further defined the nature of trusted entities. + + + 0.1 + 2004-09-29 + psa + Initial JEP version. + + + 0.0.2 + 2004-09-22 + psa + To address Council feedback, added text about service discovery and choice of stanza type (message or IQ). + + + 0.0.1 + 2004-09-16 + psa + Forked JEP-0093 by adding the action attribute, defining requirements and use cases, specifying processing rules, and detailing security considerations. + +
+ +

The Jabber protocols have long included a method for sending roster items from one entity to another, making use of the 'jabber:x:roster' namespace. Because this protocol extension was not required by &rfc2779;, it was removed from &xmppim; and documented for historical purposes in &jep0093;. However, since that time discussions in the &SJIG; have revealed that it would be helpful to use roster item exchange in the problem spaces of "shared groups" (e.g., predefined roster groups used within an organization) and roster synchronization (e.g., keeping a Jabber roster in sync with a contact list on a legacy IM service). These problem spaces require a slightly more sophisticated kind of roster item exchange than was documented in JEP-0093, specifically the ability to indicate whether a roster item is to be added, deleted, or modified. Therefore this JEP redefines roster item exchange to provide this functionality in a way that is backwards-compatible with existing implementations, albeit using a modern namespace URI of 'http://jabber.org/protocol/rosterx' rather than the old 'jabber:x:roster' namespace name. Further JEPs will specify how to solve the problems of shared groups and roster synchronization using the protocol defined herein.

+ + +

JEP-0093 did not define the requirements for roster item exchange. This section remedies that oversight.

+

Roster item exchange meets the following requirements:

+
    +
  1. Enable an entity to send one or more roster items to another entity, with the suggestion that the roster item(s) be added to the recipient's roster.
    2. +
  2. Enable an entity to send one or more roster items to another entity, with the suggestion that the roster item(s) be deleted from the recipient's roster.
    3. +
  3. Enable an entity to send one or more roster items to another entity, with the suggestion that the roster item(s) be modified in the recipient's roster.
    4. +
+

This JEP deliberately speaks of rosters and roster items, not presence subscriptions. Although rosters and subscriptions are closely connected (as explained in RFC 3921), they are not identical. The protocol defined herein enables an entity to suggest that another entity might want to add, delete, or modify roster items only, and does not dictate the suggested presence subscription state associated with those roster items. This is intentional.

+ + + +

In order to programatically suggest that the receiving entity should add one or more items to its roster, the sending entity MUST send a &MESSAGE; or &IQ; stanza containing an &X; element qualified by the 'http://jabber.org/protocol/rosterx' namespace (see Recommended Stanza Type regarding when to use &MESSAGE; and when to use &IQ;); the &X; element in turn MUST contain one or more <item/> child elements, each of which SHOULD possess an 'action' attribute whose value is "add" The default value of the 'action' attribute is "add"; therefore, if the 'action' attribute is not included or the receiving application does not understand the 'action' attribute, the receiving application MUST treat the item as if the value were "add"., MUST possess a 'jid' attribute that specifies the JabberID of the item to be added, MAY possess a 'name' attribute that specifies a natural-language name or nickname for the item, and MAY contain one or more <group/> elements specifying roster groups into which to place the item. If a &MESSAGE; stanza is sent, it MAY contain a &BODY; element but SHOULD NOT contain any other child elements. Here is an example:

+ + Some visitors, m'lord! + + + Visitors + + + Visitors + + + + ]]> +

In determining how to handle any given roster item whose 'action' attribute has a value of "add" (either explicitly or as the default value), the receiving application SHOULD proceed as follows:

+
    +
  1. If the item already exists in the roster and the item is in the specified group (or no group is specified), the receiving application MUST NOT prompt a human user for approval regarding that item and MUST NOT add that item to the roster.
    2. +
  2. If the item does not already exist in the roster, the receiving application SHOULD prompt a human user for approval regarding that item and, if approval is granted, MUST add that item to the roster.
    3. +
  3. If the item already exists in the roster but not in the specified group, the receiving application MAY prompt the user for approval and SHOULD edit the existing item so that will also belong to the specified group (in addition to the existing group, if any).
    4. +
+

If the roster item addition stanza will result in adding the item to the roster, the receiving application MUST (either with approval by a human user or automatically subject to configuration) send a roster set to the user's server containing the new item as described in RFC 3921. After completing the roster set, the receiving application SHOULD also send a &PRESENCE; stanza of type "subscribe" to the JID of the new item.

+

For a description of the recommended application behavior when a roster item addition stanza actually results in editing of an existing roster item, refer to the Suggesting Roster Item Modification section of this document.

+ + +

In order to programatically suggest that the receiving entity should delete one or more items from its roster, the sending entity MUST send a &MESSAGE; or &IQ; stanza containing an &X; element qualified by the 'http://jabber.org/protocol/rosterx' namespace; the &X; element in turn MUST contain one or more <item/> child elements, each of which MUST possess an 'action' attribute whose value is "delete", MUST possess a 'jid' attribute that specifies the JabberID of the item to be added, MAY possess a 'name' attribute that specifies a natural-language name or nickname for the item, and MAY contain one or more <group/> elements specifying roster groups for the item. If a &MESSAGE; stanza is sent, it MAY contain a &BODY; element but SHOULD NOT contain any other child elements. Here is an example:

+ + + + Visitors + + + Visitors + + + + ]]> +

In determining how to handle any given roster item whose 'action' attribute has a value of "delete", the receiving application SHOULD proceed as follows:

+
    +
  1. If the item does not exist in the roster, the receiving application MUST NOT prompt a human user for approval regarding that item and MUST NOT delete that item from the roster.
    2. +
  2. If the item exists in the roster but not in the specified group, the receiving application MUST NOT prompt the user for approval and MUST NOT delete the existing item.
    3. +
  3. If the item exists in the roster and is in both the specified group and another group, the receiving application MAY prompt the user for approval and SHOULD edit the existing item so that it no longer belongs to the specified group.
    4. +
+

If the item is to be deleted, the receiving application SHOULD remove the item from the roster by sending a roster set to the user's server with the 'subscription' attribute set to a value of "remove" as described in RFC 3921, since this results in generation of the appropriate &PRESENCE; stanzas by the user's server.

+ + +

In order to programatically suggest that the receiving entity should modify one or more items from its roster, the sending entity MUST send a &MESSAGE; or &IQ; stanza containing an &X; element qualified by the 'http://jabber.org/protocol/rosterx' namespace; the &X; element in turn MUST contain one or more <item/> child elements, each of which MUST possess an 'action' attribute whose value is "modify", MUST possess a 'jid' attribute that specifies the JabberID of the item to be added, MAY possess a 'name' attribute that specifies a natural-language name or nickname for the item, and MAY contain one or more <group/> elements specifying roster groups into which to place the item. If a &MESSAGE; stanza is sent, it MAY contain a &BODY; element but SHOULD NOT contain any other child elements. Here is an example:

+ + + + Retinue + + + Retinue + + + + ]]> +

In determining how to handle any given roster item whose 'action' attribute has a value of "modify", the receiving application SHOULD proceed as follows:

+
    +
  1. If the item does not exist in the roster, the receiving application MUST NOT prompt a human user for approval regarding that item and MUST NOT add that item to the roster.
    2. +
  2. If the item exists in the roster and the modification results in a change of group only, the receiving application MAY prompt the user for approval and SHOULD move the item to the specified group.
    3. +
  3. If the item exists in the roster and the modification results in adding the item to a new group in addition to its existing group, the receiving application MAY prompt the user for approval and SHOULD add the item to the specified group.
    4. +
  4. If the item exists in the roster and the modification results in a change of name only, the receiving application MAY prompt the user for approval and SHOULD modify the name to that specified in the modification suggestion.
    5. +
+

If a roster item addition, deletion, or modification stanza will result in editing of an existing item in the roster, the receiving application MUST (either with approval by a human user or automatically subject to configuration) send a roster set to the user's server with no changes to the 'subscription' attribute but rather with appropriate changes to the value of 'name' attribute or the <group/> child element or elements, as described in RFC 3921.

+ + + +

In order to determine whether a receiving entity supports the protocol defined herein, the sending entity SHOULD use &jep0030; but MAY depend on the "profile" of Service Discovery defined in &jep0115;. If an entity supports roster item exchange, it MUST (subject to appropriate security considerations as described under Advertising Support) include <feature var='http://jabber.org/protocol/rosterx'/> in its responses to disco#info queries. Thus a sending entity can discover if a receiving entity supports the protocol defined herein by sending an IQ request of the following form:

+ + + + ]]> +

The receiving entity then indicates its support:

+ + + ... + + ... + + + ]]> + + +

If the sending entity has knowledge (e.g., via presence or an active chat conversation) that the receiving entity is online and available, it SHOULD: If the receiving entity has more than one available resource, the sending application SHOULD communicate with the "most available" resource according its best estimation (e.g., the resource with the highest priority).

+
    +
  1. Discover if the receiving entity supports the protocol defined herein (see the Service Discovery section of this document).
    2. +
  2. If so, send its roster item exchange stanza to a particular resource (user@host/resource) of the receiving entity using an &IQ; stanza rather than a &MESSAGE; stanza.
    3. +
+

If the sending entity does not know that the receiving entity is online and available, it MUST send a &MESSAGE; stanza to the receiving entity's "bare JID" (user@host) rather than an &IQ; stanza to a particular resource.

+ +

If the sending entity uses &IQ; stanzas to communicate its roster item exchange suggestions, the receiving entity MUST adhere to the IQ semantics defined in &xmppcore;. Specifically:

+
    +
  1. If the receiving entity successfully processes the suggested action(s) (which may include ignoring certain suggestions), the receiving entity MUST return an empty IQ result to the sending entity.
    2. +
  2. If the receiving entity does not understand the roster item exchange namespace, the receiving entity MUST return an error to the sending entity, which error SHOULD be &unavailable;.
    3. +
  3. If the receiving entity will not process the suggested action(s) because the receiving entity is not registered with the sending entity, the receiving entity MUST return an error to the sending entity, which error SHOULD be ®istration;.
    4. +
  4. If the receiving entity will not process the suggested action(s) because the sending entity is not in the receiving entity's roster, the receiving entity MUST return an error to the sending entity, which error SHOULD be ¬authorized;.
    5. +
  5. If the receiving entity will not process the suggested action(s) because the sending entity is not trusted (see Trusted Entities), the receiving entity MUST return an error to the sending entity, which error SHOULD be &forbidden;.
    6. +
+

Naturally, other IQ errors may be more appropriate; however, if the receiving entity will not or cannot process the suggested action(s), it MUST return an error to the sending entity.

+ + + +
    +

  1. The sending entity or sending application MUST NOT send additions, deletions, and modifications in the same &X; element and &MESSAGE; or &IQ; stanza; instead, it SHOULD send separate stanzas for the additions, deletions, and modifications.

    2. +

  2. If approval is required or recommended regarding more than one item suggested by the sending entity, the receiving entity SHOULD present all of the items for approval at the same time or in the same interface.

    3. +

  3. If the sending entity is in some sense "trusted" (see Trusted Entities), then the receiving application MAY skip the approval steps described above.

    4. +

  4. The receiving application SHOULD NOT accept an unreasonable number of roster items from any one sending entity at one time. Unfortunately, it can be difficult to determine how many roster items count as "unreasonable". For example, when a user registers with a gateway, it is possible that the initial set of roster items may be quite large (however, note that most existing consumer IM services enforce a limit of 100 to 150 items in their contact lists). Users who have newly registered with or been newly created on a server (e.g., within an organization) may also receive a large set of initial roster items in order to sync up with shared groups established on the server. However, after such initialization, the subsequent roster item sets should be much smaller. In any case, sets of more than 150 or 200 roster items SHOULD be treated with suspicion, and entities that repeatedly send such sets SHOULD NOT be trusted.

    5. +
+ + +

The foregoing protocol description speaks only of "sending entities" and does not differentiate between different types of sending entities. However, it is envisioned that roster items will be sent to receiving entities by three different kinds of senders:

+
    +
  1. Users of Jabber clients.
    2. +
  2. Client proxy gateways.
    3. +
  3. Shared group services.
    4. +
+

These are described more completely below.

+ +

Roster item exchange as developed within the early Jabber community and documented in JEP-0093 was used to send a roster item from one user to another in a manner more structured than simply typing a third party's JID in a chat window. This usage is still encouraged. However, if the sender is a human user and/or the sending application has a primary Service Discovery category of "client" (e.g., a bot) See <http://www.jabber.org/registrar/disco-categories.html#client>., the sending application SHOULD NOT specify an 'action' attribute other than "add", the receiving application MAY ignore values of the 'action' attribute other than "add", and the receiving application MUST prompt a human user regarding whether to add the suggested item or items to the user's roster.

+ + +

The nature of client proxy gateways (i.e., entities with a service discovery category of "gateway") is specified more fully in &jep0100;. Herein we describe how such gateways should use roster item exchange, and how receiving applications should treat roster items received from such gateways.

+

In order to make use of a gateway's protocol translation service, a user MUST first register with the gateway. If the gateway advertises support for a service discovery feature of 'http://jabber.org/protocol/rosterx', then the user's client SHOULD expect that it may receive roster item suggestions from the gateway. In order to maintain synchronization between the user's contact list on a legacy IM service and the user's Jabber roster, the gateway SHOULD send roster items with an 'action' attribute of "add", "delete", or "modify" as appropriate, and the receiving application SHOULD process such roster item suggestions. Such processing MAY occur automatically (i.e., without the user's approval of each roster item or batch of roster items) if and only if the receiving application has explicitly informed the user that it will automatically process roster items from the gateway. Furthermore, the receiving application SHOULD periodically verify automatic processing with the user (e.g., once per session in which the gateway sends roster item suggestions to the user).

+ + +

There is a third category of entities that might initiate roster item exchanges, which we label a "group service" and identify by a Service Discovery category of "directory" and type of "group". A group service enables an administrator to centrally define and administer roster groups so that they can be shared among a user population in an organized fashion. Such a service could prove useful in enterprise environments + For example, when Alice is hired by the marketing department of Big Company Enterprises, it makes sense for her to automatically have the other members of the marketing department in her roster the first time she logs in, and for the rest of the marketing department to have Alice in their rosters as soon as her account has been set up. Similarly, when Bob in logistics gets fired, it makes sense for him to disappear from the rosters of everyone else in the logistics department. + and other settings where it is beneficial to synchronize rosters across individuals (e.g., schools, social networking applications, consumer IM services, and anywhere else that it is important to build and manage small communities of users).

+

In some contexts, an IM server could function as a group service (e.g., if there is a single server deployed on a small company intranet); in other contexts, it may make more sense to deploy a standalone group service (e.g., in a larger or more heterogeneous environment with users on multiple servers). In both cases, the group service MUST advertise a service discovery identity of "directory/group" and SHOULD use the protocol specified herein to communicate changes ("add", "delete", and "modify") to the relevant shared groups; in addition, a user MUST first register with the service (either over Jabber via &jep0077; or out of band, e.g., via the web) or be otherwise provisioned to use the service (e.g., by a system administrator) before accepting roster item suggestions from the service.

+

If the user has registered with a group service or been otherwise provisioned to use a group service, the receiving application SHOULD process roster item suggestions received from the service. Such processing MAY occur automatically (i.e., without the user's approval of each roster item or batch of roster items) if and only if the receiving application has explicitly informed the user that it will automatically process roster items from the service. Furthermore, the receiving application SHOULD periodically verify automatic processing with the user (e.g., once per session in which the service sends roster item suggestions to the user).

+ + + + +

A principal (user) or receiving application MAY establish a list of trusted entities from which roster item exchanges are processed automatically, i.e., without explicit approval by a human user. In order to avoid corruption of the roster, it is STRONGLY RECOMMENDED that such trusted entities be limited to gateways and group services as defined above. In addition, the receiving application SHOULD periodically verify such automatic processing with the principal, e.g., once per session in which the trusted entity sends roster item suggestions to the user.

+ + +

A sending entity could effectively deny service to the receiving entity by rapidly and repeatedly sending (1) alternating add and delete suggestions or (2) modify suggestions, thus invoking throttling mechanisms enforced by the receiving entity's server. The receiving application SHOULD guard against this by monitoring roster item exchanges received from each sending entity and refusing or ignoring roster item exchanges from offending entities (e.g., by adding such entities to a list of distrusted entities).

+ + +

A receiving application MAY refuse to advertise its support for the roster item exchange protocol (see the Service Discovery section of this document) to entities that that are (1) not explicitly trusted or (2) explicitly distrusted.

+ + + +

This JEP requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; includes 'http://jabber.org/protocol/rosterx' in its registry of protocol namespaces.

+ + +

The Jabber Registrar includes a Service Discovery type of "group" under the "directory" category in its registry of service discovery identities.

+ + + + + + + + + + The protocol documented by this schema is defined in + JEP-0144: http://www.jabber.org/jeps/jep-0144.html + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + diff --git a/xep-0145.xml b/xep-0145.xml new file mode 100644 index 00000000..0f121dab --- /dev/null +++ b/xep-0145.xml @@ -0,0 +1,167 @@ + + +%ents; +]> + + +
+ Annotations + This document defines a protocol for making annotations about roster items and other entities. + &LEGALNOTICE; + 0145 + Active + Historical + Standards JIG + Council + + XMPP Core + JEP-0049 + + + + rosternotes + + http://jabber.org/protocol/rosternotes/rosternotes.xsd + + + Stefan + Strigler + steve@zeank.in-berlin.de + zeank@jwchat.org + + + 1.0 + 2006-03-23 + psa +

Per a vote of the Jabber Council, advanced to Active.

 + + + 0.2 + 2005-07-15 + psa +

JEP Editor revisions: changed type to Historical; changed namespace to storage:rosternotes; corrected schema; specified use of DateTime profile from JEP-0082; corrected some small textual errors.

 + + + 0.1 + 2004-11-05 + st +

Initial version.

 + +
+ + +

Many modern IM clients offer functionality that enables users to make notes about items in their roster. This comes in handy if users don't have meaningful information in their vCard or if you need to remember additional things related to a roster item.

+ +

This specification defines a protocol for storing annotations about a given set of entities. Its primary goal is to enable users to store some personal piece of information with their roster items. &jep0049; provides with a convenient method for storing user data on the server using the 'jabber:iq:private' namespace; all we need to do is define a namespace and schema for storing this sort of information. For this the 'storage' element introduced in &jep0048; is reused, and a new namespace of 'storage:rosternotes' is added.

+ + + + + +

Annotations are stored using server-side private XML storage (the 'jabber:iq:private' namespace). A storage element marked by the storage:rosternotes namespace contains a collection of one or more <note/> elements, each representing a note about a given entity. For any given JID there MUST NOT be more than one note.

+ +

The 'jid' attribute of the <note/> element SHOULD be used without a resource. Along with the annotation a client MAY choose to store creation time ('cdate') and modification time ('mdate') as attributes to the <note/> element containing the note; these attributes MUST conform to the DateTime profile specified in &jep0082; and the timezone SHOULD be UTC.

+ + + + + + Seems to be a good writer + Oh my sweetest love ... + + + +]]> + +

Note: All notes are stored as a "bundle" within the same <storage/> element.

+ +

Retrieving notes uses the protocol described in JEP-0049.

+ + + + + + + +]]> + + + + + + Seems to be a good writer + Oh my sweetest love ... + + + +]]> + +

For error conditions please refer to JEP-0049.

+ + + + +

Security considerations related to private XML storage are described in JEP-0049.

+ + + +

No interaction with &IANA; is required as a result of this JEP.

+ + + +

No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this JEP.

+ + + + + + + + + + The protocol documented by this schema is defined in + JEP-0145: http://www.jabber.org/jeps/jep-0145.html + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + diff --git a/xep-0146.xml b/xep-0146.xml new file mode 100644 index 00000000..d219d2c6 --- /dev/null +++ b/xep-0146.xml @@ -0,0 +1,740 @@ + + + %ents; +]> + + + +
+ Remote Controlling Clients + This JEP specifies recommended best practices for remote controlling clients using Ad-Hoc Commands. + &LEGALNOTICE; + 0146 + Active + Informational + Standards JIG + + XMPP Core + JEP-0050 + + None + None + rc + + Remko + Tronçon + remko@el-tramo.be + remko@fab4.be + + &stpeter; + + 1.0 + 2006-03-23 + psa +

Per a vote of the Jabber Council, advanced to Active.

 + + + 0.3 + 2006-01-25 + rt + Using JEP-0033 (Extended Stanza Addressing) for Forwarding + use case. + + + 0.2 + 2005-03-16 + rt + Minor modifications; completed Set Options use case; completed Leave Groupchats use case. + + + 0.1 + 2004-11-12 + rt + Initial version. + +
+ + +

+ When one has multiple clients at different locations logged in + simultaneously, it is often desirable to control these clients from + the client you are currently using. There are a number of common tasks + one might want to perform remotely on clients: change the status of the + client, forward all received unread messages to this client, and so on. + Therefore, it makes sense to define a protocol for performing these tasks. +

+ +

+ This JEP describes a protocol to perform a set of common tasks on a + remote client, by specifying a profile of &jep0050;. +

+ + + + +

This JEP addresses the following requirements:

+
    +
  • Enable users to perform a set of common tasks on a remote + client.
    • +
  • Re-use existing XMPP and Jabber protocols wherever possible.
    • +
+ + + + +

A client MUST advertise any remote controlling commands it supports via + &jep0030; (as described in JEP-0050: Ad-Hoc Commands). + &jep0115; can be used to query capability of remote controlling commands + in a client. +

+ + + + +

This JEP defines a profile of JEP-0050: Ad-Hoc Commands + that enables a user to perform the following tasks on a remote client:

+
    +
  1. Change status
    2. +
  2. Forward unread messages residing at the remote client to the + local client
    3. +
  3. Change run-time options
    4. +
  4. Accept pending file transfer requests
    5. +
  5. Leave groupchats
    6. +
+

+ Although this JEP aims to define common use cases for remote controlling clients, + an implementation or deployment MAY support any subset and MAY support additional + commands not defined herein. +

+

Note: The text that follows assumes that implementors have read and understood JEP-0050: Ad-Hoc Commands.

+ + + +

It is common to forget changing the status of a resource when leaving the + client for a longer period. When realizing this while at another location, it + might be desirable to change the status from there, to avoid contacts + thinking that resource is attended and sending it messages.

+ + + + ]]> +

Unless an error occurs (see the + Error Handling section below), the service + SHOULD return the appropriate form.

+ + + + + Change Status + Choose the status and status message + + http://jabber.org/protocol/rc + + + + online + + + + + + + + + + 5 + + + + + + ]]> + + + + + http://jabber.org/protocol/rc + + + xa + + + -1 + + + In my chamber. + + + + + ]]> +

If the 'status-priority' variable is omitted, the client SHOULD NOT + change the priority of the client

+ + + + ]]> +

Notification of completion MAY include the processed data in a data + form of type 'result'.

+ + + + +

A user might want to forward all the unread messages residing at + the remote client to the local client (e.g. when the remote client was + accidentally left on-line, and has received messages in the meantime).

+ + For example, suppose Romeo sends a message to Juliet, thinking she is + still on her balcony. The balcony client receives the message: + + Just saying hi + Hello Juliet! + + ]]> + + However, Juliet is in her chamber, so she doesn't know about the message + (yet). Realizing she left her balcony client unattended, she sends a + request to the remote client to forward all unread messages. + + + + + ]]> + + The client forwards all unread messages to the local client, adding + information about the origin of the message (using the 'ofrom' + &jep0033; address). + The chamber client receives both these messages and a + confirmation that the command was completed. + + Just saying hi + Hello Juliet! + +
+ + + ]]> + + + + + ]]> + + A client MAY provide a more fine-grained implementation, e.g. by + presenting the requester an extra form to select which messages + have to be forwarded. + + + + +

It might be desirable to remotely set some run-time options of + a client. For example, when neighbours complain about the sounds your + client makes while you're at another location, you could turn the + sounds off at the remote client. +

+ + + + ]]> +

Unless an error occurs (see the + Error Handling section below), the service + SHOULD return the appropriate form.

+ + + + + Set Options + Set the desired options + + http://jabber.org/protocol/rc + + + 1 + + + 0 + + + 0 + + + 0 + + + 0 + + + + + ]]> + + + + + http://jabber.org/protocol/rc + + + 0 + + + 0 + + + 0 + + + 0 + + + 0 + + + + + ]]> +

The remote client sets the values of the options to their requested + value. If a variable is omitted, the client SHOULD NOT change the value of the + corresponding option.

+ + + + + ]]> +

Notification of completion MAY include the processed data in a data + form of type 'result'.

+ + + + + + + + + + ]]> +

Unless an error occurs (see the + Error Handling section below), the service + SHOULD return the appropriate form.

+ + + + + Pending File Transfers + Select the pending file transfers to accept + + http://jabber.org/protocol/rc + + + + + + + + + + + ]]> + + + + + http://jabber.org/protocol/rc + + + romeo@example.com/orchard:2 + + + + + ]]> + + The remote client accepts the selected file transfers, and informs + the local client of completion. + + + + ]]> + + + + + + + + + ]]> + + + + Leave Groupchats + Choose the groupchats you want to leave + + http://jabber.org/protocol/rc + + + + + + + + + + + ]]> + + + + + http://jabber.org/protocol/rc + + + jdev@conference.jabber.org/juliet + girlsonly@jabber.com/juliet + + + + + ]]> +

The remote client leaves the requested groupchats, and informs the + local client of completion.

+ + + + ]]> + + + + + +

Several error conditions are possible when an entity sends a command + request to the service, as defined in the following table. If one of these + errors occurs, the service MUST return an error stanza to the requesting + entity.

+ + + + + + + + + + + + + + + + + + + +
ConditionCause
&feature;The specific command is not supported (even though the ad-hoc + commands protocol is)
&forbidden;The requesting entity does not have sufficient privileges to + perform the command
&unavailable;The ad-hoc commands protocol is not supported
+ +

For the syntax of these errors, see &jep0086;. Naturally, other errors + may be returned as well.

+ + + + +

Implementations of this protocol MAY add or remove fields to forms as + they see fit. For example, when setting the status of a remote client that + supports multiple accounts, the client may choose to add a boolean field + to allow the user to specify whether the status change should be applied + globally or only to the receiving account.

+ +

Implementations MAY also introduce extra forms for commands. For example, + when forwarding unread messages, a client could return a form containing a + list + of short descriptions of unread messages, allowing the user to select the + messages he wants to forward.

+ + + +

The ability to complete the tasks specified herein MUST NOT be granted + to users who lack privileges to control a client. A sensible + access policy is to only allow remote controlling by other + resources of the same account used by the client. If other accounts + are to be able to remote control the client, the client needs more + complex access right management.

+ + + + +

This JEP requires no interaction with &IANA;.

+ + + + + + +

The Jabber Registrar includes 'http://jabber.org/protocol/rc' in its registry + of protocol namespaces (see &NAMESPACES;).

+ + + +

&jep0068; defines a process for standardizing the fields used within + Data Forms scoped by a particular namespace (see also &FORMTYPES;). + The reserved fields for the 'http://jabber.org/protocol/rc' namespace + are specified below.

+ + http://jabber.org/protocol/rc + JEP-0146 + Forms used for remote controlling clients + + + + + + + + + + + + + + + + + + + + ]]> + + + + + +

Because the protocol defined here is a profile of JEP-0050: Ad-Hoc Commands, no schema definition is needed.

+ + + diff --git a/xep-0147.xml b/xep-0147.xml new file mode 100644 index 00000000..ae951f64 --- /dev/null +++ b/xep-0147.xml @@ -0,0 +1,374 @@ + + +%ents; +]> + + +
+ XMPP URI Scheme Query Components + This document defines a registry of query components to be used in the context of XMPP IRIs/URIs and also specifies an initial submission of values to that registry. + &LEGALNOTICE; + 0147 + Active + Informational + Standards JIG + Council + + XMPP Core + RFC 4622 + JEP-0053 + + + + querytypes + + &stpeter; + + 1.2 + 2006-09-13 + psa +

Removed probe action.

 + + + 1.1 + 2006-06-19 + psa +

Added actions for roster removal, presence unsubscription, and cancellation of registration; moved querytypes related to XMPP extensions from this document to the relevant JEPs.

 + + + 1.0 + 2006-03-23 + psa +

Per a vote of the Jabber Council, advanced to Active.

 + + + 0.7 + 2006-03-16 + psa +

Added actions for ad-hoc commands and vCard retrieval; clarified some explanatory text.

 + + + 0.6 + 2005-12-01 + psa +

Updated to reflect RFC 4622-03; modified file transfer query operations to handle both send and receive use cases.

 + + + 0.5 + 2005-09-05 + psa +

Updated to reflect RFC 4622-01; added file querytype for file transfer.

 + + + 0.4 + 2005-06-06 + psa +

Updated to reflect RFC 4622-00.

 + + + 0.3 + 2005-02-28 + psa +

Updated to reflect draft-saintandre-xmpp-uri-08 and subsequent XMPP WG discussion; removed use cases for editing roster items, removing roster items, leaving chatrooms, unsubscribing, and unregistering (these make more sense from within a dedicated client); added use case for simultaneously joining a room and inviting other participants; further specified security considerations.

 + + + 0.2 + 2004-11-17 + psa +

Updated to reflect draft-saintandre-xmpp-uri-07; specified Service Discovery usage.

 + + + 0.1 + 2004-11-12 + psa +

Initial version.

 + +
+ +

&rfc4622; defines a Uniform Resource Identifier (URI) scheme for use in forming URIs and Internationalized Resource Identifiers (IRIs) On the difference between IRIs and URIs, see RFC 3987. from the addresses of entities that can communicate using the Extensible Messaging and Presence Protocol (see &xmppcore;). Such identifiers enable identification of and interaction with XMPP entities by non-native applications such as databases and web browsers.

+

However, RFC 4622 intentionally leaves the potential values of the query component open-ended, does not provide a list of common "actions" for queries (e.g., send message or join chatroom), and does not specify recommended "key-value" pairs to be used in the context of such actions. Therefore, this document defines a registry of such actions and key-value pairs (to be maintained by the ®ISTRAR;) and specifies a set of initial values for that registry.

+

This document is organized as follows:

+
    +
  • The registry is defined in the XMPP IRI/URI Querytype Registry section.
    • +
  • An initial set of actions and key-value pairs is described in the Query Actions section.
    • +
  • A corresponding initial submission to the registry is specified in the Initial Registration section.
    • +
  • The process for submitting additional values to the registry is specified in the Registration Process section.
    • +
+

Note: The format of the XMPP URI scheme, including the format of the query component, is fully specified and formally defined in RFC 4622; this document does not modify the xmpp URI scheme in any way and assumes that the reader is familiar with all aspects of RFC 4622.

+ + +

This document inherits terminology from &rfc3986;, &rfc3987;, and RFC 4622.

+ + +

The range of actions that might be triggered by interaction with an XMPP entity by means of an XMPP IRI/URI is potentially as wide as the range of extensions to XMPP. This document does not seek to exhaustively define all such potential actions. However, the following actions might be of general interest:

+
    +
  1. Sending a message.
    2. +
  2. Adding or removing a roster item.
    3. +
  3. Subscribing to or unsubscribing from an entity's presence information.
    4. +
  4. Probing for current presence information.
    5. +
  5. Determining &jep0030; information about an entity.
    6. +
  6. Joining a groupchat room (see &jep0045;).
    7. +
  7. Requesting initiation of &jep0050; associated with an entity.
    8. +
  8. Retrieving the &jep0054; data associated with an entity.
    9. +
  9. Subscribing to or unsubscribing from a &jep0060; node.
    10. +
  10. Registering with another entity via &jep0077;.
    11. +
  11. Initiating a file transfer with another entity (see &jep0096;).
    12. +
+

For each such action, the Jabber Registrar maintains a RECOMMENDED "querytype" (this can be thought of as an action name or "verb"; see RFC 4622 for syntax and semantics) as well as an OPTIONAL list of keys to be used in key-value pairs if appropriate.

+

The querytypes and key-value pairs related to RFC 3920 and RFC 3921 are defined herein; the querytypes and key-value pairs related to protocols defined in the JSF's JEP series are defined in the relevant JEPs.

+ +

It may desirable for an XMPP IRI/URI to trigger a specialized interface for sending an XMPP message stanza. The RECOMMENDED querytype for this action is "message". If no key-value pair is provided, interacting with an XMPP IRI/URI that contains a querytype of "message" SHOULD trigger an interface that enables the user to input the text of an XMPP message and other relevant parameters (e.g., a message subject or &jep0071; markup).

+ +

A query component whose querytype is "message" MAY specify various key-value pairs. The following three keys are associated with the child elements of the &MESSAGE; stanza specified in the XML schema for the 'jabber:client' namespace as defined in &xmppim;:

+
    +
  1. subject
    2. +
  2. body
    3. +
  3. thread
    4. +
+

In addition, the following three keys are associated with the attributes of the &MESSAGE; stanza specified in the XML schema for the 'jabber:client' namespace (the 'to' attribute is unnecessary, since it is provided by the XMPP address included in the IRI/URI):

+
    +
  1. from
    2. +
  2. id
    3. +
  3. type
    4. +
+

Other keys MAY be registered with the Jabber Registrar but are not specified herein.

+ + + Test Message + Here's a test message. + + ]]> + + +

The 'jabber:iq:roster' namespace provides a mechanism for managing an XMPP roster (also called a "contact list"). This namespace is defined in RFC 3921. The following actions are defined.

+ +

The registered querytype for adding items to the roster or editing items in the roster is "roster" (effectively there is no difference between adding and editing). An XMPP IRI/URI containing a "roster" querytype MAY also include at most one "name" key whose value maps to the 'name' attribute of the <item/> element within the 'jabber:iq:roster' namespace, and MAY contain one "group" key whose value maps to the character data of the <group/> child element of <item/>.

+ + + + + + + ]]> + + + + + + + ]]> + + + + + Friends + + + + ]]> +

Note: Methods (if any) for including more than one group are yet to be determined.

+ + +

The 'jabber:iq:roster' namespace includes a mechanism for removing an XMPP roster item. The registered querytype for removing an item from the roster is "remove".

+ + + + + + + ]]> + + + +

Closely coupled with roster management is presence subscription management. In XMPP, subscription management is handled via special values of the &PRESENCE; stanza, as described in RFC 3921. The following actions are defined

+ +

When an entity subscribes to another entity's presence by means of an XMPP IRI/URI, the invoked XMPP application SHOULD first send a roster add stanza as shown below (this is consistent with the recommendations in RFC 3921).

+ + + + + + + + + ]]> + + +

XMPP includes a mechanism for unsubscribing from an entity. The registered querytype for doing so is "unsubscribe".

+ + + ]]> + + + + +

Internationalization considerations for XMPP IRIs/URIs are specified in RFC 4622; the reader is referred to that document for a complete discussion of the relevant issues.

+

Localization of application-specific data presented to a human user (e.g., as encapsulated in key-value pairs) is the responsibility of the using protocol.

+ + +

Security considerations for XMPP IRIs/URIs are specified in RFC 4622.

+

Completion of some of the actions defined herein will cause changes to an entity's account, subscriptions to information, registration with services, communication with other entities, completion of ad-hoc commands, and the like. Naturally, such changes, information, services, and communications are potentially undesirable (e.g., joining a chatroom whose discussion topic is not of interest to, or even patently offensive to, the joining user). The invoked application SHOULD appropriately warn a human user regarding the potential consequences of the action about to be completed.

+ + +

This document requires no interaction with &IANA;. If in the future the IANA should wish to maintain a registry of XMPP URI/IRI query components, the Jabber Registrar will cooperate with efforts to migrate the registry from the Jabber Registrar to the IANA.

+ + + +

The Jabber Registrar maintains a registry of querytype values (see &QUERYTYPES;).

+ + ®PROCESS; + + the name of the querytype (e.g., "pubsub") + + the namespace of associated protocol output + (e.g., "http://jabber.org/protocol/pubsub") + + a natural-language description of the querytype + the document in which the querytype is specified + + + the name of the key (e.g., "action") + a natural-language description of the key + + + the name of a value (e.g., "subscribe") + a natural-language description of the value + + + + + + ]]> +

Note: Within the <querytype/> element, the <keys/> child element is OPTIONAL; within any given <key/> element, the <values/> child element is also OPTIONAL.

+

The registrant may register more than one querytype at a time, each contained in a separate <querytype/> element.

+ + +

The following submission registers parameters related to the XMPP RFCs. For submissions related to XMPP extensions, refer to the relevant JEPs.

+ + message + jabber:client + enables sending of an XMPP message stanza + JEP-0147 + + + subject + a subject for the message per the "jabber:client" schema + + + body + a body for the message per the "jabber:client" schema + + + thread + a Thread ID for the message per the "jabber:client" schema + + + from + a from address for the message per the "jabber:client" schema + + + id + an ID for the message per the "jabber:client" schema + + + type + the message type per the "jabber:client" schema + + + chat + a message of type "chat" + + + groupchat + a message of type "groupchat" + + + headline + a message of type "headline" + + + normal + a message of type "normal" + + + + + + + + probe + jabber:client + enables probing for a contact's current presence information + JEP-0147 + + + + remove + jabber:iq:roster + enables removing a roster item + JEP-0147 + + + + roster + jabber:iq:roster + enables adding or editing a roster item + JEP-0147 + + + group + the user-assigned group for the roster item + + + name + the user-assigned name for the roster item + + + + + + subscribe + jabber:client + enables sending a presence subscription request + JEP-0147 + + + + unsubscribe + jabber:client + enables unsubscribing from an entity's presence + JEP-0147 + + + ]]> + + + + diff --git a/xep-0148.xml b/xep-0148.xml new file mode 100644 index 00000000..f89866c8 --- /dev/null +++ b/xep-0148.xml @@ -0,0 +1,244 @@ + + +%ents; +]> + + +
+ Instant Messaging Intelligence Quotient (IM IQ) + Canonical documentation of the jabber:iq:iq namespace. + &LEGALNOTICE; + 0148 + Active + Humorous + Standards JIG + Council + + XMPP Core + + + + iq-iq + &stpeter; + + 1.0 + 2005-04-01 + psa + Per a vote of the Jabber Council, advanced status to Active. + +
+ +

The early Jabber community was a hotbed of innovation and experimentation. Although the community produced a large number of interesting protocols and technologies, not all of them were widely adopted. For example, server-side message filtering (implemented in the mod_filter module of the &jabberd; server) was one promising technology that simply did not scale up beyond a few hundred concurrent users. Another potentially helpful technology (though even less well-known) was that of the "Instant Messaging Intelligence Quotient" (IM IQ) as defined by the 'jabber:iq:iq' protocol. For the sake of historical completeness, this JEP provides canonical documentation of that protocol.

+ + +

It is a harsh reality of the modern Internet that plenty of stupid people have found their way onto today's communication networks (email, Usenet, IM, and the like). Because the early Jabber developers were your typically elitist geeks (whose mantra seems to have been "not everyone can be as smart as we are"), they sought to shield themselves from the inevitable emergence of dumb Jabber users.

+

At the same time, recognizing the wisdom of the age-old saying "to err is human", they knew that even normally intelligent people sometimes say appallingly stupid things. In fact, such normally intelligent people (well, okay, geniuses) might be the developers themselves! Thus they sought to build protective measures into Jabber servers so that they could avoid appearing dumb.

+

The early Jabber developers sought to achieve both of these objectives through the design of server-side intelligence detection systems using dedicated protocol elements qualified by the 'jabber:iq:iq' namespace. This protocol implements procedures for discovering, monitoring, and getting feedback on the intelligence of one's own instant messages, as well as that of other users on the network. The "IM IQ" of each user is determined by server-side parsing of messages sent by all registered users of a server, using advanced linguistic analysis techniques (as described under Implementation Notes below) enforced by the mod_iq jabberd module.

+ + + +

Before chatting with another user over the network or adding that user to one's Jabber roster, it can be helpful to get a sense of how intelligent or unintelligent that person is. This is done by requesting the person's IM IQ from that person's server by sending an IQ get qualified by the 'jabber:iq:iq' namespace to the person's bare JID (user@host) rather than full JID (similar in this regard to the functionality of &jep0054;).

+ + + + ]]> +

The server then returns the person's IM IQ, expressed as a REQUIRED <num/> integer between zero and 256, and an OPTIONAL <desc/> containing a natural-language descriptive phrase associated with that range of integer values.

+ + + 66 + moron + + + ]]> + + +

In order for a user to discover his or her own IM IQ, the user sends an IQ get without any 'to' address.

+ + + + ]]> + + + 83 + dull + + + ]]> +

A user may not agree with his or her IM IQ as computed by the server (after all, everyone thinks they are above average). Therefore it is possible that a user may attempt to change his or her IM IQ by sending an IQ set to the server:

+ + + 143 + genius + + + ]]> +

However, allowing users to change their own IM IQs is unacceptable, since it would make such information unreliable. Therefore, if a server receives such an IQ set, it MUST return a ¬allowed; error to the user, and MAY further decrement the user's IM IQ as a result.

+ + + 143 + genius + + + + + + ]]> + + +

Even smart people say stupid things, and we are all familiar with the experience of having said something stupid (or just average) and realizing later that one could have said something exceedingly clever. To prevent people from saying stupid things and to help users appear as smart as possible, the mod_iq jabberd module provides hints to users regarding what to say at a given point in a conversation, based on the advanced linguistic analysis technologies described under Implementation Guidelines below. A user can ask for a hint by sending the complete message to the server itself, wrapped in a &QUERY; element qualified by the 'jabber:iq:iq' namespace. (While it may be argued that this functionality could be provided client-side, thus saving a roundtrip, it is consistent with the Jabber philosophy of "smart servers, dumb clients" as explained in &jep0134;.)

+ + + + some-thread-id + d00d, u r dum -- RTFM, OK? + + + + ]]> +

The server then determines a more intelligent message to send and returns the XML character data of the &BODY; element to the user in a <hint/> element.

+ + + + I've heard that there's this thing called the Internet, which + contains incredible amounts of helpful information. Have you considered + using it? + + + + ]]> +

Messages checked with the server before sending SHOULD NOT affect the user's IM IQ computation; however, the server MAY decrement the user's IM IQ more significantly if the user ends up sending the original message rather than the smarter one provided by the server.

+ + + + +

The mod_iq jabberd module uses somewhat out-of-date terminology for intelligence levels See, for example, D. Wechsler, The Measurement of Adult Intelligence (Baltimore: The Williams and Wilkins Company), 1944., as shown in the following table.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Number RangeDescriptive Label
140+genius
120-139very superior
110-119superior
90-109normal
80-89dull
70-79borderline deficiency
50-69moron
20-49imbecile
0-19idiot
+

While once common, these terms are now considered politically incorrect. However, please note that this JEP merely provides informational documentation of a protocol historically used within the Jabber community, and is not intended to stereotype individuals in any manner whatsoever. A given server implementation of the 'jabber:iq:iq' protocol MAY substitute more modern ranges and terminology if desired or leave out the descriptive phrases entirely, and a given client implementation MAY rename or disguise the descriptive phrases.

+

That said, it is true that many people on the Jabber network do act like morons, imbeciles, and even idiots.

+ + +

Using the methods described in the next section, the mod_iq jabberd module assigns and dynamically updates a person's IM IQ based on all the messages sent by the user. Upon registration, each user is assigned a baseline IM IQ of 100 ("intelligent until proven an idiot"), unless the user made errors in the registration process or chose an especially stupid password (e.g., "password"), in which case the initially assigned IM IQ could be as low as 70 ("borderline deficiency"). In a manner similar to server-side "karma" ratings, the IM IQ is then modified dynamically based on the semantic value of the user's outbound messages, up to a high of 256 or down to a low of zero (0).

+

IM IQ is determined based on a user's actual message traffic only, not on other factors such as inane presence status text or the contacts added to the user's roster. While the latter functionality might have been useful, it would violate the rule of not assigning guilt based on association.

+ + +

The mod_iq jabberd module makes use of several Analytical Language Engine (ALE) technologies for determining the intelligence of specific messages and thus also a user's IM IQ (the average of all messages sent). These technologies include the following:

+
    +
  • Phrasal Objectification of Realtime Threads (PORT) -- this is a parsing technique for breaking conversation threads into meaningful phrases, even across message boundaries.
    • +
  • Bayesian Estimation of Entropic Responses (BEER) -- within information theory, entropy is a measure of the rate of information transfer; this technique uses Bayesian estimation methods to determine whether a given message imparts useful information or not.
    • +
  • Situational Analysis of Kladistic Evolution (SAKE) -- kladistics (also spelled "cladistics"), from the Greek "klados" (meaning "branch"), is the study of grouping things into branches that diverge from a common origin; it is used in biology to study descent from a common ancestor, and also in the study of conversation threads to determine how a conversation would evolve depending on things said (or messages sent) at any point in the conversation flow.
    • +
  • Semantic Correlation and Observation of Truth in Conversation Handling (SCOTCH) -- a person may seem intelligent to the casual observer, but his or her messages may actually not provide deep insights or even track reality in a useful or consistent fashion; this technique builds on early semantic web insights to determine the truth value of a given message within the context of a realtime conversation.
    • +
  • Webs of Intelligent Network Endpoints (WINE) -- any given person can engage in conversations with a large number of interlocutors, yet that person's status as an intelligent network endpoint is influenced by reputational factors across the full web of linguistic interactions, not just with any one person; this technique accounts for such reputational effects to paint a complete picture of the person's perceived intelligence across the network.
    • +
+

Naturally, because of the powerful and potentially unpredictable effects of these technologies, development of mod_iq was restricted to senior developers on the jabberd team, or at least (for developers in the U.S.) those over the age of 21. See Title 23, Chapter 1, Subchapter 1, Section 158 of the United States federal legal code as enacted by the National Minimum Drinking Age Act of 1984 <http://www.law.cornell.edu/uscode/23/158.shtml>.

+ + + +

The descriptive phrases for various intelligence levels SHOULD be localized based on the user's preferred language; however, if the server does not support the 'xml:lang' attribute, this localization MAY be performed by the client.

+ + +

Most people become somewhat insecure when they realize that in fact they are not as smart as they thought they were; for this reason, querying the server for one's own IM IQ is NOT RECOMMENDED on a regular basis.

+ + +

This JEP requires no interaction with &IANA;.

+ + +

The ®ISTRAR; shall include the 'jabber:iq:iq' namespace in its registry of protocol namespaces.

+ + + + + + + + + + + The protocol documented by this schema is defined in + JEP-0148: http://www.jabber.org/jeps/jep-0148.html + + + + + + + + + + + + + + + + + + ]]> + + diff --git a/xep-0149.xml b/xep-0149.xml new file mode 100644 index 00000000..fd9e8452 --- /dev/null +++ b/xep-0149.xml @@ -0,0 +1,169 @@ + + +%ents; +]> + + +
+ Time Periods + This document defines a method to specify the valid time periods for states, events, and activities communicated via Jabber/XMPP protocols. + &LEGALNOTICE; + 0149 + Active + Informational + Standards JIG + Council + + XMPP Core + JEP-0082 + + + + N/A + &stpeter; + + 1.0 + 2006-01-24 + psa + Per a vote of the Jabber Council, advanced status to Active. + + + 0.2 + 2005-12-21 + psa + Updated to reflect draft-ietf-simple-rpid-10. + + + 0.1 + 2005-04-21 + psa + Initial JEP version. + + + 0.0.2 + 2005-04-07 + psa + Modified to use SHIM headers rather than a structured data format qualified by a dedicated namespace. + + + 0.0.1 + 2005-03-17 + psa + First draft. + +
+ +

Certain events and states may last for only a limited period of time. For example, when a person changes his availability to "dnd" and his status to "In a Meeting", the person (or his calendaring application) may know that the meeting is expected to last for 90 minutes; because those who subscribe to the person's presence may find it helpful to know how long the person will be in the meeting, it might be desirable to include that time period information in the presence stanza sent when the person's availability changes. Similar considerations apply to other states, events, and activities, such as various forms of "extended presence" (see &jep0119;).

+

This JEP defines a straightforward XMPP extension for encapsulating information about time periods, using new headers that adhere to the format specified in &jep0131;.

+ + +

This JEP addresses the following requirements:

+
    +
  1. Provide the ability to specify time periods for states, events, and activities communicated via Jabber/XMPP protocols.
    2. +
  2. Conform to &jep0082;.
    3. +
+ + +

In order to specify the time period for a state, event, or activity, the generating entity SHOULD include both "Start" and "Stop" SHIM headers that specify the dateTimes at which the time period starts and stops. The following rules apply:

+
    +
  1. All start and stop dates MUST conform to the dateTime profile specified in JEP-0082.
    2. +
  2. All dateTime information MUST be expressed in UTC (i.e., with no timezone offsets).
    3. +
  3. Start and stop times SHOULD be understood by the recipient as estimates or approximations.
    4. +
  4. If both a start time and a stop time are specified, the stop time MUST be later than the start time.
    5. +
+

These SHIM headers MAY be included wherever appropriate; however, it is expected that they will be included mainly to further specify basic presence states (see &rfc3921;) and various "extended presence" states, events, and activities (see, for example, &jep0107; and &jep0108;).

+

There is no requirement that the start time needs to be the time when the stanza is generated; for example, the start time may be retroactive to a dateTime in the past or may be an estimated dateTime in the future.

+ + + +

In order to specify that a basic presence state will last for a specific time period, the entity that generates the presence stanza SHOULD include the desired SHIM headers.

+ + dnd + In a Meeting + +
2005-03-17T11:30:00Z
+ + + ]]> + + +

An XMPP extension for user activity is specified in JEP-0108. It may be desirable to include time period information when publishing one's activity.

+ + + + + + + + + My best friend's birthday! + + +
2005-03-17T19:00:00Z
+
2005-03-17T23:00:00Z
+ + + + + + ]]> + + +

An XMPP extension for user mood is specified in JEP-0107. It may be desirable to include time period information when publishing one's mood.

+ + + + + + + She has been bothering me *all day*! + + +
2005-03-17T07:00:00Z
+ + + + + + ]]> +

Note that the start time is (intended to be) retroactive.

+ + + +

For the sake of interoperability, it may be desirable for certain kinds of implementations (e.g., gateways) to transform XMPP start and stop times into the formats used by other protocols (e.g., the 'from' and 'until' attributes specified in &rfc4480;, see also &rfc4481;).

+ + +

It is possible that inclusion of time periods for particular states, events, or activities may reveal information that would enable a recipient to launch an attack while the sender is unavailable or away (e.g., if the sender specifies that he will be on vacation for the next three weeks, a recipient might therefore learn that this is a good time to break into the sender's house). Therefore, senders of time period information should balance the desire to share helpful information against the need for appropriate control over security-critical availability information.

+ + +

This JEP requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; includes the following entries in its registry of SHIM headers (see &SHIMHEADERS;).

+ + Start + The dateTime at which a state, event, or activity starts + JEP-0149 + + +
+ Stop + The dateTime at which a state, event, or activity stops + JEP-0149 +
+ ]]> + + + diff --git a/xep-0150.xml b/xep-0150.xml new file mode 100644 index 00000000..a9581fc6 --- /dev/null +++ b/xep-0150.xml @@ -0,0 +1,353 @@ + + +%ents; +]> + + +
+ Use of Entity Tags in XMPP Extensions + This document defines best practices for the use of Entity Tags in XMPP extensions. + &LEGALNOTICE; + 0150 + Experimental + Informational + Standards JIG + Council + + XMPP Core + RFC 2616 + JEP-0131 + + + + N/A + &hildjj; + &stpeter; + + 0.2 + 2005-08-09 + psa +

Added security considerations.

 + + + 0.1 + 2005-06-02 + psa +

Initial JEP version.

 + + + 0.0.1 + 2005-05-26 + psa +

First draft.

 + +
+ +

When a Jabber instant messaging client connects to its server, it typically retrieves a great deal of information, such as a user's roster, privacy lists, and service discovery information. However, this information may not have changed since the client last retrieved the data. In order to improve client start-up time or conserve bandwidth in certain environments, it would be desirable if the client could cache the information and retrieve it only if it has changed.

+

Such a mechanism exists as part of &rfc2616; in the form of the Entity Tags, which are included in the ETag and If-None-Match headers used for HTTP caching. Since &jep0131; enables an XMPP entity to communicate any HTTP header, it should be possible to re-use existing Entity Tag semantics for caching information sent over an XMPP network. This JEP defines best practices for such functionality, which could be used between any two XMPP entities that support SHIM headers (though it is envisioned to be most useful for clients that retrieve information from servers and services).

+ + +

This JEP addresses the following requirements:

+
    +
  1. Enable caching of information sent over an XMPP network (i.e., retrieval of information only if it has changed since it was last retrieved).
    2. +
  2. Re-use existing HTTP Entity Tag semantics.
    3. +
+ + +

In HTTP, an "entity" is the information transferred as the payload of a request or response, and an "Entity Tag" is an opaque string that uniquely identifies that payload. For example, when an HTTP server sends an entity in an HTTP response, it can include an ETag header that identifies the payload as cacheable, and the client can cache that entity; in future requests, the client can include the same value in an If-None-Match header and the server will either return an HTTP 304 ("Not Modified") error if the entity has not changed or return the entity in the HTTP response if it has changed. (Note: For information about the semantics of Entity Tags, the ETag header, and the If-None-Match header, refer to Sections 3.11, 14.19, and 14.26 respectively of RFC 2616.)

+

Similarly, the basic concept behind XMPP Entity Tag use is semantically equivalent to the use in HTTP; this is made possible by a straightforward application of SHIM headers as specified in JEP-0131. In the context of an IQ request-response interaction, the responding entity will include an ETag SHIM header in its IQ response (indicating that the data can be cached), the requesting entity will include that identical value in an If-None-Match SHIM header when it queries the server for the same entity, and the responding entity will return either an IQ result with the changed entity or an IQ error indicating that the entity has not changed.

+

Here is an example of such a request-response flow (the example is that of roster retrieval):

+ + + + ]]> + + + + Friends + + + Servants + + +
some-long-opaque-string
+ + + + ]]> + + + +
some-long-opaque-string
+ + + + ]]> +

If the responding entity does not understand the If-None-Match header or does not handle Entity Tags for the namespace in the request, it MUST ignore the header and return whatever information it would have returned if the header had not been present.

+

If the responding entity determines that the requested information has not changed since it was last retrieved by the requesting entity, then it MUST return a <not-modified/> error corresponding to the HTTP 304 error returned by HTTP entities that support the ETag header:

+ + + +
some-long-opaque-string
+ + + + + + + ]]> +

Note: The <not-modified/> error is not specified as a stanza error in &rfc3920; and an error code of 304 was not included in the older Jabber error codes (see &jep0086;). The authors of this proposal will request that the <not-modified/> error condition be added to the successor to RFC 3920 during the process of revising the XMPP specifications within the Internet Standards Process.

+

Note: In HTTP, an Entity Tag may be either "strong" or "weak" (see Section 13.3.3 of RFC 2616); Entity Tags as used in XMPP extensions MUST be considered strong rather than weak.

+

Note: The ETag and If-None-Match headers SHOULD be used only in &IQ; stanzas, although they MAY be used in &MESSAGE; stanza interactions if IQ request-response semantics are not appropriate, for example in &jep0072; and in certain applications that use &jep0004;.

+ + + +

JEP-0131 specifies how support for a particular SHIM header can be determined using &jep0030;. To review, the protocol flow between a client and a server would be as follows:

+ + + + ]]> + + + ... + + + ... + + + ]]> +

The client now knows that the server supports the ETag and If-None-Match SHIM headers and can proceed accordingly.

+

Note: If an XMPP entity supports Entity Tags, it MUST at a minimum support both the ETag and If-None-Match SHIM headers.

+

Note: Even if an entity supports the ETag and If-None-Match SHIM headers, it is not required to support Entity Tag functionality for all namespaces. For example, a server could support Entity Tags only for rosters and privacy lists but not for the 'jabber:iq:last' or 'jabber:iq:version' namespaces. Similarly, a &jep0045; service could support Entity Tags only for room lists (retrieved via a "disco#items" request) but not for other requests. As noted, if an entity does not support Entity Tags for a given namespace or request, it SHOULD proceed as if the ETag or If-None-Match SHIM header had not been included in the request.

+

Optionally, an entity MAY communicate the namespaces for which it supports Entity Tag functionality by listing those namespaces in its response to a "disco#info" request sent to a node of "http://jabber.org/protocol/shim#ETag":

+ + + + ]]> + + + ... + + + ... + + + ]]> +

Alternatively, as shown above and as used in HTTP, the requesting entity MAY implicitly discover that Entity Tag functionality is supported with regard to a given response entity type if the responding entity includes an ETag SHIM header in its response.

+ + +

As specified in &rfc3921;, an XMPP instant messaging client will typically store its "roster" (contact list) on the server so that any connecting client for that account can retrieve the roster at will. Since RFC 3921 defines no upper limit on the number of items allowed in the roster, it is possible for a roster to become quite large (e.g., there are known cases of rosters with more than 1,000 items). Therefore a server may support Entity Tag functionality with regard to roster management. The process is as follows.

+

First, the client requests its roster:

+ + + + ]]> +

If the server supports Entity Tag functionality for rosters, it SHOULD include an ETag SHIM header in its response (although it MAY decide not to include the header if the roster is deemed to be not worth caching because it is so small):

+ + + + Friends + + + Servants + + +
some-long-opaque-string
+ + + + ]]> +

The client would then cache that roster and associate the included Entity Tag with that cached copy. In order to subsequently retrieve the roster, the client would include the last known Entity Tag value with the request in an If-None-Match SHIM header:

+ + + +
some-long-opaque-string
+ + + + ]]> +

If the roster did not change since the client last retrieved the roster and the server supports Entity Tags for the 'jabber:iq:roster' namespace, the server MUST return a <not-modified/> error:

+ + + +
some-long-opaque-string
+ + + + + + + ]]> +

If the roster has changed, the provided Entity Tag value is not valid, or the server does not support Entity Tags, it MUST return the roster as if the If-None-Match header was not included:

+ + + + Friends + + + Servants + + +
some-new-opaque-string
+ + + + ]]> + + +

The payloads exchanged in the privacy list protocol (specified Section 10 of RFC 3921) can also be quite large. Therefore a server might want to support Entity Tags in the context of privacy list management. The process is as follows.

+

First, a client requests a privacy lists:

+ + + + + + ]]> +

The server returns the list and includes an Entity Tag in an ETag SHIM header.

+ + + + + + + + + +
some-long-opaque-string
+ + + + ]]> +

Later, the client requests the same privacy list again and includes the provided Entity Tag in an If-None-Match SHIM header:

+ + + + +
some-long-opaque-string
+ + + + ]]> +

If the privacy list did not change since the client last retrieved it and the server supports Entity Tags for the 'jabber:iq:privacy' namespace, the server MUST return a <not-modified/> error:

+ + + + +
some-long-opaque-string
+ + + + + + + ]]> +

If the privacy list has changed, the provided Entity Tag value is not valid, or the server does not support Entity Tags, it MUST return the privacy list as if the If-None-Match header was not included:

+ + + + + + + + + +
some-new-opaque-string
+ + + + ]]> + + + +

If a malicious entity gains access to a user's credentials or is able to masquerade as another entity on the network (e.g., as a man in the middle), it could force retrieval of information before it has changed. However, such access would compromise communications in a more serious fashion and corruption of the Entity Tags functionality is insignificant in comparison.

+ + +

This proposal requires no interaction with &IANA;.

+ + +

This proposal requires no interaction with the ®ISTRAR;.

+ + +

This JEP describes best practices for use of JEP-0131 and therefore does not require a dedicated schema.

+ + +

Is the ETag tied to a bare JID or full JID?

+ + diff --git a/xep-0151.xml b/xep-0151.xml new file mode 100644 index 00000000..52d20521 --- /dev/null +++ b/xep-0151.xml @@ -0,0 +1,828 @@ + + +%ents; +]> + + +
+ Virtual Presence + This JEP proposes extensions to the Jabber groupchat protocol for virtual presence on Web pages. + &LEGALNOTICE; + 0151 + Experimental + Standards Track + Standards JIG + + XMPP Core + JEP-0045 + + None + None + Not yet assigned + + + Heiner + Wolf + wolf@bluehands.de + wolfspelz@jabber.bluehands.de + + + + 0.2 + 2005-07-05 + hw +

Simplified VPI file and rule syntax, basically omitting the rule/search/replace tags.

 + + + 0.1 + 2005-06-02 + psa +

Initial JEP version.

 + + + 0.0.8 + 2005-05-20 + hw +

Added ignore-tag.

 + + + 0.0.7 + 2005-02-08 + hw +

Added comments on anonymity of presence element JID. + Added additional avatar retrieval methods: 1. presence stanza avatar data element 2. via disco

 + + + 0.0.6 + 2005-01-26 + hw +

Replaced firebat:chat:key by firebat:chat:state

 + + + 0.0.5 + 2004-07-29 + hw +

Notes about future changes in the JID/storage related sections.

 + + + 0.0.4 + 2004-07-27 + hw +

Changed avatar position request frem message-x to iq-get, because MUC may block unknown message namespaces.

 + + + 0.0.3 + 2004-03-17 + hw +

Textual changes. Added service tag to rule to overwrite default service of the location.

 + + + 0.0.2 + 2003-11-19 + hw +

Refined introduction and requirements. Added location mapping.

 + + + 0.0.1 + 2003-11-11 + hw +

Initial version.

 + +
+ + +

Virtual presence on Web pages (also sometimes known as co-browsing, while co-browsing can also mean something different) makes people aware of each other, who are at the same Web location at the same time. The basic purpose of a virtual presence system is to show names, icons, and/or avatars of people who are on a page or a set of pages and to let them communicate. This document proposes extensions to the Jabber protocol, which enable neat virtual presence on Web pages. The extensions are implemented as namespaces for the protocol elements &IQ;, &PRESENCE;, &MESSAGE;, and for server storage.

+ +

This document also covers the mapping of URLs to Jabber chat rooms. It describes step by step how clients derive virtual locations from URLs of web pages. The process includes queries to the web server, queries to default configuration sources, delegation between configuration sets, ways for administrators of websites to opt out, and methods to shape the virtual space actively by clustering together or splitting off URL groups.

+ +

This document describes an implementation that proved to be useful over one year. We propose the extensions, but we are open to comments and other proposals, if readers think that different approaches would better fit into the Jabber architecture. This also applies to namespaces, especially since the extensions where designed while the Jabber community was moving to URL-style namespaces. So did this implementation.

+ + + + + + +

Meeting on virtual locations is very similar to meeting peers in a public chat room. But web pages can be regarded as 2 dimensional. They very often cover the entire screen. They use graphics elements for their content. Plainly speaking: representing users as figures or other images fits well to web pages. Once they are shown as individual figures, a line based chat and a chat window are not required any more (though a chat window can still be used). The figures can move around and talk in chat bubble style. Chat bubbles in turn enable incremental chat.

+ +

This document describes protocol elements for +

    +
  • the visualization of users on web pages (animated avatars) and
    • +
  • communication beyond line based group chat (incremental or instant bubble chat)
    • +
+

+ +

While users are browsing the web, they enter and leave many rooms. They meet many people and some of them multiple times. Minimum overall traffic and minimum traffic on the user connection are primary design goals. The user connection is limited by typical karma settings of jabber servers. Logging in to virtual locations (rooms) must be quick in terms of round trips and cheap in terms of traffic. Once logged in to a room, the traffic on the user connection should be independent of the number of peers already present.

+ +

The extensions have been designed to be: +

    +
  • compatible to the existing Jabber infrastructure and protocols,
    • +
  • lightweight with respect to the number of new elements,
    • +
  • lightweight with respect to the traffic generated.
    • +
+

+ +

The traffic goals can be met by using only the initial &PRESENCE; stanza, which carries all required information, so that no peer-to-peer messages are required on entering. VP clients which gather additional information about peers (e.g. avatar images) should cache the data so that it can be re-used. This is especially important since users browsing virtually connected locations (i.e. linked pages) may meet very often in a short time.

+ +

The virtual presence extensions make use of Jabber group chat. Virtual locations are implemented as public Jabber chat channels. The proposed protocol works with &jep0045; rooms and GroupChat 1.0 compatible services. Its core functionality described here uses only groupchat features.

+ +

The virtual presence extensions are supposed to be implemented by Jabber IM clients in addition to the IM functions or by pure virtual presence (Jabber VP) clients.

+ + + + + +

The virtual presence network is a distributed network of Jabber conference components. Each component is hosting a part of the Web. Conference components may be specifically set up for virtual locations, or they may run chat rooms for virtual locations in addition to other rooms. A website may choose to run a conference component to host the presence on its web pages or it may use a publicly available service. Websites, which do not care, are covered by default servers, while others may opt out entirely in order to avoid virtual presence on their pages.

+ +

Usually VP clients gather URLs from active web browsers. They convert these URLs to Jabber chat rooms IDs (JIDs) using web server specific and general rules for the mapping process. Then they enter the room as described in the section 'Example of a Virtual Meeting'. There are many different types of URLs. Many are based on file system paths, others are query style, or a mix of path and query. Sometimes users regard individual pages as locations, sometimes a 'location' consists of multiple pages. Large websites may even consist of multiple DNS names, so that users expect to be at the same location regardless of the actual server name.

+ +

Usually website operators will not care about virtual presence on their pages. But once there is a significant amount of chat on their pages, they want to control what happens there. In other words: they need to be able to enforce domestic authority on their pages and even expel visitors from 'their' chat. They will install moderators (persons or software). Moderators authorized by the website might operate on public chat servers, but control is only guaranteed, if a website controls the assignment of moderators by running the chat server. Hence, website operators must be able to control the mapping process so that they can assign chat server addresses (and chat room names) to URLs. Many websites are hierarchical, with sub-folders being managed by different independent owners. The mapping process should allow for detailed mapping rules for sub-folders and general rules closer to the root of websites, so that the 'inner' config prevails.

+ +

The mapping process is controlled by configuration files. The files will be downloaded from websites and/or from a default location. Most websites do not know about virtual presence and if they know, then they do not care. Therefore, the mapping process should be designed to allow for virtual presence without cooperation of the website. A default configuration with a simple standard mapping will be used if a website does not provide mapping rules.

+ +

Configuration files for the mapping process will often be downloaded over the network. Since the data for multiple virtual locations might add up to large files, the configuration can be split up into individual documents. The splitting is managed by delegation to other config files for subsets of URLs. This is especially important for the default configuration, which may cover special rules for prominent websites.

+ +

Global fallback servers are not able to carry all the enter/leave and chat traffic. The virtual presence of many users on many websites demands commercial services for virtual presence hosting. Much like web hosters provide disk space, traffic and processing power, there are commercial (or free) presence hosting services, which provide traffic and processing power. Website operators will either run their own presence servers or rely on commercial services. Commercial operators are limiting the ad-hoc creation of chat rooms for virtual presence or they allow static rooms only. Website operators encode the 'rented' room JID into their mapping configuration. They might even delegate the handling of configuration files entirely to the presence server operator by means of config file delegation.

+ +

The mapping process should try to protect the privacy of the user. After all, virtual presence is a violation of privacy in general, because people know where other people are (virtually). This is critical, if compared to the totally un-observed Web without virtual presence. In the real world people are used to being seen in physical locations, but only by others who are physically present in the same location. The mapping process should emulate this restriction. The general idea is to include a one way function (message digest) during the mapping process to prohibit the discovery of 'interesting' chat room names. In other words: observers must do the forward mapping and enter a room to see who is there or discover random room names without being able to re-create the source URL. So, they may be able to find people in random rooms, but do not know the virtual location.

+ +

This mapping process is designed to +

    +
  • make the virtual presence service a distributed network of jabber servers, i.e. conference components,
    • +
  • allow for flexible mapping from URLs to JIDs, taking into account that +
      +
    • most URLs are path based,
      • +
    • URLs contain queries,
      • +
    • sometimes only the query part defines the virtual location,
      • +
    • groups of URLs map to a single JID,
      • +
    • a single virtual location may comprise multiple web servers,
      • +
    • groups of URLs may only cover a sub-folder of path based URLs,
      • +
    • not all URLs are known at config time,
      • +
    +
    • +
  • allow operators of websites to control the mapping for the URL-space they control,
    • +
  • let websites opt out of virtual presence,
    • +
  • allow for hierarchical configuration for file system path based URLs,
    • +
  • support delegation,
    • +
  • allow for virtual presence without the cooperation of the website,
    • +
  • allow for distribution of the load of the default configuration server,
    • +
  • support commercial virtual presence servers and rented rooms,
    • +
  • be extensible to other protocols as virtual presence transport,
    • +
  • be easily implemented by website operators,
    • +
  • at least limit the privacy issues associated with virtual presence.
    • +
+

+ + + + + + + +

Since it has been suggested that the use of Shakespeare characters might please the reader we will try to employ them without really knowing the works of Shakespeare. Two characters called Romeo and Juliet will appear. Both will be equipped with a Web browser and a virtual presence Jabber client which implements the protocol extensions described in this document (called VP client in the following). The communication is shown as seen by the conference component including 'from' attributes.

+ + +

This shows how the first meeting of Romeo and Juliet would have happened if they had known Cyberspace, i.e. the Web. Romeo browses the Web with his favorite web client. He reads the page http://www.shakespeare.com/market/ModernLibrary/page1.html. He is also running a VP client. There is no mention of a buddy list jabber client at this point. The VP client is properly logged in to the Jabber server using the JID romeo@montague.net. Through some magic, the VP client acquires the URL of the current web page. The VP client converts the URL into the JID of a public chat room (see section 'Virtual Locations'). The JID will usually be a SHA1 digest of the URL prefixed to a conference component (like f4eb29410ec339144633773dda1dc4a643513933@shakespeare.com). For the sake of readability we will refer to the chat room as room1@shakespeare.com. The VP client then enters the room using 'YoungHero' as the nickname.

+ ]]> + + +

The room responds:

+ ]]> + + +

Upon reception the VP client visualizes the presence of Romeo at the location to Romeo, e.g. by displaying Romeo's icon and/or nickname on, at, or close to the web page. In other words: the VP client shows an avatar of Romeo on the page.

+ +

Dramatic increases when Juliet browses to the same web page. Her VP client also gathers the URL, performs the same mapping and enters the room. It sends a &PRESENCE; stanza to the room using nickname 'WebGirl'. The room as expected returns the acknowledgement. In addition the room forwards both &PRESENCE; stanzas to the VP clients in order to announce the mutual presence.

+ +

Romeo gets:

+ ]]> + + +

Juliet gets the equivalent. Romeo's VP client shows Juliet's presence by adding a second avatar to the page. They now engage in a vivid conversation. In deviation to the original text Juliet would not ask "Who art thou, Romeo?", because she only knows the nickname and on the other hand she actually knows where Romeo is: he is on the same web page. There is nothing new until now. Everything happened according to GroupChat 1.0 (JEP-0045) without MUC features. Of course, users can join the same room with any client that supports GroupChat, if they know the room's JID.

+ +

Extensions come into the play in order to make the virtual presence more attractive and more vivid.

+ + + + +

For more information about 'YoungHero' beyond the nickname Juliet needs a JID (see below for anonymous variants of the avatar image). Non-anonymous rooms will supply the JIDs automatically. But we suggest that rooms, which make up the virtual presence network are configured to be anonymous so that users can choose if they want to disclose the JID. We propose an extension to the &PRESENCE; stanza for users to supply their JID automatically to peers in anonymous rooms with minimum traffic even for many participants.

+ +

Note: even though Romeo sends a JID, the systems is still anonymous. Romeo could send any JID. He may send a (fake) JID that is just the base address of his storage, but not his communication address. In anonymous rooms Juliet will use any JID Romeo provides. If the room is not anonymous, then Romeo's client may use Juliet's actual JID.

+ +

Entering the room Juliet would add a JID-element to the initial &PRESENCE; stanza.

+ + juliet@capulet.com/balcony +]]> + + +

(Note: 'firebat' was the developer name of the VP client. Jabber.org URIs could be used here)

+ +

This tells the conference component to send the JID to all participants automatically. Romeo will receive the &PRESENCE; stanza including the JID element. Romeo may now fetch Juliet's avatar or add Juliet to a buddy list.

+ +

Note: disclosing the JID is usually not advisable in public rooms. We decided to offer the functionality as an option, for 2 reasons: +

    +
  1. to provide access to extended information from peers without cluttering the &PRESENCE; stanza more than necessary,
    2. +
  2. to allow for caching of extended information.
    3. +
+ Caching requires a persistent and unique id per user. While a message digest of the JID would be sufficient for caching extended information, it is not sufficient for retrieving extended information. +

+ + + + + +

Romeo will be much more interested in Juliet if Juliet is depicted by a nice image rather than only a name. Users may choose avatars, publish those avatars, and change them on the fly. Changes to the avatar are tracked by comparing a stored digest of the avatar data to the received digest. The avatar digest will be received as part of the &PRESENCE; stanza. Juliet also includes an avatar-digest element with a hex-coded SHA1-digest of the avatar data (i.e. the digest of the image file):

+ + juliet@capulet.com/balcony + 9b3635eb1440a1ee1c9f67767651194f34ecf130 +]]> + + +

Romeo receives the digest with the initial &PRESENCE; stanza from Juliet. Since this is their first meeting Romeo does not have Juliet's avatar yet. He will fetch the avatar from Juliet's public XML server storage (for a public XML storage free variant see below):

+ + + +]]> + + +

The server returns Juliet's avatar.

+ + + + + +]]> + + +

The 'src' attribute points to the real data, which is to be fetched out of band via HTTP. Juliet supplied a reference to the data because she is a smart WebGirl concerned about bandwidth on the Jabber connection. But if the Capulets would not own a domain she could also choose to store the avatar data directly on the server using base-64 encoding. The avatar response would then be like:

+ + + + E00fcB79F822u192e7A2067E5229ec136892A296... + +]]> + + +

Juliet can omit the 'mimetype' attribute if she supplies the avatar URL, because the HTTP server will return the MIME type. The 'mimetype' attribute must be included for immediate data. Avatars may be of any type and size. The maximum visible dimensions of avatars should be 64x96 pixels. Larger images will be scaled down to fit into this rectangle. They will not be scaled up. Images align at the bottom so that they can 'stand' on a page on the same base line.

+ +

Implementation note: The client should check the image size (byte count) and advice the user if the size exceeds 20 kb. It should also check the image dimensions and warn the user if the image will be scaled down. Checking the size is especially important for immediate data, which will be uploaded over a Jabber connection which is subject to flow control. Typical karma settings only allow for few kb without stalling the connection.

+ +

Implementation note: Avatars and associated digests should be stored permanently. They will always be up to date as soon as people meet and exchange digests. There is no cache timeout. The implementation should keep an eye on the avatar storage and delete old and rarely used ones.

+ +

Avatars images can also be created of other data types. The following shows an avatar description in XML format, which is to be processed by an advanced avatar engine. The avatar engine will be chosen by the MIME type. For simple image based avatars, the MIME type selects the type of image decoder. Other MIME types may select from a dynamic list of installable avatar rendering plug-ins.

+ + + + + + + + + + + + + + + + + + + + +]]> + + +

The example avatar data above will be interpreted by the avatar engine, which registered for the MIME type 'avatar/comic'. This is a sample implementation of an animated avatar. The data states that an animation file shall be loaded from http://avatar.vp.bluehands.de/comic/lluna.xml and then the character config shall be applied modifying the colors of the character definition.

+ +

The design is particular targeted at existing online games as avatar providers. It would be very easy to adapt the avatar rendering of an online role playing game (MMORPG) or any other community so that it provides avatar images for the VP client. In this case the avatar data would probably only consist of the online accout ID. This is up to the implementation. We imagine such avatar data to be like:

+ + + + ACCOUNTID=6575438998 + +]]> + + +

... and the plug-in (which is part or the game distribution) connects to the game server, fetches the configuration, and renders Juliet as an nightelve mage level 30 with all insignia on the web page of Romeo. Romeo is very impressed, falls in love instantly and they both die in the course of a tragic story. Provided that Romeo happens to have the same gaming engine installed. Having not might save him in this time.

+ +

Note: As a matter of fact, we propose a call level plug-in interface described at http://developer.lluna.de/docs/animated-avatars.html for advanced avatars.

+ +

Note: To make things simple for the implementation users may have 2 avatars. The first avatar ('storage:client:avatar') is restricted to GIF and PNG images. The second avatar is fully featured, but optional. It is accessed through the namespace 'storage:client:avatar2' and tracked through digest 'firebat:avatar2:digest'. VP clients must implement 'storage:client:avatar' and 'firebat:avatar:digest' with at least PNG support. They may implement 'storage:client:avatar2' and 'firebat:avatar2:digest'. The scheme can be extended with higher numbers.

+ + + + + +

If Juliet wants to protect her real JID, then she can not use public XML server storage. She can still provide an avatar by including the avatar data into the &PRESENCE; stanza.

+ + +as part of: +9b3635eb1440a1ee1c9f67767651194f34ecf130 + +]]> + + +

Juliet must not send bulky immediate data, but a reference to the image. Immediate data is only allowed, if it is smaller than a simple &PRESENCE; stanza (see above).

+ + ACCOUNTID=6575438998 +]]> + + +

Note: There are other features which won't work without the real JID. Therefore, it is recommended that clients include the JID in the &PRESENCE; stanza. If Juliet wants to use all JID-based features then she would rather use a public Jabber server with an anonymous account, like she is used to do in case of email. This feature is supported because there are still Juliets who refrain from disclosing the JID and because the avatar is very important.

+ +

If Juliet provides the JID, but public XML server storage is not supported on Juliet's server, then Romeo may try to discover the avatar using disco features. He will query Juliet's server avatar disco node

+ + +]]> + + +

The result contains an item with the JID of the pubsub component where Juliet's avatar information is published and the specific node for that information:

+ + + + +]]> + + + + + +

A web page can be regarded as a two dimensional space. Avatars can move around on the page. Users are not just at a page, they are at a certain coordinate of the page. Entering the room Juliet tells Romeo (and all other participants) her initial position by including a position element into the initial &PRESENCE; stanza:

+ + juliet@capulet.com/balcony + 9b3635eb1440a1ee1c9f67767651194f34ecf130 + +]]> + + +

The coordinates are in pixels from the bottom left corner of the browser window. In this case she only tells the horizontal position. She could add a 'y' attribute. She also voluntarily discloses the width of her browser window. The width ('w') and height ('h') attributes are optional. They enable relative positioning at the other end.

+ +

As soon as Juliet enters and her avatar appears, Romeo moves his avatar up to Juliet's. Romeo's VP client sends a new &PRESENCE; stanza with an altered position. The message is automatically broadcast by the room to all participants and stored for new participants. Romeo approaches Juliet:

+ + romeo@montague.net + e5229ec136892e00fcb79f822c192e7a2067a296 + +]]> + + +

Note that this &PRESENCE; stanza, which is sent in order to move the avatar is not different from the initial &PRESENCE; stanza to the room. This is just a repetition with a different coordinate.

+ +

Juliet's VP client forwards the movement to the avatar rendering engine. In case of an image based avatar the image is just moved to take up the new position. In case on an animated avatar, the avatar engine will generate a sequence of images which lets the figure 'walk' to the new position or whatever movement method is appropriate for the avatar.

+ +

Now Romeo occupies exactly the part of the web page that Juliet is reading so she moves Romeo (locally) out of the way. This happens only on Juliet's screen. Once Juliet finished reading, she wants to restore Romeo's position. She sends a control message to Romeo to request the current position:

+ + + +]]> + + +

Romeo responds with a control message which indicates the avatar position:

+ + + + + +]]> + + +

Juliet' VP client restores Romeo's avatar position:

+ + + + + +

We remember: after seeing Juliet's avatar, Romeo has already falling in love. But Juliet is a more realistic type. She insists on talking before falling in love. The avatar-on-web-pages paradigm frees us from chat line based chat. Each avatar may show a separate chat bubble with the latest text or even a chat history.

+ +

While Juliet is writing an opening, her VP client may send the current contents of the chat line to the room giving other participants snapshots of the text. We propose instant chat updates as an extension to groupchat. For backward compatibility these snapshots are transmitted as control messages without body text, so that other clients ignore them. Once Juliet hits the send button (or the enter-key) the VP client sends the chat message as body text of a &MESSAGE;. With a timely distance of fractions of seconds to few seconds Juliet sends the following messages:

+ + + Who + + + + Who art thou, + + + + Who art thou, YoungHer + + + + Who art thou, YoungHero? +]]> + + +

Note: we propose to send the full text with every message. Differential updates seem to be the proper way. But the addressing information sent with each message produces more traffic than the enclosed text. This is especially true for randomly chosen (read: long) room names. On the other hand differential text requires synchronization points for new participants, who lack the history. Such synchronization points would carry the full text every other second rendering differential updates almost useless.

+ +

Implementation note: The traffic must stay below the karma-limitations of typical jabber servers. The minimum delay between instant chat messages should be 1 sec. The delay should be increased with the size of the text. We get a good balance between interactivity and traffic with the following algorithm (in msec): delay = max(5000, min(NumberOfChars x 25, 1000)). In words: from 1 second at 40 characters up to 5 seconds at 200 characters.

+ +

Implementation note: There is no limitation on the size of the instant chat specified. But some users, especially the ones not used to chat channels write without ever pressing the enter-key. Implementations should limit the size to reasonable length (200-1000 characters) by telling the user, refusing to send more, or just stripping the beginning of a long text.

+ + + + +

After some chatting, Juliet is still not convinced. She demands to see Romeo live (although not in person). Romeo switches on his webcam and sends the webcam URL as part of the &PRESENCE; stanza.

+ + romeo@montague.net + e5229ec136892e00fcb79f822c192e7a2067a296 + + http://romeo.montague.net/video/icon +]]> + + +

Juliet's VP client HTTP-requests the video stream. The video is shown close to Romeo's avatar. Juliet falls in love.

+ +

The video format is the common, widely used webcam format introduced by Netscape (JPEG server-pushed).

+ +

In the real world there are many Romeos and Juliets even on the same page at the same time. Some of them with a webcam. Depending on the default settings of VP clients all users (say 8) will automatically request the videos of the subset of users equipped with a webcam (say 3). This automatically creates many video streams, 3 streams on the dialup line of all users and 7 streams on the line of webcam users. We therefore suggest the following optimizations and limitations: +

    +
  • video dimensions should be limited to 64x64 pixels, thus fitting into the 64x96 avatar rectangle,
    • +
  • the frame rate should not exceed 3 frames per second for simple web browsing (special applications, especially assymmetric ones, like virtual class rooms, presentations may differ),
    • +
  • for small sizes, quantization tables and Huffman tables make much more data than the encoded image. Therefore, the DQT and DHT markers should be stripped from JPEG frames except for the first frame of a stream. Only the JPEG baseline algorithm is supported with static Huffman tables,
    • +
  • VP clients which support such a optimized JPEG server-push format should add a 'Accept: image/djpeg' header to the HTTP request. (djpeg for differential JPEG)
    • +
+ + The purpose of these limitations is to allow for webcams which send optimized streams of small images (reducing the data volume by a factor of 3) while supporting usual webcams. +

+ + + + + + + +

Finding a virtual location for a websites means mapping a URL to a JID. The VP client gets the URL from the browser by some platform dependent way of interprocess communication. The URL may have been entered by the user, or it may be the result of a URI resolver. Then the VP client searches for an applicable mapping rule. This may include fetching multiple configuration files over the network. Finally the rule is applied and the VP client can enter the room.

+ +

The mapping process is explained in great detail here. Server admins only need the sections 'Mapping Rules' and 'Config Files'

+ + + +

The basic mechanism is very simple: a URL is mapped by means of a regular expression with replacement term. A hash function may follow after the regular expression and an optional prefix can be added for convenience. The mapping rule produces a room name and a chat service URL. The chat service URL points to the server which hosts the channel. It also tells which protocol to use. Protocol, server address and channel name identify the chat channel.

+ +

Romeo is on http://www.shakespeare.com/market/ModernLibrary/index.html. A single mapping rule might cover the entire URL space of http://www.shakespeare.com/. It might look like:

+ + + \1-room + vp- + xmpp:conference.shakespeare.com + ]]> + + + + + +

This <name/>-tag produces the room name. The text of the <name/>-tag in combination with the match expression of the <location/> extracts the first level folder of the path section from the URL. It creates a room for each first level folder. The resulting room name is 'market-room'. It is hashed by a message digest, if the <digest/> tag is present. A SHA1 digest is used by default. VP clients must support SHA1. The hashed result will be prefixed by 'vp-'. Prefixing is provided for convenience, so that rooms generated for virtual presence can be sorted easily in room lists of conference components. Both <digest/> and <prefix/> are optional.

+ +

The \1 variable of the match-expression is used to generate a room per sub-folder of the URL. Match-expression variables can be used inside all elements to modify the inner text of the element. You might use the \1 inside the <service/>-tag to point to a different chat server per sub-folder of the URL.

+ +

The rule generates a virtual location ID. This mechanism is extensible to other protocols as virtual presence transport, e.g. IRC. The <service/>-tag contains a service URL, which consists of a scheme and server address. In this case the 'xmpp'-scheme means that the Jabber protocol will be used and that the VP client joins a Jabber chat room with a JID created according to the Jabber ID building rules, i.e. room-name@server-address, where the room-name has been derived from the 'name'-tag and mangled by the 'digest'-tag before it has been prepended to '@server-address'.

+ +

A <location/> without match-attribute matches all URLs. In other words: the default match-attribute is '.*'.

+ + + + + +

Rules can be stored in various ways. If they are stored in files, then the rules are wrapped by a toplevel element. The VPI toplevel element can contain multiple <location/>-elements (rules):

+ + + + ... + ... + ... + ... +]]> + +

Examples are available at http://developer.lluna.de/docs/vpi-file-syntax.html

+ + + + + +

Independent services may publish lists of virtual locations. An example is a 'topsites'-service, which publishes a list of most active locations as a list of URLs. These services usually require the cooperation of VP clients. VP clients publish their locations (and URLs), if configured to do so. In some cases website operators allow for virtual presence on their pages, but they do not want that the real URLs are published, or they do not want the URLs published at all. Therefore, the location configuration offers optional tags to control how URLs are disclosed by VP clients. A <hidden/>-tag prohibits the publication of the URL. A <destination/>-tag modifies the URL. A <hidden/> location may look like:

+ + + shakespeare + + xmpp:conference.shakespeare.com + + ]]> + + +

In this example all URLs of the website will be mapped to a single room. Users will be present there, but the room will not appear in public lists (if clients and publication services comply).

+ +

A simplification of the above is the <mapped/>-tag, which does not employ regular expressions. All URLs of the website can be mapped to a single location (omitting the <hidden/> feature again):

+ +

The <destination/>-tag modifies the URL so that website operators control which URLs are published. They might delete a web-session ID from URLs or alter the URL so that users who discover the location on a publication service are directed to a different URL. The biggest concern is that the exposed URL may contain security relevant session data. The <destination/>- (per <rule/>) allows to remove this data from URLs while preserving browseable URLs. The following example deletes any path and query from URLs.

+ + + shakespeare + + xmpp:conference.shakespeare.com + http://www.shakespeare.com/ + ]]> + + +

Note: VP clients should not rely on a <destination/> only, when publishing URLs. A client should consult the user if, how, and where URLs are to be published. It is recommended to strip the query part by default until configured otherwise.

+ +

The <ignore/>-tag prevents virtual presence clients from dealing with matching URLs. There will be no virtual presence associated with the URL.

+ + + +]]> + + + + + + +

Location configuration data, such as the above is stored in configuration files called Virtual Presence Information (VPI) files. The files are fetched via HTTP or FTP, according to the scheme of the URL which is to be mapped. Websites can offer VPI files at each level in the path hierarchy. If they do not offer VPI files then the VP client reverts to default VPI. The VP client tries to find a VPI file in the same folder as the file of the URL. It strips the file and query parts of the URL and appends the file name _vpi.xml:

+ + + + +

HTTP-servers have many different ways to respond if the file is not available, which is the most common case. They should respond with a 404 status code and an optional HTML message. But some web servers are configured to return a default document, some return a status code 200 and a 'Content-type: text/html' message with an error text, some even return status code 200 and 'Content-type: text/xml' with an HTML message. It is therefore recommended that VP clients check the HTTP status code, the Content-type and the validity of the XML document. If there is no such file or if it is not a valid XML file or, in case of HTTP, if the Content-type is not text/xml, then the request fails. If the request fails then the client ascends the path until it hits the top level of the website trying to fetch:

+ + + + +

If the request fails, then the client reverts to a default VPI file if there is any. The current implementation uses http://vpi.vp.bluehands.de/lluna-2.5.2/root-vpi.xml. It will finally use http://www.virtual-presence.org/LMS/root-vpi.xml (LMS = Location Mapping System) or another global configuration file. http://vp.jabber.org/root.xml would be an option.

+ +

If there is no default VPI file then the VP client uses the following configuration data:

+ + + \1 + + xmpp:location.virtual-presence.org +]]> + + +

This configuration creates a virtual location for each web server address. The server name is obfuscated by a hash function (SHA1). The location configuration applies to all URLs, since the match-attribute of the <location/> defaults to '.*'.

+ +

VP clients must cache the result of VPI downloads including failed requests and invalid responses. They must keep a local copy for at least a few minutes to avoid traffic from multiple (ascending) VPI file downloads.

+ +

Note: There are many websites, which consist of multiple web server addresses. This is especially true for large sites, which use DNS round-robin for load balancing. These websites need a special mapping to meet the expectation of the user, because users usually do not care if they are on www01.website.com or on www02.website.com. If users expect to see each other, then the virtual presence service should meet the expectations. There might also be website operators, who do not like virtual presence on their pages. These operators may even take legal action against the provider of the VP client software. So, these websites may require special configuration as well. And there may be other reasons for individual configuration of selected websites. Therefore, it is recommended, that VP clients update their default configuration, i.e. by using an automatic update feature or by downloading the default VPI.

+ +

A VPI file may delegate the handling of URL spaces to another VPI file. The <delegate/>-node replaces the <mapping/> and <service/> nodes of the <location/>. If the VP client discovers a <delegate/> tag inside a <location/>, which matches the URL to be mapped, then it stops processing the file and loads the VPI file denoted by the <delegate/>-tag. A request to http://www.shakespeare.com/market/ModernLibrary/_vpi.xml could return VPI like:

+ + + http://www.shakespeare.com/_vpi.xml +]]> + + +

This means that the VP client skips http://www.shakespeare.com/market/_vpi.xml and continues with http://www.shakespeare.com/_vpi.xml. Delegation can be used to direct the VP client to the VPI file of a commercial virtual presence service. The commercial service would then be responsible to create rooms for customers and to provide the appropriate VPI. Delegation is also useful to split up the default VPI file. The default VPI file contains special configuration for some large websites. It has been split into individual files for different (DNS) top level domains. The global VPI file currently in use (http://vpi.vp.bluehands.de/lluna-2.5.2/root-vpi.xml) contains the following statement for the .com space:

+ + + http://vpi.vp.bluehands.de/lluna-2.5.2/dotcom-vpi.xml +]]> +... + + + + + + +

This section is intended as a guideline for the implementation of the mapping process.

+ +

The mapping has 2 phases: +

    +
  1. finding the rule
    2. +
  2. applying the rule
    3. +
+

+ + + +

+ We get a URL from the web browser, say + + We try to fetch the configuration file from + + The request fails (the failure is noted in the cache), and we try + + The request fails again (the failure is noted in the cache). We try + + We do not find it (the failure is noted in the cache), and we revert to the + global file (which one depends on the client configuration) + + The request returns (and the data is stored in the cache): + + + + + + http://vpi.vp.bluehands.de/lluna-2.5.2/dotcom-vpi.xml + + + + + http://vpi.vp.bluehands.de/lluna-2.5.2/dotde-vpi.xml + + + + + xmpp:location.virtual-presence.org + + \1 + + +]]> + + We try to find a <location/> that matches our URL. We find: + + http://vpi.vp.bluehands.de/lluna-2.5.2/dotcom-vpi.xml +]]> + + This means that all .com domains are forwarded to a separate VPI file. + We fetch: + + + We store the result in the cache and search for a matching <location/> + again. We find the default section (rest of the file omitted, the match-attribute is more general than the one of the previous <delegate/>, because here we are already in the .com domain): + + xmpp:location.virtual-presence.org + + \1 + + +...]]> + + The <location/> matches, so we get a virtual presence + service address and a set of rules. + The virtual presence server is + + + The protocol to use is + + + There mapping rule is: + \1 + ]]> + + The result of the first phase is a mapping rule, which will be + applied to all URLs in the same folder as the original URL. In regex-speech: + + + To apply the mask only to URLs in the same URL-path folder is a security + requirement, so that 'inner' VPI files + from websites can not configure the mapping of 'outer' folders or 'siblings'. +

+

+ The original URL was: + + + So, the security mask is (the rule applies only to URLs in the same folder as the original URL): + + If the security mask applies to a URL can be verified by a simple string-compare without using a regular expression. +

+

+ The <location/> has a match attribute. This is the user supplied mask + of the rule: + +

+ + + + + +

+ + The URL where we want to meet people is: + + + We got many rules with a security mask (from the folder of the original URL) and a regular expression + (from the match-attribute). For each new URl we check the URL against the security mask and the regular expression. + One of the rules applies to the URL: + + + The regular expression + + + and the room <name> + + + will extract the first level folder from the URL. The URL + + + gives: + + + The <digest/>-tag tells us to hash the regex replacement result with + the default message digest SHA1. So we get: + + + The <prefix/>-tag tells us to prefix with + + + and finally the ID of the virtual location (the room name) is: + + + From the <service/> + + + the client knows the transport protocol and the address. The Jabber protocol will + be used as transport protocol and the Jabber conference room JID is + + +

+ + + + + + + + +

This document does not introduce new error codes.

+ + + +

The system has been designed to protect the privacy of the user as good as possible. If users decide to run the VP client, then other users may see their movement, but only if they enter the same locations. There is no way to track users, especially since the JIDs of virtual locations (Jabber chat rooms) are supposed to be SHA1 digests of URLs which are not predicable. So people trying to track Romeo have to guess the URL and enter the respective chat room to find Romeo. They cannot browse the room list of a conference component and deduce the URL from the room name.

+

The fact that clients may disclose their JID in order to provide access to their avatar server storage and in order to enable caching is a weak point. A different but equally unique ID could be for caching purposes, provided that it is part of the &PRESENCE; stanza. But traffic restrictions on the client connection prevent that additional data is exchanged between peers in a room. The data could be broadcast to the room, but this could end up in many people always broadcasting avatars while entering a room (web page). The chosen solution is to let peers download from public server storage. A better solution might be to let the conference component fetch from the server storage. In this case clients would need only the room-JID of the user, not the real JID.

+ + + +

These namespaces need to be reviewed and/or registered with the Jabber Registrar as a result of this JEP. +

    +
  • firebat:user:jid
    • +
  • firebat:avatar:position
    • +
  • firebat:avatar:getpos
    • +
  • firebat:chat:state
    • +
  • firebat:icon:video
    • +
  • firebat:avatar:digest
    • +
  • firebat:avatar2:digest
    • +
  • storage:client:avatar
    • +
  • storage:client:avatar2
    • +
+

+ + + + +

No schema definitions yet. They will be added in the next version of this document, if it is considered for publication.

+ + + + +

The virtual presence on Jabber has been designed to fit easily into the existing Jabber infrastructure including existing software components, clients, and protocols. It turns out that Jabber offers everything necessary for basic virtual presence.

+ +

This document proposes a mapping process in order to create a space for virtual presence on top of the URL based Web infrastructure. It also proposes namespace extensions for the protocol, which make virtual presence on web pages more convenient. The core features are: +

    +
  • URL mapping and service discovery,
    • +
  • avatars standing and walking on a web page,
    • +
  • bubble chat,
    • +
  • iconic video.
    • +
+ There are definitely more features possible. Suggestions are welcome

+ + + diff --git a/xep-0152.xml b/xep-0152.xml new file mode 100644 index 00000000..7bcd7f0b --- /dev/null +++ b/xep-0152.xml @@ -0,0 +1,240 @@ + + +%ents; +]> + + +
+ Reachability Addresses + This document defines an XMPP protocol extension for communicating reachability information related to non-XMPP devices. + &LEGALNOTICE; + 0152 + Experimental + Standards Track + Standards JIG + Council + + XMPP Core + XMPP IM + + + + reach + &hildjj; + &stpeter; + + 0.2 + 2006-09-17 + psa +

Defined PEP transport.

 + + + 0.1 + 2005-06-16 + psa +

Initial JEP version.

 + + + 0.0.1 + 2005-06-07 + psa/jjh +

First draft.

 + +
+ +

Sometimes it is desirable or necessary to switch from instant messaging (IM) to another real-time communications medium, such as a telephone conversation conducted over the traditional public switched telephone network (PSTN) or more recent Voice over Internet Protocol (VoIP) applications. In order to facilitate switching from IM to telephony or some other medium, a user needs to advertise the address(es) at which they can be reached. There are several possible ways to do this:

+
    +

  • Publish the reachability address(es) in the user's vCard (see &jep0054;); this is convenient, but is not very dynamic (e.g., reachability addresses might change when the user moves to a new conference room in an office building).

    • +

  • Publish the user's reachability status (but not addresses) as a feature bundle within &jep0115; information; this is somewhat dynamic (subscribers can be informed when reachability information is available) but requires every interested subscriber to perform service discovery in order to determine the reachability address(es).

    • +

  • Send the reachability address(es) within a &PRESENCE; stanza; this option is described in the Presence Broadcast section of this JEP and is consistent with Section 5.1.2 of &rfc3921; since reachability is one aspect of a user's availability for communication.

    • +

  • Send reachability address(es) to the appropriate &jep0163; node; this option is described in the PEP Transport section of this JEP but may not be available at all service providers.

    • +
+ + +

This JEP addresses the following requirements:

+
    +
  • Enable clients to dynamically publish reachability addresses.
    • +
  • Minimize network traffic.
    • +
+ + +

The following is an example of the basic data format for reachability addresses:

+ + + + + ]]> +

When publishing reachability addresses, the <reach/> element MUST contain at least one <addr/> element. Each <addr/> element MUST possess a 'uri' attribute, whose value MUST be the Uniform Resource Identifier (&rfc3986;) or Internationalized Resource Identifier (&rfc3987;) of an alternate communications method for reaching the user.

+

The <addr/> element MAY contain one or more <desc/> children whose XML character data is a natural-language description of the address; this element SHOULD possess an 'xml:lang' attribute whose value is a language tag that conforms to &rfc3066; (although the default language MAY be specified at the stanza level; see Section 9.1.5 of &rfc3920;). In order to preserve bandwidth, the <desc/> element SHOULD NOT be included when sending reachbility data via presence broadcast, but MAY be included when using personal eventing.

+ + + New conference room number + + + My softphone + + + ]]> + + +

As described below, this JEP specifies two methods of advertising reachability addresses:

+
    +
  • Presence broadcast
    • +
  • Personal eventing via publish-subscribe (PEP)
    • +
+

This JEP does not recommend one transport method over the other.

+

In addition, a contact MAY request a user's reachability addresses using an &IQ; request-response sequence.

+ +

In order to broadcast reachability addresses in presence information, a user's client includes the <reach/> element in the &PRESENCE; stanza it sends to its server:

+ + + + + + + ]]> +

The user's server then broadcasts that presence stanza to all entities who are subscribed to the user's presence:

+ + + + + + +. +. +. + ]]> + + +

In order to publish reachability via the publish-subscribe transport, an entity MUST first create the appropriate node as explained in JEP-0060. Here we assume that the node already exists.

+ + + + + + + My mobile number + + + My softphone + + + + + + + ]]> + + + + + + + My mobile number + + + My softphone + + + + + + + ]]> + + +

If a client supports the reachability addresses protocol described herein, it SHOULD include a &jep0030; feature of 'http://jabber.org/protocol/reach' in its replies to disco#info requests:

+ + + + + + + ... + + ... + + + ]]> +

If desired, the contact then MAY query the user for any reachability addresses:

+ + + + + + + + My mobile number + + + My softphone + + + + ]]> + + + +

To preserve network bandwidth, the sender SHOULD NOT include the <desc/> element unless that information is deemed necessary to enable communication.

+

A recipient SHOULD attempt communications with reachability addresses in the order that the <addr/> elements appear within the <reach/> element.

+ + +

If included, the <desc/> element SHOULD possess an 'xml:lang' attribute specifying the language of the human-readable descriptive text for a particular address.

+ + +

This document introduces no security considerations above and beyond those described in RFC 3920, RFC 3921, and (for the personal eventing transport) JEP-0163.

+ + +

This document requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; shall include 'http://jabber.org/protocol/reach' in its registry of protocol namespaces.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + diff --git a/xep-0153.xml b/xep-0153.xml new file mode 100644 index 00000000..84b27d9d --- /dev/null +++ b/xep-0153.xml @@ -0,0 +1,284 @@ + + +%ents; +]> + + +
+ vCard-Based Avatars + This document provides historical documentation of a vCard-based protocol for exchanging user avatars. + &LEGALNOTICE; + 0153 + Active + Historical + Standards JIG + Council + + XMPP Core + XMPP IM + JEP-0054 + + + + vcard-avatar + + http://jabber.org/protocol/vcard-avatar/vcard-avatar.xsd + + &stpeter; + + 1.0 + 2006-08-16 + psa + Per a vote of the Jabber Council, advanced status to Active. + + + 0.3 + 2006-01-12 + psa + Collected all syntax rules into dedicated section; incorporated feedback from implementation experience; adjusted text regarding base64 encoding. + + + 0.2 + 2005-10-18 + psa + Changed 8k limit from MUST NOT to SHOULD NOT; specified that client should publish new presence stanza if it obtains an avatar image after sending an empty photo element; specified that the update child should be included in directed presence stanzas; more clearly specified Base64 rules. + + + 0.1 + 2005-06-16 + psa + Initial JEP version. + + + 0.0.3 + 2005-06-14 + psa + Changed type from Informational to Historical, adjusted text accordingly. + + + 0.0.2 + 2005-06-13 + psa + Specified that the image data is actually Base64 encoded. + + + 0.0.1 + 2005-06-09 + psa + First draft. + +
+ +

There exist several proposed protocols for communicating user avatar information over Jabber/XMPP (see &jep0008; and &jep0084;). This document describes another such protocol that is in use today on the Jabber/XMPP network. This document is historical and does not purport to propose a standards-track protocol. However, a future protocol may improve on the approach documented herein.

+ + +

The protocol described herein seems to have been designed with the following requirements in mind:

+
    +
  • Enable a user to store an avatar image in his or her vCard.
    • +
  • Provide notice of avatar changes via the &PRESENCE; stanza.
    • +
  • Enable a contact to retrieve a user's avatar image if the user is offline.
    • +
  • Enable a contact to retrieve a user's avatar image without requesting it of the user's particular client, thus preserving bandwidth.
    • +
+ + + +

Before informing contacts of the user's avatar, the user's client first publishes the avatar data to the user's public vCard using the protocol defined in &jep0054;.

+ + + 1476-06-09 + + Italy + Verona + + + + JulietCapulet + jcapulet@shakespeare.lit + + image/jpeg + + Base64-encoded-avatar-file-here! + + + + + ]]> + + ]]> +

Next, the user's client computes the SHA1 hash of the avatar image data itself (not the base64-encoded version) in accordance with &rfc3174;. This hash is then included in the user's presence information as the XML character data of the <photo/> child of an &X; element qualified by the 'vcard-temp:x:update' namespace, as shown in the following example:

+ + + sha1-hash-of-image + + + ]]> +

The user's server then broadcasts that presence information to all contacts who are subscribed to the user's presence information.

+ + +

When the recipient's client receives the hash of the avatar image, it SHOULD check the hash to determine if it already has a cached copy of that avatar image. If not, it retrieves the sender's full vCard in accordance with the protocol flow describerd in JEP-0054 (note that this request is sent to the user's bare JID, not full JID):

+ + + + ]]> + + + 1476-06-09 + + Italy + Verona + + + + JulietCapulet + jcapulet@shakespeare.lit + + image/jpeg + + Base64-encoded-avatar-file-here! + + + + + ]]> + + + + +

The following rules apply to inclusion of the update child element (<x xmlns='vcard-temp:x:update'/>) in presence broadcasts:

+
    +

  1. If a client supports the protocol defined herein, it MUST include the update child element in every presence broadcast it sends and SHOULD also include the update child in directed presence stanzas (e.g., directed presence sent when joining &jep0045; rooms).

    2. +
  2. +

    If a client is not yet ready to advertise an image, it MUST send an empty update child element, i.e.:

    + + + + ]]> +
    3. +
  3. +

    If there is no avatar image to be advertised, the photo element MUST be empty, i.e.:

    + + + + + + ]]> +

    If the client subsequently obtains an avatar image (e.g., by updating or retrieving the vCard), it SHOULD then publish a new &PRESENCE; stanza with character data in the <photo/> element.

    +
    4. +

    Note: This enables recipients to distinguish between the absence of an image (empty photo element) and mere support for the protocol (empty update child).

    +
+ + +

The following rules apply to downloading and uploading the vCard:

+
    +

  1. A client MUST NOT advertise an avatar image without first downloading the current vCard. Once it has done this, it MAY advertise an image. However, a client MUST advertise an image if it has just uploaded the vCard with a new avatar image. In this case, the client MAY choose not to redownload the vCard to verify its contents.

    2. +

  2. Within a given session, a client MUST NOT attempt to upload a given avatar image more than once. The client MAY upload the avatar image to the vCard on login and after that MUST NOT upload the vCard again unless the user actively changes the avatar image.

    3. +

  3. The client MUST NOT poll for new versions of the user's vCard in order to determine whether to update the avatar image hash.

    4. +
+ + +

Jabber/XMPP allows multiple resources to authenticate for the same JID simultaneously. This introduces the potential of conflict between the resources regarding the user's avatar image. The following rules apply when a client receives a presence broadcast from another resource of its own JID:

+
    +

  1. If the presence stanza received from the other resource does not contain the update child element, then the other resource does not support vCard-based avatars. That resource could modify the contents of the vCard (including the photo element); because polling for vCard updates is not allowed, the client MUST stop advertising the avatar image hash. However, the client MAY reset its hash if all instances of non-conforming resources have gone offline.

    2. +
  2. +

    If the presence stanza received from the other resource contains the update child element, then the other resource conforms to the protocol for vCard-based avatars. There are three possible scenarios:

    +
      +

    • If the update child element is empty, then the other resource supports the protocol but does not have its own avatar image. Therefore the client can ignore the other resource and continue to broadcast the existing image hash.

      • +

    • If the update child element contains an empty photo element, then the other resource has updated the vCard with an empty BINVAL. Therefore the client MUST retrieve the vCard. If the retrieved vCard contains a photo element with an empty BINVAL, then the client MUST stop advertising the old image.

      • +

    • If the update child element contains a non-empty photo element, then the client MUST compare the image hashes. If the hashes are identical, then the client can ignore the other resource and continue to broadcast the existing image hash. If the hashes are different, then the client MUST NOT attempt to resolve the conflict by uploading its avatar image again. Instead, it MUST defer to the content of the retrieved vCard by resetting its image hash (see below) and providing that hash in future presence broadcasts.

      • +
    +
    3. +
+ + +

Resetting the image hash consists of the following steps:

+
    +

  1. Immediately send out a presence element with an empty update child element (containing no photo element).

    2. +

  2. Download the vCard from the server.

    3. +

  3. If the BINVAL is empty or missing, advertise an empty photo element in future presence broadcasts.

    4. +

  4. If the BINVAL contains image data, calculate the hash of image and advertise that hash in future presence broadcasts.

    5. +
+ + +

The following rules apply to the XML syntax:

+
    +

  1. The <PHOTO/> element SHOULD contain a <BINVAL/> child whose XML character data is Base64-encoded data for the avatar image.

    2. +

  2. The <PHOTO/> element SHOULD NOT contain an <EXTVAL/> that points to a URI for the image file.

    3. +

  3. The <PHOTO/> element MUST NOT contain the avatar image itself.

    4. +

  4. The <PHOTO/> element SHOULD contain a <TYPE/> child whose XML character data specifies the content-type of the image data. The XML character data SHOULD be "image/gif", "image/jpeg", or "image/png".

    5. +

  5. The <PHOTO/> element MUST NOT possess a 'mime-type' attribute.

    6. +
+ + +

The following rules apply to images:

+
    +

  1. The image SHOULD use less than eight kilobytes (8k) of data; this restriction is to be enforced by the publishing client.

    2. +

  2. The image height and width SHOULD be between thirty-two (32) and ninety-six (96) pixels; the recommended size is sixty-four (64) pixels high and sixty-four (64) pixels wide.

    3. +

  3. The image SHOULD be square.

    4. +

  4. The image content type The IANA registry of content types is located at <http://www.iana.org/assignments/media-types/>. SHOULD be image/gif, image/jpeg, or image/png; support for the "image/png" content type is REQUIRED, support for the "image/gif" and "image/jpeg" content types is RECOMMENDED, and support for any other content type is OPTIONAL.

    5. +

  5. The image data MUST conform to the base64Binary datatype See <http://www.w3.org/TR/xmlschema-2/#base64Binary>. and thus be encoded in accordance with Section 6.8 of &rfc2045;, which recommends that base64 data should have lines limited to at most 76 characters in length. However, any whitespace characters (e.g., '\r' and '\n') MUST be ignored.

    6. +
+ + + +

The XML character data of the <TYPE/> element is a hint. If the XML character data of the <TYPE/> specifies a content type that does not match the data provided in the <BINVAL/> element, the processing application MUST adhere to the content type of the actual image data and MUST ignore the <TYPE/>. If the <TYPE/> is something other than image/gif, image/jpeg, or image/png, it SHOULD be ignored.

+

If the image data exceeds the 8 KB restriction, the processing application SHOULD process the data.

+ + +

This document introduces no security considerations above and beyond those described in &rfc3920;, &rfc3921;, and &jep0054;.

+ + +

This document requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; includes 'vcard-temp:x:update' in its registry of protocol namespaces (see &NAMESPACES;).

+ + + + + + + + + + The protocol documented by this schema is defined in + JEP-0153: http://www.jabber.org/jeps/jep-0153.html + + + + + + + + + + + + + ]]> + + +

The author wishes to thank the helpful developers who have implemented this protocol and provided feedback regarding its documentation.

+ + diff --git a/xep-0154.xml b/xep-0154.xml new file mode 100644 index 00000000..efe164b4 --- /dev/null +++ b/xep-0154.xml @@ -0,0 +1,1947 @@ + + +%ents; +]> + + +
+ User Profile + This document specifies how to represent and manage profile data about IM users and other XMPP entities using the XMPP Data Forms extension. + &LEGALNOTICE; + 0154 + Experimental + Standards Track + Standards JIG + Council + + XMPP Core + JEP-0004 + JEP-0060 + JEP-0068 + JEP-0163 + + + JEP-0054 + + + profile + &stpeter; + + 0.5 + 2006-08-02 + psa +

Updated to reflect changes to JEP-0163; added some mappings to the eduPerson object class.

 + + + 0.4 + 2006-01-16 + psa +

Defined data management methods using IQ and the PEP subset of pubsub; added various data fields from LDAP; changed namespace from profiledata to profile.

 + + + 0.3 + 2005-11-11 + psa +

Added postaladdress, fav_chatrooms, alt_contact, teams; added various security-related fields.

 + + + 0.2 + 2005-07-25 + psa +

Added mappings to common LDAP schemas.

 + + + 0.1 + 2005-06-16 + psa +

Initial JEP version.

 + + + 0.0.5 + 2005-06-13 + psa +

Defined how to handle vCard types such as home vs. work addresses.

 + + + 0.0.4 + 2005-04-07 + psa +

Reworked field standardization; added support for telephony addresses, electronic addresses, and organizational data.

 + + + 0.0.3 + 2005-03-11 + psa +

Added open issues.

 + + + 0.0.2 + 2005-01-06 + psa +

Explained requirements and design decisions in more detail, especially with regard to extensibility; split photo into two elements (data and URL).

 + + + 0.0.1 + 2004-11-10 + psa +

First draft.

 + +
+ +

It is widely acknowledged within the Jabber/XMPP community that the &jep0054; specification (JEP-0054) has outlived its usefulness. There are several reasons for this conclusion:

+
    +
  1. JEP-0054 is not fully consistent with the Internet-Draft on which it was based.
    2. +
  2. The Internet-Draft on which it was based was never approved by the IETF.
    3. +
  3. Because of confusion over aspects of the vcard-temp specification, there exist incompatible implementations.
    4. +
  4. vCard (&rfc2426;) captures only a limited set of information.
    5. +
  5. vCard (even in its XML representation For links to the experimental XML representation of vCard, see JEP-0054.) is not easily extensible, leading those who develop profiles for specialized communities to "roll their own" protocols, to the detriment of interoperability.
    6. +
  6. vCard data tends to be monolithic (the basic unit of information is the full vCard, not parts thereof).
    7. +
  7. The publication model for JEP-0054 is to set the full vCard, rather than only the parts that need to be modified.
    8. +
  8. The retrieval model for JEP-0054 is to get the full vCard, rather than only the parts that have been modified.
    9. +
+

Given the weaknesses of vCard, there is interest across the broader Internet community in replacing vCard with something more modern and extensible. Unfortunately, no other standards development organization has developed an alternative to vCard. Part of the challenge is that quite detailed ontologies have been developed that might replace parts of the vCard specification (e.g., the Extensible Name and Address Language See <http://xml.coverpages.org/xnal.html>. developed by &OASIS;) while less-formal ontologies are being used to represent other parts of the problem space (e.g., &foaf;). The relevant protocols are in flux and it is unclear when (or even if) stability will emerge.

+

Because of the unsettled landspace and the strong desire within the Jabber/XMPP community to move beyond JEP-0054, this JEP specifies methods for the representation of profile data in terms of the &jep0004; protocol (further qualified using the standardization concepts specified in &jep0068;) and for the management of profile data using standard IQ request-response semantics as well as, for more frequently-modified data, &jep0060; semantics (specifically the simplified subset of those semantics specified in &jep0163;). The rationale behind these design decisions is provided below.

+ + +

This JEP addresses the following requirements for data management:

+
    +
  1. Enable an entity to publish profile data about itself.
    2. +
  2. Enable requesting entities to retrieve profile data about other entities.
    3. +
+

This JEP addresses the following requirements for data representation:

+
    +
  1. Specify how to represent profile data in an XMPP-friendly manner for communication over the wire.
    2. +
  2. Ensure that the protocol is extensible (e.g., not limited to existing vCard fields). + The extensibility requirement is critically important, because it would be best if the protocol specified herein could be used to represent data used within specialized communities. Examples of such communities include dating services, multiplayer gaming networks, IM services provided by portals and ISPs, and expert-location systems within large corporations. While such communities might use part or all of some common set of data fields (such as fields that map to familiar vCard elements), each community might also want to represent quite disparate kinds of information (dating criteria, favorite games, contact preferences, areas of expertise, and the like). Furthermore, data might be used to profile network actors that are not persons (e.g., bots, services, and other software agents). Therefore, the ideal proposal will provide an extensible framework for representing profile data and will not limit itself to representing the relatively small set of data fields covered by the vCard format. +
    3. +
  3. Where possible, map profile data fields to existing vCard fields and other common formats.
    4. +
+ + + +

There are several possible approaches to representing profile data for communication over XMPP networks, including the following:

+
    +
  1. +

    IQ (request-and-response) semantics.

    +

    In the simplest case, an entity may store its own profile data and provide only the complete profile and only on request, using the request-response semantics of the XMPP &IQ; stanza type. This model is most appropriate for stable entities that are always online and whose profile data does not change frequently, such as servers and server-side components (entities that are not always online or that frequently modify their profile data, such as IM users, may prefer to publish their information to entities that are always online, such as an IM user's server). While it may seem desirable to embed profile data in the responses an entity provides to service discovery information requests using &jep0128;, it is likely that profile data will be quite extensive; therefore, we define a standalone "wrapper" element for profile data, qualified by the 'http://jabber.org/protocol/profile' namespace.

    +
    2. +
  2. +

    Pubsub (publish-and-subscribe) semantics.

    +

    A more complex model is for an entity to publish its profile data to a publish-subscribe node or nodes and allow other entities to subscribe to that node or nodes, thus receiving notifications whenever the profiled entity updates its data. This model is more appropriate for entities that modify their profile data on a regular basis or when other entities wish to be informed when the profile data changes. Because this model will most likely be used most often by IM users and other intermittently-connected network endpoints, we use the simplified subset of the XMPP publish-subscribe extension defined in JEP-0163 to implement this model.

    +
    3. +
+ + +

As with data management, there are several possible approaches to representing profile data for communication over XMPP networks, including the following:

+
    +
  • +

    Structured data formats, such as &jep0080; and &jep0112;.

    +

    Such data formats have the advantage of being human-readable. However:

    +
      +
    1. They are not easily extensible: developers of specialized community services would need to write their own structured data formats, even to add one new field.
      2. +
    2. They are not easy to map to backend data storage facilities (e.g., database administrators generally would prefer to have generic database schemas and re-usable code for parsing the XML wire protocol into the database fields).
      3. +
    3. They would require specialized interface handlers for each data structure, rather than a generic interface handler.
      4. +
    +
    • +
  • +

    A format represented by means of &w3rdf;.

    +

    An argument could be made that RDF is a reasonable approach for representing profile data for communication over the XMPP network; however, such an argument will not be made in the current proposal. The author has considered RDF and has concluded that there are several reasons why RDF is undesirable as an XMPP wire protocol:

    +
      +
    1. RDF exists in an XML representation but the semantics of RDF impose a more complex conceptual structure (data triples) than does XML, which is sub-optimal since unnecessary complexity is to be avoided (see &jep0134;).
      2. +
    2. RDF requires a specialized parser rather than the normal XML parser that comes standard with all XMPP implementations.
      3. +
    3. As long as it is possible to define a consistent mapping of profile data to RDF representations, it should be straightforward to convert the XMPP data formats into those RDF representations if desired (e.g., to output a FOAF file).
      4. +
    +
    • +
  • +

    A format represented by means of Data Forms (JEP-0004).

    +

    The Data Forms protocol defined in JEP-0004 has several advantages for use over XMPP:

    +
      +
    1. It can be parsed using an off-the-shelf XML parser.
      2. +
    2. It is already widely deployed in existing Jabber/XMPP clients, servers, and components.
      3. +
    3. The data forms protocol is easily extensible.
      4. +
    4. The Jabber/XMPP community possesses consistent methods for profiling and scoping data forms (as specified in JEP-0068).
      5. +
    5. Data forms have a generic schema that is easy to map to common data storage mechanisms (usually databases).
      6. +
    6. Data forms provide a consistent abstraction layer for XMPP applications, thus shielding them from changes in the profile data formats being defined by other Internet projects and standards development organizations.
      7. +
    7. The use of data forms as the medium of representation for communication over the wire does not prevent applications from storing backend profile data in some other underlying format (e.g., RDF or a database).
      8. +
    +
    • +
+

Therefore, this proposal specifies that profile data shall be scoped by a FORM_TYPE of 'http://jabber.org/protocol/profile', in accordance with the field standardization methods defined in JEP-0068. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the ®ISTRAR; (although they may or may not be defined in a Jabber Enhancement Proposal). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of JEP-0068. Alternatively, specialized applications MAY define separate FORM_TYPEs for their particular data elements.

+

The following is a simple and incomplete example of profile data represented via the Data Forms protocol, containing two registered data fields and one unregistered field:

+ + + + http://jabber.org/protocol/profile + + + Peter Saint-Andre + + + stpeter + + + Joaquin Sorolla + Jan Vermeer + + + + ]]> +

By specifying that all fields are scoped by a FORM_TYPE of 'http://jabber.org/protocol/profile', this proposal does not mean to imply that all profile data will or should be gathered in one data form. In reality, most such data will probably be gathered at the time of registration either at a website or via a "wizard" interface that breaks the process into smaller bundles (such as "Basic Personal Data", "Physical Location", "Internet Addresses", "Hobbies and Interests", and "Favorite Things"). The use of one FORM_TYPE is simply meant to scope the data fields so that each field is unique within the context of profile data. Any form that uses these fields along with a FORM_TYPE of 'http://jabber.org/protocol/profile' is of the "profile type" (i.e., is a specific instance of that type), which does not limit the number of forms that can be of that type.

+

However, scoping all data fields with a single FORM_TYPE implies it is necessary to define separate data fields for similar kinds of information. For example, the vCard specification (RFC 2426) defines "types" for certains kinds of data, such as email addresses, telephone numbers, and physical addresses, making it possible to specify that a telephone number corresponds to a fax machine or mobile phone or that a physical address corresponds to one's home or work location. In the Data Forms representation, any desired piece of information (e.g., work phone) must be represented with a separate data field.

+

In order to address most (if not all) of the pieces of information described in existing profile specifications, this JEP defines a great number of data fields. Even so, the data fields specified herein are not exhaustive, and it is expected that additional fields will be registered in the future through the mechanisms specified in the Jabber Registrar Considerations section of this JEP.

+ + + + +

In order to publish a full profile, an entity sends an IQ-set to its server with a child element of <profile/> containing the full profile information.

+ + + + + http://jabber.org/protocol/profile + + + Hamlet + + + DK + + + Elsinore + + + hamlet@denmark.lit + + + + + ]]> +

If the server can succesfully process the request and host the full profile, it MUST return an IQ-result:

+ + ]]> +

Otherwise it MUST return an error. If the server does not support the profile data functionality, the error MUST be &unavailable;.

+ + +

In order to update selected fields in a public profile, an entity simply publishes the modified fields (not the entire profile) to a pubsub node of "http://jabber.org/protocol/profile" at its server using the PEP subset of the publish-subscribe extension, as specified in JEP-0163.

+ + + + + + + http://www.denmark.lit/blogs/princely_musings + + + + + + + ]]> +

The PEP service then MUST send notifications containing the updated field(s) to the node subscribers:

+ + + + + + + + http://www.denmark.lit/blogs/princely_musings + + + + + + + + +. +. +. + ]]> +

If the field(s) published are "public", the publisher SHOULD then repost the full profile as described above in order to keep the full profile in sync.

+

Note: The account owner MAY decide to effectively maintain two profile subsets: public profile fields (posted via the "full profile" protocol) and restricted profile fields (published only via PEP). If so, the client MUST keep track of which fields are in the public profile subset and which fields are in the restricted profile subset, and MUST NOT update the full profile if the account owner has updated a field in the restricted profile set.

+ + + + +

If an entity can provide profile data directly using the standalone 'http://jabber.org/protocol/profile' namespace, it SHOULD advertise that feature in response to &jep0030; information requests:

+ + + + ]]> + + + + ... + + ... + + + ]]> +

Note: Because the foregoing request was sent to the bare JID <hamlet@denmark.lit>, the response is provided by the <denmark.lit> server on behalf of the registered account. The answer indicates that the server can also provide profile data on behalf of the registered account.

+ + +

In order to request the full profile, the requesting entity sends an IQ-get to the providing entity's JID, where the request contains an empty <profile/> element qualified by the 'http://jabber.org/protocol/profile' namespace. In this example, the request is sent to a server:

+ + + + ]]> +

The server then replies:

+ + + + + http://jabber.org/protocol/profile + + + shakespeare.lit IM server + + + UK + + + England + + + London + + + Bankside + + + 21 New Globe Walk + + + SE1 9DT + + + 51.5076 + + + -0.0953 + + + +44 20 7902 1400 + + + +44 20 7902 1401 + + + Globe Theatre + + + admin@shakespeare.lit + + + + + ]]> +

If a server supports stored profile data for user accounts that it hosts, a requesting entity can request the full profile for such an account:

+ + + + ]]> +

If the requesting entity is not allowed to retrieve hosted profiles (e.g., because it is not on a whitelist of entities permitted to "spider" the server's users), the server SHOULD return a &unavailable; error:

+ + + + + + + ]]> +

If the requested account does not exist or has not published profile data, the server also SHOULD return a &unavailable; error.

+

Otherwise, the server SHOULD return the profile for the hosted account.

+ + + + + http://jabber.org/protocol/profile + + + Hamlet + + + DK + + + Elsinore + + + hamlet@denmark.lit + + + http://www.denmark.lit/blogs/princely_musings + + + + + ]]> + + +

In order to receive updated fields for a contact's profile, an entity shall send a pubsub subscription request to the contact's bare JID (&BAREJID;) and specify a node of "http://jabber.org/protocol/profile":

+ + + + + + ]]> +

If the server allows the subscription, it MUST return an IQ-result (see JEP-0163 for error scenarios):

+ + ]]> +

When the contact sends updated fields to the profile node, the entity will receive notifications:

+ + + + + + + + http://www.denmark.lit/blogs/princely_musings + + + + + + + + ]]> +

It is the responsibility of the receiving entity to correctly process the notification and update the contact's profile information accordingly.

+ + + +

The following subsections specify common fields for defining various aspects of a person, which shall form the initial submission to the Jabber Registrar; many of these fields map to elements specified in vCard, xNAL, FOAF, LDAP (see &rfc2252;, &rfc2256;, and &rfc2798;) This specification does not require that profile data fields mapped to LDAP fields must adhere to the X.500 data types that are re-used by LDAP. However, implementations MAY enforce those data types if desired., and LDAP object classes such as Person, organizationalPerson, inetOrgPerson, and eduPerson.

+ +

Mappings are provided to vCard, LDAP, xNAL, and FOAF.

+ +

A display name is a version of a person's name intended for display in a user interface. Sometimes also called a "full name" or "formatted name".

+

The Data Forms field that represents a display name is "display_name".

+

This field maps to:

+
    +
  • vCard FN
    • +
  • LDAP displayName
    • +
  • FOAF name
    • +
+ + Peter Saint-Andre + + ]]> + + +

A familiar name is a shortened or modified form of someone's given name that may be used in somewhat informal contexts or that is preferred by the person (e.g., "Chuck" instead of "Charles").

+

The Data Forms field that represents a familiar name is "familiar_name".

+

This field maps to:

+
    +
  • eduPersonNickname
    • +
+ + Pete + + ]]> + + +

A family name is that part of a person's name which signifies the person's primary family association. Sometimes also called a "last name" or "surname".

+

The Data Forms field that represents a family name is "family_name".

+

This field maps to:

+
    +
  • vCard FAMILY
    • +
  • LDAP sn
    • +
  • xNAL LastName
    • +
  • FOAF family_name
    • +
  • FOAF surname
    • +
+ + Saint-Andre + + ]]> + + +

A given name is that part of a person's name which signifies the person's primary individual identity. Sometimes also called a "first name" or (in some countries) a "Christian name".

+

The Data Forms field that represents a given name is "given_name".

+

This field maps to:

+
    +
  • vCard GIVEN
    • +
  • LDAP givenName
    • +
  • xNAL FirstName
    • +
  • FOAF first_name
    • +
  • FOAF givenname
    • +
+ + J. + + ]]> + + +

A middle name is that part of a person's name which signifies the person's secondary individual identity. Sometimes also called a "middle initial".

+

The Data Forms field that represents a middle name is "middle_name".

+

This field maps to:

+
    +
  • vCard MIDDLE
    • +
  • xNAL MiddleName
    • +
+ + Peter + + ]]> + + +

A name prefix is that part of a person's name which prepends the person's full name (e.g., Mr or Dr). Sometimes also called an "honorific" or "title".

+

The Data Forms field that represents a name prefix is "name_prefix".

+

This field maps to:

+
    +
  • vCard PREFIX
    • +
  • xNAL Title
    • +
  • FOAF title
    • +
+ + Mr + + ]]> + + +

A name suffix is that part of a person's name which is appended to the person's full name (e.g., Jr or Esq).

+

The Data Forms field that represents a name suffix is "name_suffix".

+

This field maps to:

+
    +
  • vCard SUFFIX
    • +
  • xNAL GeneralSuffix
    • +
+ + Esq + + ]]> + + +

A nickname is a global, memorable (but not unique) friendly or informal name chosen by the owner of a JID. The purpose of a nickname is to associate a distinctive mapping between the person's unique JID and non-unique nickname. A nickname is normally used in online contexts (e.g., in chatrooms) that are less formal than real life (where a person's Familiar Name would be more appropriate). Sometimes also called an "alias". A person SHOULD specify only one nickname (i.e., not more than one).

+

The Data Forms field that represents a nickname is "nickname".

+

This field maps to:

+
    +
  • vCard NICKNAME
    • +
  • xNAL Alias
    • +
  • FOAF nick
    • +
+ + stpeter + + ]]> + + +

In some cultures, one's name includes a part that is derived from the given name of one's father; this part of one's name is called a "patronymic".

+

The Data Forms field that represents a patronymic is "patronymic".

+ + Ivanovich + + ]]> + + + +

Mappings are provided to vCard, xNAL, and JEP-0112 (&jep0112;).

+ +

A country is the sovereign nation in which a person is located. Sometimes also called a "nation".

+

The Data Forms fields that represent a country are "country", "home_country", and "work_country" for generic addresses, home addresses, and work addresses respectively.

+

This field maps to:

+
    +
  • vCard COUNTRY (or JEP-0054 CTRY), optionally supplemented with the "HOME" or "WORK" type
    • +
  • LDAP c
    • +
  • xNAL CountryName
    • +
  • JEP-0112 country
    • +
+ + USA + + ]]> + + +

A region is a second-level administrative unit within the nation in which a person is located. Sometimes also called a "province", "state", or "administrative area".

+

The Data Forms field that represents a region is "region".

+

The Data Forms fields that represent a region are "home_region" and "work_region" for home addresses and work addresses respectively.

+

This field maps to:

+
    +
  • vCard REGION, optionally supplemented with the "HOME" or "WORK" type
    • +
  • LDAP st
    • +
  • xNAL AdministrativeAreaName
    • +
  • JEP-0112 region
    • +
+ + New York + + ]]> + + +

A locality is a defined place within the region in which a person is located. Sometimes also called a "city", "town", or "village".

+

The Data Forms fields that represent a locality are "locality", "home_locality", and "work_locality" for generic addresses, home addresses, and work addresses respectively.

+

This field maps to:

+
    +
  • vCard LOCALITY, optionally supplemented with the "HOME" or "WORK" type
    • +
  • LDAP l
    • +
  • xNAL LocalityName
    • +
  • JEP-0112 locality
    • +
+ + New York City + + ]]> + + +

An area is a sub-division within the locality in which a person is located. Sometimes also called a "neighborhood", "suburb", "district", or "section".

+

The Data Forms fields that represent a area are "area", "home_area", and "work_area" for generic addresses, home addresses, and work addresses respectively.

+

This field maps to:

+
    +
  • xNAL DependentLocalityName
    • +
  • JEP-0112 area
    • +
+ + Manhattan + + ]]> + + +

A street is the street address (number plus street name, or two street names at an intersection) at which a person is located, or a postal box number for physical mail delivery. Sometimes also called a "street address".

+

The Data Forms fields that represent a street are "street", "home_street", and "work_street" for generic addresses, home addresses, and work addresses respectively.

+

This field maps to:

+
    +
  • vCard STREET, optionally supplemented with the "HOME" or "WORK" type
    • +
  • LDAP street
    • +
  • xNAL ThoroughfareNumber + ThoroughfareName
    • +
  • JEP-0112 street
    • +
+ + Fifth Avenue and 34th Street + + ]]> + + +

A building is the name for a specific structure on a street or within an area.

+

The Data Forms fields that represent a building are "building", "home_building", and "work_building" for generic addresses, home addresses, and work addresses respectively.

+

This field maps to:

+
    +
  • vCard EXTADR, optionally supplemented with the "HOME" or "WORK" type
    • +
  • xNAL BuildingName
    • +
  • JEP-0112 building
    • +
+ + Empire State Building + + ]]> + + +

A floor is a named or numbered floor or level within a building. Sometimes also called a "level", "block", or "suite".

+

The Data Forms fields that represent a floor are "floor", "home_floor", and "work_floor" for generic addresses, home addresses, and work addresses respectively.

+

This field maps to:

+
    +
  • vCard EXTADR, optionally supplemented with the "HOME" or "WORK" type
    • +
  • xNAL SubPremiseNumber
    • +
  • JEP-0112 floor
    • +
+ + 102 + + ]]> + + +

A room is a named or numbered subdivision of a floor. Sometimes also called a "unit" or "apartment".

+

The Data Forms fields that represent a room are "room", "home_room", and "work_room" for generic addresses, home addresses, and work addresses respectively.

+

This field maps to:

+
    +
  • vCard EXTADR, optionally supplemented with the "HOME" or "WORK" type
    • +
  • LDAP roomNumber
    • +
  • xNAL SubPremiseNumber
    • +
  • JEP-0112 room
    • +
+ + Observatory + + ]]> + + +

A postal box is a set of numeric or alphanumeric characters used to identify a mailbox at a postal delivery center.

+

The Data Forms fields that represent a postal box are "postalbox", "home_postalbox", and "work_postalbox" for generic addresses, home addresses, and work addresses respectively.

+

This field maps to:

+
    +
  • vCard POBOX, optionally supplemented with the "HOME" or "WORK" type
    • +
  • LDAP postOfficeBox
    • +
+ + 1641 + + ]]> + + +

A postal code is a set of numeric or alphanumeric characters used to identify an area for postal delivery. Sometimes also called a "ZIP code" (in the U.S.).

+

The Data Forms fields that represent a postal code are "postalcode", "home_postalcode", and "work_postalcode" for generic addresses, home addresses, and work addresses respectively.

+

This field maps to:

+
    +
  • vCard PCODE, optionally supplemented with the "HOME" or "WORK" type
    • +
  • LDAP postalCode
    • +
  • xNAL PostalCodeNumber
    • +
  • JEP-0112 postalcode
    • +
+ + 10002 + + ]]> + + +

A postal address is a free-form mailing address, which may be easier to enter (or, in some cultural contexts, more appropriate) than the atomic address parts such as street, floor, etc.

+

The Data Forms fields that represent a postal address are "postaladdress", "home_postaladdress", and "work_postaladdress" for generic addresses, home addresses, and work addresses respectively.

+

This field maps to:

+
    +
  • LDAP postalAddress, homePostalAddress
    • +
+ + 1899 Wynkoop Street + Suite 600 + Denver, CO 80202 + USA + + ]]> + + + +

Mappings are provided to vCard and JEP-0080 (&jep0080;).

+ +

Altitude is a person's height or depth in relationship to sea level, where positive altitude is meters above sea level and negative altitude is meters below sea level.

+

The Data Forms field that represents altitude is "alt".

+

This field maps to:

+
    +
  • JEP-0080 alt
    • +
+ + 1609 + + ]]> + + +

Latitude is a person's latitude in relation to the equator, where positive latitude is north of the equator and negative latitude is south of the equator.

+

The Data Forms field that represents latitude is "lat".

+

This field maps to:

+
    +
  • vCard LAT
    • +
  • JEP-0080 lat
    • +
+ + 39.75477 + + ]]> + + +

Longitude is a person's longitude in relation to the equator, where positive longitude is east of the meridian and negative longitude is west of the equator.

+

The Data Forms field that represents longitude is "lon".

+

This field maps to:

+
    +
  • vCard LON
    • +
  • JEP-0080 lon
    • +
+ + -104.99768 + + ]]> + + + + +

A fax number is a number for a machine that handles fascimile transmissions.

+

The Data Forms fields that represent a fax number are "fax", "home_fax", and "work_fax" for generic addresses, home addresses, and work addresses respectively.

+

This field maps to:

+
    +
  • vCard TEL (+ "FAX" modifier), optionally supplemented with the "HOME" or "WORK" type
    • +
  • LDAP facsimileTelephoneNumber
    • +
+ + 303-308-3215 + + ]]> + + +

A landline telephone number is a number for a traditional "PSTN" or "POTS" telephone.

+

The Data Forms fields that represent a landline telephone number are "landline", "home_landline", and "work_landline" for generic addresses, home addresses, and work addresses respectively.

+

This field maps to:

+
    +
  • vCard TEL, optionally supplemented with the "HOME" or "WORK" type
    • +
  • LDAP telephoneNumber
    • +
  • FOAF phone
    • +
+ + 303-308-3282 + + ]]> + + +

A mobile telephone number is a number for a mobile phone or cell phone on a wireless network.

+

The Data Forms fields that represent a mobile telephone number are "mobile", "home_mobile", and "work_mobile" for generic addresses, home addresses, and work addresses respectively.

+

This field maps to:

+
    +
  • vCard TEL (+ "CELL" modifier), optionally supplemented with the "HOME" or "WORK" type
    • +
  • LDAP mobile
    • +
  • FOAF phone
    • +
+ + 303-555-1212 + + ]]> + + +

A pager number is a number for a dedicated alphanumeric paging device.

+

The Data Forms fields that represent a pager number are "pager", "home_pager", and "work_pager" for generic addresses, home addresses, and work addresses respectively.

+

This field maps to:

+
    +
  • vCard TEL (+ "PAGER" modifier), optionally supplemented with the "HOME" or "WORK" type
    • +
  • LDAP pager
    • +
+ + 303-555-1212 + + ]]> + + +

A SIP address is a sip: or sips: URI at which a person can be contacted for Voice over Internet Protocol (VoIP) communications.

+

The Data Forms field that represents a SIP address is "sip_address".

+

This field does not map to data in vCard or any other profile representation format.

+ + sip:stpeter@sipspeare.lit + + ]]> + + +

A Skype address is an address on the popular Skype system for Voice over Internet Protocol (VoIP) communications.

+

The Data Forms field that represents a Skype address is "skype_address".

+

This field does not map to data in vCard or any other profile representation format.

+ + SomeSkypeUser + + ]]> + + +

A videophone address is an address used for for H.323 video conferencing systems.

+

The Data Forms field that represents a videophone address is "video_phone".

+

This field does not map to data in vCard or any other profile representation format.

+ + foo + + ]]> + + + + +

An AIM screen name is an address at which a person or other entity can be contacted on the AOL Instant Messenger service.

+

The Data Forms field that represents an AIM screen name is "aim_id".

+

This field maps to:

+
    +
  • FOAF aimChatID
    • +
+ + psaintandre + + ]]> + + +

An email address is the value of a mailto: URI at which a person or other entity can be contacted using standard electronic mail protocols.

+

The Data Forms field that represents longitude is "email".

+

This field maps to:

+
    +
  • vCard EMAIL
    • +
  • LDAP mail
    • +
+ + stpeter@jabber.org + stpeter@gmail.com + + ]]> + + +

An ICQ number is an address at which a person or other entity can be contacted on the ICQ instant messaging service.

+

The Data Forms field that represents an ICQ number is "icq_id".

+

This field maps to:

+
    +
  • FOAF icqChatID
    • +
+ + 70902454 + + ]]> + + +

A Jabber ID is the value of an xmpp: URI at which a person or other entity can be contacted over a Jabber/XMPP network.

+

The Data Forms field that represents a Jabber ID is "jid".

+

This field maps to:

+
    +
  • FOAF jabberID
    • +
+ + stpeter@jabber.org + peter@saint-andre.com + + ]]> + + +

An MSN address is address at which a person or other entity can be contacted on the MSN instant messaging service.

+

The Data Forms field that represents an MSN address is "msn_id".

+

This field maps to:

+
    +
  • FOAF msnChatID
    • +
+ + petersaintandre@hotmail.com + + ]]> + + +

A Yahoo ID is address at which a person or other entity can be contacted on the Yahoo! Instant Messenger service.

+

The Data Forms field that represents a Yahoo ID is "yahoo_id".

+

This field maps to:

+
    +
  • FOAF yahooChatID
    • +
+ + psaintandre + + ]]> + + + + +

An avatar is an often fanciful representation of a user's desired self-image or persona (e.g., in the context of a game). An avatar is usually not intended to be an accurate picture of the user's actual physical appearance (that is handled by the photo_url and photo_data fields).

+

An avatar can come in two forms: the avatar data itself, or a URL for a avatar.

+

The Data Forms field that represents the URL for an avatar is "avatar_url".

+

This field does not map to data in vCard or any other profile representation format.

+ + http://www.saint-andre.com/images/stpeter_small.jpg + + ]]> + + +

A biographical URL is the value of an http: URI at which can be found biographical information about a person.

+

The Data Forms field that represents a biographical URL is "bio".

+ + http://www.jabber.org/people/stpeter.shtml + http://www.saint-andre.com/me/ + + ]]> + + +

A FOAF URL is the value of an http: URI at which can be found a "friend of a friend" (FOAF) file about a person or entity.

+

The Data Forms field that represents a FOAF URL is "foaf_url".

+ + http://www.saint-andre.com/me/foaf.rdf + + ]]> + + +

A homepage URL is the value of an http: URI that is the default resource on the World Wide Web for a person or other entity.

+

The Data Forms field that represents a homepage URL is "homepage".

+

This field maps to:

+
    +
  • LDAP labelledURI
    • +
  • FOAF homepage
    • +
+ + http://www.saint-andre.com/ + + ]]> + + +

A photograph provides a pictorial representation of a person. Sometimes also called a "mugshot".

+

A photograph can come in two forms: the photo data itself (see below) or a URL for a photograph (e.g., the vCard PHOTO element can represent either, while the FOAF depiction and FOAF img can represent only a URL). The Data Forms field specified here identifies a URL for a photograph, not the data itself.

+

The Data Forms field that represents the URL for a photograph is "photo_url".

+

This field maps to:

+
    +
  • vCard PHOTO
    • +
  • FOAF depiction
    • +
  • FOAF img
    • +
+ + http://www.saint-andre.com/images/stpeter.jpg + http://www.saint-andre.com/images/stpeter_hell.jpg + http://www.saint-andre.com/images/stpeter_oscon.jpg + + ]]> + + +

A publications URL is the value of an http: URI at which can be found the list of a person's published writings.

+

The Data Forms field that represents a publications URL is "publications".

+

This field maps to:

+
    +
  • FOAF publications
    • +
+ + http://www.saint-andre.com/thoughts/publications.html + + ]]> + + +

A resume URL is the value of an http: URI at which can be found a person's resume or curriculum vitae.

+

The Data Forms field that represents a resume URL is "resume".

+ + http://www.saint-andre.com/work/ + + ]]> + + +

A status URL is the value of an http: URI that specifies the current status of a person or other entity (e.g., a person's online presence or a server's uptime).

+

The Data Forms field that represents a homepage URL is "status_url".

+ + http://status.jabber.org/ + + ]]> + + +

An organizational URL is the value of an http: URI that specifies the homepage for an organization or employer.

+

The Data Forms field that represents an organizational URL is "org_url".

+

This field maps to:

+
    +
  • FOAF workplaceHomepage
    • +
+ + http://www.jabber.org/ + + ]]> + + +

A weblog URL is the value of an http: URI at which a person or other entity maintains a weblog.

+

The Data Forms field that represents a weblog URL is "weblog".

+

This field maps to:

+
    +
  • FOAF weblog
    • +
+ + http://www.saint-andre.com/blog/ + + ]]> + + + + +

It may be appropriate to list others who can be contacted if the individual is not available.

+ + xmpp:peter@jabber.org + + ]]> + + +

An affiliation is a person's relationship to an institution, such as student, faculty, intern, fellow. An affiliation is in general less rigid than an Employee Type, which may not be relevant in noncommercial organizations.

+

The Data Forms field that represents an organizational affiliation is "affiliation".

+

This field maps to:

+
    +
  • LDAP eduPersonAffiliation
    • +
+ + faculty + + ]]> + + +

In some organizations, a person may be assisted by another individual.

+

The Data Forms field that represents an assistant is "assistant".

+

This field maps to:

+
    +
  • LDAP secretary
    • +
+ + Peter Pan + + ]]> + + +

The kind of business performed by an organization.

+

The Data Forms field that represents a business category is "business_category".

+

This field maps to:

+
    +
  • LDAP business_category
    • +
+ + Automobile sales + + ]]> + + +

Some organizations have departments, which can be named or numbered.

+

The Data Forms field that represents a department name is "department_name".

+ + Executive + + ]]> + + +

Some organizations have departments, which can be named or numbered.

+

The Data Forms field that represents a department number is "department_number".

+

This field maps to:

+
    +
  • LDAP departmentNumber
    • +
+ + 5674 + + ]]> + + +

Some organizations assign numbers to employees.

+

The Data Forms field that represents an employee number is "employee_number".

+

This field maps to:

+
    +
  • LDAP employeeNumber
    • +
+ + 1 + + ]]> + + +

Some organizations have different types of employees, such as "full-time", "part-time", "contractor", and "temp".

+

The Data Forms field that represents an employee type is "employee_type".

+

This field maps to:

+
    +
  • LDAP employeeType
    • +
+ + volunteer + + ]]> + + +

A job title is the official name of a person's position within an organization.

+

The Data Forms field that represents a job title is "job_title".

+

This field maps to:

+
    +
  • vCard TITLE
    • +
  • LDAP title
    • +
  • FOAF title
    • +
+ + Executive Director + + ]]> + + +

In most organizations, a person is managed by or reports to another individual (often not exposed outside the organization).

+

The Data Forms field that represents a manager is "manager".

+

This field maps to:

+
    +
  • LDAP manager
    • +
+ + William Shakespeare + + ]]> + + +

An organizational name is the official name of an organization (company, school, etc.) within which a person works.

+

The Data Forms field that represents the name of an organization is "org_name".

+

This field maps to:

+
    +
  • vCard ORGNAME
    • +
  • LDAP o
    • +
+ + Jabber Software Foundation + + ]]> + + +

An organizational role describes a person's profession or how a person contributes within an organization.

+

The Data Forms field that represents an organizational role is "org_role".

+

This field maps to:

+
    +
  • vCard ROLE
    • +
+ + Patron Saint + Chief Evangelist + Glorified Tech Writer + + ]]> + + +

An organizational unit is the name of part (subsidiary, department, etc.) of an organization.

+

The Data Forms field that represents an organizational unit is "org_unit".

+

This field maps to:

+
    +
  • vCard ORGUNIT
    • +
  • LDAP ou
    • +
+ + Jabber Council + + ]]> + + +

An affiliation is a person's relationship to an institution, such as student, faculty, intern, fellow. (An affiliation is in general less rigid than an Employee Type, which may not be relevant in noncommercial organizations.) Since a person may be affiliated with multiple organizations (e.g., multiple research institutions), the primary affiliation is used to describe a person's affiliation to their primary organization.

+

The Data Forms field that represents a primary organizational affiliation is "primary_affiliation".

+

This field maps to:

+
    +
  • LDAP eduPersonPrimaryAffiliation
    • +
+ + fellow + + ]]> + + +

An organizational name is the official name of an organization (company, school, etc.) within which a person works. Since a person may be affiliated with multiple organizations (e.g., multiple research institutions), the primary organizational name is used to differentiate the main organization with which a person is affiliated.

+

The Data Forms field that represents the name of a primary organization is "primary_org_name".

+

This field maps to:

+
    +
  • vCard o
    • +
+ + Columbia University + + ]]> + + +

An organizational role describes a person's profession or how a person contributes within an organization. Since a person may be affiliated with multiple organizations (e.g., multiple research institutions), the primary organizational role is used to differentiate the person's role at their primary organization.

+

The Data Forms field that represents an organizational role is "primary_org_role".

+

This field maps to:

+
    +
  • vCard ROLE
    • +
+ + Professor Emeritus + + ]]> + + +

An organizational unit is the name of part (subsidiary, department, etc.) of an organization Since a person may be affiliated with multiple organizational units (e.g., multiple schools within a university), the primary organizational name is used to differentiate the main organization with which a person is affiliated.

+

The Data Forms field that represents an organizational unit is "primary_org_unit".

+

This field maps to:

+
    +
  • LDAP ou
    • +
  • LDAP eduPersonPrimaryOrgUnitDN
    • +
+ + Jabber Council + + ]]> + + +

Usually a person has a system or network username within an organization (usually not exposed outside the organization).

+

The Data Forms field that represents such a username is "system_username".

+

This field maps to:

+
    +
  • LDAP uid
    • +
  • LDAP userid
    • +
+ + psaintandre + + ]]> + + +

People often work in teams. Sometimes it can be helpful to list those teams.

+

The Data Forms field that represents a work team is "teams".

+ + Infrastructure Team + Jabber Council + + ]]> + + +

Often a person has a dedicated workstation address or name within an organization (usually not exposed outside the organization).

+

The Data Forms field that represents such a username is "workstation".

+ + squire + + ]]> + + + +

These data fields are not necessarily permanent, but do not tend to change very often if at all.

+ +

A birth day-of-month is the day of the month in which a person was born. (Note: This data field is not what in English is usually referred to as a person's "birthday", i.e. the year+month+day on which the person was born; the "birthday" is split into three data fields in order to protect personal privacy, since a given individual might want to disclose his or her birth year, birth month, birth day-of-month, or some combination thereof but not all three.)

+

The Data Forms field that represents a birth day-of-month is "birth_dayofmonth".

+

When combined with other birthday-related fields, this field maps to:

+
    +
  • vCard BDAY
    • +
+ + 06 + + ]]> + + +

A birth month is the month of the year in which a person was born.

+

The Data Forms field that represents a birth month is "birth_month".

+

When combined with other birthday-related fields, this field maps to:

+
    +
  • vCard BDAY
    • +
+ + 08 + + ]]> + + +

A birth year is the year in which a person was born.

+

The Data Forms field that represents a birth year is "birth_year".

+

When combined with other birthday-related fields, this field maps to:

+
    +
  • vCard BDAY
    • +
+ + 1966 + + ]]> + + +

It can be helpful to provide a natural-language description of a person.

+

The Data Forms field that represents a description of a person is "description".

+

This field maps to:

+
    +
  • LDAP description
    • +
+ + I'm a Jabber fanatic. + + ]]> + + +

Some people may want to know the color of a person's eyes. The allowable or recommended values for this field are not specified.

+

The Data Forms field that represents a person's eye color is "eye_color".

+ + blue + + ]]> + + +

Gender is the self-defined gender of a person (this is not limited to "male" and "female", although those are the expected values in most instances). Sometimes also called "sex" or "gender identification".

+

The Data Forms field that represents a person's gender is "gender".

+

This field maps to:

+
    +
  • FOAF gender
    • +
+ + male + + ]]> + + +

Some people may want to know the color of a person's hair (if any). The allowable or recommended values for this field are not specified.

+

The Data Forms field that represents a person's hair color is "hair_color".

+ + none + + ]]> + + +

Some people may want to know a person's height. This SHOULD be expressed in centimeters (which can be transformed into other units if necessary by a client).

+

The Data Forms field that represents a person's height is "height".

+ + 178 + + ]]> + + +

Yes, it is a sensitive topic, but some people may want to know a person's weight. This SHOULD be expressed in kilograms (which can be transformed into other units if necessary by a client).

+

The Data Forms field that represents a person's weight is "weight".

+ + 75 + + ]]> + + + + +

An area of expertise is a subject in which a person has a great deal of knowledge.

+

The Data Forms field that represents an area of expertise is "expertise".

+ + Jabber + XMPP + + ]]> + + +

An avatar is an often fanciful representation of a user's desired self-image or persona (e.g., in the context of a game). An avatar is usually not intended to be an accurate picture of the user's actual physical appearance (that is handled by the photo_url and photo_data fields).

+

An avatar can come in two forms: the avatar data itself, or a URL for a avatar.

+

The Data Forms field that represents avatar data is "avatar_data".

+

This field does not map to data in vCard or any other profile representation format.

+ + base64-encoded-image-data + + ]]> + + +

Some people are members of clubs or other voluntary organizations.

+

The Data Forms field that represents club memberships is "clubs".

+ + DENSA + + ]]> + + +

Some people have dietary preferences (vegan, vegetarian, kosher, peanut allergy, no shellfish, etc.).

+

The Data Forms field that represents dietary preferences is "dietary_preferences".

+ + none + + ]]> + + +

A hobby is a non-work activity that a person enjoys pursuing. Also called an "avocation".

+

The Data Forms field that represents a hobby is "hobby".

+ + guitar + songwriting + blogging + reading + hiking + + ]]> + + +

An interest a thing that a person cares about or is curious about. It is, generally, less active than a hobby.

+

The Data Forms field that represents an interest is "interest".

+ + history + baseball + economics + + ]]> + + +

Some people know more than one language, but less than well (e.g., the person may not be able to speak fluently). The definition of "less well" is left to the user.

+

The value of this field MUST be an abbreviation for a language as specified in &rfc3066;.

+

The Data Forms field that represents a language known less that well is "languages_lesswell".

+ + cz + de + nl + + ]]> + + +

Everyone knows at least one language well (e.g., they are able to speak or write the language with a fair degree of fluency). Determination of whether someone knows a language "well" or "fluently" is left to the user.

+

The value of this field MUST be an abbreviation for a language as specified in RFC 3066.

+

The Data Forms field that represents a language known well is "languages_well".

+

This field maps to:

+
    +
  • LDAP preferredLanguage
    • +
+ + en + + ]]> + + +

Many people own automobiles, which usually have license or registration numbers.

+

The Data Forms field that represents a car license or registration number is "car_license_number".

+

This field maps to:

+
    +
  • LDAP carLicense
    • +
+ + JABBER + + ]]> + + +

Human beings often get married, sometimes get divorced, become widowed, etc.

+

The Data Forms field that represents whether a person's marital status is "marital_status".

+ + married + + ]]> + + +

A Myers-Briggs type indicator is four-letter acronym that is a popular way to characterize different personality types.

+

The Data Forms field that represents a Myers-Briggs type indicator is "mbti".

+

This field maps to:

+
    +
  • FOAF myersBriggs
    • +
+ + INTP + + ]]> + + +

A photo provides a pictorial representation of a person. Sometimes also called a "mugshot".

+

A photo can come in two forms: the photo data itself, or a URL for a photo (e.g., the vCard PHOTO element can represent either, while the FOAF depiction and FOAF img can represent only a URL).

+

The Data Forms field that represents photo data is "photo_data".

+

This field maps to:

+
    +
  • vCard PHOTO
    • +
  • LDAP jpegPhoto
    • +
+ + base64-encoded-image-data + + ]]> + + +

A profession is what a person does for his or her primary employment. Also known as a "vocation". The allowable or recommended values for this field are not specified.

+

The Data Forms field that represents a profession is "profession".

+ + software engineer + + ]]> + + +

Many people feel affiliated with a religious belief system.

+

The Data Forms field that represents a religious affiliation is "religion".

+ + none + + ]]> + + +

The allowable or recommended values for this field are not specified.

+

The Data Forms field that represents a person's sexual orientation is "sexual_orientation".

+ + straight + + ]]> + + +

Some people smoke tobacco in various forms (cigarettes, cigars, pipes, etc.).

+

The Data Forms field that represents whether a person smokes is "smoker".

+ + no + + ]]> + + +

A wishlist is a list of items that a person would like to receive as gifts.

+

The Data Forms field that represents a wishlist is "wishlist".

+ + A Mini Cooper + + ]]> + + +

A Chinese zodiac sign denotes the type of year in which a person was born according to the Chinese calendar (e.g., the year of the dragon).

+

The Data Forms field that represents a Chinese zodiac sign is "zodiac_chinese".

+ + horse + + ]]> + + +

A Western zodiac sign is that part of the astrological belt under which a person was born; each sign is named after one of the constellations.

+

The Data Forms field that represents a Western zodiac sign is "zodiac_western".

+ + Leo + + ]]> + + + +

Some people have PGP keys, X.509 certificates, and the like.

+ +

The ASCII armored output of a PGP key.

+

The Data Forms field that represents a PGP key is "pgpkey".

+

This field maps to:

+
    +
  • vCard KEY with TYPE of PGP
    • +
+ + +-----BEGIN PGP PUBLIC KEY BLOCK----- +Version: GnuPG v1.2.4 (Darwin) + +mQGiBEGSeUQRBADTT8NqGpxDQ1GjmAJBDNET0blyb1LF6exYLxydX+hzcooE5WxP +Zdo5Xx0RrLYlKmmcKv0Z8cG/kei2pkS05h/oqluphGmzMBIeC/ox22z87PKpVDfj +OEYQOZqhqdFI+KRIa4M89CQOO1N5V2KlX9GaNjxRearKvLgsoeTzpPtybwCgl91i +SqQnry1YV+PFOjRcDT7cX+UD/2JxXU5d1Z1WZf7ttM3QjSaPc9CA4fS+axinRkn/ +IbRJ/Lj8Tz+Vb4kBbBhmFG8JCoRtj2J8bsDdaFCh7nHqT2u4oXy0NJSCKrDRBcuL +bEQfasT/cuBXIM2A7nB1UtlUCYXnINxakYLIsW9BvvFN935FhZ81EJvLW34W2Mf7 +Y+9ZA/0adScaI05UUE5RRcZSiXs8/p+R6SeaW2gjS5beL5Wv6ExRlDe92rGqrjtN +PmBRiDiVBSoYlqOepBZk+wM+/B4WMsmUFVeXsXWjWMlghyyni2rI1Z2v1UH8KBKm +259k7SlU/BbnEAHIzuHPSQHJNUX+YqWArz1v5tDcQn7L1Wo7PbRAUGV0ZXIgU2Fp +bnQtQW5kcmUgKHhtcHA6c3RwZXRlckBqYWJiZXIub3JnKSA8c3RwZXRlckBqYWJi +ZXIub3JnPoheBBMRAgAeBQJBknlEAhsDBgsJCAcDAgMVAgMDFgIBAh4BAheAAAoJ +EFmFiWTXBRKsfeQAoJdO0PvP1Mi/kJ9U1zVpa4GPpXYCAJ9oFjonfr+Z3ZTefjSb +tZpE2mny57kCDQRBknlzEAgAisWlkK6daVjrxouZK9KvX8tt3CKVse4CY52Lq7xi +dtEAhDcXX9SgTnlxgrcCnBipj/OMi/B2M0U88qv3TcsZ0dWZt7H4FnHJvU4xloK8 +qRkJ7xa6gCEoPAc7ESdr//6J/eEvWMqixstOUyfRg2AQp/eSHX0Cl/TQImRVZbh6 +HYCehrqpErAnz0VY8nvun3709LgvIMUvKrnV7lF9wOuuhWCK9IYdpmgoD4d/Gr4t +ZVuE1jYN4tBLyQXtJDAR/UvKHEiXUAhsfXOtfCUQV5MaxM6YQce63BGl05kS7oLH +Sx+KYOX1vEi3k1OFfH5CpqYaxmfhSzdyz7Hhdsl+IbkhzwAECwf/YQfpx4z9dnJn +3ePrZhz5SI4KjdbOCmqhLFd8aVoQ9BCriePH3kPjjoE9Qz+0NlFqzuG4/tkZkAok +BA0GqYE4XXgvpwGpK95mlUvxDOowu0fLVQA8NfpU3U7YItZkfAPZ2M+PnmayRILi +0yBmm1taVllCD2mc2vhsMRUoD1DUworSzQuTG9YlQ89Q2/1LsoQzYjBz9XIfYV4A +MPr/PKPkKy3D7BYHi/DOnkcP9hLXJSCjgV5TpuWuCVX9aYU2Yb7BfY1OFORBCUaV +B1YLAPtXqfqjz25pIQPDEUbpKzhEO7xNU4EPT8ZsSfqqOd3aMet8McieRfMd+VIe +4J1OUIg1oYhJBBgRAgAJBQJBknlzAhsMAAoJEFmFiWTXBRKs/GgAn0R63qTEQd/e +XhK8hFkPvXjudl7xAJ95+2fAHfmHheZJVaO8VaJiL54Tvw== +=ZRIc +-----END PGP PUBLIC KEY BLOCK----- + + + ]]> + + +

The fingerprint (hashed value) of a PGP key.

+

The Data Forms field that represents a PGP fingerprint is "pgp_fingerprint".

+ + E5CA EAE7 C8D6 CFE2 6D7A 8653 5985 8964 D705 12AC + + ]]> + + +

The ID of a PGP key.

+

The Data Forms field that represents a PGP key ID is "pgpkey_id".

+ + D70512AC + + ]]> + + +

The fingerprint of an X.509 certificate, hashed using MD5.

+

The Data Forms field representing such a value is "x509_fingerprint_md5".

+ + 5D 41 20 54 7C 90 49 A1 78 36 07 29 75 9B A7 D0 + + ]]> + + +

The fingerprint of an X.509 certificate, hashed using SHA-1.

+

The Data Forms field representing such a value is "x509_fingerprint_sha1".

+ + C3 88 33 27 F3 47 3B 8B 07 71 3E 96 44 A7 EE E2 E0 50 4A 5B + + ]]> + + + +

Most people have favorite movies, authors, TV shows, musical artists, foods, games, etc.

+ +

The Data Forms field that represents favorite authors is "fav_authors".

+

This field does not map to data in vCard or any other profile representation format.

+ + Jacob Bronowski + Friedrich Nietzsche + Carroll Quigley + Yevgeny Zamyatin + + ]]> + + +

The Data Forms field that represents favorite athletes is "fav_athletes".

+

This field does not map to data in vCard or any other profile representation format.

+ + Lance Armstrong + Andre Agassiz + + ]]> + + +

The Data Forms field that represents favorite beverages is "favorite_beverages".

+

This field maps to:

+
    +
  • LDAP drink
    • +
  • LDAP favoriteDrink
    • +
+ + Guinness + + ]]> + + +

The Data Forms field that represents favorite charities is "fav_charities".

+

This field does not map to data in vCard or any other profile representation format.

+ + Institute for Justice + PERC + + ]]> + + +

The Data Forms field that represents favorite chatrooms is "fav_chatrooms".

+

This field does not map to data in vCard or any other profile representation format.

+ + jabber@conference.jabber.org + jdev@conference.jabber.org + + ]]> + + +

The Data Forms field that represents favorite drinks is "fav_drinks".

+

This field does not map to data in vCard or any other profile representation format.

+ + Guinness + + ]]> + + +

The Data Forms field that represents favorite foods is "fav_foods".

+

This field does not map to data in vCard or any other profile representation format.

+ + Thai + Mexican + Italian + + ]]> + + +

The Data Forms field that represents favorite games is "fav_games".

+

This field does not map to data in vCard or any other profile representation format.

+ + chess + + ]]> + + +

The Data Forms field that represents favorite movies is "fav_movies".

+

This field does not map to data in vCard or any other profile representation format.

+ + In Search of Bobby Fischer + Strictly Ballroom + The Truth About Cats and Dogs + Ray + + ]]> + + +

The Data Forms field that represents favorite music is "fav_music".

+

This field does not map to data in vCard or any other profile representation format.

+ + J.S. Bach + Duke Ellington + Mellow Candle + Yes + + ]]> + + +

A quote is a phrase or saying that a person identifies with in some way. According to the 2004 Pew Internet survey on instant messaging, quotes represent the most popular item to include in online profiles on major consumer-oriented instant messaging services.

+

The Data Forms field that represents favorite quotes is "fav_quotes".

+

This field does not map to data in vCard or any other profile representation format.

+ + I am large, I contain multitudes. + "Think like a man of action, act like a man of thought." --Henri Bergson + One crowded hour of glorious life is worth an age without a name. + + ]]> + + +

The Data Forms field that represents favorite sports teams is "fav_teams".

+

This field does not map to data in vCard or any other profile representation format.

+ + New York Yankees + Colorado Rockies + + ]]> + + +

The Data Forms field that represents favorite TV shows is "fav_tv".

+

This field does not map to data in vCard or any other profile representation format.

+ + Antiques Road Show + + ]]> + + + + +

Some people move around a lot.

+

The Data Forms field that represents places lived is "places_lived".

+

This field does not map to data in vCard or any other profile representation format.

+ + Denver, Colorado, USA + New Hope, Pennsylvania, USA + Maplewood, New Jersey, USA + Atlanta, Georgia, USA + Fairfax, Virginia, USA + Ceske Budejovice, Czech Republic + New York City + Readfield, Maine, USA + Sea Cliff, NY, USA + + ]]> + + +

The Data Forms field that represents schools attended is "schools".

+

This field does not map to data in vCard or any other profile representation format.

+ + Columbia University + American Renaissance School + Maranacook Community School + + ]]> + + + + +

Profile data can be personally significant and even security critical. Due care should be taken in determining who shall have access to such information. In particular, an entity SHOULD ensure that its public profile contains only information that it deems safe to be world-readable, SHOULD ensure that any pubsub node it may create for profile data has an access model of "presence" or "roster", and SHOULD NOT publish private or restricted data except to such a pubsub node.

+ + +

This JEP requires no interaction with &IANA;.

+ + + +

To follow.

+ + + + diff --git a/xep-0155.xml b/xep-0155.xml new file mode 100644 index 00000000..0868c858 --- /dev/null +++ b/xep-0155.xml @@ -0,0 +1,560 @@ + + +%ents; +]> + + +
+ Chat Session Negotiation + This document specifies a feature negotiation profile for initiating a one-to-one chat session. + &LEGALNOTICE; + 0155 + Experimental + Standards Track + Standards JIG + Council + + XMPP Core + XMPP IM + JEP-0020 + JEP-0068 + + + + chatneg + &stpeter; + &ianpaterson; + + 0.8 + 2006-10-02 + ip +

Added continue field and optional terminate acknowledgement; specified renegotiation failure proceedure; added context to Introduction; changed unavailable presence handling; renamed logging field to otr.

 + + + 0.7 + 2006-07-14 + psa +

Added secure field from JEP-0116.

 + + + 0.6 + 2006-07-13 + psa +

Specified that a client must re-initiate if it receives presence unavailable; changed JEP type to Standards Track.

 + + + 0.5 + 2006-01-24 + psa +

Added renegotiate use case.

 + + + 0.4 + 2006-01-03 + psa +

Added terminate use case; further specified mapping to SIP.

 + + + 0.3 + 2005-12-30 + psa +

Further specified use of id attribute and thread element.

 + + + 0.2 + 2005-07-15 + psa +

Further described contexts in which chat session negotiation could be useful; added more examples; added reference to SIP RFC and explained basic mapping to SIP INVITE method; added Jabber Registrar considerations.

 + + + 0.1 + 2005-07-14 + psa +

Initial JEP version.

 + + + 0.0.1 + 2005-07-12 + psa +

First draft.

 + +
+ +

The traditional model for one-to-one chat "sessions" in Jabber/XMPP is for a user to simply send a message to a contact without any formal negotiation of chat session parameters (e.g., see &xmppim;). This informal approach to initiation of a chat session is perfectly acceptable in many contexts, environments, and cultures. However, it may be desirable to formally request the chat and negotiate its parameters before beginning the chat session in some circumstances, such as:

+
    +
  • Whenever parameters specific to a chat session must be agreed. e.g., security and privacy parameters (see &jep0116; and &jep0136;).
    • +
  • The parties are unknown to each other, have not exchanged presence, or have not discovered their respective capabilities via &jep0030; or &jep0115;.
    • +
  • When an XMPP-based system interfaces with a SIP-based system built on top of &rfc3261;. In essence, a chat state negotiation request as specified herein is functionally equivalent to a SIP INVITE request, and acceptance of such a request is functionally equivalent to sending a SIP 200 OK response; see Section 17 of RFC 3261.
    • +
  • Within an organization or culture in which one would not simply begin chatting with another person (e.g., a superior) without first receiving permission to do so.
    • +
+

This proposal defines best practices for such a negotiation, re-using the protocol defined in &jep0020;.

+ + + +

In order to initiate a negotiated chat session, the initiating party ("user") sends a &MESSAGE; stanza to the receiving party ("contact") containing a <feature/> child qualified by the 'http://jabber.org/protocol/feature-neg' namespace. The &MESSAGE; stanza MUST NOT contain a &BODY; child element (as specified in &rfc3921;). The &MESSAGE; stanza is used because the user does not necessarily know which of the contact's resources is most available (or indeed if the contact is online). The &MESSAGE; stanza type SHOULD be "normal" (either explicitly or by non-inclusion of the 'type' attribute). The stanza SHOULD include an 'id' attribute and MUST contain a &THREAD; element for tracking purposes (where the newly-generated ThreadID is unique to the proposed session). The data form MUST contain a hidden FORM_TYPE field whose value is "http://jabber.org/protocol/chatneg" and MUST contain a boolean field named "accept". &BOOLEANNOTE;

+

The following is an example of a negotiation request:

+ + ffd7076498744578d10edabfe7f4a866 + + + + http://jabber.org/protocol/chatneg + + + true + + + + 0 + + + 0 + + + 1 + + + 1 + + + Can we talk? + + + + + ]]> +

In the foregoing example, Romeo requests a chat with Juliet and also queries her regarding whether she wants to disable all message logging (see &jep0136;) A client MUST NOT set the 'otr' field to 'true' unless it has confirmed that its server will allow it to switch off Automated Archiving (see Message Archiving). and support &jep0071; and &jep0085; extensions during this chat session. (Note: These fields are examples only; a full set of chat session negotiation parameters will be registered as described in the Jabber Registrar Considerations section of this document.)

+

Juliet's server delivers Romeo's request to her most available resource (which happens to be "balcony").

+

In any response to the request, the contact's client MUST mirror the 'id' attribute and &THREAD;value so that the user's client can correctly track the response.

+

We assume that Juliet accepts the chat and specifies that she does not want to log messages or use XHTML formatting but that she does want to use Chat State Notifications:

+ + ffd7076498744578d10edabfe7f4a866 + + + + http://jabber.org/protocol/chatneg + + + true + + + 0 + + + 1 + + + 1 + + + 1 + + + Sure, let's talk! + + + + + ]]> +

However, it could be that Juliet is busy so she declines the invitation.

+ + ffd7076498744578d10edabfe7f4a866 + + + + http://jabber.org/protocol/chatneg + + + 0 + + + Sorry, can't chat now! How about tonight? + + + + + ]]> +

If Juliet's client does not support feature negotiation or does not support the "http://jabber.org/protocol/chatneg" FORM_TYPE, it SHOULD return a &unavailable; error. However, if Juliet does not want to reveal her presence to Romeo for whatever reason, or she is using a legacy client that does not support returning a &unavailable; error, then her client MAY return no error. In this case Romeo MAY, proceed to send stanzas to Juliet outside the context of a negotiated chat session.

+ + ffd7076498744578d10edabfe7f4a866 + + + + http://jabber.org/protocol/chatneg + + + 1 + + + + 0 + + + 0 + + + 1 + + + 1 + + + Can we talk? + + + + + + + + ]]> +

If Juliet's client does not support one of the required features, it SHOULD return a &feature; error (but MAY return no error if, for example, Juliet does not want to reveal her presence to Romeo for whatever reason):

+ + ffd7076498744578d10edabfe7f4a866 + + + + http://jabber.org/protocol/chatneg + + + 1 + + + + 0 + + + 0 + + + 1 + + + 1 + + + Can we talk? + + + + + + + + ]]> +

If Juliet's client does not support one of the optional features (e.g., Chat State Notifications) but it accepts the request, it MUST set the value of that boolean variable to "0" or "false".

+ + +

At any time during an existing chat session, either party MAY attempt to renegotiate the parameters of the session. The requesting party does this by sending a new &MESSAGE; stanza containing a feature negotiation form and a &THREAD; element with the same value as that of the existing chat session.

+

Note: The "accept" field SHOULD NOT be included in a renegotiation form. The set of other fields in the form MAY be different from the set included in the initial session negotitation.

+ + ffd7076498744578d10edabfe7f4a866 + + + + http://jabber.org/protocol/chatneg + + + 1 + + + 1 + + + 1 + + + 1 + + + Gotta have formatting! + + + + + ]]> + + ffd7076498744578d10edabfe7f4a866 + + + + http://jabber.org/protocol/chatneg + + + true + + + 1 + + + 1 + + + 1 + + + Agreed, XHTML is fun. + + + + + ]]> +

If the other party's client does not support one of the required features, it SHOULD return a &feature; error instead. In that case the existing negotiated chat session parameters are maintained. Either party MAY then terminate the chat session as specified in the section Terminating a Chat.

+ + +

Either party MAY use chat renegotiation to attempt to continue the session using another of its resources. The requesting party does this by sending a feature renegotiation form with a "continue" field containing the value of the new resource:

+ + ffd7076498744578d10edabfe7f4a866 + + + + http://jabber.org/protocol/chatneg + + + PDA + + + I am leaving the orchard. + + + + + ]]> +

The requesting party SHOULD NOT send stanzas within the session from either resource until the other party has accepted or rejected (with a &feature; error) the switch to the new resource.

+

The other party SHOULD accept the switch since the requesting party might otherwise be unable to continue the session:

+ + ffd7076498744578d10edabfe7f4a866 + + + + http://jabber.org/protocol/chatneg + + + PDA + + + OK, hurry to me. + + + + + ]]> +

Once the other party has accepted the switch then all stanzas sent within the chat session MUST be to or from the new resource. Note: Both parties MUST ensure that they comply with all the other chat session negotiation parameters that were previously agreed for this session.

+ + +

In order to explicitly terminate a negotiated chat, the party that wishes to end the chat MUST do so by sending a &MESSAGE; containing a data form of type "submit". The &MESSAGE; stanza SHOULD possess an 'id' attribute and MUST contain a &THREAD; element with the same XML character data as the original initiation request. The data form containing a boolean field named "terminate" set to a value of "1" or "true" and MAY also contain a "reason" field.

+ + ffd7076498744578d10edabfe7f4a866 + + + + http://jabber.org/protocol/chatneg + + + 1 + + + Gotta go! + + + + + ]]> +

Both parties MUST then consider the chat session to be ended.

+

The other party's client MAY explicitly acknowledge the termination of the chat by sending a &MESSAGE; containing a data form of type "result", with no "reason" field and the value of the "terminate" field set to "1" or "true". The client MUST mirror the 'id' attribute and &THREAD; value it received.

+ + ffd7076498744578d10edabfe7f4a866 + + + + http://jabber.org/protocol/chatneg + + + 1 + + + + + ]]> + + + +

When mapping instant messaging flows to SIP, implementations SHOULD adhere to &xmppsimple;.

+

In addition, the following mappings apply to chat session negotiation:

+
    +
  • Initiation of a negotiated chat session maps to the semantics of the SIP INVITE method.
    • +
  • Renegotiation of a negotiated chat session also maps to the semantics of the SIP INVITE method.
    • +
  • Termination of a negotiated chat session maps to the semantics of the SIP BYE method.
    • +
  • The XMPP &THREAD; value maps to the semantics of the SIP Call-ID attribute.
    • +
+ + +

A client MAY require a human user to approve each chat session negotiation request or MAY auto-accept and auto-reject requests based on some user-configurable policy.

+

If a party receives XMPP presence of type "unavailable" from the full JID (&FULLJID;) of the other party (i.e., the resource with which it has had an active session) during a chat session, the receiving party MAY assume that the other client will still be unable to continue the session (perhaps it simply became "invisible", or it is persisting the state of the negotiated chat until it reconnects and receives "offline" messages). +However, if the receiving party assumes that the other client will not be able to continue the session, then it MUST explicitly terminate the session (see Terminating a Chat) - since its assumption could be incorrect. If the receiving party later receives presence of type "available" from that same resource or another resource associated with the other party and the receiving party desires to restart the chat session, it MUST initiate a new chat session (including a newly-generated ThreadID) with the other party rather than renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in JEP-0085.)

+ + +

If a contact accepts a user's request or returns an error to the user, the user will effectively discover the contact's presence (at least the presence of one of the contact's resources). Due care must therefore be exercised in determining whether to accept the request or return an error. For examples, the contact's client SHOULD NOT automatically (i.e. without first asking the contact) either accept the user's request or return an error to the user unless the user is subscribing to the contact's presence (and the contact's presence is not currently "invisible" to the user). Furthermore, the contact's client MUST NOT take either action if the user is in the contact's block list.

+ + +

This JEP requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; shall include 'http://jabber.org/protocol/chatneg' in its registry of Service Discovery features.

+ + http://jabber.org/protocol/chatneg + Support for Chat Session Negotiation and its FORM_TYPE + JEP-0155 + + ]]> + + +

&jep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. The following fields shall be registered for use in Chat Session Negotiation:

+ + http://jabber.org/protocol/chatneg + JEP-0155 + + Forms enabling negotation of a one-to-one + chat session between two entities. + + + + + + + + + + + ]]> + + + +

This proposal re-uses the format defined in JEP-0020 and therefore does not require a separate schema.

+ + +

Thanks to Thomas Charron and Jean-Louis Seguineau for their feedback.

+ + diff --git a/xep-0156.xml b/xep-0156.xml new file mode 100644 index 00000000..4821ccd1 --- /dev/null +++ b/xep-0156.xml @@ -0,0 +1,160 @@ + + +%ents; +]> + + +
+ A DNS TXT Resource Record Format for XMPP Connection Methods + This document defines a DNS TXT Resource Record format for use in specifying methods of connecting to an XMPP server. + &LEGALNOTICE; + 0156 + Experimental + Standards Track + Standards JIG + Council + + XMPP Core + RFC 1464 + + + + N/A + &hildjj; + &stpeter; + + 0.3 + 2005-05-16 + psa +

Clarified order of lookups; restored _xmpp-client-tcp and added _xmpp-server-tcp as optional records if SRV is not supported or accessible.

 + + + 0.2 + 2005-12-05 + psa +

Removed _xmpp-client-tcp from TXT records (belongs in SRV records only).

 + + + 0.1 + 2005-09-08 + psa +

Initial JEP version.

 + + + 0.0.3 + 2005-09-07 + psa +

More fully specified the rationale for using DNS TXT records.

 + + + 0.0.2 + 2005-08-27 + psa +

Added security considerations and registrar considerations.

 + + + 0.0.1 + 2005-08-23 + psa/jh +

First draft.

 + +
+ +

Although &rfc3920; specifies the use of TCP as the method of connecting to an XMPP server, other connection methods are possible. These include the older &jep0025; method, the more recent &jep0124; method, and less common methods such as &wap;. For some of these methods, it is necessary to discover further parameters before connecting, such as the HTTP URL of an alternative connection manager. Currently, if a client application needs to discover connection methods before connecting to an XMPP service, the relevant information must be provided manually by a human user, which is cumbersome and error-prone. Thankfully, there are several potential ways to complete this pre-connection service discovery in an automated fashion:

+
    +

  1. Specify a &w3wsdl; definition (or other XML file format) and a canonical URL for that definition at a domain that offers XMPP services. Unfortunately, this approach requires access to the HTTP server for the domain (and quite possibly to the root directory thereof), which may be difficult for XMPP server administrators to arrange. In addition, it requires a client to retrieve the relevant file via HTTP before performing DNS lookups and XMPP connection; it would be more efficient to use recognized DNS methods since DNS lookups are already required by RFC 3920.

    2. +

  2. Specify a way to define the required service discovery information as part of the existing DNS SRV records (see &rfc2782;) for a domain that offers XMPP services. While this approach sounds promising, it is not feasible since the DNS SRV Target field can be used only to specify domain names and cannot be used to specify full URIs (such as the URL for an HTTP connection manager).

    3. +

  3. Specify a way to define the required service discovery using the "straightforward NAPTR" (S-NAPTR) profile of the Dynamic Delegation Discovery System (see &rfc3958; and &rfc3401;). Unfortunately, S-NAPTR also does not allow inclusion of full URIs, and thus does meet the requirements for discovery of XMPP connection methods.

    4. +

  4. Specify a way to define the required service discovery using a new profile of the Dynamic Delegation Discovery System, which would be nearly identical to S-NAPTR except that it would specify only one app-service (most likely "xmpp") and allow inclusion of the DDDS "U" flag (see &rfc3404;), so that the output of a DDDS rule could be a URI. While this is a valid approach that is worth pursuing, the authors are concerned about the deployability of such an approach, especially for client-side applications (the main focus of this specification).

    5. +

  5. Specify a way to define the required service discovery information via properly-formatted DNS TXT records (see &rfc1464;). While this approach requires an update to the DNS records for the server domain, that is usually necessary in order to establish XMPP services in the first place. Furthermore, although there are some perils to be avoided in the use of DNS TXT records (e.g., wildcards), the technology is well understood and widely deployed (e.g., it is used by the SPF and SenderID systems).

    6. +
+

Therefore this document defines a way to encapsulate information about XMPP connection methods in DNS TXT resource records.

+ + +

The following format for DNS TXT resource records is specified in RFC 1464:

+ <"attribute name=attribute value"> + ]]> +

This document specifies that the following additional rules apply for DNS TXT resource records used to specify XMPP connection methods:

+
    +
  1. It is RECOMMENDED for the owner to be "_xmppconnect".
    2. +
  2. The class field SHOULD be IN.
    3. +
  3. The ttl field is OPTIONAL.
    4. +
  4. The attribute name SHOULD begin with the string "_xmpp-client-" or "_xmpp-server-" and SHOULD be registered as described in the Jabber Registrar Considerations section of this document.
    5. +
  5. If the txt-data field contains only an attribute name (i.e., no unquoted "=" character followed by additional characters), the receiving application SHOULD interpret it as indicating the presence of the attribute or feature with no defined value.
    6. +
  6. If the txt-data field contains an unquoted "=" character, it MUST also contain an attribute value.
    7. +
+ + +

The following business rules apply:

+
    +
  1. TXT lookups MUST be used only as a fallback after the methods specified in RFC 3920 have been exhausted.
    2. +
  2. A domain SHOULD NOT present information in DNS TXT records that is available via the DNS SRV records defined in RFC 3920. However, a domain MAY present such information in DNS TXT records if SRV records are not supported or accessible. Any values (e.g., port numbers) presented via SRV records MUST be taken as canonical and MUST supersede values provided via TXT records.
    3. +
  3. The order of DNS TXT records SHOULD NOT be interpreted as significant by the presenting domain or the receiving entity.
    4. +
+ + +

The following examples show three DNS TXT resource records: the first indicates support for the httpbind connection method defined in JEP-0124 including the appropriate URL, the second indicates support for the httppoll connection method defined in JEP-0025 including the appropriate URL, and the third indicates support for WAP connections including the appropriate URL.

+ + + +

It is possible that advertisement of connection methods other than the standard TCP connection method may introduce security vulnerabilities, since a connecting entity (usually a client) might deliberately seek to connect using the method with the weakest security mechanisms (e.g., no channel encryption or relatively weak authentication). Care must be taken in determining which connection methods are appropriate to advertise.

+ + +

This JEP requires no interaction with &IANA;.

+ + + +

The Jabber Registrar shall maintain a registry of attributes for use in DNS TXT resource records that advertise XMPP connection methods.

+ + ®PROCESS; + + the name of the attribute + a natural-language description of the connection method + the syntax or datatype of the attribute value + the document in which the connection method is specified + + ]]> +

The registrant may register more than one attribute at a time, each contained in a separate <attribute/> element.

+ + + + _xmpp-client-httpbind + the HTTP Binding connection method + the http: or https: URL at which to contact the HTTP Binding connection manager or proxy + JEP-0124 + + + + _xmpp-client-httppoll + the HTTP Polling connection method + the http: or https: URL at which to contact the HTTP Polling connection manager or proxy + JEP-0025 + + + + _xmpp-client-tcp + standard client-to-server TCP connection method (usually on port 5222) + may contain the port number (however, this should be discovered via SRV) + RFC 3920 + + + + _xmpp-server-tcp + standard server-to-server TCP connection method (usually on port 5269) + may contain the port number (however, this should be discovered via SRV) + RFC 3920 + + + ]]> + + + + diff --git a/xep-0157.xml b/xep-0157.xml new file mode 100644 index 00000000..eb2ae9a9 --- /dev/null +++ b/xep-0157.xml @@ -0,0 +1,164 @@ + + +%ents; +]> + + +
+ Contact Addresses for XMPP Services + This document defines a method for specifying contact addresses related to an XMPP service. + &LEGALNOTICE; + 0157 + Experimental + Standards Track + Standards JIG + Council + + XMPP Core + + + + N/A + &stpeter; + + Jacek + Konieczny + jajcus@jajcus.net + jajcus@jabber.bnet.pl + + + 0.3 + 2006-07-31 + psa +

Recommended support for RFC2142-style mailbox in addition to XMPP address.

 + + + 0.2 + 2006-07-18 + psa +

Removed extended addressing recommendations pending further review.

 + + + 0.1 + 2005-09-08 + psa +

Initial JEP version.

 + + + 0.0.2 + 2005-09-06 + psa +

Added security considerations and Jabber Registrar considerations.

 + + + 0.0.1 + 2005-08-27 + psa/jk +

First draft.

 + +
+ + &BISNOTE; +

&rfc2142; specifies conventional electronic mailbox names for common services, roles, and functions related to SMTP, NNTP, and HTTP (such as postmaster@domain.tld, usenet@domain.tld, and webmaster@domain.tld). However, no such conventional email address or Jabber ID (JID) has been specified for XMPP services. This document remedies that oversight.

+ + +

Many existing Jabber/XMPP server implementations use the bare domain of the server as an alias for the server administrators, such that a &MESSAGE; stanza addressed to that domain name (e.g., "jabber.org") is delivered to the JIDs of the server administrators (this does not apply to &IQ; or &PRESENCE; stanzas). It is RECOMMENDED that all server implementations support this functionality, and the authors will work toward standardization of this functionality in the forthcoming revisions to &rfc3920;.

+ + +

Consistent with RFC 2142, a domain that offers a Jabber/XMPP service SHOULD provide an Internet mailbox of "XMPP" for inquiries related to that service, which MAY be advertised through a URI of <mailto:xmpp@domain.tld>.

+ + + +

Advertising contact addresses may open those addresses to unwanted communication. Server administrators should balance the need for openness with the desire for control over communication with customers and peers. That said, certain contact addresses (e.g., abuse addresses and security addresses) may enable server administrators to more quickly learn of abusive usage and potential security holes, and advertisement of those addresses is strongly encouraged.

+ + +

This document requires no interaction with &IANA;.

+ + + diff --git a/xep-0158.xml b/xep-0158.xml new file mode 100644 index 00000000..f5b5988b --- /dev/null +++ b/xep-0158.xml @@ -0,0 +1,759 @@ + + +%ents; +]> + + +
+ Robot Challenges + This document specifies an XMPP protocol extension that entities may use to discover whether the sender of an XML stanza is a human user or a robot. + &LEGALNOTICE; + 0158 + Deferred + Standards Track + Standards JIG + + XMPP Core + XMPP IM + JEP-0004 + JEP-0066 + + None + None + challenge + &ianpaterson; + + 0.4 + 2005-09-30 + ip + Required WAV instead of MP3 for audio CAPTCHAs; minor corrections + + + 0.3 + 2005-09-28 + ip + Added more CAPTCHA types and the legacy question and answer section + + + 0.2 + 2005-09-14 + ip + Minor fixes + + + 0.1 + 2005-09-14 + ip + Initial JEP version. + + + 0.0.1 + 2005-09-07 + ip + First draft. + +
+ + +

The appearance of large public IM services based on &rfc3920; and &rfc3921; makes it desirable to implement protocols that discourage the sending of large quantities of IM SPAM (SPIM) from XMPP clients (connected to legitimate servers) and XMPP servers (with virtual clients) -- all hosted on networks of 'zombie' machines. SPIM is defined here as any type of unsolicited XMPP stanza sent by a 'robot' and delivered to a human, including messages and subscription requests. SPIM has the potential to disrupt people even more than SPAM, because each message interrupts the receiver (humans typically filter SPAM in batch mode).

+

Several of the most effective techniques developed to combat SPAM require humans to be differentiated from bots using a "Completely Automated Public Turing Test to Tell Computers and Humans Apart" or CAPTCHA (see <http://www.captcha.net/>). These challenge techniques are easily adapted to discourage SPIM. The very occasional inconvenience of responding to a CAPTCHA (for example, when creating an IM account or sending a message to a new correspondent) is small and perfectly acceptable -- especially when compared to the countless robot-generated interruptions people might otherwise have to filter every day.

+

An alternative technique to CAPTCHAs requires Desktop PC clients to undertake a Hashcash Hashcash <http://hashcash.org/>. challenge. These are completely transparent to PC users. They require clients to perform specified CPU-intensive work, making it difficult to send large amounts of SPIM.

+

The generic challenge protocol described in this document is designed for incorporation into other protocols like &jep0077; and &jep0159;.

+ + + + +

The CAPTCHAs in most common use today are Optical Character Recognition (OCR) challenges where an image containing deformed text is presented and the human enters the characters they can read. However if OCR software advances more rapidly than the techniques used to disguise text from Artificial Intelligence (AI) then very different CAPTCHAs will need to be deployed. This protocol must be extensible enough to allow the incorporation of CAPTCHA techniques that may not have been envisaged.

+ + +

Several common CAPTCHA techniques present major problems to users with disabilities (see &w3turingtest;). Clients running in constrained environments may not be able to perform some challenges (for example, due to the absence of audio output or a lack of CPU performance). This protocol must allow clients to be offered a choice from a variety of challenges.

+ + + + +

This protocol requires multimedia to be included within &jep0004;. This section defines a new namespace ('http://jabber.org/protocols/media') for that purpose. The root element for the namespace is <media/>. It MUST be contained within a <field/> element qualified by the 'jabber:x:data' namespace.

+

If the media is an image or video then the <media/> element SHOULD include 'width' and 'height' attributes specifying the recommended display size of the media in pixels.

+

The <media/> element SHOULD contain at least one <uri/> element to specify the out-of-band location of the media data. Constrained execution environments prevent some clients rendering media unless it has been received out-of-band (e.g., Web clients). The <uri/> element MUST contain a URI that indicates the location.

+

The <media/> element MAY also contain one or more <data/> elements for distributing the media in-band. The <data/> element MUST contain the Base64 encoded (in accordance with Section 3 of &rfc3548;) media data. The encoded data SHOULD NOT be larger than 8 KB. Note that if a stanza contains more than one <data/> element then the sending entity MUST take care not to trigger karma limits.

+

Each <uri/> or <data/> element MUST include a 'type' atribute that specifies the MIME type (see &rfc2045;) of the media.

+ + http://www.victim.com/challenges/speech.wav?F3A6292C + http://www.victim.com/challenges/speech.ogg?F3A6292C + http://www.victim.com/challenges/speech.mp3?F3A6292C + ** Base64 encoded audio ** + + ]]> + + + + +

An entity (client or server) MAY send a challenge to a client immediately after receiving a stanza from the client. An entity MUST NOT send challenges under any other circumstances. Hereafter, the entity that sends a challenge is called a "challenger".

+ + Love pills - 75% OFF + + http://www.spimmer.com/lovepills.html + + + ]]> + +

Each of the challenge form's <field/> elements (see Data Forms) that are not hidden MAY contain a different challenge and any media required for the challenge. The hidden 'from' field MUST contain the value of the 'to' attribute of the client's stanza that triggered the challenge. If the stanza from the client included an 'id' attribute then the hidden 'sid' field MUST be set to that value. The 'xml:lang' attribute of the challenge stanza SHOULD be the same as the one received from the client. The hidden 'FORM_TYPE' field MUST have a value of "http://jabber.org/protocol/challenge" in accordance with &jep0068;.

+

The challenger SHOULD include an explanation (in the &BODY; element) for clients that do not support this protocol. The challenger MAY also include a URL (typically a Web page with instructions) using &jep0066; as an alternative for clients that do not support the challenge form. Note: even if it provides a URL, a challenger MUST always provide a challenge form. A constrained client, like a mobile phone, cannot present a Web page to its user.

+ + Your messages to innocent@victim.com are being blocked. + Visit the Web page to unblock them. + + http://www.victim.com/challenge.html?F3A6292C + + + + + http://jabber.org/protocol/challenge + + innocent@victim.com + spam1 + + + http://www.victim.com/challenges/ocr.jpeg?F3A6292C + ** Base64 encoded image ** + + + + + http://www.victim.com/challenges/picture.jpeg?F3A6292C + ** Base64 encoded image ** + + + + + http://www.victim.com/challenges/speech.wav?F3A6292C + http://www.victim.com/challenges/speech.ogg?F3A6292C + + + + + http://www.victim.com/challenges/video.mpeg?F3A6292C + + + + + + + + ]]> + + + +

The client SHOULD ignore the challenge stanza in either of the following cases:

+
    +
  • If it has not recently sent (in the last two minutes for example) a stanza to the JID specified in the 'from' field of the form with the 'id' specified in the 'sid' field (or with no 'id' if no 'sid' field is included). Otherwise the user's presence would be disclosed, or a SPIM robot might dupe the user into providing answers to other people's challenges!
    • +
  • If the 'from' attribute of the challenge stanza does not match the 'from' field of the form. (If the values are different, then they still match if the bare JIDs are the same, or if the 'from' attribute is the domain of the other JID.)
    • +
+

Otherwise, if the challenger provided a URL using Out-of-Band Data, then the client MAY present the URL to its user, instead of responding to the challenge form, in any of the following cases:

+
    +
  • if it does not understand the challenge form
    • +
  • if it does not support all of the required challenges (see Multiple Challenges)
    • +
  • if it does not support enough of the challenges (see Multiple Challenges)
    • +
+

Otherwise, the client MUST respond to the challenger, preserving the 'id' attribute of the challenge stanza.

+

The client MUST respond with a ¬acceptable; error in any of the following cases:

+
    +
  • if it does not support all of the required challenges (see Multiple Challenges)
    • +
  • if it does not support enough of the challenges (see Multiple Challenges)
    • +
  • if its user declines the challenge
    • +
+ + + + + + ]]> +

Otherwise, it MUST select one challenge according to the user's preferences and submit the user's response form to the challenger.

+ + + + + http://jabber.org/protocol/challenge + + innocent@victim.com + spam1 + 7nHL3 + + + + ]]> + + + +

The challenger SHOULD send a &unavailable; error to the client if:

+
    +
  • The challenger did not send the specified challenge. If the challenger is a client then it SHOULD be careful not to leak information about the presence of its user and reply to potentially bogus challenge responses with exactly the same XML that its server would send if its user were offline.
    • +
  • The client already submitted its response to this challenge.
    • +
  • The client took too long to submit its response.
    • +
+

Note: This error MAY be sent even in cases where the challenge became unnecessary while the challenger was waiting for the response.

+ + + + + + ]]> +

After receiving a correct response to its challenge, the challenger SHOULD inform the client that it was successful.

+ + ]]> +

However, if the client submits an incorrect response the challenger SHOULD send it a ¬acceptable; error with type "cancel": If a large proportion of the responses a server is receiving from another IP are incorrect then it SHOULD inform the administrator of the other server (using the protocol to be defined in a forthcoming proposal on SPIM reporting). It SHOULD also automatically block all stanzas from the abusive user, users, server or IP.

+ + + + + + ]]> + + + +

The enitity may demand responses to more than one of the challenges it is offering by including an 'answers' <field/> element in the form. It may require responses to particular challenges by including <required/> elements in the compulsory fields.

+ + Your messages to innocent@victim.com are being blocked. + To unblock them, ask innocent@victim.com to send you a message. + + + + http://jabber.org/protocol/challenge + + innocent@victim.com + spam2 + 2 + + + http://www.victim.com/challenges/ocr.jpeg?F3A6292C + + + + + http://www.victim.com/challenges/audio.wav?F3A6292C + + + + + + + + + + ]]> + +

If the client finds the request acceptable, it MUST answer all challenges that include a <required/> element. If the total number of answers was specified and it is greater than the number of <required/> elements then the client MUST also answer one or more of the challenges without a <required/> element. In the example above, the client should respond to the 'qa' challenge and one of the other challenges ('ocr', 'audio_recog' or 'SHA-256').

+ + + + + http://jabber.org/protocol/challenge + + innocent@victim.com + spam2 + 2 + divad + innocent@victim.com2450F06C173B05E3 + + + + ]]> +

The challenger MAY decide the client has passed a challenge even if the responses are not all perfectly correct.

+ + + + +

This section shows how challenges SHOULD be combined with the existing registration protocol according to the rules defined in the Extensibility section of In-Band Registration. Note: The <challenge/> wrapper element is not required.

+ + + + ]]> +

Note that the challenge form MUST be inside the &QUERY; element, and the server's challenge ID is specified within the form:

+ + + + + http://jabber.org/protocol/challenge + + F3A6292C + 3 + + + http://www.victim.com/challenges/ocr.jpeg?F3A6292C + + + + + + + + + + + + To register, visit http://www.victim.com/register.html + + + http://www.victim.com/register.html + + + + ]]> + +

The server MAY include an <instructions/> element and a URL using Out-of-Band Data (e.g., a web page) in the &QUERY; element (see example above). In-Band Registration recommends that the challenger SHOULD submit the completed x:data form, however if it does not understand the form, then it MAY present the instructions and the included URL to the user instead of providing the required information in-band.

+ + + + + http://jabber.org/protocol/challenge + + F3A6292C + 3 + 7nHL3 + bill + Calliope + + + + ]]> + + + + +

Entities MUST address the needs of disabled people and CPU-constrained clients by offering people a reasonable choice of different types of challenges.

+

Desktop clients running on modern PCs will typically be configured to automatically perform a specified 'SHA-256' Hashcash challenge (see below) whenever it is below a certain level of difficulty, with the result that many people may not even notice challenges most of the time. However, people using CPU-constrained clients (e.g. Web or mobile clients) would notice the performance hit. They might prefer to take a CAPTCHA challenge instead. A CPU-constrained client could ask a faster computer (its server, for example) to perform a Hashcash challenge for it.

+

Visually disabled people using a CPU-constrained client could configure their client to always present them with an audio CAPTCHA challenge.

+

Most of the challenges below are language sensitive. However, the evaluation of the OCR and Hashcash responses does not depend on the language the client is using.

+

Challenge types are distinguished by the 'var' attribute of each <field/> element. Several types of challenges are described below. More challenges MAY be documented elsewhere and registered with the ®ISTRAR; (see Field Standardization).

+ + +

The SHA-256 Hashcash challenge is transparent to average PC users. It is indicated when the value of the 'var' attribute is 'SHA-256'. It forces clients to perform CPU-intensive work, making it difficult to send large amounts of SPIM. This significantly reduces SPIM, but alone it will not completely stop SPIM being sent through large collections of 'zombie' computers. The hope is that the extra CPU usage will often be noticed by the owners of the zombie machines, who will be more likely to fix them.

+

The challenger MUST set the 'label' attribute of the <field/> element to a hexadecimal random number containing a configured number of bits (220 ≤ label < 221, for example).

+

To pass the test, the client MUST return a text string that starts with the JID the client sent the first stanza to (i.e., the stanza that triggered the challenge). The least significant bits of the SHA-256 hash (see &nistfips180-2;) of the string MUST equal the hexadecimal value specified by the challenger (in the 'label' attribute of the <field/> element). For example, if the 'label' attribute is the 20-bit value 'e03d7' then the following string would be correct:

+ innocent@victim.com2450F06C173B05E3 +

Note: When configuring the number of bits to be specified by a challenger in the 'label' attribute values, administrators MUST balance the need to make mass SPIM as difficult as possible, with the inconvenience that may be caused to the users of less powerful computers. (Most clients will be challenged only very occasionally, so the consumption of 70% of a typical desktop CPU for 4 seconds might be considered appropriate.) Administrators SHOULD increment the configured number of bits from time to time to match increases in the performance of typical desktop PCs. If an administrator notices that SPIM robots never attempt the Hashcash challenge, then he SHOULD consider reducing the number of bits, to avoid inconveniencing people unnecessarily.

+ + +

For those CAPTCHA types where generic instructions are possible (see table below) then the <field/> element SHOULD NOT include a 'label' attribute (the client MUST present generic instructions to its user in the language of its user interface). Otherwise the 'label' attribute SHOULD ask a specific question in the language indicated by the 'xml:lang' attribute of the challenge stanza.

+

If a media type is specified (see table below) then the <field/> element MUST contain a <media/> element that includes a <uri/> element of that type. Clients that support the CAPTCHA type MUST be able to play or render the specified MIME-types (see table below). They MAY also support other formats. Audio CAPTCHAs typically require challengers to provide at least the 'audio/x-wav' MIME-type (with the PCM codec) because more efficient patent-free formats are often not supported by constrained clients. It is RECOMMENDED that challengers provide more compact formats (like Ogg Speex or MP3) too.

+

The 'type' attribute of the <field/> element SHOULD be 'text-single', 'text-private', or 'text-multi' (if no 'type' is specified, the default is 'text-single'). The 'boolean' and 'list-single' field types would make it trivial for a robot to provide a correct response at least some of the time. The response MUST be provided in the language specified by the 'xml:lang' attribute of the challenge stanza.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
'var'NameMedia typeMIME-type'label'Example generic instructions
ocr*Optical Character Recognitionimageimage/jpegNoEnter the code you see
picture_recogPicture Recognitionimageimage/jpegNoDescribe the picture
video_recogVideo Recognitionvideovideo/mpegNoDescribe the video
speech_recogSpeech Recognitionaudioaudio/x-wavNoEnter the words you hear
audio_recogAudio Recognitionaudioaudio/x-wavNoDescribe the sound you hear
picture_qPicture Questionimageimage/jpegNoAnswer the question you see
video_qVideo Questionvideovideo/mpegNoAnswer the question in the video
speech_qSpeech Questionaudioaudio/x-wavNoAnswer the question you hear
qaText Question and Answer--Yes**-
+

* The image portrays random characters that humans can read but OCR software cannot. See PWNtcha <http://sam.zoy.org/pwntcha/> for some example OCR CAPTCHA images. To pass the challenge, the user must simply type the characters. The correct answer SHOULD NOT depend on the language specified by the 'xml:lang' attribute of the challenge stanza.

+

** To pass the challenge, the user must type the answer to the question in the 'label' attribute.

+

Note: It may be profitable to send SPIM even if less than one percent of CAPTCHA responses are successful. The effectiveness of a CAPTCHA challenge needs to be close to perfect, unless it is used in combination with other anti-SPIM techniques.

+ + + + +

An challenger MAY provide a text question in the &BODY; element of a challenge stanza for clients that do not support challenge forms. Entities that cannot serve Out-of-Band Data URLs MAY use this option to challenge legacy clients.

+ +

Note: Robots always attempt the easiest challenge they are offered. So the question MUST be at least as difficult for a robot as the challenge form.

+

Note: Even if it provides a text question in the &BODY; element, a challenger MUST always provide a challenge form.

+ + Your messages to me are being blocked. To unblock them, + reply with the color of a stop light followed by 'F3A6292C'. + + + + http://jabber.org/protocol/challenge + + innocent@victim.com + spam1 + + + + + + ]]> +

Legacy clients respond to the challenger using a &MESSAGE; stanza (not an &IQ;).

+ + red F3A6292C + + ]]> +

The challenger SHOULD treat the stanza as a normal message (instead of as a response to its challenge) if the legacy client either takes too long to submit it or has already responded to the challenge. The challenger MAY treat the response as a normal message even in cases where the challenge became unnecessary while the challenger was waiting for the response.

+

Otherwise the challenger MUST report the result of the challenge to the legacy client using a &MESSAGE; stanza (not an &IQ;).

+ + Your message was delivered. Your messages + to me are no longer being blocked. + + ]]> + + + + + Your message to me was not delivered. + + + + ]]> + + + +

It is RECOMMENDED that entities employ other techniques to combat SPIM in addition to those described in this document. The expectation is that this protocol will be an important and successful tool for discouraging SPIM. However, much of its success is dependent on the quality of the CAPTCHAs employed by a particular implementation.

+

The administrator of a challenger MUST discontinue the use of Robot Challenges under the following circumstances:

+
    +
  • If he realises that the challenger's challenges are largely ineffective in combating SPIM, and that the reduction in SPIM does not compensate for the inconvenience to humans of responding to the challenger's challenges.
    • +
  • If other, more transparent, techniques being employed by the challenger are so successful that challenges are offering only negligible additional protection against SPIM.
    • +
  • If the challenger needs no protection at all because it receives only a negligible amount of SPIM.
    • +
+ + + +

This JEP introduces no security considerations above and beyond those described in RFC 3920 and RFC 3921.

+ + + +

This JEP requires no interaction with &IANA;.

+ + + + +

Upon approval of this JEP, the ®ISTRAR; shall register the following protocol namespaces:

+
    +
  • http://jabber.org/protocol/challenge
    • +
  • http://jabber.org/protocol/media
    • +
+ + + +

Upon approval of this JEP, the Jabber Registrar shall register the following new FORM_TYPE. Additional fields will be defined in future submissions.

+ + http://jabber.org/protocol/challenge + JEP-0158 + forms enabling robot challenges + + + + + + + + + + + + + + + + ]]> + + +

Upon approval of this JEP, the Jabber Registrar shall register the following new fields for the existing jabber:iq:register FORM_TYPE. Additional fields will be defined in future submissions.

+ + jabber:iq:register + JEP-0077 + + + + + + + + + + + + + + ]]> + + + + + + + + + + + + + + + + + + + + ]]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + + + +

Another protocol could allow users to edit the challenges their server will make on their behalf. For example, the number of SHA-256 bits, a personal or original question and answer, a picture, a video, or a sound recording... Of course Aunt Tillie would typically only use this feature if she was plagued by SPIM.

+ + diff --git a/xep-0159.xml b/xep-0159.xml new file mode 100644 index 00000000..802c0a18 --- /dev/null +++ b/xep-0159.xml @@ -0,0 +1,236 @@ + + +%ents; +]> + + +
+ SPIM-Blocking Control + This JEP allows clients to control how their servers may block SPIM that is addressed to them. It specifies a default privacy list fall-through action. + &LEGALNOTICE; + 0159 + Deferred + Standards Track + Standards JIG + + XMPP Core + XMPP IM + JEP-0030 + + None + None + spim-control + &ianpaterson; + + 0.1 + 2005-09-14 + ip + Initial JEP version. + + + 0.0.1 + 2005-09-08 + ip + First draft. + +
+ + + +

The appearance of large public IM services based on &rfc3920; and &rfc3921; created an urgent need to implement protocols that discourage the sending of large quantities of IM SPAM (SPIM) from XMPP clients (connected to legitimate servers) and XMPP servers (with virtual clients) -- all hosted on networks of 'zombie' machines. SPIM is defined here as any type of unsolicited XMPP stanza sent by a 'robot' and delivered to a human, including messages and subscription requests. SPIM has the potential to disrupt people even more than SPAM, because each message interrupts the receiver (humans typically filter SPAM in batch mode).

+

SPIM blocking is more efficiently performed on the receiving server for several reasons:

+
    +
  • The sending server may be controlled by the SPIMer.
    • +
  • Client implementations are simplified.
    • +
  • Client-to-server bandwidth is saved.
    • +
  • Consistency with the stanza blocking protocol specified by RFC 3921.
    • +
  • The use of interactive SPIM recognition techniques (like &jep0158;) does not leak information about the destination client's presence.
    • +
  • If the destination client is not online when the stanza is sent, then all SPIM would need to be stored by the server until the user comes back online to decide if it is SPIM.
    • +
  • Furthermore, if the sending client is no longer online when the stanza is received, then it would not be possible for the receiving client to use interactive SPIM recognition techniques.
    • +
+

However, no automated SPIM recognition techniques work perfectly all the time. This document is designed to give users control over the SPIM recognition their servers perform on their behalf.

+ + +

Clients should be able to:

+
    +
  • disable SPIM recognition for senders that have been falsely identified as SPIMers
    • +
  • stop SPIM from senders that SPIM recognition is failing to block
    • +
  • exempt from SPIM recognition stanzas sent by: +
      +
    • specific users
      • +
    • users of specific domains
      • +
    • members of specific roster groups
      • +
    • presence subscribers
      • +
    +
    • +
  • rely on the server to automatically exempt from SPIM recognition stanzas sent by other existing correspondents
    • +
+ + +

The stanza blocking protocol defined in RFC 3921 allows a client to control explicitly which senders its server must block stanzas from. Such explicit blocking is suitable for privacy control, but not for filtering SPIM.

+

This document contradicts an assumption expressed in the standard blocking protocol in order to extend client control to SPIM blocking. More specifically, it simply defines a SPIM recognition privacy-list fall-through action that is different from the 'allow' default assumed in RFC 3921. The language used in RFC 3921 Section 10.2 Rule 7 appears to be deliberately vague (informative rather than normative) in order to permit other default fall-through actions. The protocol defined in this document is therefore (arguably) compatible with RFC 3921.

+ + +

The various SPIM recognition procedures that may be employed by the server are beyond the scope of this document. No single measure can differentiate all SPIM perfectly. It is RECOMMENDED that servers implement a combination of complementary SPIM recognition techniques (and other anti-SPIM techniques Other examples of anti-SPIM policies and protocols include: requiring a user to pass a robot challenge before registering a new account, invite-only and/or out-of-band user account registration, providing a standard protocol for reporting SPIM to both the servers involved, server-to-server connection dialback, karma (client-to-server and server-to-server), legal agreements not to send SPIM during user account registration, and IP blocking.).

+

For example, a server could employ traffic and reputation analysis to filter the majority of SPIM, and use Robot Challenges to identify the remainder (feeding what it learns back to the traffic and reputation analysis).

+ + + + +

A client MAY confirm that its server supports SPIM-Blocking Control using &jep0030;.

+ + + + ]]> + + + + ... + + ... + + + ]]> + + + +

This section specifies server functionality not defined in RFC 3921.

+ +

A server that supports this protocol MAY maintain a separate If the server were to maintain a single unified list of the correspondents of all its users, then SPIMers would only need to pass a single SPIM recognition test before being allowed to send SPIM to all the server's users. list of each user's correspondents. Each list contains all the bare JIDs the user has either sent a stanza to or received a stanza from (over the past few weeks or months).

+

Note: When it blocks a stanza, the server MUST NOT add the 'from' attribute of the stanza to the correspondents list.

+

Note: The lists of correspondents have a very different function from rosters. Edits are initiated by the server not the client, allowing the lists to be completely transparent to clients.

+ + +

The server SHOULD perform the following procedures whenever it receives a stanza that falls through the active privacy list of the user it is addressed to without being either allowed or denied:

+
    +
  1. If the server maintains correspondents lists, and if the bare JID in the 'from' attribute of the received stanza is on the addressed user's correspondents list, then the server SHOULD allow the stanza to be delivered to the user.
    2. +
  2. Otherwise, the server SHOULD perform one or more SPIM recognition procedures (not defined in this document).
    3. +
  3. Depending on the result of those procedures, it SHOULD then either allow, deny or delay the delivery of the stanza without informing the sender.
    4. +
+ + +

When a SPIM recognition procedure delays delivery of a stanza the server SHOULD store it temporarily.

+

While delivery is being delayed:

+
    +
  • The server SHOULD allow or deny delivery of the stanza immediately (and without informing the sender) when any subsequent changes to the user's privacy list, correspondents list or roster explicitly either allow or deny the delivery of the stanza. For example, the first time a stanza is delivered the correspondents list will change, typically triggering the immediate delivery of any other delayed stanzas.
    • +
  • The server MAY allow or deny delivery of the stanza at any time (for reasons not defined in this document).
    • +
+

Once delivery of a stanza has been delayed for an implementation-specific length of time, or an implementation-specific number of stanzas from the same sender (or same sending server) are being delayed, the server SHOULD deny delivery of the stanza without informing the sender.

+

A good example of a delayed SPIM recognition procedure is when servers use the Robot Challenges protocol to confirm whether or not a client is a SPIM robot before denying or allowing the delivery of a stanza from a new correspondent. The very occasional inconvenience of responding to a challenge is small and perfectly acceptable -- especially when compared to the countless robot-generated interruptions people might otherwise have to filter every day. If a human user fails such a robot challenge then his client SHOULD give him the option to resend the stanza immediately.

+ + + + +

This informative section requires no client or server functionality beyond that defined in RFC 3921.

+ + +

The client SHOULD use the 'subscription' type to exclude all JIDs on the user's roster from SPIM blocking (see the items with order 20, 30 and 40 in the example below).

+ + +

At least in the medium term, clients that use non-XMPP protocols cannot be expected to support interactive SPIM recognition techniques (like Robot Challenges). So, if its server uses interactive techniques, the client MAY use the 'jid' type to ensure its server does not block stanzas arriving from the transports the user has registered with (see the item with order 50 in the example below).

+ + +

If a user believes SPIM will not be sent by users of a particular server (e.g. the user's own corporate server), then the client MAY use the 'jid' type to exclude all these users from SPIM blocking (see the item with order 60 in the example below).

+ + + + + ... + + + + ... + + ... + + ... + + + + ]]> + + + +

No SPIM recognition techniques are perfect. Senders are sometimes falsely identified as SPIM bots. (For example, when a server sends Robot Challenges, but the client does not support that protocol.)

+

In these cases the user MAY ask out-of-band the person he is trying to communicate with to allow communications in one of the following ways:

+
    +
  • simply send him a message, so her server adds him to her correspondents list
    • +
  • add his JID to her active privacy list with action='allow'
    • +
  • add him to her roster (either in a group whose stanzas are allowed in her active privacy list, or with a subscription type that is allowed The subscription type SHOULD never be 'none' because RFC 3921 specifies that, for the purposes of blocking, all JIDs not on the roster also have the subscription type 'none'.)
    • +
+ + + +

If stanzas from a SPIM robot running on a zombie domain somehow manage to get past the server's SPIM recognition then the client MAY use the 'jid' type to block one or all JIDs from the domain. (RFC 3921 already enables this functionality.)

+ + + + ... + + ... + + + + ]]> + + + +

A client MAY disable server-side SPIM blocking by ensuring the default fall-through action is never applied. It does this simply by including an explicit fall-through item in its active privacy list.

+ + + + ... + + + + + ]]> +

Note: Before a server with existing accounts deploys this protocol, it MAY ensure all users' privacy lists have an explicit fall-through item. As a result, SPIM recognition would be disabled until users choose to switch it on.

+ + + + +

If a server implements this protocol and its security is compromised, then the attacker may be able to access the list of all previous correspondants for every user. People are unable to delete their own lists and they may not even be aware that they exist. So servers MUST ensure they protect this sensitive information very carefully.

+ + + +

This JEP requires no interaction with &IANA;.

+ + + + +

Upon approval of this JEP, the Jabber Registrar shall register the following well-known Service Discovery node:

+
    +
  • http://jabber.org/protocol/spim-control
    • +
+ + + diff --git a/xep-0160.xml b/xep-0160.xml new file mode 100644 index 00000000..94f8f9eb --- /dev/null +++ b/xep-0160.xml @@ -0,0 +1,130 @@ + + +%ents; +]> + + +
+ Best Practices for Handling Offline Messages + This document specifies best practices to be followed by Jabber/XMPP servers in handling messages sent to recipients who are offline. + &LEGALNOTICE; + 0160 + Active + Informational + Standards JIG + Council + + XMPP Core + XMPP IM + JEP-0030 + + + + msgoffline + &stpeter; + + 1.0 + 2006-01-24 + psa + Per a vote of the Jabber Council, advanced status to Active. + + + 0.2 + 2005-11-15 + psa + Added section on handling of each message type. + + + 0.1 + 2005-10-05 + psa + Initial JEP version. + + + 0.0.1 + 2005-09-27 + psa + First draft. + +
+ +

&rfc3920; and &rfc3921; specify general rules for handling XML stanzas, but explicitly do not address how to handle message stanzas sent to recipients (e.g., IM users or other nodes) that are offline, except to say that a server MUST return a &unavailable; error if offline message storage or message forwarding is not enabled (see Section 11.1 of RFC 3921). This document fills the gap by specifying best practices for storage and delivery of so-called "offline messages".

+ + +

The RECOMMENDED process flow is as follows:

+
    +
  1. Sender generates XMPP message stanza This JEP does not discuss IQ or presence stanzas, handling of which is described in RFC 3920 and RFC 3921. for delivery to a recipient such as an IM user or other node, where the 'to' address is of the form <node@domain> or <node@domain/resource> (see RFC 3921 for rules regarding server handling of such XMPP message stanzas).
    2. +
  2. Recipient's server determines that the intended recipient has no available resources that have specified non-negative presence priority. As specified in RFC 3920, available resources that have specified a negative presence priority shall never receive message stanzas addressed to <node@domain>.
    3. +
  3. Recipient's server does not return a &unavailable; error but instead stores the message stanza for later delivery.
    4. +
  4. When the recipient next sends non-negative available presence to the server, the server delivers the message to the resource that has sent that presence. (Alternatively, the server may support &jep0013;, although that functionality is not described herein.)
    5. +
+

This flow is described more fully below.

+

First, the sender (in this example, romeo@montague.net) sends a message to an intended recipient (juliet@capulet.com).

+ + + O blessed, blessed night! I am afeard. + Being in night, all this is but a dream, + Too flattering-sweet to be substantial. + + + ]]> +

Next, the recipient's server determines if there are any available resources that have sent non-negative presence priority. If there are, the server immediately delivers the message stanza to the resource that it determines to be most available (based on its own algorithm). If there are not, the server stores the message for later delivery.

+

Now the recipient authenticates with the server and sends initial presence (with a non-negative priority) to the server.

+ + 1 + + ]]> +

The recipient's server now delivers the offline message to that resource (it is RECOMMENDED for the server to add a &jep0091; extension to indicate that the message was stored offline).

+ + + O blessed, blessed night! I am afeard. + Being in night, all this is but a dream, + Too flattering-sweet to be substantial. + + + Offline Storage + + + ]]> + + +

Message stanzas SHOULD be handled by a server as follows (based on the values of the 'type' attribute specified in RFC 3921):

+
    +

  • normal -- Messages with a 'type' attribute whose value is "normal" (or messages with no 'type' attribute) SHOULD be stored offline.

    • +

  • chat -- Messages with a 'type' attribute whose value is "chat" SHOULD be stored offline, with the exception of messages that contain only &jep0085; content (such messages SHOULD NOT be stored offline).

    • +

  • groupchat -- Messages with a 'type' attribute whose value is "groupchat" SHOULD NOT be stored offline, since by definition a user without online presence cannot be in a &jep0045; room.

    • +

  • headline -- Messages with a 'type' attribute whose value is "headline" SHOULD NOT be stored offline, since such messages are usually time-sensitive.

    • +

  • error -- Messages with a 'type' attribute whose value is "error" SHOULD NOT be stored offline, although a server MAY store &jep0079; error messages offline.

    • +
+ + +

If a server supports offline message handling as described herein, it SHOULD return a "msgoffline" feature in response to &jep0030; information requests:

+ + + + ]]> + + + ... + + + + ]]> + + +

A message stored offline may not be readable by the recipient if the message was encrypted using a session-based encryption method such as &jep0116; or if the key used in object encryption is revoked after the message was sent but before it is read.

+

In certain countries, offline storage of message stanzas may introduce legal requirements or privacy vulnerabilities that do not apply to messages that are delivered immediately and never stored on an intermediate server.

+ + +

This JEP requires no interaction with &IANA;.

+ + +

The ®ISTRAR; includes "msgoffline" in its registry of service discovery features (see &DISCOFEATURES;).

+ + diff --git a/xep-0161.xml b/xep-0161.xml new file mode 100644 index 00000000..82aaf0be --- /dev/null +++ b/xep-0161.xml @@ -0,0 +1,227 @@ + + +%ents; +]> + + +
+ SPIM Reporting + This document specifies an XMPP protocol extension for reporting unsolicited bulk instant messages (SPIM). + &LEGALNOTICE; + 0161 + Experimental + Standards Track + Standards JIG + Council + + XMPP Core + XMPP IM + JEP-0030 + + + + spimreport + &stpeter; + + 0.2 + 2006-09-21 + psa +

Modified business rules; added security considerations; defined XML schema.

 + + + 0.1 + 2005-10-19 + psa +

Initial JEP version.

 + + + 0.0.1 + 2005-09-28 + psa +

First draft.

 + +
+ +

Unsolicited bulk email, commonly called "spam", is a widespread problem on today's email network. We want to make sure that unsolicited bulk instant messaging, commonly called "SPIM" (short for "spam over IM"), does not become a widespread problem on the XMPP instant messaging network. To that end, this document specifies a protocol for reporting particular instances of SPIM.

+ + + +

The protocol for SPIM reporting is quite simple: wrap the complete SPIM stanza in a <spim/> element qualified by the 'http://jabber.org/protocol/spimreport' namespace and send an IQ stanza of type "set" to the entity that shall receive the report. This protocol is intended to be used by recipients of SPIM stanzas and by other entities (e.g., servers or services) that wish to pass around SPIM reports. The following is an example:

+ + + You too can be rich! Find out how at + http://spimmersheaven.info/makemoney + Let's chat to make your dreams + come true! + + + ]]> + + + + + You too can be rich! Find out how at + http://spimmersheaven.info/makemoney + Let's chat to make your dreams + come true! + + + + + ]]> +

If the entity that receives the report does not support the SPIM Reporting protocol, it MUST return a &unavailable; error to the reporting entity:

+ + + + + You too can be rich! Find out how at + http://spimmersheaven.info/makemoney + Let's chat to make your dreams + come true! + + + + + + + + ]]> +

If the entity that receives the report is able to process the report, it MUST return an IQ-result to the reporting entity:

+ + ]]> + + +

If an entity that processes SPIM reports determines that the suspected spimmer is indeed an actual spimmer, it SHOULD report its conclusions to appropriate other entities (e.g., the spimmer's server or dedicated SPIM reporting services). Here again, the protocol is quite simple: wrap the spimmer's JID in a <spimmer/> element qualified by the 'http://jabber.org/protocol/spimreport' namespace and send an IQ stanza of type "set" to the entity that shall receive the report. This protocol SHOULD NOT be used by recipients of SPIM stanzas. The following is an example:

+ + makemoney@spimmersheaven.info + + ]]> + + + +

The following rules and guidelines apply to the act of reporting SPIM.

+
    +

  1. The recipient SHOULD NOT report the SPIM stanza to a server or service until it determines that the server or service supports the SPIM Reporting protocol (see the Discovering Support section of this document).

    2. +

  2. If the recipient's home server (i.e., the server with which it has a registered account or other trust relationship) supports the SPIM Reporting protocol, the recipient SHOULD report the offending stanza to its own server only.

    3. +

  3. If the recipient's home server does not support the SPIM Reporting protocol, the recipient SHOULD report the SPIM stanza to one or more dedicated SPIM reporting services if available.

    4. +

  4. The recipient MAY report the SPIM stanza to the suspected spimmer's server (but see the Security Considerations section of this document).

    5. +

  5. The recipient SHOULD NOT report the SPIM stanza to the suspected spimmer.

    6. +
+ + + +

The following rules and guidelines apply to initial processing of a SPIM report.

+
    +
  1. Before processing the report, the processor MAY respond to the report by sending a challenge to the sender (e.g., using &jep0158;) in order to make sure that the sender is not sending spurious reports or otherwise abusing the SPIM reporting system.
    2. +
  2. The processor MUST add the report to a list or database of pending SPIM reports.
    3. +
  3. If the suspected spimmer is not already on the processor's list of known spimmers, the processor SHOULD use the report in determining whether the suspected spimmer is an actual spimmer (see next section).
    4. +
  4. The processor MAY report the SPIM stanza to one or more dedicated SPIM reporting services if available.
    5. +
  5. The processor MAY report the SPIM stanza to other servers it trusts.
    6. +
  6. The processor MAY report the SPIM stanza to the suspected spimmer's server.
    7. +
  7. The processor SHOULD NOT report the SPIM stanza to the suspected spimmer.
    8. +
+ + +

Not all SPIM reports are valid, and not all JIDs that send stanzas reported as SPIM are spimmers. Care must be taken in correctly determining if a suspected spimmer is an actual spimmer. The following rules apply:

+
    +

  1. The processor SHOULD NOT add a suspected spimmer to its list of known spimmers until it has received at least three (3) valid SPIM reports with regard to that suspected spimmer.

    2. +

  2. If the processor determines that the suspected spimmer is an actual spimmer, the processor:

    +
      +
    1. MUST add that JID to its list of known spimmers.
      2. +
    2. SHOULD send a spimmer report to the spimmer's server.
      3. +
    3. MAY send a spimmer report to SPIM reporting services or reputation services.
      4. +
    4. MAY send a spimmer report to other servers it trusts.
      5. +
    5. SHOULD NOT send a spimmer report to the spimmer.
      6. +
    +
    3. +
+ + + +

In order to discover whether another entity supports SPIM reporting, &jep0030; SHOULD be used. If an entity supports SPIM reporting, it MUST return a feature of "http://jabber.org/protocol/spimreport" in responses to service discovery information requests, as shown in the following examples:

+ + + + ]]> + + + ... + + ... + + + ]]> + + +

Not all reported SPIM is actual SPIM, and not all reported spimmers are actual spimmers. Processors must take care to ensure that processing of one or a few reports do not result in branding of a legitimate sender as a spimmer, since otherwise the sender could effectively be the subject of a denial of service attack.

+

Client recipients are discouraged from sending SPIM reports to the servers of suspected spimmers, since the sending server itself could be a rogue domain that could send SPIM from any JID at that domain.

+ + +

This document requires no interaction with &IANA;.

+ + +

The ®ISTRAR; shall add 'http://jabber.org/protocol/spimreport' to its registry of protocol namespaces.

+ + + + + + + + + + + + + + + + + + + + + ]]> + + diff --git a/xep-0162.xml b/xep-0162.xml new file mode 100644 index 00000000..6f2ff4b3 --- /dev/null +++ b/xep-0162.xml @@ -0,0 +1,192 @@ + + +%ents; +]> + + +
+ Best Practices for Roster and Subscription Management + This document specifies best practices for roster and subscription management in Jabber/XMPP clients. + &LEGALNOTICE; + 0162 + Deferred + Informational + None + None + None + Standards JIG + + Lucas + Nussbaum + lucas@lucas-nussbaum.net + lucas@nussbaum.fr + + N/A + + 0.2 + 2005-12-06 + lnu + Added a note about the name of the Hidden group. Clarified which items should be displayed. + + + 0.1 + 2005-10-19 + lnu + Initial JEP version. + + + 0.0.3 + 2005-10-18 + lnu + Added a remark about "Remove" vs "Block" in other IM systems. + + + 0.0.2 + 2005-10-07 + lnu + Integrated some feedback for standards-jig. + + + 0.0.1 + 2005-10-04 + lnu + First draft. + +
+ + + + +

&rfc3921; explains how subscriptions and rosters integrate. However, + several points are left to the client author's discretion, and this can lead + to some confusion among client developers. This JEP specifies best practices + that enable all Jabber clients to manage subscriptions and roster in a coherent + way, thus making sure that such clients will not surprise end users with + unexpected behavior.

+ + + + + +

As defined in RFC 3921 (sections 6, 7, 8), a roster item can have one + of the following subscription states:

+ +
    + +
  • subscription='none': you aren't interested in the item's + presence, and neither is the item interested in yours.
    • + +
  • subscription='from': the item is interested in your + presence information, but you don't care about the contact. (You must + be somebody important! ;)
    • + +
  • subscription='to': You are interested in the item's + presence information, but the contact is not interested in + yours.
    • + +
  • subscription='both': You and the contact are interested in each other's presence information.
    • + +
+ +

Additionally, if subscription='from' or + subscription='none', you can have ask='suscribe', which + means you sent a subscription request to the item but haven't received an + answer yet.

+ + + + + + +

It is necessary to distinguish two things:

+
    +
  • Removal from the user's roster (does the user's roster include an entry + for this JID?) ;
    • +
  • Removal of presence subscription (cancellation of subscription).
    • +
+

Three problems have to be taken into consideration here:

+
    + +
  • Removing an item from your roster (i.e., performing a roster set with subscription='remove') cancels all subscriptions (both from + the item and to the item).
    • + +
  • The fact that a user is no longer interested in the contact's + presence doesn't mean that the contaccontact is no longer interested in the + user's presence.
    • + +
  • This is complex, and should be presented in a simple way to the + user.
    • + +
+ +

Therefore, the following behavior is RECOMMENDED for Jabber clients:

+ +
    +

  1. When the user asks for the removal of an item with + subscription='both', the Jabber client SHOULD ask the user whether + he wants to revoke the contact's authorization to see the user's presence + too. This action SHOULD be called "Remove" since this is the convention used + by other IM systems.

    2. +
  2. +

    The Jabber client SHOULD NOT remove the contact from the roster. There + are two exceptions:

    +
      +

    1. The Jabber client MAY remove the contact from the roster if the user + explicitely asked (so the user has to be informed he might remove both + presence subscriptions).

      2. +

    2. The jabber client MAY transparently remove the contact from the roster if + the user asked to, and if subscription='none' or + subscription='to'.

      3. +
    +
    3. +
+ +

In addition to the "Remove" action described above, the client MAY + provide a way to revoke the contact's subscription to the user's presence. + This action, if provided, SHOULD be called "Block" since this is the + convention used by other IM networks.

+ + + + +

Defining a sensible roster policy is difficult, because many users have different, special needs. We have to ensure that:

+
    +
  • Most contacts that everybody wants to hide are hidden.
    • +
  • No contact that someone wants to see is hidden.
    • +
+ +

The user's roster contains both contacts of interest for the user + (contacts with subscription='both' or subscription='to') and contacts which + are only interested in receiving the user's presence information. Also, the + user might be interested in having some contacts even with + subscription='none', because he often send messages to them but isn't + interested in their presence.

+ + +

Therefore, the following types of contacts SHOULD be displayed by clients:

+
    +
  • items with subscription='both' or subscription='to' ;
    • +
  • items with subscription='none' or subscription='from' and ask='subscribe'. It is ((subscription='none' or subscription='from') and ask='subscribe') ;
    • +
  • items with subscription='none' or subscription='from' which have a 'name' attribute or a 'group' child set. It is ((subscription='none' or subscription='from') and (name attribute or group child)).
    • +
+ +

The client MAY display contacts with subscription='from' which don't match + one of the above cases in an additional 'Observers' group. If no 'Observers' group is + used, the client SHOULD NOT display contacts which don't match one of the + above rules.

+ +

Some users give nicknames to contacts they do not want to see, to be able to remember who they are when cleaning the roster. An additional 'Hidden' group MAY be used to handle such contacts. The client SHOULD NOT display contacts if one of their groups is the 'Hidden' group. (This mean that if contact 'C' is in groups 'G' and 'Hidden', 'C' should never be displayed, even in group 'G'.)

+ + + +

The name of the 'Hidden' group can be managed in two different ways :

+
    +
  • It could always be named 'Hidden' but be displayed translated by the client ;
    • +
  • It could be named as the user wants. Its name could then be stored using jabber:iq:private, like the delimiter for nested groups in &jep0083;.
    • +
+

This is left as an open issue since no clients (to the author's knowledge) implement this 'Hidden' group. But the preference should go to the first solution, which avoids relying on &jep0049;.

+ + + + diff --git a/xep-0163.xml b/xep-0163.xml new file mode 100644 index 00000000..edc9d9f7 --- /dev/null +++ b/xep-0163.xml @@ -0,0 +1,767 @@ + + +%ents; +]> + + +
+ Personal Eventing via Pubsub + This document specifies XMPP semantics for using the publish-subscribe protocol to broadcast state change events associated with an instant messaging and presence account. + &LEGALNOTICE; + 0163 + Draft + Standards Track + Standards JIG + Council + + XMPP Core + XMPP IM + JEP-0030 + JEP-0060 + JEP-0115 + + + + pep + &stpeter; + + Kevin + Smith + kevin@kismith.co.uk + kevdadrum@jabber.ex.ac.uk + + + 1.0 + 2006-09-20 + psa +

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

 + + + 0.15 + 2006-08-30 + psa +

Added the deliver_notifications and send_last_published_item configuration options to the recommended defaults.

 + + + 0.14 + 2006-08-02 + psa +

Changed various recommended defaults from SHOULD to MUST; corrected several errors in the text and examples.

 + + + 0.13 + 2006-08-01 + psa +

Recommended node creation with default configuration on initial publish; corrected several errors and clarified several points in the text.

 + + + 0.12 + 2006-08-01 + psa +

Simplified the subscription process using XMPP presence and entity capabilities.

 + + + 0.11 + 2006-07-20 + psa +

Clarified rules regarding number of notifications and when to generate notifications; corrected several errors in the text and examples.

 + + + 0.10 + 2006-07-07 + psa +

Updated to reflect version 1.8 of JEP-0060.

 + + + 0.9 + 2006-06-15 + psa +

Updated to reflect use of data forms in JEP-0060.

 + + + 0.8 + 2006-04-10 + psa +

Clarified terminology and defaults.

 + + + 0.7 + 2006-04-10 + psa +

Specified that notifications are to be sent from bare JID, not full JID.

 + + + 0.6 + 2006-04-10 + psa +

Updated to reflect pubsub changes; clarified business rules for generation of notifications and cancellation of subscriptions.

 + + + 0.5 + 2006-03-09 + psa +

Modified roster groups example to use jabber:x:data; added note about advertising client support for PEP.

 + + + 0.4 + 2006-02-02 + psa/ks +

Specified rules for generation of notifications, including use of presence in determining address of intended recipient for notifications and sending of last published item on receipt of presence information; changed name to Personal Eventing Protocol; specified service discovery identity of pubsub/pep; removed section on service types; added Kevin Smith as co-author.

 + + + 0.3 + 2006-01-30 + psa +

Specified that a service may enforce additional privacy and security policies; specified that an account owner must always be allowed to subscribe and to retrieve items; specified that an implementation should enforce access modifications resulting from roster state changes.

 + + + 0.2 + 2006-01-11 + psa +

Updated to reflect proposed JEP-0060 modifications.

 + + + 0.1 + 2005-11-02 + psa +

Initial JEP version.

 + + + 0.0.2 + 2005-10-25 + psa +

Added more details and examples.

 + + + 0.0.1 + 2005-10-24 + psa +

First draft.

 + +
+ + +

The XMPP &jep0060; extension ("pubsub") can be used to broadcast state change events associated with a Jabber/XMPP account or user, such as those described in &jep0080;, &jep0107;, &jep0108;, and &jep0118;. Currently, many "extended presence" formats are sent using the &PRESENCE; stanza type; however, this overloads presence, results in unnecessary presence traffic, and does not provide fine-grained control over access. The use of publish-subscribe rather than presence is therefore preferable. However, the full, generic pubsub protocol is often thought of as complicated and therefore has not been widely implemented. To make publish-subscribe functionality more accessible (especially to instant messaging and presence applications that conform to &xmppim;), this document defines simplified protocol semantics that can be followed by instant messaging client and server developers, hopefully resulting in the deployment of personal eventing services across the Jabber/XMPP network.

+

Note: This document does not show error flows related to the various publish-subscribe use cases referenced herein, since they are exhaustively defined in JEP-0060. The reader is referred to JEP-0060 for all relevant protocol details related to the XMPP publish-subscribe extension.

+ + + +

Personal eventing via pubsub ("PEP") is based on six principles:

+
    +
  1. Every account a pubsub service.
    2. +
  2. One publisher per node.
    3. +
  3. One node per namespace.
    4. +
  4. Use presence.
    5. +
  5. Notifications are filtered based on expressed interests.
    6. +
  6. Smart defaults.
    7. +
+

These principles are described more fully below.

+ +

When a user creates an account (or has an account provisioned) at a Jabber/XMPP server that supports PEP, the server associates a virtual pubsub service with the account. This greatly simplifies the task of discovering the account owner's personal pubsub nodes, since the root pubsub node simply is the account owner's bare JID (&BAREJID;). This assumption also simplifies publishing and subscribing.

+ + +

There is no need for multiple publishers to a PEP service, since by definition the service generates information associated with only one entity. The owner-publisher for every node is the bare JID of the account owner.

+ + +

There is only one publish-subscribe node associated with any given payload type (XML namespace) for the account owner (e.g., there is one pubsub node for geolocation events, one node for tune events, and one node for mood events). This simplifies node creation, discovery, publishing, and subscribing.

+ + +

Although generic publish-subscribe services do not necessarily have access to presence information about subscribers, PEP services are integrated with presence in the following ways:

+
    +
  • Each messaging and presence account simply is a virtual publish-subscribe service.
    • +
  • The default access model is "presence".
    • +
  • A contact's subscription to an account owner's personal eventing data is normally handled via the existence of an XMPP presence subscription.
    • +
  • Services take account of subscriber presence in the generation of notifications. This works only if the subscription state is "both" (see RFC 3921).
    • +
+

These uses of presence simplify the task of developing compliant clients (cf. &jep0134;).

+ + +

By default, the existence of an XMPP presence subscription is used to establish a PEP subscription to the account owner's personal eventing data. In order to filter which notifications are sent by the PEP service, the contact's client includes extended &jep0115; information in the presence notifications it sends to the account owner, and the PEP service sends only those notifications that match the contact's expressed notification preferences.

+ + +

Most pubsub configuration options and metadata are not needed for personal eventing. Instead, PEP services offer smart defaults to simplify node creation and management.

+ + + + +

This document illustrates PEP through a series of examples that use the following scenario:

+
    +
  1. +

    An owner-publisher juliet@capulet.com who publishes the following information:

    +
      +
    1. Tune information that anyone may see (i.e., an access model of "open")
      2. +
    2. Activity information that only subscribers to her presence may see (i.e., an access model of "presence")
      3. +
    3. Geolocation information that only contacts in her "Friends" group may see (i.e., an access model of "roster" with a group of "Friends")
      4. +
    4. Bookmark information that only the account owner may see (i.e., an access model of "whitelist")
      5. +
    +

    Note: A PEP node with an access model of "whitelist" and no entities on the whitelist effectively results in a node that enables private data storage; for details, see the Private Data Storage section of this document.

    +
    2. +
  2. +

    Three users who have the following relationship to Juliet:

    +
      +
    1. benvolio@montague.net, who has no subscription to Juliet's presence
      2. +
    2. nurse@capulet.com, who has a bidirectional subscription to Juliet's presence and who is in the "Servants" group in Juliet's roster
      3. +
    3. romeo@montague.net, who has a bidirectional subscription to Juliet's presence and who is in the "Friends" group in Juliet's roster
      4. +
    +
    3. +
+

The examples shown in the following sections walk through the protocol flows for node creation, discovery, publishing, and subscribing.

+ + + +

Naturally, before an account owner attempts to complete any PEP use cases, its client SHOULD determine whether the account owner's server supports PEP; to do so, it MUST send a &jep0030; information request to the server:

+ + + + ]]> +

If a server supports PEP, it MUST return an identity of "pubsub/pep" (as well as a list of the namespaces and other features it supports, including all supported JEP-0060 features):

+ + + + + + + + + + + + ... + + + ]]> + + + +

When an account owner attempts to publish an item to a PEP node and that node does not already exist, the PEP service MUST automatically create the node with default configuration. This similar to the room creation process in JEP-0045: Multi-User Chat. However, if the account owner wishes to create a node with a configuration other than the default (e.g., a node with an access model of "open", "roster", or "whitelist"), the account owner MUST follow the node creation protocol specified in JEP-0060.

+

For example, Juliet would send the following stanzas in order to create the nodes mentioned above:

+ + + + + + + http://jabber.org/protocol/pubsub#node_config + + + + + + + + + + + ]]> + + + + + + + + + My nurse's birthday! + + + + + + + + ]]> + + + + + + + http://jabber.org/protocol/pubsub#node_config + + + + + + + + + + + + + + ]]> + + + + + + + http://jabber.org/protocol/pubsub#node_config + + + + + + + + + + + ]]> + + + +

A contact MAY send service discovery requests to the account owner's bare JID (&BAREJID;). Although this is not necessary in order to subscribe to the account owner's personal eventing data (as explained in the following section), it is shown here to further illustrate the role of access models.

+

First, benvolio@montague.net sends a disco#info request to juliet@capulet.com:

+ + + + ]]> +

If Juliet's server supports PEP (thereby making juliet@capulet.com a virtual pubsub service), it MUST return an identity of "pubsub/pep":

+ + + + + ... + + + ]]> +

Second, benvolio@montague.net sends a disco#items request to juliet@capulet.com:

+ + + + ]]> +

The account owner's server MUST check the access model for each of the account owner's PEP nodes and MUST return as service discovery items only those nodes to which the contact is allowed to subscribe or from which the contact is allowed to retrieve items without first subscribing.

+

Therefore, in this case, the server would return only the "http://jabber.org/protocol/tune" node (since it has an open access model and the contact does not have a presence subscription to the account owner's presence):

+ + + + + + ]]> +

Next, nurse@capulet.com sends a disco#items request to juliet@capulet.com:

+ + + + ]]> +

However, in this case, the server would return the "http://jabber.org/protocol/tune" node (open access model) and the "http://jabber.org/protocol/activity" node (presence access model):

+ + + + + + + ]]> +

Finally, romeo@montague.net sends a disco#items request to juliet@capulet.com:

+ + + + ]]> +

In this case, the server would return the "http://jabber.org/protocol/tune" node (open access model) and the "http://jabber.org/protocol/activity" node (presence access model) and the "http://jabber.org/protocol/geoloc" node (roster access model):

+ + + + + + + + ]]> + + + +

If an entity is not subscribed to the account owner's presence, it MUST subscribe to a node using the protocol defined in JEP-0060. For instance, here is how benvolio@montague.net would subscribe Juliet's tune information:

+ + + + + + ]]> +

However, when a contact is affiliated with the account owner through a presence subscription, PEP greatly simplifies the subscription process. This is done by associating the presence subscription with a pubsub subscription to the account owner's root collection node (i.e., bare JID), with a subscription_type of "items" and a subscription_depth of "all".

+

Consider the following presence subscription exchange:

+ + + + ]]> +

For PEP purposes, this is equivalent to the following pubsub subscription exchange:

+ + + + + + + http://jabber.org/protocol/pubsub#subscribe_options + + + items + + + all + + + + + + + + ]]> +

Note: Automated pubsub subscriptions MUST be based on the JID contained in the 'from' address of the presence subscription request, which for IM contacts will be a bare JID (&BAREJID;).

+ + + +

An account owner publishes an item to a node by following the protocol specified in JEP-0060:

+ + + + + + Gerald Finzi + Introduction (Allegro vigoroso) + Music for "Love's Labors Lost" (Suite for small orchestra) + 1 + 255 + + + + + + ]]> +

As a result, the account owner's server generates notifications and sends them to all subscribers who have requested or are interested in the data as described in the Contact Notification Filtering and Generating Notifications sections of this document.

+

The server MUST set the 'from' address on the notification to the bare JID (&BAREJID;) of the account owner (in this example, "juliet@capulet.com"). When sending notifications to an entity that has a presence subscription to the account owner, the server SHOULD include an &jep0033; "replyto" extension specifying the publishing resource (in this example, "juliet@capulet.com/balcony"); this enables the subscriber's client to differentiate between information received from each of the account owner's resources (for example, different resources may be in different places and therefore may need to specify distinct geolocation data). However, a server MUST NOT include the "replyto" address when sending a notification to an entity that does not have a presence subscription to the account owner. In addition, any errors related to the notification MUST be directed to the JID of the 'from' address on the notification (i.e., the bare JID) so that bounce processing can be handled by the PEP service rather than by the publishing client.

+

Assuming that all three entities previously mentioned would receive the notifications, the PEP service would generate the following stanzas:

+ + + + + + Gerald Finzi + Introduction (Allegro vigoroso) + Music for "Love's Labors Lost" (Suite for small orchestra) + 1 + 255 + + + + + + + + + + + + Gerald Finzi + Introduction (Allegro vigoroso) + Music for "Love's Labors Lost" (Suite for small orchestra) + 1 + 255 + + + + + +
+ + + + + + + + + Gerald Finzi + Introduction (Allegro vigoroso) + Music for "Love's Labors Lost" (Suite for small orchestra) + 1 + 255 + + + + + +
+ + + ]]> +

Note the 'to' addresses: the notification to Benvolio is addressed to "benvolio@montague.net" (bare JID) since the PEP service does not have presence information about the subscriber, whereas the notifications to the Nurse and to Romeo are addressed to the full JIDs of those subscribers.

+ + + +

A contact may not want to receive notifications for all payload types. A contact SHOULD signal its preferences to the account owner's server by including JEP-0115 information that specifies the namespaces for which the contact wishes to receive notifications (if any).

+

In order to make this possible, all possible payload namespaces can be appended with the string "+notify" to indicate that the contact wishes to receive notifications for the payload format. Thus if Romeo wants to receive notifications for activity data and geolocation data but not tune data, his client would advertise support for the following namespaces in the disco#info results it sends: Including, say, the 'http://jabber.org/protocol/geoloc' namespace indicates that the client understands the geolocation namespace, whereas including the 'http://jabber.org/protocol/geoloc+notify' namespace indicates that the client wishes to receive notifications related to geolocation.

+
    +
  • http://jabber.org/protocol/activity+notify
    • +
  • http://jabber.org/protocol/geoloc+notify
    • +
+

This set of namespaces would then be advertised as a JEP-0115 "ext" value, such as the following:

+ + + + ]]> +

Note: In JEP-0115, the "ext" values are opaque strings with no semantic meaning.

+

It is the responsibility of the account owner's server to cache JEP-0115 information (including "ext" values and their associated namespaces). When the server receives presence from a contact, it MUST check that presence information for entity capabilities data and correlate that data with the desired namespaces for the contact's client. The server MUST NOT send notifications related to any data formats that the contact's client has not asked for via the relevant "namespace+notify" disco#info feature. This enables a client to turn off all notifications (e.g., because of bandwidth restrictions) and to easily receive all desired data formats simply by adding support for the appropriate "namespace+notify" combination in its disco#info results and client capabililies. However, it also implies that a client can request notifications only on a global basis and cannot request, say, mood information only from certain contacts in the user's roster. Community consensus is that this is an acceptable tradeoff. Also, note that this works only if the account owner has a presence subscription to the contact and the contact has a presence subscription to the account owner.

+

Some examples may help to illustrate the concept of notification filtering. Here we show presence generated by two of the contacts listed above (benvolio@montague.net does have any presence subscriptions to or from juliet@capulet.com and therefore is not involved in these protocol flows).

+ + + + + + + + ]]> +

We assume that Juliet's server doesn't know anything about these capabilities, so it sends service discovery information requests to each of the clients on Juliet's behalf (realistically, the capulet.com server will quickly build up a cache of client capabilities, with the result that it will not need to send these service discovery requests):

+ + + + + + + + + + + + + + + ]]> + + + + + + + + + + + + + ]]> +

Now we revisit account owner publication and server generation of notifications, with filtering enabled because the server has caps information:

+
    +

  • If Juliet publishes a tune item to the open-access "http://jabber.org/protocol/tune" node, her server will send notifications to <benvolio@montague.net> (bare JID) and to <nurse@capulet.com/chamber> (full JID) but not to <romeo@montague.net/orchard>.

    • +

  • If Juliet publishes an activity item to the presence-access "http://jabber.org/protocol/activity" node, her server will send notifications only to <nurse@capulet.com/chamber>.

    • +

  • If Juliet publishes a geolocation item to the roster-access "http://jabber.org/protocol/geoloc" node, her server will send notifications only to <romeo@montague.net/orchard>.

    • +
+ + + + +
    +

  1. If a subscriber subscribed using a full JID (&FULLJID;), domain identifier (&DOMAIN;), or domain plus resource (&DOMAINRES;), a PEP service MUST send one notification only, addressed to the subscribed JID.

    2. +

  2. If a subscriber subscribed using a bare JID (&BAREJID;) and a PEP service does not have appropriate presence information about the subscriber, a PEP service MUST send at most one notification, addressed to the bare JID (&BAREJID;) of the subscriber, and MAY choose not to send any notification. (By "appropriate presence information" is meant an available presence stanza with non-negative priority and JEP-0115 data that indicates interest in the relevant data format.)

    3. +

  3. If a subscriber subscribed using a bare JID (&BAREJID;) and a PEP service has appropriate presence information about the subscriber, the PEP service MUST send one notification to the full JID (&FULLJID;) of each of the subscriber's available resources that have specified non-negative presence priority and included JEP-0115 information that indicates an interest in the data format.

    4. +
+ + +
    +

  1. When an account owner publishes an item to a node, a PEP service MUST generate a notification and send it to all appropriate subscribers (where the number of notifications is determined by the foregoing rules).

    2. +

  2. When a PEP service receives initial presence information from a subscriber's resource with a non-negative priority and including JEP-0115 information that indicates an interest in the data format, it MUST generate a notification containing the last published item for that node and send it to the newly-available resource.

    3. +

  3. As an exception to the foregoing MUST rules, a PEP service MUST NOT send notifications to a subscriber if the user has blocked the subscriber from receiving all or any kinds of stanza (presence, message, IQ, or any combination thereof) using communiations blocking as specified in XMPP IM.

    4. +
+ + + + +

As described in the Generating Notifications section of this document, a PEP service MUST send the last published item to all new subscribers and to all newly-available resources for each subscriber. That is, the default value of the "pubsub#send_last_published_item" node configuration field must be "on_sub_and_presence"; this behavior essentially mimics the functionality of presence as defined in XMPP IM.

+ + + + ]]> + + + + ]]> + + + + + + Gerald Finzi + Introduction (Allegro vigoroso) + Music for "Love's Labors Lost" (Suite for small orchestra) + 1 + 255 + + + + + + + ]]> + + + +

As noted, PEP services may be used to implement private data storage, such as defined in &jep0049;. A future version of this document will specify this usage in more detail.

+ + + +

A PEP service MUST:

+
    +
  • Support the node discovery, node creation, node deletion, publish item, subscribe, unsubscribe, and item retrieval use cases specified in JEP-0060.
    • +
  • Support the "owner" and "subscriber" affiliations.
    • +
  • Support the "presence" access model and set it to the default.
    • +
  • Support the "open", "roster", and "whitelist" access models.
    • +
  • Treat the account owner's bare JID (&BAREJID;) as a collection node (i.e., as the root collection node for the account's virtual pubsub service).
    • +
  • Deliver payloads (if included) in all notifications.
    • +
  • Send the last publish item as described above.
    • +
  • Support the 'deliver_notifications' and 'send_last_published_item' configuration options.
    • +
+

A PEP service MAY support other use cases, affiliations, access models, and features, but such support is OPTIONAL.

+ + + + +

In order to ensure appropriate access to information published at nodes of type "presence" and "roster", a PEP service MUST re-calculate access controls when:

+
    +
  1. A presence subscription state changes (e.g., when a subscription request is approved).
    2. +
  2. A roster item is modified (e.g., when the item is moved to a new roster group).
    3. +
+

If the modification results in a loss of access, the service MUST cancel the entity's subscription. In addition, the service MAY send a message to the (former) subscriber informing it of the cancellation (for information about the format of messages sent to notify subscribers of subscription cancellation, see the "Notification of Subscription Denial or Cancellation" section of JEP-0060).

+ + + + +

A PEP service MAY enforce additional privacy and security policies when determining whether an entity is allowed to subscribe to a node or retrieve items from a node; however, any such policies shall be considered specific to an implementation or deployment and are out of scope for this document.

+ + + +

This JEP requires no interaction with &IANA;.

+ + + + +

The ®ISTRAR; includes a category of "pubsub" in its registry of Service Discovery identities (see &DISCOCATEGORIES;); as a result of this JEP, the Registrar includes a type of "pep" to that category.

+

The registry submission is as follows:

+ + pubsub + + pep + + A personal eventing service that supports the + publish-subscribe subset defined in JEP-0163. + + JEP-0163 + + + ]]> + + + + +

Because Personal Eventing via Pubsub simply reuses the protocol specified in JEP-0060, a separate schema is not needed.

+ + + +

The authors wish to thank the participants in the XMPP Interoperability Testing Event held July 24 and 25, 2006, who provided valuable feedback that resulted in radical simplification of the protocol.

+ + + diff --git a/xep-0164.xml b/xep-0164.xml new file mode 100644 index 00000000..874a52ee --- /dev/null +++ b/xep-0164.xml @@ -0,0 +1,184 @@ + + +%ents; +]> + + +
+ vCard Filtering + This document specifies a mechanism for requesting specific sections of a vCard. + &LEGALNOTICE; + 0164 + Deferred + Standards Track + Standards JIG + Council + + XMPP Core + JEP-0054 + + + + vcard-temp-filter + + Daniel + Henninger + jadestorm@nc.rr.com + daniel@jabber.vorpalcloud.org + + + 0.1 + 2005-11-16 + psa + Initial JEP version. + + + 0.0.2 + 2005-11-05 + dah + Switched to filter out, instead of filter in. + + + 0.0.1 + 2005-10-22 + dah + First draft. + +
+ +

Because XML vCards (see &jep0054;) are now actively used for storing avatars (see &jep0153;), the ability to retrieve only portions of a vCard has become desirable. This JEP can eliminate unnecessary bandwidth usage when larger elements of a vCard are not needed.

+ + +

Any entity supporting this extension MUST be prepared to accept more fields than were requested, in case the target does not support this extension. A compliant target SHOULD exclude any fields listed in the filter element. In the event that the filter element does not exist or is empty, the target MUST return the entire vCard as it would without this extension.

+ + + +

To illustrate the functionality of this JEP, we will first request a standard vCard. As shown in JEP-0054, a user may view another user's vCard by sending an IQ of type "get" to the other user's bare JID. A compliant server MUST return the vCard to the requestor and not forward the IQ to the requestee's connected resource.

+ + + + ]]> +

The server should then return the other user's vCard to the requestor:

+ + + Jeremie Miller + + Jeremie + Miller + + + jer + jeremie@jabber.org + jer@jabber.org + + + ]]> +

A user may request that specific portions of another user's vCard be excluded by including the requested field(s) inside a filter element qualified by the 'vcard-temp-filter' namespace, inside the vCard element.

+ + + + + + + + ]]> +

The server should then return all available fields from the other user's vCard except for those listed in the filter stanza:

+ + + JeremieMiller + + Jeremie + Miller + + + jer + jeremie@jabber.org + + + ]]> + + + +

This JEP introduces no new security concerns beyond those already involved in implementation and deployment of the 'vcard-temp' protocol.

+ + +

This JEP requires no interaction with &IANA;.

+ + +

The ®ISTRAR; shall add 'vcard-temp-filter' to its registry of official namespaces.

+ + +

The schema for the 'vcard-temp-filter' namespace re-uses the element names from the DTD described in JEP-0054.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + diff --git a/xep-0165.xml b/xep-0165.xml new file mode 100644 index 00000000..f4518edb --- /dev/null +++ b/xep-0165.xml @@ -0,0 +1,141 @@ + + +%ents; +]> + + +
+ Prevention of JID Spoofing + This document recommends best practices to prevent the spoofing of Jabber IDs. + &LEGALNOTICE; + 0165 + Experimental + Informational + Standards JIG + Council + + XMPP Core + XMPP IM + JEP-0172 + + + + N/A + &stpeter; + + 0.3 + 2006-06-10 + psa +

Further clarified security considerations as well as the relationship between referrals and presence subscriptions; updated to use proposed syntax for fingerprints.

 + + + 0.2 + 2006-03-28 + psa +

Updated to use JEP-0172 syntax for nicknames.

 + + + 0.1 + 2005-11-16 + psa +

Initial JEP version.

 + + + 0.0.2 + 2005-11-14 + psa +

Further defined petname practices; specified how to include nicknames and fingerprints.

 + + + 0.0.1 + 2005-09-28 + psa +

Initial version.

 + +
+ +

There are two forms of address spoofing: forging and mimicking.

+

In the context of Jabber technologies, an address is forged when an entity is able to generate an XML stanza whose 'from' address does not correspond to the account credentials with which the entity authenticated onto the network -- for example, if an entity authenticated as "stpeter@jabber.org" is able to send XML stanzas from "MaineBoy@jabber.org" or "peter@saint-andre.com".

+

An address is mimicked when an entity provides legitimate authentication credentials for and sends XML stanzas from an account whose Jabber ID (JID) appears to a human user to be the same as another JID -- for example, in some clients "paypa1@jabber.org" (spelled with the number one as the final character of the node identifier) may appear to be the same as "paypal@jabber.org (spelled with the lower-case version of the letter "L"). This phenomenon is sometimes called "typejacking". A more sophisticated example of address mimicking (which may not render correctly in all browsers) is the following:

+ +ᏚᎢᎵᎬᎢᎬᏒ@ᎫᎪᏴᏴᎬᏒ.org + +

That JID is not an uppercase version of "stpeter@jabber.org" in US-ASCII characters, but a fake JID made up mostly of Cherokee characters, namely:

+ U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 + @ + U+13AB U+13AA U+13F4 U+13F4 U+13AC U+13D2 .org +

In this example, it is unlikely that the average user could tell the difference between the real JID and the fake JID. Naturally, there is no way to distinguish with full certainty which is the fake JID and which is the real JID. For example, in some communication contexts, the Cherokee JID may be the real JID and the US-ASCII JID may thus appear to be the fake JID.

+

Traditionally, forging of JIDs has been very difficult in Jabber/XMPP systems given the requirement for servers to stamp 'from' addresses and for servers to verify sending domains via server dialback or server-to-server authentication (see &rfc3920;). However, it may be relatively easy to mimic (some) JIDs in Jabber/XMPP systems, especially because JIDs can contain almost any Unicode character. The possibility of address mimicking introduces security vulnerabilities of the kind that have also plagued the World Wide Web, specifically the phenomenon known as phishing. Phishing has been defined as "a broadly launched social engineering attack in which an electronic identity is misrepresented in an attempt to trick individuals into revealing personal credentials that can be used fraudulently against them" (see Financial Services Technology Consortium Counter-Phishing Initiative: Phase I). To be precise, the current document (1) does not assume that such attacks will be broadly launched and (2) focuses on the misrepresentation of Jabber IDs (not any other identifiers) within the context of Jabber/XMPP systems.

+

To combat those vulnerabilities, this document recommends a set of best practices to minimize the potential impact of address mimicking on the Jabber/XMPP network. This document does not cover handling of non-XMPP addresses, for example HTTP URLs. Jabber/XMPP clients SHOULD handle such addresses in accordance with best practices for the relevant non-XMPP technology.

+ + + +

Every human user of Jabber/XMPP technologies presumably has a preferred language (or, in some cases, a small set of preferred languages), which an XMPP application SHOULD gather either explicitly from the user or implicitly via the user's operating system. Furthermore, every language has a range of characters normally used to represent that language in textual form. Therefore, an XMPP application SHOULD warn the user when presenting a JID that uses characters outside the normal range of the user's preferred language(s). This recommendation is not intended to discourage communication across language communities; instead, it simply recognizes the existence of such language communities and encourages due caution when presenting unfamiliar character sets to human users.

+ + +

As explained in &petnames;, no one naming or address scheme can provide names that are simultaneously global, memorable, and unique. However, certain combinations of names and addresses can provide all three properties, and such combinations are commonly called "petname systems". Consider the following combination of names:

+
    +

  1. The JID "stpeter@jabber.org" is globally unique on the Jabber network, but it is not necessarily memorable.

    2. +

  2. The nickname "psa" (asserted by the user associated with the address "stpeter@jabber.org") is globally memorable but not necessarily unique; see &jep0172; for more information about user-asserted nicknames.

    3. +

  3. The handle or petname For consistency with other XMPP specifications, wee use the term "alias" rather than "petname". "that JSF dude" (assigned by a contact who adds "stpeter@jabber.org" to her contact list) is privately memorable and unique If not shared or leaked, it may even be securely unique. but is by no means global since it has meaning only to the person who assigns it; for consistency with JEP-0172 we refer to this as a "handle".

    4. +
+

A client SHOULD require an end user to assign a handle for every contact added to the person's roster, which SHOULD be stored as the value of the <item/> element's 'name' attribute qualified by the 'jabber:iq:roster' namespace (for details regarding roster syntax, refer to &rfc3921;). A client SHOULD then present that handle instead of or in addition to the contact's JID or nickname (e.g., in the user's roster and in chat interfaces). This will help to prevent mimicked addresses from being presented as equivalent to the address that is being mimicked.

+ + +

Although a Jabber ID can be considered globally unique, the petname system in which it is embedded can be strengthened by associating that JID with a key or certificate that can be used for signing and encryption (such as a PGP key or X.509 certificate), preferably a key or certificate that encapsulates the associated XMPP address (e.g., as described in Section 5.1.1 of RFC 3920). A client SHOULD associate a key or certificate with the user of that client, and SHOULD generate such a key or certificate if the user does not have one.

+

Unfortunately, cryptographic identities such as keys, certificates, and fingerprints are even less memorable than JIDs, which makes assigning a handle even more important. Therefore, if a contact provides such a cryptographic identity, a client MUST reliably associate it with the contact in a user's roster (including, as mentioned, an alias for each contact) in order to further strengthen the petname system.

+ + +

In order to strengthen the web of interaction and trust between Jabber/XMPP users, it is helpful for them to share roster items. In particular, when a user wants to subscribe to the presence of a potential contact, the user SHOULD seek a referral from a third person who knows both the user and the contact. Such a referral consists of a roster item sent from the third person to the potential contact, encapsulated using the &jep0144; protocol:

+ + + + + + ]]> +

Here, the 'name' attribute encapsulates what in petname systems is known as an "alleged name", that is, the name for an entity proposed by a third party.

+

Such a referral SHOULD also include the user's nick as understood by the third person (encapsulated in the format defined in &jep0172;) and fingerprint of the user as understood by the third person (encapsulated in the format defined in the proposal available at <http://www.jabber.org/jeps/inbox/fingerprint.html>:

+ + + + psa + + C3 88 33 27 F3 47 3B 8B 07 71 3E 96 44 A7 EE E2 E0 50 4A 5B + + + + + ]]> +

The third person MUST NOT simply copy the fingerprint as communicated by the contact but instead MUST validate the fingerprint against the public key or certificate of the contact.

+ + +

We have seen that, at a minimum, three names or address types are needed to provide a petname system for XMPP: a JID, a nickname, and a handle (preferably strengthened by inclusion of a fingerprint derived from a key or certificate). However, at present a subscription request contains only the JID of the sender:

+ + ]]> +

Naturally, based on the JID, it is possible to pull information about the sender from a persistent data store such as an LDAP database, &jep0054; node, or future profile system. However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender (encapsulated via the format specified in JEP-0172) and the fingerprint of the sender's certificate or key.

+ + psa + + C3 88 33 27 F3 47 3B 8B 07 71 3E 96 44 A7 EE E2 E0 50 4A 5B + + + ]]> +

If one or more referrals have been received, the user or client MUST check the fingerprint provided in the subscription request against the fingerprint provided in the referral or referrals.

+ + + +

In order for a user-assigned alias to strengthen the security of the petname system, it MUST NOT be shared with anyone other than the user who assigned it. The user SHOULD NOT assign as an alias the alleded name received in a referral.

+

A user SHOULD NOT place more trust a referral than he or she places in the person who sends it.

+ + +

This document requires no interaction with &IANA;.

+ + +

This document requires no interaction with the ®ISTRAR;.

+ + diff --git a/xep-0166.xml b/xep-0166.xml new file mode 100644 index 00000000..0ceeba8d --- /dev/null +++ b/xep-0166.xml @@ -0,0 +1,826 @@ + + +%ents; +]> + + +
+ Jingle + This document defines a framework for initiating and managing peer-to-peer sessions (e.g., voice and video exchanges) between Jabber/XMPP clients in a way that is interoperable with existing Internet standards. + &LEGALNOTICE; + 0166 + Experimental + Standards Track + Standards JIG + Council + + XMPP Core + + + + jingle + &scottlu; + &joebeda; + &stpeter; + &hildjj; + &seanegan; + &robmcqueen; + + 0.10 + 2006-09-29 + ram/psa +

Made several corrections to the state machines and examples.

 + + + 0.9 + 2006-09-08 + ram/psa +

Further cleaned up state machines and state-related actions.

 + + + 0.8 + 2006-08-23 + ram/psa +

Changed channels to components in line with ICE; changed various action names for consistency; added session-extend and session-reduce actions to add and remove description/transport pairs; added description-modify action; added sender attribute to specify directionality.

 + + + 0.7 + 2006-07-17 + psa +

Added implementation note about handling multiple content types.

 + + + 0.6 + 2006-07-12 + se/psa +

Changed media type to content type.

 + + + 0.5 + 2006-03-20 + psa/jb +

Further clarified state machine diagrams; specified that session accept must include agreed-upon media format and transport description; moved deployment notes to appropriate transport spec.

 + + + 0.4 + 2006-03-01 + psa/jb +

Added glossary; clarified state machines; updated to reflect publication of JEP-0176 and JEP-0177.

 + + + 0.3 + 2006-02-24 + psa/jb +

Provided more detail about modify scenarios; defined media-specific and transport-specific actions and adjusted state machine accordingly.

 + + + 0.2 + 2006-02-13 + psa/jb +

Per agreement among the co-authors, moved transport definition to separate specification, simplified state machine, and made other associated changes to the text, examples, and schemas; also harmonized redirect, decline, and terminate processes.

 + + + 0.1 + 2005-12-15 + psa +

Initial JEP version.

 + + + 0.0.10 + 2005-12-11 + psa +

More fully documented burst mode, connectivity checks, error cases, etc.

 + + + 0.0.9 + 2005-12-08 + psa +

Restructured document flow; provided example of burst mode.

 + + + 0.0.8 + 2005-12-05 + psa/sl/jb +

Distinguished between dribble mode and burst mode, including mode attribute, service discovery features, and implementation notes; provided detailed resource discovery examples; corrected state chart; specified session termination; specified error conditions; specified semantics of informational messages; began to define security considerations; added Joe Beda as co-author.

 + + + 0.0.7 + 2005-11-08 + psa +

Added more detail to basic session flow; harmonized candidate negotiation process with ICE.

 + + + 0.0.6 + 2005-10-27 + psa +

Added Jabber Registrar considerations; defined schema; completed slight syntax cleanup.

 + + + 0.0.5 + 2005-10-21 + psa/sl +

Separated methoddescription formats from signalling protocol.

 + + + 0.0.4 + 2005-10-19 + psa/sl +

Harmonized basic session flow with Google Talk protocol; added Scott Ludwig as co-author.

 + + + 0.0.3 + 2005-10-10 + psa +

Added more detail to basic session flow.

 + + + 0.0.2 + 2005-10-07 + psa/jjh +

Protocol cleanup.

 + + + 0.0.1 + 2005-10-06 + psa/jjh +

First draft.

 + +
+ +

There exists no widely-adopted standard for initiating and managing peer-to-peer (p2p) interactions (such as voice, video, or file sharing exchanges) from within Jabber/XMPP clients. Although several large service providers and Jabber/XMPP clients have written and implemented their own proprietary XMPP extensions for p2p signalling (usually only for voice), those technologies are not open and do not always take into account requirements to interoperate with the Public Switched Telephone Network (PSTN) or emerging SIP-based Internet voice networks. By contrast, the only existing open protocol has been &jep0111;, which made it possible to initiate and manage p2p sessions, but which did not provide enough of the key signalling semantics to be easily implemented in Jabber/XMPP clients. It is true that TINS made it relatively easy to implement an XMPP-to-SIP gateway; however, in line with the long-time Jabber philosophy of "simple clients, complex servers", it would be better to force complexity onto the server-side gateway and to keep the client as simple as possible.

+

The result has been an unfortunate fragmentation within the XMPP community regarding signalling protocols. There are, essentially, two approaches to solving the problem:

+
    +
  1. Recommend that all client developers implement a dual-stack (XMPP + SIP) solution.
    2. +
  2. Define a full-featured protocol for XMPP signalling.
    3. +
+

Implementation experience indicates that a dual-stack approach may not be feasible on all the computing platforms for which Jabber clients have been written, or even desirable on platforms where it is feasible. For example, one large ISP recently decided to switch to a pure XMPP approach after having implemented and deployed a dual-stack client for several years. Therefore, it seems reasonable to define an XMPP signalling protocol that can provide the necessary signalling semantics while also making it possible to interoperate with existing Internet standards.

+

As a result of feedback received on JEP-0111, the second and fourth authors of this document began to define such a signalling protocol, code-named Jingle. Upon communication with members of the Google Talk team, Google Talk is a messaging and voice chat service and client provided by Google; see <http://www.google.com/talk/>. it was discovered that the emerging Jingle approach was conceptually (and even syntactically) quite similar to the signalling protocol used in the Google Talk application. Therefore, in the interest of interoperability and adoption, we decided to harmonize the two approaches. The signalling protocol specified therein is, therefore, substantially equivalent to the existing Google Talk protocol, with several adjustments based on feedback received from implementors as well as for publication within the Jabber Software Foundation's standards process.

+ + +

The protocol defined herein is designed to meet the following requirements:

+
    +
  1. Make it possible to manage a wide variety of peer-to-peer sessions (not limited to voice and video) within XMPP. Possible other content description formats include file sharing, application casting, application sharing, whiteboarding, torrent broadcasting, shared real-time editing, and distributed musical performance, to name but a few.
    2. +
  2. Make it possible to add, modify, and remove content types from an existing session.
    3. +
  3. Make it relatively easy to implement support for the protocol in standard Jabber/XMPP clients.
    4. +
  4. Where communication with non-XMPP entities is needed, push as much complexity as possible onto server-side gateways between the XMPP network and the non-XMPP network.
    5. +
+

This document defines the signalling protocol only. Additional documents specify the following:

+
    +

  • Various content description formats (audio, video, etc.) and, where possible, mapping those types to the Session Description Protocol (SDP; see &rfc4566;); one example is &jep0167;.

    • +

  • Various content transport methods.

    • +

  • Procedures for mapping the Jingle signalling protocol to existing signalling standards such as the IETF's Session Initiation Protocol (SIP; see &rfc3261;) and the ITU's H.323 protocol (see &h323;).

    • +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
TermDefinition
SessionA number of pairs of negotiated content transport methods and content description formats connecting two entities. It is delimited in time by an initiate request and session ending events. During the lifetime of a session, pairs of content descriptions and content transport methods can be added or removed.
Content TypeA formal declaration of the purpose(s) of the session. Common sessions might include types such as "voice", both "voice" and "video", and "file sharing". A session consists of at least one active negotiated content type at a time. Depending on the content type and the content description, one content description may require multiple components to be communicated by the transport. This is the 'what' of the session. In Jingle XML syntax the content type is the namespace of the &DESCRIPTION; element.
Content DescriptionThe details of the content type being established. For instance, this might describe the acceptable codecs when establishing a voice conversation. The XML elements for the content description are qualified by the namespace of the content type. The content description defines the bits to be transferred.
Transport MethodThe method for establishing data stream(s) between entities. Possible transports might include &jep0176;, &jep0177;, inband data, etc. This is the 'how' of the session. In Jingle XML syntax this is the namespace of the &TRANSPORT; element. The content transport method defines how to transfer bits from one host to another.
ComponentA component is a numbered stream of data which needs to be transmitted between the endpoints for a given content type in the context of a given session. It is up to the transport to negotiate the details of each component. For instance, the voice content type might use two components, one to transmit an RTP stream, and another to transmit RTCP timing information.
+ + +

Jingle consists of three parts, each with its own syntax, semantics, and state machine:

+
    +
  1. Overall session management
    2. +
  2. Content description formats (the "what")
    3. +
  3. Content transport methods (the "how")
    4. +
+

This document defines the semantics and syntax for overall session management, and provides pluggable "slots" for content description formats and content transport methods, which are specified in separate documents.

+ +

The state machine for overall session management (i.e., the state per Session ID) is as follows:

+ + o + | + | session-initiate + | + | +-----------------------+ + |/ | +PENDING o---------------------+ | + | | session-info, | | + | | content-remove, | | + | | content-modify, | | + | | content-accept, | | + | | content-decline, | | + | +------------------+ | + | | + | session-accept | + | | + ACTIVE o---------------------+ | + | | session-info, | | + | | content-add, | | + | | content-remove, | | + | | content-modify, | | + | | content-accept, | | + | | content-decline, | | + | +------------------+ | + | | + +-------------------------+ + | + | session-redirect, + | session-terminate + | + o ENDED + +

There are three overall session states:

+
    +
  1. PENDING
    2. +
  2. ACTIVE
    3. +
  3. ENDED
    4. +
+

The actions related to management of the overall Jingle session are:

+
    +
  1. content-accept (accept a content-add, content-modify, or content-remove; implicitly also serves as a description-accept and transport-accept)
    2. +
  2. content-add (add one or more new content types to the session; this MUST NOT be sent while the session is in the PENDING state)
    3. +
  3. content-decline (reject a content-add or content-modify)
    4. +
  4. content-modify (change an existing content type, mainly the directionality)
    5. +
  5. content-remove (remove one or more content types from the session)
    6. +
  6. session-accept (definitively accept a session request; implicitly also serves as a description-accept and transport-accept)
    7. +
  7. session-initiate (request a new Jingle session)
    8. +
  8. session-info (session-level information / messages)
    9. +
  9. session-redirect (redirect an initiate request to another address)
    10. +
  10. session-terminate (end an existing session)
    11. +
+ + +

The content type of a session is made up of two aspects:

+
    +
  1. The content description format specifies the "what" of the session (e.g., audio).
    2. +
  2. The content transport method defines "how" the data shall be exchanged (e.g., raw UDP).
    3. +
+

The &CONTENT; element also specifies who will be sending content (the initiator, the recipient, or both).

+ +

When negotiating the session and its content type, the entities involved in the session need to exchange content description formats. The approach taken herein is to specify pure session description information in separate specifications, one for each content description format (audio, video, etc.). While it is possible to send raw Session Description Protocol (SDP) data for the session descriptions (the approach that was taken in JEP-0111), this is not necessarily helpful, since SDP is not structured data, not all SDP data is needed or used in the most common use cases, and SDP has been heavily extended in several useful directions that are not captured in the core SDP specification. The session negotiation must contain some content description format(s), which are defined in separate specifications. Those specifications also define the state chart for the content description format in question.

+

The generic state machine for management of any given content description format is as follows:

+ + START + o + | + | session-initiate + | content-add + | +[PENDING] o-------------+ + | | | description-info + | |_________| description-modify + | + | content-accept + | description-accept + | session-accept + | + | _____________________o [MODIFYING] + | / description-modify / \ + |/ / | + [ACTIVE] o--------------------/ | + |\ description-decline | + | \______________________/ + | description-accept + | + | content-remove + | session-terminate + | + o [ENDED] + +

The states related to management of content description formats are:

+
    +
  1. PENDING
    2. +
  2. ACTIVE
    3. +
  3. MODIFYING
    4. +
  4. ENDED
    5. +
+

The actions related to management of content description formats are:

+
    +
  1. description-info (description-level information / messages)
    2. +
  2. description-modify (request a change to a content description format)
    3. +
  3. description-accept (accept a proposed content change)
    4. +
  4. description-decline (decline a proposed content change)
    5. +
+ + +

As with the content description formats, the content transport methods are specified in separate specifications. Possible content transport methods include Real-time Transport Protocol (RTP) with Interactive Connectivity Establishment (ICE) and raw UDP. Those specifications will also define the state chart for the content transport method in question.

+

The generic state machine for any given content transport method is as follows:

+ + START + o + | + | session-initiate + | content-add + | +[PENDING] o-------------+ + | | | transport-info + | |_________| transport-modify + | + | content-accept + | session-accept + | transport-accept + | + | ___________________o [MODIFYING] + | / transport-modify / \ + |/ / | + [ACTIVE] o------------------/ | + |\ transport-decline | + | \____________________/ + | transport-accept + | + | content-remove + | session-terminate + | + o [ENDED] + +

The states related to management of content transport methods are:

+
    +
  1. PENDING
    2. +
  2. ACTIVE
    3. +
  3. MODIFYING
    4. +
  4. ENDED
    5. +
+

The actions related to management of content transport methods are:

+
    +
  1. transport-info (transport-level information / messages)
    2. +
  2. transport-modify (request a change to the content transport methods)
    3. +
  3. transport-accept (accept a proposed transport change)
    4. +
  4. transport-decline (decline a proposed transport change)
    5. +
+ + + + + +

In order to initiate a Jingle session, the initiating entity must determine which of the target entity's XMPP resources is best for the desired content description format. If a contact has only one XMPP resource, this task MUST be completed using &jep0030; or the presence-based profile of service discovery specified in &jep0115;.

+

Naturally, instead of sending service discovery requests to every contact in a user's roster, it is more efficient to use Entity Capabilities, whereby support for Jingle and various Jingle content description formats and content transport methods is determined for a client version in general (rather than on a per-JID basis) and then cached. Refer to JEP-0115 for details.

+

If a contact has more than one XMPP resource, it may be that only one of the resources supports Jingle and the desired content description format, in which case the user MUST initiate the Jingle signalling with that resource.

+

If a contact has more than one XMPP resource that supports Jingle and the desired content description format, it is RECOMMENDED for a client to use &jep0168; in order to determine which is the best resource with which to initiate the desired Jingle session.

+ + +

Once the initiating entity has discovered which of the target entity's XMPP resources is ideal for the desired content description format, it sends a session initiation request to the target entity. This request is an IQ-set containing a &JINGLE; element qualified by the 'http://jabber.org/protocol/jingle' namespace. The &JINGLE; element MUST possess the 'action', 'initiator', and 'sid' attributes (the latter two uniquely identify the session). For initiation, the 'action' attribute MUST have a value of "session-initiate" and the &JINGLE; element MUST contain one or more &CONTENT; elements, each of which defines a content type to be transferred during the session; each &CONTENT; element in turn contains one &DESCRIPTION; child element that specifies a desired content description format and one or more &TRANSPORT; child elements that specify potential content transport methods.

+

The following example shows a Jingle session initiation request for a session that contains both audio and video content:

+ + + + + ... + + + ... + + + ... + + + + + ... + + + ... + + + ... + + + + + ]]> +

Note: The syntax and semantics of the &DESCRIPTION; and &TRANSPORT; elements are out of scope for this specification, but are defined in related specifications.

+

The attributes of the &JINGLE; element are as follows:

+
    +
  • The 'action' attribute is REQUIRED; it specifies a Jingle action as listed in this document (e.g., "session-initiate").
    • +
  • The 'initiator' attribute is the full JID of the entity that has initiated the session flow (which may be different from the 'from' address on the IQ-set).
    • +
  • The 'responder' attribute (see examples below) is the full JID of the entity that has replied to the initiation (which may be different from the 'to' address on the IQ-set).
    • +
  • The 'sid' attribute is a random session identifier generated by the initiator; this SHOULD match the XML Nmtoken production See <http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Nmtoken> so that XML character escaping is not needed for characters such as &. (Note: the 'sid' attribute effectively maps to the SIP "Call-ID" parameter.)
    • +
+

The attributes of the &CONTENT; element are as follows:

+
    +
  • The 'name' attribute is REQUIRED; it specifies a unique name or identifier for the content type (this identifier is opaque and does not have semantic meaning).
    • +
  • The 'senders' attribute specifies which entities in the session will be generating content; the allowable values are "initiator", "recipient", or "both" (where "both" is the default).
    • +
+ + +

Unless an error occurs, the target entity MUST acknowledge receipt of the initiation request:

+ + ]]> +

If the target entity acknowledges receipt of the initation request, both parties must consider the session to be in the PENDING state.

+

There are several reasons why the target entity might return an error instead of acknowledging receipt of the initiation request:

+
    +
  • The initiating entity is unknown to the target entity (e.g., via presence subscription).
    • +
  • The target entity does not support Jingle.
    • +
  • The target entity does not support any of the specified content description formats.
    • +
  • The target entity does not support any of the specified content transport methods.
    • +
  • The initiation request was malformed.
    • +
+

The initiating entity is unknown to the target entity (e.g., via presence subscription) and the target entity has a policy of not communicating via Jingle with unknown entities, it MUST return a &unavailable; error.

+ + + + + + ]]> +

If the target entity does not support Jingle, it MUST return a &unavailable; error.

+ + + + + + ]]> +

If the target entity does not support any of the specified content description formats, it MUST return a &feature; error with a Jingle-specific error condition of <unsupported-content/>.

+ + + + + + + ]]> +

If the target entity does not support any of the specified content transport methods, it MUST return a &feature; error with a Jingle-specific error condition of <unsupported-transports/>.

+ + + + + + + ]]> +

If the initiation request was malformed, the target entity MUST return a &badrequest; error.

+ + + + + + ]]> + + +

After acknowledging receipt of the initiation request, the target entity MAY redirect the session to another address (e.g., because the principal is not answering at the original resource). This is done by sending a Jingle redirect action to the initiating entity:

+ + + xmpp:voicemail@capulet.com + + + ]]> +

The recipient then acknowledges the redirection:

+ + ]]> +

Both entities MUST now consider the original session to be in the ENDED state, and if the initiating entity wishes to initiate a session with the redirected address it MUST do so by sending a session initiation request to that address with a new session ID.

+ + +

In order to decline the session initiation request, the target entity MUST acknowledge receipt of the session initiation request, then terminate the session as described in the Termination section of this document.

+ + +

In general, negotiation will be necessary before the parties can agree on an acceptable set of content types, content description formats, and content transport methods. The potential combinations of parameters to be negotiated are many, and not all are shown herein (some are shown in the relevant specifications for various content description formats and content transport methods).

+

One session-level negotiation is to remove a content types. For example, let us imagine that Juliet is having a bad hair day. She certainly does not want to include video in her Jingle session with Romeo, so she sends a "content-remove" request to Romeo:

+ + + + + + ]]> +

The entity receiving the session reduction request then acknowledges the request:

+ + ]]> +

If the reduction results in no more content types for the session, the entity that receives the session-reduce SHOULD send a session-terminate action to the other party (since a session with no content types is void).

+

Another session-level negotiation is to add a content type; however, this MUST NOT be done during while the session is in the PENDING state and is allowed only while the session is in the ACTIVE state (see below).

+ + +

If (after negotiation of content transport methods and content description formats) the target entity determines that it will be able to establish a connection, it sends a definitive acceptance to the initiating entity:

+ + + + + ... + + + ... + + + ... + + + + + ... + + + ... + + + ... + + + + ]]> +

The &JINGLE; element in the accept stanza MUST contain one or more <content/> elements, each of which MUST contain only one <description/> element and one or more <transport/> elements. The &JINGLE; element SHOULD possess a 'responder' attribute that explicitly specifies the full JID of the responding entity, and the initiating entity SHOULD send all future commmunications about this Jingle session to the JID provided in the 'responder' attribute.

+

The initiating entity then acknowledges the target entity's definitive acceptance:

+ + ]]> +

Now the initiating entity and target entity can begin sending content over the negotiated connection.

+

If one of the parties cannot find a suitable content transport method, it SHOULD terminate the session as described below.

+ + +

In order to modify an active session, either party may send a "content-remove", "content-add", "content-modify", "description-modify", or "transport-modify" action to the other party. The receiving party then sends an appropriate "-accept" or "-decline" action, and may first send an appropriate "-info" action.

+

If both parties send modify messages at the same time, the modify message from the session initiator MUST trump the modify message from the recipient and the initiator SHOULD return an &unexpected; error to the other party.

+

One example of modifying an active session is to add a content type. For example, let us imagine that Juliet gets her hair in order and now wants to add video. She now sends a "content-add" request to Romeo:

+ + + + + ... + + + ... + + + ... + + + + + ]]> +

The entity receiving the session extension request then acknowledges the request and, if it is acceptable, returns a content-accept:

+ + ]]> + + + + + ... + + + ... + + + ... + + + + + ]]> +

The other party then acknowledges the acceptance.

+ + ]]> + + +

In order to gracefully end the session (which MAY be done at any point after acknowledging receipt of the initiation request, including immediately thereafter in order to decline the request), either the target entity or the initiating entity MUST a send a "terminate" action to the other party:

+ + + + ]]> +

The initiating entity MUST then acknowledge termination of the session:

+ + ]]> +

Unfortunately, not all sessions end gracefully. The following events MUST be considered session-ending events, and any further Jingle communication for the negotiated content description format and content transport method MUST be completed through negotiation of a new session:

+
    +
  • Receipt of a 'session-redirect' or 'session-terminate' action from the other party.
    • +
  • Receipt of &UNAVAILABLE; from the other party.
    • +
+

In particular, one party MUST consider the session to be in the ENDED state if it receives presence of type "unavailable" from the other party:

+ + ]]> +

Naturally, in this case there is nothing for the initiating entity to acknowledge.

+ + +

At any point after initiation of a Jingle session, either entity MAY send an informational message to the other party, for example to change a content transport method or content description format parameter, inform the other party that a session initiation request is queued, that a device is ringing, or that a scheduled event has occurred or will occur. An information message MUST be an IQ-set containing a &JINGLE; element whose 'action' attribute is set to a value of "session-info", "description-info", or "transport-info"; the &JINGLE; element MUST further contain a payload child element (speciific to the session, content description format, or content transport method) that specifies the information being communicated. (A future version of this specification will define payloads related to the "session-info" action.)

+ + + + +

The Jingle-specific error conditions are as follows.

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Jingle ConditionXMPP ConditionDescription
<out-of-order/>&unexpected;The request cannot occur at this point in the state machine (e.g., initiate after accept).
<unknown-session/>&badrequest;The 'sid' attribute specifies a session that is unknown to the recipient.
<unsupported-content/>¬acceptable;The recipient does not support any of the desired content description formats.
<unsupported-transports/>¬acceptable;The recipient does not support any of the desired content transport methods.
+ + + +

There is a one-to-one relationship between content types and sessions. This reduces the complexity of managing a given session, since it avoids the need to de-multiplex traffic for different content types sent over the same connection. However, it may be desirable to share different kinds of content at the same time (e.g., during a video chat one party may want to share a file); in order to do this, the parties must establish a separate session for each content type. Management of multiple sessions is a client implementation matter and is not discussed in this specification.

+ + + +

Note: This section is not yet complete.

+ +

Jingle sessions may be resource-intensive. Therefore, it is possible to launch a denial-of-service attack against an entity by burdening it with too many Jingle sessions. Care must be taken to accept content sessions only from known entities and only if the entity's device is able to process such sessions.

+ + +

Jingle communications may be enabled through gateways to non-XMPP networks, whose security characteristics may be quite different from those of XMPP networks. (For example, on some SIP networks authentication is optional and "from" addresses can be easily forged.) Care must be taken in communicating through such gateways.

+ + + + +

This JEP requires no interaction with &IANA;.

+ + + + +

The ®ISTRAR; shall include 'http://jabber.org/protocol/jingle' and 'http://jabber.org/protocol/jingle#errors' in its registry of protocol namespaces.

+ + +

The Jabber Registrar shall maintain a registry of Jingle content description formats. All content description format registrations shall be defined in separate documents (not in this JEP). Content description formats defined within the JEP series MUST be registered with the Jabber Registrar, resulting in protocol URIs of the form "http://jabber.org/protocol/jingle/description/name" (where "name" is the registered name of the content description format).

+ ®PROCESS; + + the name of the content description format (e.g., "audio") + a natural-language summary of the content description format + the document in which this content description format is specified + + ]]> + + +

The Jabber Registrar shall maintain a registry of Jingle content transport methods. All content transport method registrations shall be defined in separate documents (not in this JEP). Content transport methods defined within the JEP series MUST be registered with the Jabber Registrar, resulting in protocol URIs of the form "http://jabber.org/protocol/jingle/transport/name" (where "name" is the registered name of the content transport method).

+ ®PROCESS; + + the name of the content transport method (e.g., "raw-udp") + a natural-language summary of the content transport method + the document in which this content transport method is specified + + ]]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + + + + + + + + + + + + + + + + + + ]]> + + + +

The authors would like to thank Rohan Mahy for his valuable input on early versions of this document. Rob Taylor, Dafydd Harries, Jussi Laako, Saku Vainio, Antti Ijäs, Brian West, Anthony Minessale, Matt O'Gorman, and others have also provided helpful input. Thanks also to those who have commented on the &SJIG; and (earlier) Jingle Before this specification was accepted as a Jabber Enhancement Proposal, it was discussed on the semi-private <jingle@jabber.org> mailing list; although that list is no longer used (the Standards-JIG list is the preferred discussion venue), for historical purposes it is publicly archived at <http://mail.jabber.org/pipermail/jingle/>. mailing lists.

+ + diff --git a/xep-0167.xml b/xep-0167.xml new file mode 100644 index 00000000..d71a2340 --- /dev/null +++ b/xep-0167.xml @@ -0,0 +1,350 @@ + + +%ents; +]> + + +
+ Jingle Audio Content Description Format + This document defines a content description format for Jingle audio sessions. + &LEGALNOTICE; + 0167 + Experimental + Standards Track + Standards JIG + Council + + XMPP Core + JEP-0166 + + + + jingle-audio + &scottlu; + &stpeter; + &seanegan; + + 0.5 + 2006-08-23 + psa +

Modified namespace to track JEP-0166.

 + + + 0.4 + 2006-07-12 + se/psa +

Specified when to play received audio (early media); specified that DTMF must use in-band signalling (JEP-0181).

 + + + 0.3 + 2006-03-20 + psa +

Defined info messages for hold and mute.

 + + + 0.2 + 2006-02-13 + psa +

Defined info message for busy; added info message examples; recommended use of Speex; updated schema and Jabber Registrar considerations.

 + + + 0.1 + 2005-12-15 + psa +

Initial JEP version.

 + + + 0.0.3 + 2005-12-05 + psa +

Described service discovery usage; defined initial informational messages.

 + + + 0.0.2 + 2005-10-27 + psa +

Added SDP mapping, security considerations, IANA considerations, Jabber Registrar considerations, and XML schema.

 + + + 0.0.1 + 2005-10-21 + psa/sl +

First draft.

 + +
+ +

&jep0166; can be used to initiate and negotiate a wide range of peer-to-peer sessions. The first session type of interest is audio chat. This document specifies a format for describing Jingle audio sessions.

+ + +

The Jingle content description format defined herein is designed to meet the following requirements:

+
    +
  1. Enable negotiation of parameters necessary for audio chat over Realtime Transport Protocol (RTP; see &rfc3550;).
    2. +
  2. Map these parameters to Session Description Protocol (SDP; see &rfc4566;) to enable interoperability.
    3. +
  3. Define informational messages related to audio chat (e.g., busy and ringing).
    4. +
+ + +

A Jingle audio session is described by one or more encodings contained within a wrapper <description/> element. In the language of RFC 4566 these encodings are payload-types; therefore, each <payload-type/> element specifies an encoding that can be used for the audio stream. In Jingle Audio, these encodings are used in the context of RTP. The most common encodings for the Audio/Video Profile (AVP) of RTP are listed in &rfc3551; (these "static" types are reserved from payload ID 0 through payload ID 96), although other encodings are allowed (these "dynamic" types use payload IDs 97 to 127) in accordance with the dynamic assignment rules described in Section 3 of RFC 3551. The 'id' attribute is REQUIRED. The 'name' attribute is RECOMMENDED for static payload types, and REQUIRED for dynamic payload types. The 'clockrate' attribute is RECOMMENDED and should specify the sampling frequency in hertz. The 'channels' attribute is RECOMMENDED and should specify the number of channels; if omitted, it MUST be assumed to contain one channel.

+

The encodings SHOULD be provided in order of preference.

+ + + + + + + + + + + + + + ]]> +

The <description/> element is intended to be a child of a &JINGLE; element as specified in JEP-0166.

+

When the session is provisionally accepted, as indicated by the target entity sending an empty IQ result in response to an 'initiate' message, both receiving and sending entities SHOULD start listening for audio as defined by the negotiated transport method. For interoperability with telephony systems, each entity SHOULD play any audio received at this time, before the target sends an 'accept' message.

+ + +

If the payload type is static (payload-type IDs 0 through 96 inclusive), it MUST be mapped to a media field defined in RFC 4566: Session Description Protocol (SDP). The generic format for the media field is as follows:

+ + ]]> +

In the context of Jingle audio sessions, the <content> is "audio", the <port> is the preferred port for such communications (which may be determined dynamically), the <transport> is whatever transport method is negotiated via the Jingle negotiation (e.g., "RTP/AVT"), and the <fmt list> is the payload-type ID.

+

For example, consider the following static payload-type:

+ + ]]> + +

If the payload type is dynamic (payload-type IDs 97 through 127 inclusive), it SHOULD be mapped to an SDP media field plus an SDP attribute field named "rtpmap".

+

For example, consider a payload of 16-bit linear-encoded stereo audio sampled at 16KHz associated with dynamic payload-type 98:

+ + ]]> + + + +

If an entity supports the Jingle audio content description format, it MUST advertise that fact by returning a feature of "http://jabber.org/protocol/jingle/description/audio" in response to &jep0030; information requests.

+ + + + ]]> + + + ... + + + ... + + + ]]> + + + +

Informational messages may be sent by either party within the context of Jingle to communicate the status of a Jingle audio session, device, or principal. The informational message MUST be an IQ-set containing a &JINGLE; element of type "content-info", where the informational message is a payload element qualified by the 'http://jabber.org/protocol/jingle/info/audio' namespace; the following payload elements are defined: A <trying/> element (equivalent to the SIP 100 Trying response code) is not necessary, since each session-level action is acknowledged via XMPP IQ semantics.

+ + + + + + + + + + + + + + + + + + + + + + + + + +
ElementMeaning
<busy/>The principal or device is currently unavailable for a session because busy with another (audio or other) session.
<hold/>The principal is temporarily pausing the chat (i.e., putting the other party on hold).
<mute/>The principal is temporarily stopping audio input but continues to accept audio output.
<queued/>The audio session request is queued for pickup by the principal.
<ringing/>The device is ringing but the principal has not yet interacted with it to answer.
+

Note: Because the informational message is sent in an IQ-set, the receiving party MUST return either an IQ-result or an IQ-error (normally only an IQ-result to acknowledge receipt; no error flows are defined or envisioned at this time).

+ + + + + + + + ]]> + + + + + + ]]> + + + + + + ]]> + + + + + + ]]> + + + + + + ]]> + + + + +

Support for the Speex codec See <http://www.speex.org/>. is RECOMMENDED.

+ + +

Support for Dual Tone Multi-Frequency (DTMF) MUST use the protocol described in &jep0181;.

+ + + +

The description of a format for audio sessions introduces no known security vulnerabilities.

+ + +

This JEP requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; shall include 'http://jabber.org/protocol/jingle/description/audio' and 'http://jabber.org/protocol/jingle/info/audio' in its registry of protocol namespaces.

+ + +

The Jabber Registrar shall include the name "audio" in its registry of Jingle content description formats. The registration is as follows:

+ + audio + Jingle sessions that support audio exchanges + JEP-0167 + + ]]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + + + + + + + + + + + + + + + + + + + ]]> + + + diff --git a/xep-0168.xml b/xep-0168.xml new file mode 100644 index 00000000..03fbe303 --- /dev/null +++ b/xep-0168.xml @@ -0,0 +1,341 @@ + + +%ents; +]> + + +
+ Resource Application Priority + This document defines an XMPP protocol extension to indicate the presence priority of XMPP resources for applications other than messaging. + &LEGALNOTICE; + 0168 + Experimental + Standards Track + Standards JIG + Council + + XMPP Core + XMPP IM + JEP-0030 + + + + rap + &stpeter; + &hildjj; + + 0.3 + 2006-09-17 + psa +

Changed im application type to messaging; added jingle-video.

 + + + 0.2 + 2005-12-19 + psa +

Clarified structure of, and added schema for, RAP request namespace.

 + + + 0.1 + 2005-12-15 + psa +

Initial JEP version.

 + + + 0.0.6 + 2005-11-29 + psa +

Document cleanup.

 + + + 0.0.5 + 2005-11-17 + psa +

Added support for RAP requests via IQ.

 + + + 0.0.4 + 2005-10-27 + psa/jjh +

Defined registry of application types; clarified business rules; corrected schema.

 + + + 0.0.3 + 2005-10-24 + psa/jjh +

Broadened previous resource flagging proposal to include priority for applications other than messaging.

 + + + 0.0.2 + 2005-09-26 + psa/jjh +

Added more business rules and examples; defined service discovery guidelines.

 + + + 0.0.1 + 2005-09-23 + psa/jjh +

First draft.

 + +
+ +

Within the Extensible Messaging and Presence Protocol (XMPP; see &rfc3920;), presence indicates availability for communication -- specifically, communication via XMPP messaging (usually in the form of "instant messaging" or IM as described in &rfc3921;). However, a wide variety of entities might provide XMPP presence, including entities that are not primarily focused on IM (e.g., phones) or even entities that do not support XMPP messaging at all.

+

Consider a scenario in which a contact wants to initiate a voice chat (e.g., via &jep0166;) with a user who has the following three XMPP resources:

+ + + + + + + + + + + + + + + + + + + + + +
ResourceMessaging PriorityVoice Chat Priority
desktop105
pda5-1
mobile-110
+

If the contact chooses the resource with which it initiates a voice chat based on the user's default XMPP presence priority (i.e., priority for XMPP messaging), the resulting behavior could be misleading (i.e., initiating the voice chat with the "desktop" resource rather than the "mobile" resource).

+

What is needed is a way for the user's clients to indicate that the application priority for the three resources is different from the standard XMPP messaging priority. This document defines such a mechanism via an optional XMPP presence extension.

+

In addition, this document also defines a way for an XMPP server to flag which resource it considers to be primary for any given application type, if it has information -- such as communication preferences -- that can help determine the primary resource.

+ + +

Consider the three resources ("desktop", "pda", and "mobile") mentioned above. The presence stanzas received by a contact for those three resources would be as follows:

+ + 10 + + + + + 5 + + + + + -1 + + + ]]> +

(Note: This protocol uses a 'num' attribute rather than a 'priority' attribute to reduce confusion with XMPP presence and also to save some bytes.)

+

The following business rules apply to resource application presence provided by the client:

+
    +

  1. A client SHOULD NOT specify resource application presence if the priority for that application is not different from the resource's XMPP messaging priority.

    2. +

  2. A client MUST NOT generate a <rap/> element that has an 'app' attribute whose value is "messaging" or that has no 'app' attribute (since the default 'app' is "messaging").

    3. +
+ + +

The user's server may have special information that enables it to flag a resource as primary for a given application type. For instance, the server may include a communication policy service that enables the user to define (outside the context of any presence priorities) that she would prefer to be called at her "desktop" resource only between the hours of 9:00 AM and 5:00 PM local time, prefer to be called on her mobile at all other times, and so on.

+

To flag the primary resource related to a specific application type, the server shall add a <primary/> child to the relevant RAP element. Here is an example:

+ + -1 + + + + + ]]> +

The following business rules apply to resource flagging by the server:

+
    +

  1. A server MAY add the primary resource flag to the presence broadcasts generated by the resource it determines is "most available" for a given application type.

    2. +

  2. Because the default 'app' is "im", to flag the primary resource for XMPP messaging the server SHOULD NOT include an 'app' attribute, SHOULD NOT include a 'num' attribute, and MUST include a <primary/> child.

    3. +

  3. An available resource that has specified a negative priority for an application type MUST NOT be flagged as the primary resource for that application type.

    4. +

  4. A client SHOULD NOT include the primary resource flag in presence stanzas that it generates; however, if a client includes the primary resource flag in a presence stanza, the server SHOULD remove or overwrite the flag.

    5. +

  5. In response to a presence probe, a server SHOULD send presence from the primary resource first (this enables the receiving client to skip any local most-available algorithms it might implement).

    6. +

  6. If the primary resource changes for a given application type, a server MUST push presence (including the primary resource flag) for the new primary resource. If the change in primary resource occurs because of a presence broadcast from the current primary resource, the server MUST push presence from the current primary resource (without the primary resource flag) before pushing presence from the new primary resource (including the primary resource flag).

    7. +
+ + +

In the interest of saving bandwidth, a server MAY choose to strip all RAP data out of presence stanzas and instead provide RAP data only on request via IQ interactions. + A likely scenario is as follows:

+
    +

  1. Contact's client sends &jep0030; information request to user's client or receives &jep0115; data from user's client, and thereby discovers that user's client supports the 'http://jabber.org/protocol/rap' namespace.

    2. +

  2. User's client publishes RAP extensions but user's server strips them out in presence broadcasts.

    3. +

  3. Contact decides to initiate a non-IM interaction with user.

    4. +

  4. Contact's client notices the lack of RAP data from user (despite discovered support) and sends disco#info request to user's server, which signals that it supports the 'http://jabber.org/protocol/raprequest' namespace.

    5. +

  5. Contact's client sends RAP request to user's bare JID (&BAREJID;).

    6. +

  6. If contact is authorized to view user's presence data, user's server returns the latest RAP data for all of the user's resources. (Note: See the Security Considerations section of this document for an important proviso regarding access to RAP data.)

    7. +
+

An example protocol flow for the last two steps is as follows...

+

First, the contact's client requests the user's RAP data by sending a request to the user's bare JID:

+ + + + ]]> +

On behalf of the user, the user's server then returns the full &PRESENCE; stanzas (containing RAP data) for each of the user's connected clients:

+ + + + 10 + + + + 5 + + + + -1 + + + + + ]]> +

Note: The XML data of the server's response to a RAP request may seem to be potentially confusing, but it is fully consistent with &w3xmlnamespaces; as well as the schemas for the 'jabber:client' and 'http://jabber.org/protocol/raprequest' namespaces.

+ + +

In order to discover whether a server or other entity supports this protocol, an entity MUST use &jep0030;.

+ + + + ]]> +

If the queried entity supports resource application presence, it MUST return a feature of "http://jabber.org/protocol/rap":

+ + + ... + + ... + + + ]]> +

If the queried entity supports resource application presence as well as RAP requests (see the Requesting RAP Data Via IQ section of this document), it MUST return features of "http://jabber.org/protocol/rap" and "http://jabber.org/protocol/raprequest":

+ + + ... + + + ... + + + ]]> + + +

Neither client publishing of resource application priority nor server flagging of the primary resource introduces any known security vulnerabilities or compromises of user privacy.

+

If a server supports RAP requests, it MUST carefully control access to RAP data in order to guard against presence leaks and directory harvest attacks. Specifically, if the requesting entity is not authorized (e.g., a contact with a presence subscription of "both" or "from" as described in RFC 3921) or is not explicitly trusted (e.g., a server in a trusted network), the server MUST return a &forbidden; error in response to RAP requests.

+ + +

This document requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; shall include the following namespaces in its registry of protocol namespaces:

+
    +
  • http://jabber.org/protocol/rap
    • +
  • http://jabber.org/protocol/raprequest
    • +
+ + +

The Jabber Registrar shall maintain a registry of application types. Although strictly speaking this should not be necessary, it is desirable to maintain a list of "short names" for various application types rather than using long XML namespaces, especially in presence broadcasts. For example, a short name of "jingle-audio" is only 12 characters long, whereas the full XML namespace "http://jabber.org/protocol/jingle/description/audio" is 48 characters long. The difference can be quite significant when many presence stanzas are sent.

+ + ®PROCESS; + + the value of the 'app' attribute + the full namespace associated with the relevant protocol + a natural-language description of the application type + the document in which this application type is specified + + ]]> + + + + jingle-audio + http://jabber.org/protocol/jingle/description/audio + Jingle audio sessions + JEP-0167 + + + + jingle-video + http://jabber.org/protocol/jingle/description/video + Jingle video sessions + JEP-0180 + + + + messaging + jabber:client + Standard XMPP messaging + RFC 3921 + + ]]> + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + + + + + + + + + + + + + + + + ]]> + + + diff --git a/xep-0169.xml b/xep-0169.xml new file mode 100644 index 00000000..a03bd185 --- /dev/null +++ b/xep-0169.xml @@ -0,0 +1,542 @@ + + +%ents; +]> + + +
+ Twas The Night Before Christmas (Jabber Version) + The classic Christmas poem annotated with Jabber/XMPP protocols. + &LEGALNOTICE; + 0169 + Active + Humorous + Standards JIG + Council + + XMPP IM + JEP-0045 + JEP-0060 + JEP-0080 + JEP-0090 + JEP-0107 + JEP-0108 + JEP-0112 + JEP-0163 + + + + N/A + &stpeter; + + 1.0 + 2005-12-19 + psa + Happy Holidays! + +
+ + + +

'Twas the night before Christmas,

+ + + + + + + + 18071224T22:58:35 + EST + + + ]]> + +

When all through the house,

+

Not a creature was stirring, not even a mouse:

+ + + xa + zzz + + ]]> + +

The stockings were hung by the chimney with care,

+

In hopes that St. Nicholas soon would be there;

+

The children were nestled all snug in their beds,

+ + + + + + + children's bedroom + + + + + + ]]> + +

While visions of sugar-plums danced in their heads.

+ + + + + + + + + + dreaming of sugar-plums + + + + + + ]]> + +

And Mama in her 'kerchief, and I in my cap,

+

Had just settled down for a long winter's nap.

+ + + + + + + master bedroom + + + + + + ]]> + +

When out on the lawn there arose such a clatter,

+

I sprang from the bed to see what was the matter.

+

Away to the window I flew like a flash,

+

Tore open the shutters, and threw up the sash.

+

The moon on the breast of the new-fallen snow

+

Gave the lustre of mid-day to objects below,

+

When, what to my wondering eyes should appear,

+

But a miniature sleigh, and eight tiny rein-deer,

+ + + + + + + 41.70 + -73.92 + 50 + + + + + + ]]> + + + + + + + 41.70 + -73.92 + 50 + + + + + + ]]> + +

With a little old driver, so lively and quick,

+

I knew in a moment it must be St. Nick.

+

More rapid than eagles his coursers they came,

+

And he whistled, and shouted, and called them by name;

+ + + Now, Dasher! + + + + Now, Dancer! + + + + Now, Prancer and Vixen! + + + + On, Comet! + + + + On, Cupid! + + + + On, Donder and Blitzen! + + + + To the top of the porch! + + + + To the top of the wall! + + + + Now dash away! + + + + Dash away! + + + + Dash away all! + + ]]> + +

As dry leaves that before the wild hurricane fly,

+

When they meet with an obstacle, mount to the sky,

+

So up to the house-top the coursers they flew,

+

With the sleigh full of toys, and St. Nicholas too.

+ + + + + + + 41.70 + -73.92 + 60 + + + + + + ]]> + + + + + + + 41.70 + -73.92 + 60 + + + + + + ]]> + + +

And then, in a twinkling, I heard on the roof

+

The prancing and pawing of each little hoof.

+

As I drew in my hand, and was turning around,

+

Down the chimney St. Nicholas came with a bound.

+ + + + + + + 41.70 + -73.92 + 52 + + + + + + ]]> + + + + + + + 41.70 + -73.92 + 52 + + + + + + ]]> + + + + ]]> + +

He was dressed all in fur, from his head to his foot,

+

And his clothes were all tarnished with ashes and soot;

+

A bundle of toys he had flung on his back,

+

And he looked like a peddler just opening his pack.

+

His eyes -- how they twinkled! his dimples how merry!

+

His cheeks were like roses, his nose like a cherry!

+

His droll little mouth was drawn up like a bow,

+

And the beard of his chin was as white as the snow;

+

The stump of a pipe he held tight in his teeth,

+

And the smoke it encircled his head like a wreath;

+

He had a broad face and a little round belly,

+

That shook, when he laughed, like a bowlful of jelly.

+

He was chubby and plump, a right jolly old elf,

+

And I laughed when I saw him in spite of myself;

+ + + + + + + + + + + + + ]]> + +

A wink of his eye and a twist of his head

+

Soon gave me to know I had nothing to dread.

+ + + + + + + + + + + + + ]]> + +

He spoke not a word, but went straight to his work,

+ + + + + + + + + + + + + ]]> + + + + + + + + + + + + + ]]> + + +

And filled all the stockings; then turned with a jerk,

+

And laying his finger aside of his nose

+

And giving a nod, up the chimney he rose.

+ + + + + + + 41.70 + -73.92 + 60 + + + + + + ]]> + + + + + + + 41.70 + -73.92 + 60 + + + + + + ]]> + + +

He sprung to his sleigh, to his team gave a whistle,

+

And away they all flew, like the down of a thistle.

+ + + + + + + 41.70 + -73.92 + 100 + + + + + + ]]> + + + + + + + 41.70 + -73.92 + 100 + + + + + + ]]> + + +

But I heard him exclaim, ere he drove out of sight --

+ + + Happy Christmas to all, and to all a good night. + + ]]> + + + ]]> + + + + +

The foregoing poem, informally known as 'Twas the Night Before Christmas but formally entitled Account of a Visit from St. Nicholas, was authored by Major Henry Livingston Jr. in 1807 or 1808. As noted at <http://rpo.library.utoronto.ca/poem/1312.html>, "In the year 2000, Don Foster, an English professor at Vassar College in Poughkeepsie, New York, used external and internal evidence to show that Clement Clarke Moore could not have been the author of this poem, but that it was probably the work of Livingston, and that Moore had written another, and almost forgotten, Christmas piece, Old Santeclaus. Foster's analysis of this deception appears in his Author Unknown: On the Trail of Anonymous (New York: Henry Holt, 2000): 221-75." See also <http://rpo.library.utoronto.ca/poet/204.html> and <http://www.henrylivingston.com/>.

+

This document makes reference to the following Jabber/XMPP protocols:

+
    +
  • &rfc3921;
    • +
  • &jep0045;
    • +
  • &jep0060;
    • +
  • &jep0080;
    • +
  • &jep0090;
    • +
  • &jep0107;
    • +
  • &jep0108;
    • +
  • &jep0112;
    • +
  • &jep0163;
    • +
+

Note: For the sake of brevity, not all protocol exchanges are shown above. Refer to the appropriate specifications for detailed protocol descriptions.

+ + + +

This document assumes the following architecture:

+ +

In addition, we assume that the twas-the-night.lit server is running a virtual pubsub service for each account it hosts (in accordance with JEP-0163) and that the users "narrator", "mama", and "child" publish information to personal pubsub nodes related to mood (JEP-0107), activity (JEP-0108), and physical location (JEP-0112).

+

* The U.S. Military divides its operations geographically among NORTHCOM, SOUTHCOM, EUCOM, and PACOM. Given the scale of operations implemented by Santa's workshop, it comes as no surprise that the command center at the North Pole is known as POLECOM. Naturally POLECOM subscribes to the pubsub feeds for Santa's geolocation and activity, as well as the sleigh's geolocation, just in case a search and rescue mission needs to be initiated.

+ + + +

The protagonist of this poem is variously called (in English) St. Nicholas, St. Nick, Santa Claus, Kris Kringle, and bears a striking resemblance to the Sinterklaas of Dutch legend. Use of the name "St. Nicholas" is not meant to disparage other names for this character in English or any other language.

+ + + +

It is NOT RECOMMENDED for mere mortals to fly in reindeer-powered sleighs, to enter and exit houses through chimneys, or to perform other dangerous acts described herein.

+ + + +

This JEP requires no interaction with &IANA;.

+ + + +

This JEP requires no interaction with the ®ISTRAR;.

+ + + diff --git a/xep-0170.xml b/xep-0170.xml new file mode 100644 index 00000000..dbb45f85 --- /dev/null +++ b/xep-0170.xml @@ -0,0 +1,160 @@ + + +%ents; +]> + + +
+ Recommended Order of Stream Feature Negotiation + This document specifies a recommended order for negotiation of XMPP stream features. + &LEGALNOTICE; + 0170 + Experimental + Informational + Standards JIG + Council + + XMPP Core + JEP-0077 + JEP-0079 + JEP-0138 + + + + N/A + &stpeter; + + 0.4 + 2006-08-02 + psa + Modified recommended order of for server-to-server negotiations if service provisioning requires dialback after TLS negotiation. + + + 0.3 + 2006-01-24 + psa + Split into client-to-server and server-to-server sections; specified recommended order of server-to-server negotiations. + + + 0.2 + 2006-01-16 + psa + Changed order of SASL and stream compression to reflect list discussion. + + + 0.1 + 2006-01-11 + psa + Initial JEP version. + + + 0.0.1 + 2006-01-10 + psa + First draft. + +
+ +

During its formalization of the core Jabber protocols, the IETF's XMPP WG introduced the concept of XML stream features. While the order in which features shall be negotiated is clearly defined for the features specified in &rfc3920; and &rfc3921;, the number of possible features is open-ended (which is why the ®ISTRAR; maintains a registry of stream features). This document specifies the recommended order for negotiation of various stream features.

+ + + +

The XMPP RFCs define an ordering for the features defined therein, namely:

+
    +
  1. TLS
    2. +
  2. SASL
    3. +
  3. Resource binding
    4. +
  4. IM session establishment
    5. +
+

That order MUST be followed if no other stream features are negotiated.

+ + +

&jep0138; is negotiated when it is not possible to set TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation of both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:

+
    +
  1. TLS
    2. +
  2. SASL
    3. +
  3. Stream compression
    4. +
  4. Resource binding
    5. +
  5. IM session establishment
    6. +
+ + +

The &jep0077; protocol can be used to establish an account before logging in. That step would be completed before SASL because an entity cannot authenticate if it does not first create an account. Therefore the following order is RECOMMENDED:

+
    +
  1. TLS
    2. +
  2. In-band registration
    3. +
  3. SASL
    4. +
  4. Resource binding
    5. +
  5. IM session establishment
    6. +
+

If both stream compression and in-band registration are negotiated, the following order is RECOMMENDED:

+
    +
  1. TLS
    2. +
  2. In-band registration
    3. +
  3. SASL
    4. +
  4. Stream compression
    5. +
  5. Resource binding
    6. +
  6. IM session establishment
    7. +
+ + +

The legacy &jep0078; protocol can be used by clients to log into older (pre-XMPP) servers. In essence the "jabber:iq:auth" protocol is an older way of doing what the XMPP RFCs specify in the SASL, resource binding, and IM session stream features. Therefore the following order is RECOMMENDED:

+
    +
  1. TLS
    2. +
  2. jabber:iq:auth
    3. +
+

If the "jabber:iq:auth" feature is negotiated, then SASL, resource binding, and IM session establishment MUST NOT be negotiated. TLS SHOULD be negotiated, but some older software will instead connect to an SSL-enabled port rather than upgrading port 5222 using TLS.

+

If both stream compression and non-SASL authentication are negotiated, the following order is RECOMMENDED:

+
    +
  1. TLS
    2. +
  2. jabber:iq:auth
    3. +
  3. Stream compression
    4. +
+ + +

Support for the &jep0079; protocol is advertised as a stream feature but its use is not negotiated; therefore no recommendation is needed.

+ + + + +

The XMPP RFCs define an ordering for the features defined therein, namely:

+
    +
  1. TLS
    2. +
  2. SASL
    3. +
+

That order MUST be followed if no other stream features are negotiated.

+ + +

RFC 3920 requires SASL negotiation after TLS negotiation. When the certificate presented by the initiating entity makes reference to a trusted root certification authority, SASL negotiation provides meaningful authentication. In that case, the order shown above is recommended.

+

However, it is possible that the initiating entity will present a self-signed certificate or a certificate whose associated root certification authority is not trusted by the receiving entity. In this situation, service provisioning policies at the receiving entity may dictate the use of server dialback in order to provide a stronger level of trust for the server-to-server stream (where such trust is essentially trust in the underlying Domain Name System), even though server dialback explicitly does not provide authentication. In this case, the following order is RECOMMENDED:

+
    +
  1. TLS
    2. +
  2. Dialback
    3. +
+ + +

&jep0138; is negotiated when it is not possible to set TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation fo both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:

+
    +
  1. TLS
    2. +
  2. SASL
    3. +
  3. Stream compression
    4. +
+

If stream compression is negotiated in addition to TLS and dialback, it is RECOMMENDED to negotiate it after both TLS and dialback:

+
    +
  1. TLS
    2. +
  2. Dialback
    3. +
  3. Stream compression
    4. +
+ + + +

The order of negotiated stream features has security implications and may be security-critical. In particular, TLS MUST be negotiated first.

+ + +

This JEP requires no interaction with &IANA;.

+ + +

This JEP requires no interaction with the Jabber Registrar.

+ + diff --git a/xep-0171.xml b/xep-0171.xml new file mode 100644 index 00000000..1d00128d --- /dev/null +++ b/xep-0171.xml @@ -0,0 +1,467 @@ + + +%ents; +]> + + +
+ Language Translation + This JEP defines a protocol for providing language translation facilities over XMPP. It supports human, machine, client-based, and server-based translations. + &LEGALNOTICE; + 0171 + Experimental + Standards Track + Standards JIG + Council + + XMPP Core + XMPP IM + JEP-0030 + + + + langtrans + + Boyd + Fletcher + boyd@spawar.navy.mil + + + Daniel + LaPrade + daniel.laprade@je.jfcom.mil + + + Keith + Lirette + keith.lirette@je.jfcom.mil + + + Brian + Raymond + brian.raymond@je.jfcom.mil + + + 0.2 + 2006-04-24 + psa + Added text about use of Thread IDs. + + + 0.1 + 2006-01-24 + psa + Initial JEP version. + + + 0.0.4 + 2006-01-17 + psa + Converted to JEP format, cleaned up text, modified examples, changed pivotable and reviewed attributes to xs:boolean, corrected schema. + + + 0.0.3 + 2006-01-16 + bf + Changed xml:lang to destination, derived to derived_from; added service discovery identity. + + + 0.0.2 + 2005-12-28 + bf + Miscellaneous edits. + + + 0.0.1 + 2005-12-21 + bf + First draft. + +
+ +

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 XMPP (see &rfc3920;). 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.

+ + + + + + + + + + + +
TermDefinition
Original TextThis is the message text that was originally created by the sender. This is the text that is translated.
Translated TextThis 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 LanguagePivoting 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 TextThis 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 EngineSince 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 SetSome 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.
+ + +

The protocol defined herein addresses the following requirements:

+
    +

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

    2. +
  2. +

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

    +
      +
    1. Identification of Original Text
      2. +
    2. Identification of Translated Text
      3. +
    3. Identification of any Pivot Language(s) and Text
      4. +
    4. Identification of the method and order of translation
      5. +
    +
    3. +
  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. +
    2. Identification of Location of the translation.
      3. +
    3. Identification of Sender and Destination language of choice.
      4. +
    4. Discovery of Server support for translation including which language pair, dictionaries, and engines are available.
      5. +
    5. Identification of desire to text to be translated or not to be translated.
      6. +
    +
    4. +
+

The following methods of translation are supported:

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

The following use cases simple scenarios for expression translation as well as requesting them from remote entities.

+ +

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. +
  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. +
  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. +
+ + + Hello + Bonjour + How are you? + comment allez-vous? + + + + + ]]> + + +

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.

+ + Bonjour + Hello + x443;лте + comment allez-vous? + How are you? + Как вы? + + + + + + ]]> + + +

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.

+ + Bonjour + Hello + x443;лте + comment allez-vous? + How are you? + Как вы? + + + + + + ]]> + + + + +

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 &jep0030;. The server SHOULD return the availability of of translation providers and language pairings for which the user has rights to use.

+ + + + ]]> + + + ... + + + ... + + + ]]> + + +

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

+ + + + ]]> + + + ... + + + ... + + + ]]> + + +

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.

+ + + + ]]> + + + + + + + + + + + + ]]> + + + + +

To request service from a translation provider you can send a message to a provider requesting translations. The lack of a 'derived_from' attribute in the <translation/> element indicates a request for a translation. The request SHOULD include an XMPP &THREAD; element for tracking purposes.

+ + 5f3ea6f710337db2388e965e837fcc96334361e4 + Hello + How are you? + + + + + ]]> +

If the translation request included a Thread ID, the translation provider MUST echo that thread in its response so that the requesting entity can keep associate the response with the request.

+ + 5f3ea6f710337db2388e965e837fcc96334361e4 + Bonjour + Hello + comment allez-vous? + How are you? + + + + + ]]> + + + + 5f3ea6f710337db2388e965e837fcc96334361e4 + Hello + How are you? + + + + + + ]]> + + 5f3ea6f710337db2388e965e837fcc96334361e4 + Hello + Bonjour + x443;лте + comment allez-vous? + How are you? + Как вы? + + + + + + ]]> + + +

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.

+ + 5f3ea6f710337db2388e965e837fcc96334361e4 + Hello + How are you? + + + + + ]]> + + 5f3ea6f710337db2388e965e837fcc96334361e4 + Bonjour + Hello + comment allez-vous? + How are you? + + + + + ]]> +

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.

+ + + + + + ]]> +

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

+ + + + + + ]]> + + + + +

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. +
  2. The display of translated message should clearly show how (automated, manual, automated with human review) a messaged was translated.
    3. +
  3. The display of a message should clearly show if the translation is the destination, original or pivot language.
    4. +
  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. +
  5. It is recommended that only one level of pivoting be used as quality of the destination translation degrades significantly after each pivot.
    6. +
+

Note: The 'reviewed' and 'pivotable' attributes are of type "boolean" and MUST be handled accordingly. &BOOLEANNOTE;

+ + +

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

+ + +

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.

+ + +

This JEP requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; shall include 'http://jabber.org/protocol/langtrans' and 'http://jabber.org/protocol/langtrans#items' in its registry of protocol namespaces.

+ + +

The Jabber Registrar shall add a type of "translation" to the "automation" category in its registry of service discovery identities.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + + diff --git a/xep-0172.xml b/xep-0172.xml new file mode 100644 index 00000000..6a1b6f26 --- /dev/null +++ b/xep-0172.xml @@ -0,0 +1,401 @@ + + +%ents; +]> + + +
+ User Nickname + This document defines a protocol for communicating user nicknames. + &LEGALNOTICE; + 0172 + Draft + Standards Track + Standards JIG + Council + + XMPP Core + + + + nick + + http://jabber.org/protocol/nick/nick.xsd + + &stpeter; + &val; + + 1.0 + 2006-06-05 + psa +

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

 + + + 0.9 + 2006-05-10 + psa +

Added pubsub examples.

 + + + 0.8 + 2006-04-28 + psa +

Clarified terminology; explicitly mentioned that nicknames must not be included in presence broadcasts (only subscription requests); added implementation note about display names.

 + + + 0.7 + 2006-04-21 + psa/vm +

Added further detail to waitlist example; added schema.

 + + + 0.6 + 2006-03-27 + psa +

Specified security considerations.

 + + + 0.5 + 2006-03-22 + psa +

Fixed MUC invite example; clarified that nick refers to entity associated with nearest ancestor element that specifies a sender; added waitlist example.

 + + + 0.4 + 2006-03-20 + psa +

To reflect use of dedicated namespace, (1) changed JEP type from Informational to Standards Track and (2) updated Jabber Registrar Considerations.

 + + + 0.3 + 2006-03-16 + psa/vm +

Modified to use dedicated namespace; added example for multi-user chat invitations.

 + + + 0.2 + 2006-03-08 + psa +

Added wrapper element from JEP-0154.

 + + + 0.1 + 2006-01-24 + psa +

Initial JEP version.

 + + + 0.0.3 + 2006-01-22 + psa/vm +

Added message exchange use case.

 + + + 0.0.2 + 2006-01-18 + psa/vm +

Added MUC and nickname management use cases; specified profile data syntax.

 + + + 0.0.1 + 2005-09-12 + psa +

Initial version.

 + +
+ +

A nickname is a global, memorable (but not necessarily unique) friendly or informal name chosen by the owner of a bare JID (&BAREJID;) for the purpose of associating a distinctive mapping between the person's unique JID and non-unique nickname. While nicknames have been a common feature of instant messaging systems for many years, they have not always featured prominently in Jabber/XMPP IM systems (e.g., nicknames are not specified in &rfc3921;). However, there are several reasons why nicknames are important:

+
    +
  • Users like them.
    • +
  • They are easier to remember than JIDs.
    • +
  • They can be used to help prevent mimicking of JIDs (see &jep0165;).
    • +
+

This document defines best practices that enable IM users to advertise their preferred nicknames over Jabber/XMPP instant messaging networks.

+ + +

This proposal draws a distinction between the following kinds of names, where a JID is an innate feature of a user's identity on an XMPP system, a nickname is asserted by a user, and a handle is assigned by a contact to a user.

+ + + + + + + + + + + + + + + + + +
NameDefinition
Jabber ID (JID)A global and unique XMPP identifier registered to a particular user, of the form &BAREJID;; represented in the 'from' attribute of XML stanzas sent by that user, the 'jid' attribute of items associated with that user in a contact's roster, etc.
NicknameA global and memorable (but not necessarily unique) friendly name or informal name asserted by an IM user. Typically, a nickname is different from a familiar name, such as "Chuck" for "Charles", "Bill" for "William", "Pete" for "Peter", or "Dave" for "David"; instead, a nickname is even less formal, such as "stpeter" or "dizzyd". A nickname is thus typically different from a "display name" as that term is understood in SMTP (see &rfc2821;) and SIP (see &rfc3261;).
HandleA private, unique, and memorable "petname" or "alias" assigned by a contact to a user; represented in the 'name' attribute of the item associated with that user's JID in the contact's roster. In RFC 3921, the name here called a "handle" is described as an "alias"; rfc3921 will be modified to use the term "handle" instead.
+ + +

A nickname MUST be encapsulated as the XML character data of a <nick/> element qualified by the 'http://jabber.org/protocol/nick' namespace. Here is an example:

+ Ishmael + ]]> +

A nickname of this form has the same semantic meaning as the following data fields:

+
    +
  • The "NICKNAME" field specified in &jep0054;.
    • +
  • The "nickname" field specified in &jep0154;.
    • +
  • The "nickname" field specified in &jep0077;.
    • +
  • The "nick" field specified in &foaf;.
    • +
  • The "Alias" field specified in the Extensible Name and Address Language See <http://xml.coverpages.org/xnal.html>. developed by &OASIS;.
    • +
+

The entity to which the <nick/> refers is the from address (no matter how encapsulated in XML) of the nearest ancestor element that specifies the sender (which might be a parent or grandparent element, e.g. the 'from' attribute of an &IQ; stanza).

+ + +

In general, a user SHOULD include his or her nickname when establishing initial communication with a contact or group of contacts (i.e., the user has never been in communication with and does not have a prior relationship with the contact or group of contacts). Appropriate use cases therefore include:

+
    +
  • Presence subscription requests
    • +
  • Message exchange
    • +
  • Multi-user chat
    • +
  • Waiting lists
    • +
+ +

As defined in RFC 3921, a presence subscription request contains only the JID of the sender:

+ + ]]> +

Naturally, based on the JID of the sender, it is possible for the client to pull information about the sender from a persistent data store such as an LDAP database, &jep0054; node, or JEP-0154 store. However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender:

+ + Ishmael + + ]]> +

Note: This document recommends sending the nickname only in presence subscription requests; the nickname MUST NOT be included in presence broadcasts (i.e., &PRESENCE; stanzas with no 'type' attribute or of type "unavailable").

+ + +

When a user begins to chat with a contact but the two parties have no pre-existing relationship or prior communications (e.g., no presence subscription or previous message exchange), the user SHOULD include the nickname with the first message sent to the contact:

+ + Call me Ishmael + Ishmael + + ]]> + + +

&jep0045; defines a protocol for groupchat rooms. A user specifies a "room nickname" when joining such a room (the resource identifier of the 'to' address):

+ + ]]> +

A user MAY specify his or her persistent nickname as well. This may be desirable because the user's preferred room nickname is already taken or because the service "locks down" room nicknames.

+ + Ishmael + + ]]> +

If a user includes his or her persistent nickname in the room join request, the nickname SHOULD also be included in any presence changes sent to the room:

+ + away + writing + Ishmael + + ]]> +

A nickname may also be included in a MUC room invitation:

+ + + + Ishmael + + + + ]]> +

Although the foregoing stanza may seem to violate the rule about associating a nick with the nearest ancestor element that specifies the sender's JID, the output from the MUC room does not violate that rule, since the room swaps the to and from addresses before sending the invitation to the invitee:

+ + + + Ishmael + + + + ]]> + + +

&jep0130; defines a protocol that enables a user to be informed when a contact signs up for an IM account. The user MAY include his or her nick in the request so that the contact can associate a nickname with the request.

+ + + + +45-555-1212 + + Ishmael + + + ]]> +

Naturally, the WaitingListService SHOULD pass the nick on to its InteropPartners as well:

+ + + + contact-number + + Ishmael + + + ]]> +

If an InteropPartner knows a contact's nickname when it returns results to the WaitingListService it SHOULD include the nickname:

+ + + + contact-number + Starbuck + + + + ]]> +

Finally, if the user's waiting list service knows the contact's nickname when it sends a notification to the user, it SHOULD include the nickname:

+ + This message contains a WaitingList item. + + + +45-555-1212 + Starbuck + + + + ]]> + + +

In order for a user to modify his or her nickname and notify contacts of that change, it is RECOMMENDED for clients to use &jep0163; (a.k.a. PEP).

+ + + + + CallMeIshmael + + + + + ]]> + + + + + CallMeIshmael + + + + +
+ + +. +. +. + ]]> +

If a JEP-0163-compliant personal eventing service is not available, a client SHOULD use a standalone &jep0060; service.

+ + + + + CallMeIshmael + + + + + ]]> + + + + + CallMeIshmael + + + + +
+ + +. +. +. + ]]> +

If a client does not support JEP-0060 or the subset thereof specified in JEP-0163, it MAY send one &MESSAGE; stanza to each of its contacts, containing the updated nickname (note: the client SHOULD send the messages in a staggered fashion in order to avoid server-enforced rate limiting, commonly known as "karma").

+ + CallMeIshmael + +. +. +. + ]]> + + + +

An IM client MAY use the user's own nickname as all or part of the "display name" shown to the user of that client (e.g., as the sending name in one-to-one chats and groupchats). For example, if the user whose JID is narrator@moby-dick.lit asserts that his nickname is "Ishmael", that user's client may show "Ishmael" as all or part of the user's display name. How the client shall store the display name is out of scope for this document; possible mechanisms include the user's local vCard, an organizational LDAP directory, &jep0049;, or JEP-0154.

+ + +

A nickname is a memorable, friendly name asserted by a user. There is no guarantee that any given nickname will be unique even within a particulat community (such as an enterprise or university), let alone across the Internet through federation of communities. Clients SHOULD warn users that nicknames asserted by contacts are not unique and that nickname collisions are possible. Clients also MUST NOT depend on nicknames to validate the identity of contacts; instead, nicknames SHOULD be used in conjunction with JIDs (which are globally unique) and user-assigned handles (which are private and unique) as described in JEP-0165 in order to provide a three-pronged approach to identity validation, preferably in combination with X.509 certificates.

+ + +

This JEP requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; includes 'http://jabber.org/protocol/nick' in its registry of protocol namespaces (see &NAMESPACES;).

+ + + + + + + + + + The protocol documented by this schema is defined in + JEP-0172: http://www.jabber.org/jeps/jep-0172.html + + + + + + + ]]> + + +

Thanks to Ian Paterson for his feedback.

+

Unbeknownst to the authors of this document, work on user nicknames was previously done by Richard Dobson (see <http://richard.dobson-i.net/jep.php?html=jep-01xx.xml>).

+ + diff --git a/xep-0173.xml b/xep-0173.xml new file mode 100644 index 00000000..a7094122 --- /dev/null +++ b/xep-0173.xml @@ -0,0 +1,218 @@ + + +%ents; +]> + + +
+ Pubsub Subscription Storage + This JEP defines a protocol for storing subscriptions to Pubsub nodes. + &LEGALNOTICE; + 0173 + Deferred + Historical + Standards JIG + Council + + XMPP Core + JEP-0049 + JEP-0060 + + + + pubsubs + + Magnus + Henoch + henoch@dtek.chalmers.se + legoscia@jabber.cd.chalmers.se + + + 0.1 + 2006-02-09 + psa +

Initial JEP version; changed title to Pubsub Subscription Storage; changed namespace to storage:pubsubs for consistency with other storage JEPs.

 + + + 0.0.4 + 2005-12-11 + mh +

Add resource attribute.

 + + + 0.0.3 + 2005-11-13 + mh +

Add subscription attribute.

 + + + 0.0.2 + 2005-10-28 + mh +

Fix typo and schema.

 + + + 0.0.1 + 2005-10-25 + mh +

First draft.

 + +
+ +

&jep0060; allows Jabber entities to subscribe to various kinds of information, but provides no way of remembering which nodes a user has subscribed to. Other protocols (e.g. &jep0080;, &jep0084;) allow information about a certain entity to be published to a Pubsub node. These protocols use &jep0030; to allow other entities to find the pubsub node used by a certain entity, but provide no way of performing the opposite mapping, from pubsub node to information source. This JEP attempts to fill that void, using &jep0049; for storing information about subscriptions.

+ + +

This protocol enables Jabber clients to do the following:

+
    +
  • Remember which pubsub nodes the entity has subscribed to, and what kind of information is available at each node
    • +
  • Update the mappings when subscriptions are added or removed
    • +
  • Correlate incoming pubsub events to subscriptions
    • +
+ + +

The <subscriptions/> element qualified by the 'storage:pubsubs' namespace is the root element used in the jabber:iq:private transactions. It has zero or more <subscription/> child elements, each of which MUST possess the following attributes:

+ +
    +
  • jid -- The JID of the pubsub service used
    • +
  • node -- The pubsub node at which the data is available
    • +
  • subscription -- The current subscription state, one of "none", "pending", "unconfigured" and "subscribed"
    • +
+ +

Additionally, the <subscription/> element MAY possess these attributes:

+
    +
  • resource -- The resource that is subscribed to this pubsub node. If the 'resource' attribute is absent, the bare JID is subscribed.
    • +
  • user -- The JID of the owner of this particular piece of data
    • +
  • targetns -- The namespace of the data in question
    • +
+ + + +

In this example, the user already has a subscription to Juliet's geolocation, possibly established through another client.

+ + + + + +]]> + + + + + + + +]]> + + + +

Due to the nature of JEP-0049, incremental updates are not possible; a client MUST send the entire <subscriptions/> node for each update. Before performing the update, the client SHOULD retrieve the stored subscriptions, and incorporate any changes.

+

In this example, the user has just subscribed to Romeo's tune (see &jep0118;). Assuming that retrieving happened as in the previous use case, updating the subscriptions proceeds as follows:

+ + + + + + + + +]]> + +]]> + + + +

Having recorded the retrieved mappings, the client is now prepared to identify incoming pubsub events. Assume that the following event arrives:

+ + + + + + Yes + Heart of the Sunrise + Yessongs + 3 + 686 + + + + + +]]> +

The client now knows that this information comes from romeo@montague.net.

+ + + +

Pubsub events offer an opportunity to spoof sender addresses e.g. through 'replyto' data (as specified by the &jep0033; protocol). This protocol attempts to close that hole. It does so by the following rules and assumptions:

+
    +
  • A client MUST add mappings (i.e. associations between a publisher's JID and a pubsub node) only from trustworthy sources, i.e. published disco items (see &jep0030;). This relies on disco information not being cracked or falsified.
    • +
  • A client MUST retrieve mappings only from trustworthy sources, i.e. private XML storage. This assumes that no-one but the user is able to change such information.
    • +
+ + +

This JEP requires no interaction with &IANA;.

+ + +

No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this JEP.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + diff --git a/xep-0174.xml b/xep-0174.xml new file mode 100644 index 00000000..25197cc4 --- /dev/null +++ b/xep-0174.xml @@ -0,0 +1,307 @@ + + +%ents; +]> + + +
+ Link-Local Messaging + This document describes how to establish XMPP-like communications over local networks using zero-configuration networking. + &LEGALNOTICE; + 0174 + Experimental + Standards Track + Standards JIG + Council + + XMPP Core + XMPP IM + RFC 3927 + draft-cheshire-dnsext-dns-sd + draft-cheshire-dnsext-multicastdns + + + + N/A + &stpeter; + + 0.8 + 2006-07-31 + psa +

Recommended use of TLS and SASL for stream security.

 + + + 0.7 + 2006-06-06 + psa +

Further clarified internationalization considerations.

 + + + 0.6 + 2006-06-05 + psa +

Clarified internationalization considerations and use of mDNS in unicast mode for avatar retrieval.

 + + + 0.5 + 2006-04-14 + psa +

Specified presence name conflict resolution procedure, offline procedure, use of DNS NULL record for icons, and handling of multiple network interfaces.

 + + + 0.4 + 2006-03-16 + psa +

Corrected PTR format and client discovery process.

 + + + 0.3 + 2006-02-23 + psa +

Added more details about DNS setup and stream initiation; specified internationalization considerations.

 + + + 0.2 + 2006-02-22 + psa +

Corrected information about Service Instance Name format, p2pj port, and presence discovery process.

 + + + 0.1 + 2006-02-09 + psa +

Initial JEP version; changed title to Link-Local Messaging.

 + + + 0.0.1 + 2006-02-07 + psa +

First draft.

 + +
+ +

XMPP as defined in &rfc3920; does not support direct client-to-client interactions, since it requires authentication with a server: an XMPP client is allowed access to the network only once it has authenticated with a server, and the server must not grant access if authentication fails for any reason. If an unauthenticated client attempts to communicate directly with another client, such communication will fail because all XMPP communications are sent through one or more servers and a client cannot inject messages onto the network without first authenticating with a server.

+

However, it is possible to establish an XMPP-like communications system on a local network using zero-configuration networking. In this situation, the clients obviate the XMPP requirement for authentication with a server by relying on zero-configuration networking to establish link-local communication using the _presence._tcp DNS SRV service type. Once discovery has been completed, the clients are then able to exchange messages and other structured data using the XMPP &MESSAGE; and &IQ; stanzas. Note well that such communications are restricted to the local network because of how zero-configuration networking works. It is impossible for clients that communicate via link-local addresses to insert messages into an XMPP network, which is why this kind of local "mesh" is most accurately referred to as an XMPP-like system that exists outside the context of existing XMPP networks (though see the Security Considerations regarding the ability to "forward" messages from a local mech to an XMPP network or vice-versa).

+

Such a local "mesh" can be quite valuable in certain circumstances. For instance, participants in a trade show or conference, users of the same WiFi hotspot, or employees on the same local area network can communicate without the need for a pre-configured server. For this reason, support for link-local messaging has been a feature of Apple's iChat client when operating in Bonjour (formerly Rendezvous) mode. Because it is desirable for other Jabber clients to support such functionality, this document describes how to use zero-configuration networking as the basis for link-local communication.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
TermDescription
BonjourApple Computer's implementation of zero-configuration networking, formerly known as Rendezvous. See <http://www.apple.com/macosx/features/bonjour/>.
DNS-SDA convention for naming and structuring DNS SRV records such that a client can dynamically discover a domain for a service using only standard DNS queries. See &dnssd;. For a full list of registered DNS-SD records, see <http://www.dns-sd.org/ServiceTypes.html>.
Link-local addressAn IPv4 or IPv6 address that is valid for communication with other devices connected to the same physical or logical link. See &rfc3927;.
Multicast DNS (mDNS)A technology that provides the ability to perform DNS-like operations on a local link in the absence of any conventional unicast DNS server. See &mdns;.
Zero-configuration networkingA set of technologies that enable the use of the Internet Protocol for local communications. See <http://www.zeroconf.org/>.
+ + +

In order to advertise its availability for link-local messaging, a client MUST publish four different kinds of DNS records:

+
    +
  1. +

    An address ("A") record of the following form:

    + +
    2. +
  2. +

    An "SRV" record (see &rfc2782;) of the following form:

    + IN SRV port-number username@machine-name.local. + ]]> +
    3. +
  3. +

    A "PTR" record (see &rfc2317; and &rfc1886;) of the following form:

    + +
    4. +
  4. +

    Optionally, various "TXT" records (see &rfc1464;) of the following form, as further described in to the TXT Records section of this document:

    + IN TXT "1st=user-first-name" + IN TXT "email=user-email-address" + IN TXT "jid=user-jabber-id" + IN TXT "last=user-last-name" + IN TXT "msg=freeform-availability-status" + IN TXT "phsh=sha1-hash-of-avatar" + IN TXT "port.p2pj=5298" + IN TXT "status=avail-away-or-dnd" + IN TXT "txtvers=1" + IN TXT "vc=capabilities-string" + ]]> +
    5. +
+

The "machine-name" is the name of the computer, the "username" is the system username of the principal currently logged into the computer, the "port" may be any unassigned port number, and the "ip-address" is the physical address of the computer on the local network.

+

So, for example, if the machine name is "roundabout", the username is "stpeter", the chosen port is "5526", the IP address is "10.2.1.187", and the personal information is that associated with the author of this document, the DNS records would be as follows:

+ +

The IPv4 and IPv6 addresses associated with a machine may vary depending on the local network to which the machine is connected. For example, on an Ethernet connection the physical address might be "10.2.1.187" but when the machine is connected to a wireless network, its physical address might change to "10.10.1.179".

+

In the unlikely event that the "presence name" (username@machine-name) asserted by a client is already taken by another entity on the network, the client MUST choose a different presence name, which SHOULD be formed by adding the digit "1" to the end of the username string, adding the digit "2" if the resulting presence name is already taken, and incrementing the digit until a unique presence name is constructed.

+ +

DNS-SD enables service definitions to include various TXT keys that specify parameters to be used in the context of the service type. The TXT keys defined for the _presence._tcp service are as follows:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameDescription
1stThe given or first name of the user.
emailThe email address of the user.
jidThe Jabber ID of the user.
lastThe family or last name of the user.
msgNatural-language text describing the user's state. This is equivalent to the XMPP &STATUS; element.
phshThe SHA-1 hash of the user's avatar icon or photo. The client should keep a local cache of icons keyed by hash. If the phsh value is not in the cache, the client should fetch the unknown icon and then cache it. Implementations should also include logic for expiring avatar icons. This SHOULD be requested using mDNS in unicast mode by sending a DNS query to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent FF02::FB).
port.p2pjThe (hardcoded) port for link-local communications. Clients MUST use the port discovered via SRV lookups and MUST ignore the value of this TXT field, which is included only for backwards-compatibility with some older, existing implementations.
statusThe presence availability of the user. Allowable values are "avail", "away", and "dnd", which map to mere XMPP presence (the user is available) and the XMPP &SHOW; values of "away" and "dnd", respectively.
txtversThe version of the TXT fields supported by the client. This document describes txtvers "1".
vcA flag advertising the user's ability to engage in audio or video conferencing. If the user is able to engage in audio conferencing, the string MUST include the "A" character. If the user is able to engage in video conferencing, the string MUST include the "V" character. If the user is able to engage in conferencing with more than one participant, the string MUST include the "C" character. If the user is not currently engaged in an audio or video conference, the string MUST include the "!" character. The order of characters in the string is immaterial.
+

It is OPTIONAL to include any of these TXT keys, since link-local messaging can be used by non-human entities (e.g., devices) and these keys relate to human users. However, for use by humans, certain keys are of greater interest than others, e.g. the "msg" and "status" keys. See also the Security Considerations section of this document regarding the inclusion of information that may have an impact on personal privacy (e.g., the "1st", "last", "email", and "jid" keys).

+ + + +

In order to discover other users, a client sends an mDNS request for PTR records that match "_presence_tcp.local.". The client then receives replies from all machines that advertise support for link-local messaging. The replies will include a record corresponding the client itself; the client MUST filter out this result. The client MAY then find out detailed information about each machine by sending SRV and TXT queries to "username@machine-name._presence._tcp.local." for each machine (however, to preserve bandwidth, the client SHOULD NOT send these queries unless it is about to initiate communications with the other user, and it MUST cancel the queries after it has received a response). Note: The presence name to be used for display in a link-local "roster" MUST be obtained from the <Instance> portion of the received PTR record for each user; the client MAY display a name or nickname derived from the TXT records if available.

+ + +

When the _presence._tcp service is used, presence is exchanged via the format described in the TXT Records section of this document. In particular, presence information is not pushed as in XMPP (see &rfc3921;). Instead, clients listen for presence announcements from other local entities. Recommended rates for sending updates can be found in Multicast DNS.

+ + +

In order to exchange link-local messages, the sender and recipient MUST first establish XML streams between themselves, as is familiar from RFC 3920.

+

First, the initating party opens a TCP connection at the IP address and port discovered via the DNS lookup for a local entity and opens an XML stream to the recipient with no 'to' or 'from' address:

+ + ]]> +

The recipient then responds with a stream header as well:

+ + ]]> +

The exchange of stream headers results in an unencrypted and unauthenticated channel between the two entities. Subject to client configuration and local service policies, two entities MAY accept such a channel. However, it is RECOMMENDED to use Transport Layer Security (TLS) for channel encryption (see &rfc4346;) and the Simple Authentication and Security Layer (SASL) for authentication (see &rfc4422;), in a manner essentially the same as that defined in RFC 3920. If the initiating party wishes to TLS and SASL, it MUST include a 'version' attribute with a value of "1.0" in the stream header it sends:

+ + ]]> +

If the receiving entity supports TLS and SASL for stream security, it MUST also include the 'version' attribute:

+ + ]]> +

The parties then can complete TLS and SASL negotiation (including stream feature advertisement) as specified in RFC 3920. A future version of this specification may include more detailed examples showing the relevant protocol flows. Handling of the 'version' attribute (or lack thereof) MUST follow the rules specified in RFC 3920.

+ + +

Once the streams are established, either entity then can send XMPP message or IQ stanzas by specifying 'to' and 'from' addresses using the logical local addresses: The "JIDs" MUST be of the form "username@machine-name" as discovered via SRV (this is the <Instance> portion of the Service Instance Name).

+ + hey, testing out link-local messaging + + ]]> + + +

To end the chat, either party closes the XML stream:

+ + ]]> +

The other party then closes the stream in the other direction as well:

+ + ]]> +

Both parties then MUST close the TCP connection between them.

+ + +

In order to go offline, a client MUST send a Multicast DNS "Goodbye" packet for the user's PTR record. As a result, all other entities on the local network will receive a Multicast DNS "Remove" event, at which point they MUST cancel any outstanding TXT, SRV, or NULL record queries for the offline user.

+ + + +

Devices that use link-local messaging may have multiple network interfaces. As a result, it is possible to discover the same entity multiple times. Even if a client discovers the same presence name on multiple network interfaces, it MUST show only one entity in the local roster. In addition, because local IP addresses can be dynamically re-assigned, the client SHOULD NOT store the IP address to be used for communications when it discovers that address in the initial DNS lookup phase; instead, it SHOULD delay sending the Multicast DNS query until the client is ready to communicate with the other entity.

+ + +

If an entity has an associated icon (e.g., a user avatar or photo), its client SHOULD publish the raw binary data for that image via a DNS NULL record of the following form:

+ +

Note: In accordance with &rfc1035;, the data MUST be 65535 octets or less.

+

After retrieving the "phsh" value from a Buddy's TXT record, a client SHOULD search its local picture database to learn the last recorded picture hash value for an entity and then compare it to the "phsh" value in the TXT record. If the values are equal, the client SHOULD use the local copy of the icon. If the picture hash values are not equal, the client SHOULD issue a Multicast DNS NULL record query to retrieve the new icon. After retrieving the NULL record, the client SHOULD replace the old "phsh" value in the picture database with the new "phsh" value and save the icon to disk. If the client needs to send a Multicast DNS query in order to retrieve the icon, it MUST cancel the NULL record query immediately after receiving a response containing the new picture data.

+

If a user changes their picture, the user's client MUST update the NULL record with the contents of the new picture, calculate a new picture hash, and then update the "phsh" value in the TXT record with the new hash value. Since all users logged into local presence are monitoring for TXT record changes, they will see that the "phsh" value was changed; if they wish to view the new icon, their clients SHOULD issue a new Multicast DNS query to retrieve the updated picture.

+ + + +

RFC 1035 does not allow characters outside the &ascii; character range in DNS A records. Therefore the "machine-name" portion of an A record as used for link-local messaging MUST NOT contain characters outside the US-ASCII character range.

+

Although RFC 2317 and RFC 2782 do not allow characters outside the US-ASCII character range in PTR and SRV records respectively, Section 4.1 of DNS-Based Service Discovery recommends support for UTF-8-encoded Unicode characters in the <Instance> portion of Service Instance Names, which in link-local messaging is the "username@machine-name" portion of the PTR or SRV record. This document adheres to the recommendation in DNS-Based Service Discovery. However, as mentioned above, the "machine-name" portion of the <Instance> portion MUST NOT contain characters outside the US-ASCII range.

+

Although RFC 1464 does not allow characters outside the US-ASCII character range in TXT records, Section 6.5 of DNS-Based Service Discovery mentions support for UTF-8-encoded Unicode characters in text record values (e.g., values of the TXT "msg" name). This document adheres to the recommendation in DNS-Based Service Discovery.

+ + +

XMPP networks depend on TLS (&rfc2246;) for channel encryption, SASL (&rfc4422;) for authentication, and the Domain Name System (&rfc1034;) for validation of server hostnames; these technologies help to ensure the identity of sending entities. By contrast, zero-configuration networking uses dynamic discovery and asserted machine names as the basis of sender identity. Therefore, zero-configuration networking does not result in authenticated identities in the same way that XMPP itself does, nor does it provide for an encrypted channel between local entities. (TLS could be negotiated on the local streams, but is out of scope for this specification.)

+

Because of fundamental differences between a true XMPP network and a localized XMPP client "mesh", local entities MUST NOT attempt to inject local traffic onto an XMPP network and an XMPP server MUST reject communications until an entity is properly authenticated. However, a client on a local mesh MAY forward traffic to an XMPP network after having properly authenticated on such a network (e.g., to forward a message received on a local client mesh to a contact on an XMPP network).

+

The TXT records optionally advertised as part of this protocol MAY result in exposure of privacy-sensitive information about a human user (such as full name, email address, and Jabber ID). A client MUST allow a user to disable publication of this personal information (e.g., via client configuration).

+ + +

The p2pj port number 5298 is not included in the &ianaports; maintained by &IANA;. The author will investigate whether that port number (or some other port number) needs to be registered.

+ + +

This document requires no interaction with the ®ISTRAR;.

+ + +

Thanks to Justin Karneges, Jens Alfke, and Marc Krochmal for their input.

+ + diff --git a/xep-0175.xml b/xep-0175.xml new file mode 100644 index 00000000..58a401ac --- /dev/null +++ b/xep-0175.xml @@ -0,0 +1,155 @@ + + +%ents; +]> + + +
+ Best Practices for Use of SASL ANONYMOUS + This document specifies best practices for use of the SASL ANONYMOUS mechanism in the context of client authentication with an XMPP server. + &LEGALNOTICE; + 0175 + Active + Informational + Standards JIG + Council + + XMPP Core + + + + N/A + &stpeter; + + 1.0 + 2006-09-20 + psa +

Per a vote of the Jabber Council, advanced status to Active.

 + + + 0.1 + 2006-02-09 + psa +

Initial JEP version; modified flow to remove unecessary challenge.

 + + + 0.0.1 + 2006-01-24 + psa +

First draft.

 + +
+ + &BISNOTE; +

RFC 3920 allows the use of any SASL mechanism (see &rfc4422;) in XMPP authentication, including the SASL ANONYMOUS mechanism (see &rfc4505;). This document specifies a recommended protocol flow for such use.

+

Note: This document is provided for discussion purposes in order to clarify the usage of SASL ANONYMOUS in XMPP systems. It is not meant to supersede the text in RFC 3920, RFC 4422, or RFC 4505. However, the recommendations in this document may be folded into rfc3920bis when that document is written.

+ + +

RFC 3920 specifies that after an XMPP client authenticates with an XMPP server, it must bind a resource to the XML stream so that XML stanzas can be routed to the client. In essence there are three resource binding scenarios:

+
    +
  1. The client specifies a desired resource identifier and the server accepts it.
    2. +
  2. The client specifies a desired resource identifier but the server does not accept it, instead overruling the client and assigning a resource identifier.
    3. +
  3. The client asks the server to assign a resource identifier and the server does so.
    4. +
+

No matter which scenario is enacted, at the end of the process the server informs the client of its full JID (&FULLJID;). In particular, it might be helpful for an XMPP server to assign a full JID to the client (i.e., not just the resource identifier) if it authenticates with SASL ANONYMOUS, and to ensure that the "bare JID" portion (&BAREJID;) is unique in the context of the domain served by the server.

+

The RECOMMENDED protocol flow following TLS negotiation (refer to RFC 3920) is as follows:

+
    +
  1. +

    Client initiates stream to server.

    + + ]]> +
    2. +
  2. +

    Server replies with stream header.

    + + ]]> +
    3. +
  3. +

    Server advertises stream features.

    + + + DIGEST-MD5 + ANONYMOUS + + + ]]> +
    4. +
  4. +

    Client requests SASL ANONYMOUS mechanism.

    + + ]]> +
    5. +
  5. +

    Server sends <success/>.

    + + ]]> +
    6. +
  6. +

    Client opens new stream.

    + + ]]> +
    7. +
  7. +

    Server tells client that resource binding is required.

    + + + + + ]]> +
    8. +
  8. +

    Client requests that server create a resource for it.

    + + + + ]]> +
    9. +
  9. +

    Server replies with full JID.

    + + + somenode@example.com/someresource + + + ]]> +
    10. +
+ + +

This JEP introduces no security considerations or concerns above and beyond those discussed in RFC 3920.

+ + +

This JEP requires no interaction with &IANA;.

+ + +

This JEP requires no interaction with the ®ISTRAR;.

+ + diff --git a/xep-0176.xml b/xep-0176.xml new file mode 100644 index 00000000..02e16ad4 --- /dev/null +++ b/xep-0176.xml @@ -0,0 +1,522 @@ + + +%ents; +ICE-10"> +]> + + +
+ Jingle ICE Transport + This document defines a Jingle transport method that results in sending data between two entities using Interactive Connectivity Establishment (ICE) methodology. + &LEGALNOTICE; + 0176 + Experimental + Standards Track + Standards JIG + Council + + XMPP Core + JEP-0166 + + + + ice + &stpeter; + &joebeda; + &scottlu; + &hildjj; + &seanegan; + + 0.4 + 2006-09-13 + psa +

Updated to track ICE-10; added section on service discovery.

 + + + 0.3 + 2006-07-12 + se/psa +

Specified that DTMF must use in-band signalling (JEP-0181).

 + + + 0.2 + 2006-03-24 + psa +

Recommended use of RTP-native methods for DTMF.

 + + + 0.1 + 2006-03-01 + psa/jb + Initial JEP version (split from JEP-0166). + +
+ +

&jep0166; defines a framework for negotiating and managing out-of-band data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor content (session) types, leaving that up to separate specifications. The current document defines a transport method for establishing and managing data connections between XMPP entities, using the &ice; methodology currently being developed within the IETF.

+

The process for ICE negotiation is largely the same in Jingle as it is in draft-ietf-mmusic-ice. There are several differences:

+
    +
  • Instead of using SIP as the signalling channel, Jingle uses XMPP as the signalling channel.
    • +
  • In Jingle, each candidate transport is sent in a separate IQ exchange (rather than sending all candidates at once as in draft-ietf-mmusic-ice); this approach takes advantage of the request-response semantics of the XMPP &IQ; stanza type and enables the parties to send higher-priority candidates earlier in the negotiation.
    • +
  • Syntax from the Session Description Protocol (see &rfc4566;) is mapped to an XML syntax suitable for sending over the XMPP signalling channel.
    • +
+

Note: This JEP depends on the IETF's Interactive Connectivity Establishment (ICE) specification, which is a work in progress. Every effort has been made to keep this JEP synchronized with draft-ietf-mmusic-ice, for which the latest published version is 10 (hereafter referred to as "&ice10;"). The interested reader is referred to the &ice10; for a detailed description of the ICE methodology, which for the most part this JEP merely maps to XMPP syntax.

+ + +

The Jingle transport method defined herein is designed to meet the following requirements:

+
    +
  1. Make it possible to establish and manage out-of-band connections between two XMPP entities, even if they are behind Network Address Translators (NATs) or firewalls.
    2. +
  2. Make it relatively easy to implement support in standard Jabber/XMPP clients.
    3. +
  3. Where communication with non-XMPP entities is needed, push as much complexity as possible onto server-side gateways between the XMPP network and the non-XMPP network.
    4. +
+ + +

The reader is referred to draft-ietf-mmusic-ice for a description of various terms used in the context of ICE. Those terms are not reproduced here.

+ + + +

In order for the initiator in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in JEP-0166. This stanza MUST include at least one transport method. If the initiator wishes to negotiate the ICE transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/ice' namespace.

+ + + + + ... + + + + ... + + + + + ]]> + + +

As described in JEP-0166, to provisionally accept the session initiation request, the responder returns an IQ-result:

+ + ]]> + + +

If the responder provisionally accepts the session initiation request as shown above, both initiator and responder MUST immediately negotiate connectivity over the ICE transport by exchanging XML-formatted candidate transports for the channel. This negotiation proceeds immediately in order to maximize the possibility that media can be exchanged as quickly as possible. Concurrent with negotiation of the ICE candidates, it is possible for the initiator and responder to negotiate which content types the session will include, which transport methods will be tried for each content type, etc. Those negotiation flows are shown in JEP-0166. This JEP specifies only negotiation of the ICE transport method.

+

The candidate syntax and negotiation flow are described below.

+ +

The following is an example of the candidate format:

+ + + + + + + + ]]> +

The attributes of the <candidate/> element are described in the following table:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameDescriptionSDP SyntaxExample
componentA Component ID as defined in &ice10;Component ID value in a=candidate line1
foundationA Foundation as defined in &ice10;Foundation value in a=candidate line1
generationAn index, starting at 0, that enables the parties to keep track of updates to the candidate throughout the life of the sessionN/A0
ipThe Internet Protocol (IP) address for the candidate transport mechanism; this may be either an IPv4 address or an IPv6 addressIP Address value in a=candidate line10.0.1.1
networkAn index, starting at 0, referencing which network this candidate is on for a given peer (used for diagnostic purposes if the calling hardware has more than one Network Interface Card or NIC)N/A0
portThe port at the candidate IP addressPort value in a=candidate line8998
priorityA Priority as defined in &ice10;Priority value in a=candidate line9909
protocolThe protocol to be used; allowable values are: "udp" (when standard &ice10; is used); "tcp", "tcp-act", and "tcp-pass" (when &ice-tcp; is used); and "ssltcp" (definition to follow)a=ice-ufrag lineudp
pwdA Password as defined in &ice10;a=ice-pwd lineasd88fgpdd777uzjYhagZg
typeA Candidate Type as defined in &ice10;; the allowable values are "host" for host candidates, "srflx" for server reflexive candidates, "prflx" for peer reflexive candidates, and "relay" for relayed candidatesTyp field in a=candidate linesrflx
ufragA User Fragment as defined in &ice10;a=ice-ufrag line8hhy
+ + +

The first step in negotiating connectivity is for each client to immediately begin sending candidate transport methods to the other client. These candidates SHOULD be gathered by following the procedure specified in Section 4.1 of &ice10; and prioritized by following the procedure specified in Section 4.2 of &ice10;. Each candidate MUST be sent in a &JINGLE; element with an action of "transport-info".

+

If the responder receives and can successfully process a given candidate, it returns an IQ-result (if not, for example because the candidate data is improperly formatted, it returns an error).

+

Note well that the responder is only indicating receipt of the candidate, not telling the initiator that the candidate will be used.

+

The initiator keeps sending candidates, one after the other (without stopping to receive an acknowledgement of receipt from the responder for each candidate) until it has exhausted its supply of possible or desirable candidate transports. (Because certain candidates may be more "expensive" in terms of bandwidth or processing power, the initiator may not want to advertise their existence unless necessary.) For each candidate, the responder acknowledges receipt.

+

At the same time (i.e., immediately after provisionally accepting the session, not waiting for the initiator to begin or finish sending candidates), the responder also begins sending candidates that may work for it. As above, the initiator acknowledges receipt of the candidates.

+

As the initiator and responder receive candidates, they probe the various candidate transports for connectivity. In performing these connectivity checks, client SHOULD follow the procedure specified in Section 7 of &ice10;.

+ + + + + + + + ]]> + + + + + + + + ]]> + + + + + + + + ]]> +

For each candidate received, the other party MUST acknowledge receipt or return an error:

+ + + + + + ]]> + + + +

If, based on STUN connectivity checks, the responder determines that it will be able to establish a connection using a given candidate, it sends a &JINGLE; element with an action of 'transport-accept' to the initiator, specifying the candidate that succeeded:

+ + + + + + + + ]]> +

The &JINGLE; element in the transport-accept stanza SHOULD possess a 'responder' attribute that explicitly specifies the full JID of the responding entity. If provided, all future commmunications SHOULD be sent to the JID provided in the 'responder' attribute.

+

If the initiator can also send data over that candidate, then it acknowledges the responder's acceptance:

+ + ]]> +

Now the initiator and responder can begin sending data over the negotiated connection.

+

If a candidate succeeeded for the responder but the initiator cannot send data over that candidate, it MUST return a ¬acceptable; error in response to the responder's acceptance of the successful candidate:

+ + + + + + + + + + + ]]> +

If the responder cannot find a suitable candidate transport or it receives a ¬acceptable; errror from the initiator in response to its acceptance of a suitable transport, it SHOULD terminate the session as described below.

+ + +

In order to gracefully end the session, either the responder or the initiator MUST a send a "terminate" action to the other party:

+ + + + ]]> +

The initiator then acknowledges termination of the session:

+ + ]]> +

Unfortunately, not all sessions end gracefully. The following events MUST be considered session-ending events, and any further communication for the session type MUST be completed through negotiation of a new session:

+
    +
  • Receipt of a 'redirect' or 'terminate' action from the other party.
    • +
  • Receipt of &UNAVAILABLE; from the other party.
    • +
+

In particular, one party MUST consider the session to be in the ENDED state if it receives presence of type "unavailable" from the other party:

+ + ]]> +

Naturally, in this case there is nothing for the initiator to acknowledge.

+ + + + +

If an entity supports this specification, it MUST return a feature of "http://jabber.org/protocol/jingle/transport/ice" in response to &jep0030; information requests.

+

As mentioned in the Deployment Notes of this document, server administrators may wish to deploy STUN servers in order to ease the process of negotiating use of the Jingle ICE transport. If a STUN server is accessible via XMPP, it SHOULD be advertised by returning an appropriate item in response to service discovery item requests sent to the address of an XMPP server:

+ + + + + + + + + + ]]> +

A subsequent service discovery information request to the STUN server MUST result in a response indicating that the STUN server has a service discovery category of "proxy" and type of "stun":

+ + + + + + + + + + + ]]> +

Because the XMPP interaction is necessary only in order to discover the identity of the STUN server, only support for the "http://jabber.org/protocol/disco#info" feature is RECOMMEND.

+

It is OPTIONAL for a STUN server to support XMPP, and STUN servers may be configured into an XMPP client via other means (e.g., user configuration or default settings). Client developers SHOULD NOT depend on the existence of XMPP-aware STUN servers.

+ + + + +

If it is necessary to send Dual Tone Multi-Frequency (DTMF) tones, it is REQUIRED to use the XML format specified &jep0181;.

+ + + + +

This specification applies exclusively to Jabber/XMPP clients and places no additional requirements on Jabber/XMPP servers. However, service administrators may wish to deploy a STUN server in order to ease the client-to-client negotiation process.

+ + + + +

In order to secure the end-to-end data stream, implementations SHOULD use encryption methods appropriate to the transport method in use.

+ + + + +

This JEP requires no interaction with &IANA;.

+ + + + +

The ®ISTRAR; shall include 'http://jabber.org/protocol/jingle/transport/ice' in its registry of protocol namespaces.

+ + +

The Jabber Registrar shall include "http://jabber.org/protocol/jingle/transport/ice" in its registry of Jingle transport methods. The registry submission is as follows:

+ ®PROCESS; + + ice + + A method for negotiation of out-of-band connections with built-in NAT and firewall traversal, + similar to the IETF's Interactive Connectivity Establishment (ICE) methodology. + + JEP-0176 + + ]]> + + +

The Jabber Registrar shall include a Service Discovery type of "stun" within the "proxy" category.

+

The registry submission is as follows:

+ + proxy + + stun + a STUN (Simple Traversal of UDP Through NATs) service per RFC 3489 + JEP-0176 + + + ]]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + diff --git a/xep-0177.xml b/xep-0177.xml new file mode 100644 index 00000000..e4045a58 --- /dev/null +++ b/xep-0177.xml @@ -0,0 +1,163 @@ + + +%ents; +]> + + +
+ Jingle Raw UDP Transport + This document defines a Jingle transport method that results in sending data over a raw User Datagram Protocol (UDP) connection. + &LEGALNOTICE; + 0177 + Experimental + Standards Track + Standards JIG + Council + + XMPP Core + JEP-0166 + + + + raw-udp + &joebeda; + &stpeter; + &scottlu; + &hildjj; + &seanegan; + + 0.2 + 2006-07-12 + se/psa + Removed candidate element and specified exchange of address information via transport-info messages; clarified usage of name attribute. + + + 0.1 + 2006-03-01 + psa/jb + Initial JEP version (split from JEP-0166). + +
+ +

&jep0166; defines a framework for negotiating and managing out-of-band data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor content (session) types, leaving that up to separate specifications. The current document defines a transport method for establishing and managing data between XMPP entities using a raw User Datagram Protocol (UDP) connection (see &rfc0768;).

+ + +

The Jingle transport method defined herein is designed to meet the following requirements:

+
    +
  1. Make it possible to establish and manage out-of-band connections between two XMPP entities over the IP address and port that the initiator considers most likely to succeed.
    2. +
  2. Make it relatively easy to implement support in standard Jabber/XMPP clients.
    3. +
  3. Where communication with non-XMPP entities is needed, push as much complexity as possible onto server-side gateways between the XMPP network and the non-XMPP network.
    4. +
+ + + +

In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in JEP-0166. This stanza MUST include at least one transport methods. If the initiating entity wishes to negotiate the Raw UDP transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/raw-udp' namespace.

+ + + + + + + ]]> + + +

As described in JEP-0166, to provisionally accept the session initiation request, the target entity returns an IQ-result:

+ + ]]> + + +

Once the session is provisionally accepted, each entity should send one &TRANSPORT; element in a transport-info meessage, containing exactly one &CANDIDATE; element per channel, whose 'ip' and 'port' attributes specify the IP address and port number of the candidate that the initiator has reason to believe will be most likely to succeed for that channel. (Note: In older versions of JEP-0166, this was referrred to as the "default candidate".) This is not necessarily the initiator's preferred address for communication, but instead is the "address most likely to succeed", i.e., the address that is assumed to be reachable by the vast majority of target entities. To determine reachability, the client needs classify ahead of time the permissiveness of the firewall or network address translator (NAT) it is behind, if any. If the NAT is symmetric (not permissive), the candidate SHOULD specify a relay address. Otherwise it SHOULD be an address derived via prior discovery using &rfc3489;, which will be an address on the outside of the firewall or NAT.

+ + + + + + + + ]]> +

Note: The 'name' attribute specifies the name of the channel and the 'generation' attribute provides a tracking mechanism for determining which version of this candidate is in force (this is useful if the candidate is redefined mid-stream, for example if the port is changed).

+

Either entity may send this transport-info message at any time, after which the recipient should send and receive data to and from the new address.

+ + + +

The syntax and semantics informational message payloads specific to the Raw UDP transport method will be defined in a future version of this specification.

+ + + + + +

In order to secure the end-to-end data stream, implementations SHOULD use encryption methods appropriate to the transport method in use.

+ + + + +

This JEP requires no interaction with &IANA;.

+ + + + +

The ®ISTRAR; shall include 'http://jabber.org/protocol/jingle/transport/raw-udp' in its registry of protocol namespaces.

+ + +

The Jabber Registrar shall include "http://jabber.org/protocol/jingle/transport/raw-udp" in its registry of Jingle transport methods. The registry submission is as follows:

+ ®PROCESS; + + raw-udp + A method for exchanging data over a raw UDP connection. + JEP-0176 + + ]]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + diff --git a/xep-0178.xml b/xep-0178.xml new file mode 100644 index 00000000..166ced97 --- /dev/null +++ b/xep-0178.xml @@ -0,0 +1,338 @@ + + +%ents; +]> + + +
+ Best Practices for Use of SASL EXTERNAL + This document specifies best practices for use of the SASL EXTERNAL mechanism within XMPP. + &LEGALNOTICE; + 0178 + Experimental + Informational + Standards JIG + Council + + XMPP Core + + + + N/A + &stpeter; + &pgmillard; + + 0.3 + 2006-09-21 + psa +

Added TLS and SASL required child elements per rfc3920bis.

 + + + 0.2 + 2006-03-09 + psa +

Corrected client-server failure case to place error in SASL flow rather than binding flow; added note about non-X.509 usages.

 + + + 0.1 + 2006-03-09 + psa +

Initial JEP version.

 + + + 0.0.3 + 2006-02-10 + psa/pgm +

Specified inclusion of authorization identity for server-to-server.

 + + + 0.0.2 + 2006-02-10 + psa/pgm +

Clarified distinction between authentication and authorization.

 + + + 0.0.1 + 2006-02-09 + psa/pgm +

First draft.

 + +
+ + &BISNOTE; +

RFC 3920 allows the use of any SASL mechanism (see &rfc4422;) in XMPP authentication, including the SASL EXTERNAL mechanism. This document specifies a recommended protocol flow for such use, specifically when use of TLS is required by a deployment. The protocol flows when TLS is not required are more complicated (e.g., alternate flows involving server dialback) and may be documented in a future version of this document.

+ + +

The RECOMMENDED protocol flow for client-to-server use of SASL EXTERNAL with end-user certificates is as follows:

+
    +
  1. +

    Client initiates stream to server.

    + + ]]> +
    2. +
  2. +

    Server replies with stream header.

    + + ]]> +
    3. +
  3. +

    Server advertises TLS stream feature.

    + + + + + + ]]> +
    4. +
  4. +

    Client sends STARTTLS command to server.

    + + ]]> +
    5. +
  5. +

    Server informs client to proceed.

    + + ]]> +
    6. +
  6. +

    Client presents certificate.

    +
    7. +
  7. +

    Server validates certificate.

    +
      +
    1. +

      If certification authority is untrusted or certificate has been revoked, server closes client's TCP connection.

      +
      2. +
    2. +

      Else server completes successful TLS negotiation and client initiates a new stream header to server.

      + + ]]> +
      3. +
    +
    8. +
  8. +

    Server replies with stream header.

    + + ]]> +
    9. +
  9. +

    Server advertises SASL mechanisms. Because client presented a certificate, server advertises and prefers SASL EXTERNAL mechanism.

    + + + EXTERNAL + DIGEST-MD5 + ANONYMOUS + + + + ]]> +
    10. +
  10. +

    Because client presented a certificate, client SHOULD consider EXTERNAL to be its preferred SASL mechanism. The client SHOULD NOT include an authorization identity (i.e., XML character data for the <auth/> element) since client-to-server authorization in XMPP is handled during resource binding.

    + + ]]> +
    11. +
  11. +

    Server determines whether to allow authenticatation of user.

    +
      +
    1. +

      If the certificate presented by the client contains only one valid XMPP address A valid XMPP address is a JID encapsulated as a subjectAltName with an ASN.1 Object Identifier of "id-on-xmppAddr" (which is equivalent to the dotted display format of "1.3.6.1.5.5.7.8.5"). that corresponds to a registered account on the server, the server SHOULD allow authentication of that JID.

      + + ]]> +
      2. +
    2. +

      If the certificate contains more than one valid XMPP address that corresponds to a registered account on the server (e.g., because the server offers virtual hosting), the server SHOULD allow authentication of the JID whose hostname matches the 'to' address of the stream header sent by the client to the server.

      + + ]]> +
      3. +
    3. +

      If the certificate does not contain a valid XMPP address that corresponds to a registered account on the server, the server MAY attempt to determine if there is a registered account associated with the user, for example by performing an LDAP lookup based on the Common Name in the certificate; if such a JID mapping is successful, the server SHOULD allow authentication of that mapped JID.

      + + ]]> +
      4. +
    4. +

      If the user cannot be associated with an account registered on the server, the server MUST return a SASL failure of <not-authorized/> and close the stream.

      + + + + + ]]> +
      5. +
    +
    12. +
  12. +

    If SASL authentication succeeded, client opens new stream, then client and server proceed with resource binding as described in RFC 3920.

    +
    13. +
+ + +

The RECOMMENDED protocol flow for server-to-server use of SASL EXTERNAL with server (domain) certificates is as follows:

+
    +
  1. +

    Server1 initiates stream to server2.

    + + ]]> +
    2. +
  2. +

    Server2 replies with stream header.

    + + ]]> +
    3. +
  3. +

    Server2 advertises TLS stream feature.

    + + + + + + ]]> +
    4. +
  4. +

    Server1 sends STARTTLS command to Server2.

    + + ]]> +
    5. +
  5. +

    Server2 informs Server1 to proceed.

    + + ]]> +
    6. +
  6. +

    Server1 presents certificate.

    +
    7. +
  7. +

    Server2 validates certificate.

    +
      +
    1. +

      If certification authority is untrusted or certificate has been revoked, Server2 closes Server1's TCP connection.

      +
      2. +
    2. +

      Else Server2 completes successful TLS negotiation and Server1 initiates a new stream header to Server2.

      + + ]]> +
      3. +
    +
    8. +
  8. +

    Server2 replies with stream header.

    + + ]]> +
    9. +
  9. +

    Server2 advertises SASL mechanisms. Because Server1 presented a certificate, Server2 advertises SASL EXTERNAL mechanism.

    + + + EXTERNAL + + + + ]]> +
    10. +
  10. +

    Because Server1 presented a certificate, Server1 SHOULD consider EXTERNAL to be its preferred SASL mechanism. Server1 SHOULD include an authorization identity (base64-encoded as described in RFC 3920) as the XML character data of the <auth/> element, which SHOULD be the same as the 'from' address on the stream header.

    + Y29uZmVyZW5jZS5leGFtcGxlLm9yZwo= + ]]> +

    (In this case, the authorization identity is "conference.example.org".)

    +
    11. +
  11. +

    Server2 determines if hostname is valid.

    +
      +
    1. +

      If the authorization identity provided by Server1 matches one of the valid XMPP addresses A valid XMPP address is a JID encapsulated as a subjectAltName with an ASN.1 Object Identifier of "id-on-xmppAddr" (which is equivalent to the dotted display format of "1.3.6.1.5.5.7.8.5"). in the certificate or one of the Common Names in the certificates, Server2 SHOULD return success.

      + + ]]> +
      2. +
    2. +

      Else server MUST return a ¬authorized; failure and close the stream.

      + + + + + ]]> +
      3. +
    +
    12. +
+ + +

The SASL EXTERNAL mechanism can be used outside the context of X.509 certificates, for example via Internet Protocol Security (IPSec) as specified in &rfc4301;. A future version of this specification may document best practices for use of SASL EXTERNAL outside the context of the X.509 infrastructure.

+ + +

This JEP introduces no security considerations or concerns above and beyond those discussed in RFC 3920.

+ + +

This JEP requires no interaction with &IANA;.

+ + +

This JEP requires no interaction with the ®ISTRAR;.

+ + +

Peter Millard, co-author of the initial version of this specification, died on April 26, 2006. The remaining author appreciates his assistance in defining the best practices described herein.

+ + + diff --git a/xep-0179.xml b/xep-0179.xml new file mode 100644 index 00000000..e15339e3 --- /dev/null +++ b/xep-0179.xml @@ -0,0 +1,188 @@ + + +%ents; +]> + + +
+ Jingle IAX Transport Method + This document defines a Jingle transport method that results in using the Inter-Asterisk eXchange protocol (IAX) for the final communication. + 0179 + Experimental + Standards Track + Standards JIG + Council + + XMPP Core + JEP-0166 + + + + jingle-iax + + Antonio F. + Cano + antoniofcano@grupoikusnet.com + antoniofcano@jabber.org + + &stpeter; + + 0.2 + 2006-03-23 + psa +

Recommended use of IAX-native methods for DTMF.

 + + + 0.1 + 2006-03-09 + psa +

Initial JEP version.

 + + + 0.0.4 + 2006-03-02 + afc +

Synced with last revision of Jingle and Raw UDP transport. Review some descriptions and modify some names like location for candidate

 + + + 0.0.3 + 2006-02-26 + afc +

Modify the initiate proccess, Rome tell to Juliet the transport to use and she answer with the transport information needed to be contacted. Added to transport the remoteTransport an localTransport data.

 + + + 0.0.2 + 2006-02-24 + afc +

Some fixes and take care of Asterisk PBX entity.

 + + + 0.0.1 + 2006-02-23 + afc +

First draft.

 + +
+ +

&jep0166; defines a framework for negotiating and managing out-of-band multimedia sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor media (session) types, leaving that up to separate specifications. The current document defines a transport method for establishing and managing &iax; sessions between XMPP entities.

+

IAX is a peer-to-peer media and signaling protocol, where the endpoints maintain state machines. With respect to media, sequencing and timing information is included into IAX frames, without the use of Real-Time Transport Protocol (RTP) for the media. IAX is a binary protocol; this design choice was made for bandwidth efficiency. The IAX protocol handles the signaling and, when the call is accepted by both peers, the media passes between the two hosts. With this approach, IAX doesn't suffer from NAT traversal problems associated with others protocols like SIP or other related protocols.

+ + +

The Jingle transport description defined herein is designed to meet the following requirements:

+
    +
  1. Enable negotiation of parameters necessary for take in contact both IAX peers.
    2. +
  2. Make it relatively easy to implement support in standard Jabber/XMPP clients.
    3. +
  3. Where communication with non-XMPP entities is needed, push as much complexity as possible onto server-side gateways between the XMPP network and the non-XMPP network.
    4. +
+ + + +

In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in JEP-0166. This stanza MUST include at least one transport method. If the initiating entity wishes to negotiate the IAX transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/iax' namespace.

+ + + + + + + + ]]> + + + + +

As described in JEP-0166, to provisionally accept the session initiation request, the target entity returns an IQ-result:

+ + ]]> +

To accept the IAX transport method, the target entity MUST send a &JINGLE; element with an action of 'transport-accept', specifying the transport method desired.

+

This &TRANSPORT; element MUST include two &CANDIDATE; element per channel, whose 'ip' and 'port' attributes specify the IP address and port number of the candidate that the initiator has reason to believe will be most likely to succeed for that channel. The two candidates are the local and remote one. NAT type doesn't matter because the IAX protocol by itself addresses the problem of NAT traversal. We differentiate the two candidates with name attribute.

+

The transport attributes are:

+
    +
  1. Version -- this is the protocol version we want to use by (currently 1 or 2, perhaps other versions in the future). This information is provided as an attribute of the transport.
    2. +
  2. User -- the user needed to log into the Asterisk PBX. This is OPTIONAL.
    3. +
  3. Password -- the password needed to log the User into the Asterisk PBX. This is OPTIONAL.
    4. +
  4. Secure -- describes the encryption method, this is OPTIONAL because at the moment there is one implementation of AES128 in Asterisk but not in the protocol, this could change in the future.
    5. +
+

User and Password are OPTIONAL and needed in the case we want to call an extension that is behind an Asterisk PBX. The Asterisk PBX has to be properly configured to accept this kind of call.

+

When we get the answer, it is time to see if the media that we want to start is supported by both peers. If so the IAX session is initialized by the protocol stack.

+

The candidate attributes are:

+
    +
  1. Name -- the name of the candidate MUST be local, public or vpn.
    2. +
  2. IP -- the IP where the candidate is located.
    3. +
  3. Port -- the port where the candidate is listening.
    4. +
+

To discover this public IP address we need a third party and SHOULD make discovery via &rfc3489;, which will be an address on the outside of the firewall or NAT.

+ + + + + + + + + ]]> + + +

The syntax and semantics informational message payloads specific to the IAX transport method will be defined in a future version of this specification.

+ + + + +

The port is returned by the IAX library stack initialization process. Among IAX library implementations, IAXclient is recommended since it is easy to use, stable, multiplatform, and used in most IAX implementations. By default the port is 4569 UDP but if there is more than one IAX entity in the same box this port could be different.

+ + +

Once the Jingle negotiation has been completed and the IAX stack has control, the initiating entity has to set his callerID information (cidname to Jingle and cidnum to JabberID) before dialing to a contact. If the initator's client has to show the contact's information, this comes from the initiator attribute of the returned IQ.

+ + +

IAX is a native protocol of the Asterisk PBX. When using the IAX protocol we could easily connect with an Asterisk PBX. There are two scenarios:

+
    +

  1. We want to reach an internal extension directly (or go to PSTN line through Asterisk). in that case we need a user and password with rights into the PBX and setup into the Jabber client (the Jabber client will act like a softphone). This information has to be given for the final user to the entity. The idea in this scenario isn't so clear because if the jabber client acts like a softphone and we need to call an extension, we coudl just dial the extension without using Jingle.

    2. +

  2. The Asterisk PBX accept incoming calls from IAX. In that case just call the Asterisk like other peer and the Asterisk MUST be properly configured for accepting the 'anonymous' (not an internal user of the PBX) incoming call.

    3. +
+

In both cases, the Asterisk PBX has to be logged into the Jabber network and implement the Jingle extension like a channel (Asterisk terminology).

+ + +

If it is necessary to send Dual Tone Multi-Frequency (DTMF) tones, it is RECOMMENDED to use the IAX-native methods specified in draft-ietf-guy-iax. The XML format specified &jep0181; MAY be used only as a fallback.

+ + + +

To follow.

+ + +

This JEP requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; shall include 'http://jabber.org/protocol/jingle/transport/iax' and 'http://jabber.org/protocol/jingle/info/iax' in its registry of protocol namespaces.

+ + +

The Jabber Registrar shall include the name "iax" in its registry of Jingle transport descriptions. The registration is as follows:

+ + iax + Jingle IAX sessions. + JEP-0179 + + ]]> + + + diff --git a/xep-0180.xml b/xep-0180.xml new file mode 100644 index 00000000..0762f5b7 --- /dev/null +++ b/xep-0180.xml @@ -0,0 +1,238 @@ + + +%ents; +]> + + +
+ Jingle Video Content Description Format + This document defines a content description format for Jingle video sessions. + &LEGALNOTICE; + 0180 + Experimental + Standards Track + Standards JIG + Council + + XMPP Core + JEP-0166 + + + + jingle-video + &stpeter; + + Milton + Chen + Milton.Chen@vseelab.com + + + 0.3 + 2006-08-23 + psa +

Modified namespace to track JEP-0166.

 + + + 0.2 + 2006-07-12 + psa +

Updated to use content type instead of media type.

 + + + 0.1 + 2006-03-23 + psa/mc +

Initial JEP version.

 + + + 0.0.1 + 2006-03-20 + psa/mc +

First draft.

 + +
+ +

&jep0166; can be used to initiate and negotiate a wide range of peer-to-peer sessions. One session type of interest is video exchange. This document specifies a format for describing Jingle video sessions.

+ + +

The Jingle content description format defined herein is designed to meet the following requirements:

+
    +
  1. Enable negotiation of parameters necessary for video exchange.
    2. +
  2. Map these parameters to Session Description Protocol (SDP; see &rfc4566;) to enable interoperability.
    3. +
  3. Define informational messages related to video exchange chat.
    4. +
+ + +

A Jingle video session is described by one or more encodings contained within a wrapper &DESCRIPTION; element. In the language of RFC 4566 these encodings are payload-types; therefore, each <payload-type/> child element specifies an encoding that can be used for the video stream. Such encodings are often used in the context of the Real-time Transfer Protocol (RTP; see &rfc3550;) but may be used in other contexts as well. The most common encodings for the Audio/Video Profile (AVP) of RTP are listed in &rfc3551; (these "static" types are reserved from payload ID 0 through payload ID 96), although other encodings are allowed (these "dynamic" types use payload IDs 97 to 127) in accordance with the dynamic assignment rules described in Section 3 of RFC 3551. The &PAYLOADTYPE; element's 'id' attribute is REQUIRED and its 'name' attribute is RECOMMENDED. The encodings SHOULD be provided in order of preference.

+ + + + + + + ]]> +

The &DESCRIPTION; element is intended to be a child of a &JINGLE; element as specified in JEP-0166.

+

The defined attributes of the &PAYLOADTYPE; element are as follows:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
AttributeDescriptionDatatype/Units
channelsThe number of channels (e.g., 2 for stereoscopic video)positiveInteger (defaults to 1)
heightThe vertical extent of the displayed video, in pixelspositiveInteger
idA unique identifier for the payload typepositiveInteger
layerThe relationship of a layer to the "bottom" of the stack, where 0 = bottom (the first layer)nonNegativeInteger
nameA name for the payload typestring
transparentWhether or not a layer is transparentboolean
widthThe horizontal extent of the displayed video, in pixelspositiveInteger
xThe horizontal starting point of a tile, in pixels from the origin pointpositiveInteger
yThe vertical starting point of a tile, in pixels from the origin pointpositiveInteger
+ + +

To follow.

+ + +

If an entity supports the Jingle video content description format, it MUST advertise that fact by returning a feature of "http://jabber.org/protocol/jingle/description/video" in response to &jep0030; information requests.

+ + + + ]]> + + + ... + + + ... + + + ]]> + + +

Informational messages may be sent by either party within the context of Jingle to communicate the status of a Jingle video session, device, or principal. The informational message MUST be an IQ-set containing a &JINGLE; element of type "content-info", where the informational message is a payload element qualified by the 'http://jabber.org/protocol/jingle/info/video' namespace. No payload elements have yet been defined, but will be specified in a future version of this document.

+ + + +

Support for the Theora codec See <http://www.theora.org/>. is RECOMMENDED.

+ + + +

The description of a format for video sessions introduces no known security vulnerabilities.

+ + +

This JEP requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; shall include 'http://jabber.org/protocol/jingle/description/video' and 'http://jabber.org/protocol/jingle/info/video' in its registry of protocol namespaces.

+ + +

The Jabber Registrar shall include the name "video" in its registry of Jingle content description formats. The registration is as follows:

+ + video + Jingle sessions that support video exchanges + JEP-xxxx + + ]]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + +

To follow.

+ + + diff --git a/xep-0181.xml b/xep-0181.xml new file mode 100644 index 00000000..45d60d6b --- /dev/null +++ b/xep-0181.xml @@ -0,0 +1,176 @@ + + +%ents; +]> + + +
+ Jingle DTMF + This document specifies an XML format for encapsulating DTMF data in informational messages sent within the context of Jingle audio interactions. + &LEGALNOTICE; + 0181 + Experimental + Standards Track + Standards JIG + Council + + XMPP Core + JEP-0166 + + + + jingle-dtmf + &stpeter; + &seanegan; + + 0.3 + 2006-07-12 + se/psa +

Updated syntax to use action and code attributes rather than tone element in order to provide real-time interaction; specified how to negotiate use of the RFC 2833 format via content-info messages.

 + + + 0.2 + 2006-06-29 + psa +

Allowed characters A, B, C, and D; updated schema.

 + + + 0.1 + 2006-03-23 + psa +

Initial JEP version.

 + + + 0.0.1 + 2006-03-21 + psa + First draft. + +
+ +

Traditional telephony systems use Dual Tone Multi-Frequency (DTMF) for dialing and to issue commands such as those used in Interactive Voice Response (IVR) applications. Internet telephony systems also use DTMF tones for interoperability with the public switched telephone network (PSTN). XMPP clients that use &jep0166; for voice chat (see &jep0167;) MUST use the protocol described in this document if they wish to support DTMF.

+ + +

The format for the XML DTMF format is as follows:

+ + ]]> +

The <dtmf/> element SHOULD possess one 'action' attribute, which MUST be either "button-up" or "button-down", specifying whether the button is being depressed or released. This allows DTMF tones to be reconstructed in real-time. If the 'action' attribute is not included, the recipient MUST assume this to be a "button-down" event, and imply a "button-up" event after a reasonable timeout (100 milliseconds is RECOMMENDED) or when another DMTF event is received.

+

Unless, the 'action' attribute is 'button-up', the <dmtf/> element MUST possess a 'code' attribute that specifies the tone to be generated. The value of the 'code' attribute SHOULD be one the following characters: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, #, and * -- however, the characters A, B, C, and D MAY be sent as well. Although A, B, C, and D were originally defined as part of DTMF, they were never deployed to telephony consumers and were used only for control purposes at private branch exchanges (PBXs) and central office operator stations; however, they are used in certain non-telephony applications of DTMF, such as ham radio.

+

The <dtmf> element SHOULD be sent as the payload of a Jingle content-info message as illustrated in the following example.

+ + + + + + ]]> + + +

Some applications may want to stream Jingle voice RTP directly to a non-XMPP entity, such as a SIP phone. In this scenario, DTMF needs to be sent in the content channel. Jingle DTMF allows to Jingle entities to negotiate whether to send RTP over the XMPP signalling channel as described above, or over the content channel, using RFC 2833.

+

To request that the voice session switches to RFC 2833, a client sends a <dtmf-method/> element, qualified by the 'http://jabber.org/protocol/info/dmtf' namespace as the payload of a Jingle content-info message:

+ + + + + + ]]> +

The dtmf-method element MUST contain one 'method' attribute, the value of which SHOULD be either 'rtp' or 'xmpp'.

+

If the recipient supports the requested DTMF method, it SHOULD send an empty IQ result:

+ + ]]> +

If the recipient does not supoprt the requested DTMF method, it MUST reply with a lt;feature-not-implemented/> error with a DTMF-specific error condition of <unsupported-dtmf-method/>:

+ + + + + + + ]]> + + + +

This document introduces no known security vulnerabilities.

+ + +

This JEP requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; shall include 'http://jabber.org/protocol/jingle/info/dtmf' in its registry of protocol namespaces.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + diff --git a/xep-0182.xml b/xep-0182.xml new file mode 100644 index 00000000..ae45db8a --- /dev/null +++ b/xep-0182.xml @@ -0,0 +1,92 @@ + + +%ents; +]> + + +
+ Application-Specific Error Conditions + This document defines a registry of application-specific error conditions. + &LEGALNOTICE; + 0182 + Active + Procedural + Standards JIG + Council + + XMPP Core + + + + errors + + &stpeter; + + 1.0 + 2006-05-16 + psa +

Per a vote of the Jabber Council, advanced status to Active; also added example.

 + + + 0.2 + 2006-04-28 + psa +

Added note about scope of registry.

 + + + 0.1 + 2006-03-23 + psa +

Initial JEP version.

 + + + 0.0.1 + 2006-03-21 + psa +

First draft.

 + +
+ +

&xmppcore; specifies that an XMPP error stanza may include a child element qualified by an XML namespace other than 'urn:ietf:params:xml:ns:xmpp-stanzas'. This enables any XMPP protocol extension to define its own application-specific error conditions, such as the following:

+ + + + + + + + + + ]]> +

Although the inclusion of application-specific error conditions introduces a great deal of flexibility, it may also lead to confusion regarding possible conditions. Therefore, this document defines a registry of application-specific error conditions, to be maintained by the ®ISTRAR;. In addition, this document registers a namespace of 'http://jabber.org/protocol/errors' as a fallback namespace for generalized error conditions that are not specific to a particular protocol (e.g., <stanza-too-big/> as a particular form of the ¬acceptable; condition).

+ + + +

The Jabber Registrar maintains a registry of application-specific error conditions (see &APPERRORS;).

+

All application-specific error conditions that are defined in Jabber Enhancement Proposals MUST be included in this registry. Application-specific error conditions that are defined outside of the JEP process MAY be included in this registry, but it is not required for them to be so registered.

+ + ®PROCESS; + + the XML namespace that qualifies the condition + the XML element of the error condition + a natural-language description of the error condition + the document in which the condition is specified + + ]]> +

The registrant may register more than one condition at a time, each contained in a separate <condition/> element.

+ + + +

The ®ISTRAR; shall include 'http://jabber.org/protocol/errors' in its registry of protocol namespaces.

+ + + +

This document introduces no known security vulnerabilities.

+ + +

This JEP requires no interaction with &IANA;.

+ + diff --git a/xep-0183.xml b/xep-0183.xml new file mode 100644 index 00000000..d91a94ea --- /dev/null +++ b/xep-0183.xml @@ -0,0 +1,223 @@ + + +%ents; +]> + + +
+ Jingle Telepathy Transport + This document defines a telepathic transport method for establishing Extra-Sensory Perception (ESP) streams. + &LEGALNOTICE; + 0183 + Active + Humorous + Standards JIG + Council + + XMPP Core + JEP-0166 + + + + telepathy + &stpeter; + + 1.0 + 2006-04-01 + psa +

Per a vote of the Jabber Council, advanced status to Active.

 + +
+ +

&jep0166; defines a framework for negotiating and managing out-of-band multimedia sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor media (session) types, leaving that up to separate specifications.

+

Typical peer-to-peer session types include voice chat (see &jep0167;) and video chat (see &jep0180;). But Jingle can go farther. Indeed, why not support not only physical multimedia sessions (limited to the five physical senses) but also psychical multimedia sessions (which go beyond the basic physical senses to include advanced, extra-sensory perception)? The media (or medium) may be different, but the underlying principles are the same: fostering freedom of conversation by connecting people (e.g., through mind-reading and séances) and even applications such as accessing information from the future (e.g., in clairvoyance and precognition). Indeed, the ability to communicate with the spirit world will push Jabber/XMPP technologies into a new age of real-time communications (light years ahead of traditional IM and VoIP systems). Beyond Internet telephony, our innovations in Internet telepathy will give new meaning to the term "voice chat" as users are able to hear voices from the past, present, or future.

+

Unfortunately, these advanced session types cannot be supported using existing transport mechanisms such as &jep0176;, &jep0177;, and &jep0179;. Therefore, this document defines a new Jingle transport method for establishing and managing Extra-Sensory Perception (ESP) streams: the "telepathy" method.

+ + +

The Jingle telepathy transport method is designed to meet the following requirements:

+
    +
  1. Make it possible to establish and manage extra-sensory perception (ESP) streams between two XMPP entities.
    2. +
  2. Make it relatively easy to implement support in standard Jabber/XMPP clients.
    3. +
  3. Where communication with non-XMPP (indeed, non-material) entities is needed, push as much complexity as possible onto gateways between this world and the spirit world.
    4. +
+

Note: Whether or not an ESP stream can be established depends on the user's native telepathic abilities as well as acquired telepathic skills such as grounding, centering, pinging, pulse-sending, broadcasting, scanning, probing, suggestion, and projection. For a good introduction to telepathic skills, see The Telepathy Manual at <http://www.psipog.net/articles.php?cat=10131>. Your mileage may vary.

+ + + +

In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in JEP-0166. This stanza MUST include at least one transport method. If the initiating entity wishes to negotiate the telepathy transport, it MUST include a &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/telepathy' namespace.

+

This &TRANSPORT; element MUST include one and only one &CANDIDATE; element per channel specifying the parameters that the initiator believes will be most likely to succeed for that channel. (Note: You have to believe.) This is not necessarily the initiator's preferred address for spiritual communication, but instead is the "address most likely to succeed", i.e., the address that is assumed to be reachable by the vast majority of target entities. (Establishing direct spiritual communication is hard enough as it is.) Here is an example:

+ + + + + + + + + ]]> +

The attributes of the <candidate/> element are as follows:

+
    +
  • The 'generation' attribute is an index, starting at 0, that enables the parties to keep track of updates to the candidate throughout the life of the session.
    • +
  • The 'name' attribute specifies a unique name for the channel.
    • +
  • The 'plane' attribute is used for diagnostics; it is an index, starting at 1, referencing which astral plane this candidate is on for a given peer.
    • +
  • The 'pulse' attribute specifies the initiator's heart rate at the moment; this helps establish communications through pulse-sending of informational messages in time with the beat of your heart.
    • +
  • The 'psi-sig' attribute is the initiator's Psi Signature or "energy fingerprint"; because scanning people for their psi-sig can take time and is often a challenge, advertising one's psi-sig ahead of time makes it easier to establish a spiritual connection. The format of the 'psi-sig' attribute is a space-delimited set of descriptive words, often including colors, feelings, and emotions characterizing the person's energy state at the moment. Note: A person's psi-sig can change from moment to moment; therefore, it is advisable to also advertise it using &jep0163;.
    • +
  • The 'sign' attribute represents the initiator's Zodiac sign; including this value obviates the need for asking "what's your sign?"
    • +
  • The 'time' attribute is used for diagnostics; the allowable values are "past", "present", and "future".
    • +
+ + +

As described in JEP-0166, to provisionally accept the session initiation request, the target entity returns an IQ-result:

+ + ]]> +

To definitively accept the telepathy transport method, the target entity MUST send a &JINGLE; element with an action of 'transport-accept', specifying the transport method desired.

+ + + + + + + + ]]> +

The initiating entity then acknowledges the target entity's acceptance:

+ + ]]> +

Now the initiating entity and target entity can begin sending appropriate psychical media over the negotiated ESP stream.

+

In the event that the target entity cannot establish a channel, it SHOULD terminate the session (see JEP-0176 or JEP-0177 for examples).

+ + +

Because the informational message payloads specific to the telepathy transport method cannot be tied down to the arbitrary conventions of XML syntax, a <message/> element qualified by the 'http://jabber.org/protocol/info/telepathy' namespace may include any character data that either party feels like communicating.

+ + + + +

This specification applies exclusively to Jabber/XMPP clients and places no additional requirements on Jabber/XMPP servers. However, service administrators may wish to deploy a gateway to the spirit world in order to ease the channel negotiation process. How to develop such gateways is an inexact science (but it is a science!) and therefore is outside the scope of this document.

+ + + +

To the author's knowledge, no channel encryption technologies exist for direct spiritual connections. Although this vulnerability can be mitigated through speaking in tongues and the use of various alternative languages such as Runic and Mumbo-Jumbo, the result is only security through obscurity, not channel encryption as those familiar with the merely material world understand it. If only benighted materialist scientists and technologists would recognize the validity of psychical experience and extra-sensory perception, progress in applying encryption principles to psychical channeling and the exchange of pure spiritual energy would rapidly ensue.

+ + + +

This JEP requires no interaction with &IANA;.

+ + + + +

The ®ISTRAR; shall include 'http://jabber.org/protocol/jingle/transport/telepathy' and 'http://jabber.org/protocol/jingle/info/telepathy' in its registry of protocol namespaces.

+ + +

The Jabber Registrar shall include "http://jabber.org/protocol/jingle/transport/telepathy" in its registry of Jingle transport methods. The registry submission is as follows:

+ + telepathy + + A method for the negotiation of Extra-Sensory Perception (ESP) streams. + + JEP-0183 + + ]]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + + + + + + + + + ]]> + + + diff --git a/xep-0184.xml b/xep-0184.xml new file mode 100644 index 00000000..bdfcbb64 --- /dev/null +++ b/xep-0184.xml @@ -0,0 +1,569 @@ + + +%ents; +]> + + +
+ Message Receipts + This document specifies a protocol for XMPP message receipts. + &LEGALNOTICE; + 0184 + Experimental + Standards Track + Standards JIG + Council + + XMPP Core + + + JEP-0022 (in part) + + + amp-receipts + &stpeter; + &hildjj; + + 0.2 + 2006-09-21 + psa +

Added two more scenarios; defined business rule about not sending to bare JIDs; specified security consideration regarding presence leaks.

 + + + 0.1 + 2006-04-11 + psa +

Initial JEP version.

 + + + 0.0.2 + 2006-04-07 + psa +

Added text and examples for service discovery; added text and examples for chat session negotiation; added recommendations regarding message processing, retries, etc.

 + + + 0.0.1 + 2006-03-27 + psa +

First draft.

 + +
+ +

While &jep0079; provides message acknowledgements at the server level, it does not extend that model all the way to the client. However, sometimes client-level acknowledgements are needed, for example to provide "receipts". This document defines a mechanism for XMPP message receipts.

+ + +

This document addresses the following requirements:

+
    +
  1. Enable a sender to request notification that an XMPP message stanza has been received.
    2. +
  2. Enable a recipient to provide message receipts if desired.
    3. +
+

Note: This document explicitly does not define a protocol for "guaranteed delivery", since that term (like "security") means different things to different people. Instead, we define a more focused protocol that addresses the need for message receipts, thus solving one problem that falls under the heading of "guaranteed delivery".

+ + +

In general there are seven possible scenarios (where "S" stands for sender and "R" stands for recipient):

+ | +| send message | +| | +| <------------------------------------ | +| send receipt | +| | + ]]> +

In Scenario 1, the use case ends successfully with message delivery, receipt delivery, and no retries.

+ | +| re-send message | +| | +| <------------------------------------ | +| send receipt | +| | + ]]> +

In Scenario 2, the use case ends successfully with message delivery failure, message retry, and receipt delivery.

+ | +| send message | +| | +| x------------------------------- | +| send receipt | +| | +| [trigger timeout] | +| | +| ------------------------------------> | +| re-send message | +| | +| <------------------------------------ | +| send receipt | +| | + ]]> +

In Scenario 3, the use case ends successfully with message delivery, receipt delivery failure, message retry, and receipt delivery.

+ | +| send message | +| | +| ------------------------------------> | +| send presence unavailable | +| | + ]]> +

In Scenario 4, the use case ends unsuccessfully with message delivery and the sender generating presence unavailable (because the sender has gone offline, the recipient has no one to send the receipt to).

+ | +| send message | +| | +| -------------------------------x | +| send presence unavailable | +| | +| <------------------------------------ | +| send receipt | +| | + ]]> +

In Scenario 5, the use case ends unsuccessfully with message delivery and the sender generating presence unavailable; however, the presence unavailable is not delivered, so the recipient sends a receipt, which is not delivered within the sender's timeout period since the sender is now offline.

+ | +| send message | +| | +| <------------------------------------ | +| send presence unavailable | +| | + ]]> +

In Scenario 6, the use case ends unsuccessfully with message delivery and the recipient generating presence unavailable (because the recipient has gone offline before sending a receipt, the sender cannot be sure that the message has been received).

+ | +| send message | +| | +| x---------------------------------- | +| send presence unavailable | +| | +| [trigger timeout] | +| | +| ------------------------------------> | +| re-send message | +| | + ]]> +

In Scenario 7, the use case ends unsuccessfully with message delivery and the recipient generating presence unavailable; however, the presence unavailable is not delivered, so the sender retries sending the message and because the recipient is now offline it cannot send a receipt within the sender's timeout period.

+ + +

In order to make it possible for senders to request, and for recipients to generate, message receipts, we define a new Advanced Message Processing rule: "receipt". In accordance with JEP-0079, we provide the following information about the receipt rule:

+
    +
  • The namespace shall be "http://jabber.org/protocol/amp?condition=receipt".
    • +
  • The condition applies only to final receipt by the intended recipient; therefore, the per-hop flag does not apply.
    • +
  • The only defined value of the receipt rule is "received".
    • +
  • This condition is met if a message processing application (client) controlled by the intended recipient has received and processed the message; the term "processed" is understood to include presentation to a human user if appropriate Therefore this specification does not distinguish between delivery and presentation, as was done in &jep0022;. or any other application-specific client-side processing, including generation of an error response if the application determines that the message contents cannot be handled.
    • +
+ + +

In order to make it possible for senders to request, and for recipients to generate, message receipts, we define a new Advanced Message Processing rule: "receipt". In accordance with JEP-0079, we provide the following information about the receipt rule:

+
    +
  • The namespace shall be "http://jabber.org/protocol/amp?condition=receipt".
    • +
  • The condition applies only to final receipt by the intended recipient; therefore, the per-hop flag does not apply.
    • +
  • The only defined value of the receipt rule is "received".
    • +
  • This condition is met if a message processing application (client) controlled by the intended recipient has received and processed the message; the term "processed" is understood to include presentation to a human user if appropriate Therefore this specification does not distinguish between delivery and presentation, as was done in &jep0022;. or any other application-specific client-side processing, including generation of an error response if the application determines that the message contents cannot be handled.
    • +
  • Although any defined action may be triggered, the only action needed in order to support message receipts is the "notify" action.
    • +
+

The following is an example of a message that includes a request for return receipt.

+ + My lord, dispatch; read o'er these articles. + + + + + ]]> +

If the recipient supports Advanced Message Processing and the "receipt" rule, it MUST generate a receipt:

+ + + + + + ]]> + + +

The general business rules specified for Advanced Message Processing in JEP-0079 apply to any rule; in addition, the following business rules apply specifically to the receipt rule:

+
    +

  1. A sender SHOULD NOT include a request for message receipts when sending a message to the bare JID (&BAREJID;) of the recipient, only when sending to a full JID (&FULLJID;).

    2. +

  2. A sender SHOULD NOT include a request for message receipts unless it knows (via &jep0030; or &jep0115;) that the intended recipient supports the protocol described herein or unless the use of message receipts is negotiated via &jep0155;.

    3. +

  3. The sender (i.e., the message generating application controlled by the sender) MUST initiate a timeout upon sending each message, which timeout SHOULD be 30 seconds. If the sender does not receive a message receipt (or failure event) within its timeout period, it MUST re-send the message with an identical value of the XMPP 'id' attribute.

    4. +

  4. The sender MUST NOT send a large number of retries. How many retries are appropriate depends on how important the message is perceived to be. In any case, a sender SHOULD NOT send more than five retries.

    5. +

  5. The recipient (i.e., the message processing application controlled by the intended recipient that receives a given message) MUST initiate a timeout upon sending each message receipt, which timeout SHOULD be 60 seconds. If the recipient does not receive a re-sent message within its timeout period, it SHOULD stop waiting for a re-sent message and discard memory of that message ID.

    6. +

  6. The recipient MUST NOT include a request for message receipts in its acknowledgements. If the sender receives a request for message receipts in an acknowledgement, it MUST NOT acknowledge the acknowledement.

    7. +

  7. The recipient SHOULD send the message receipt once it has processed the message, which may include presenting it to a human user (e.g., visually or aurally). The receiving application SHOULD NOT require a human user to positively affirm that he or she has read and understood the message before sending the receipt, since this is unnecessarily intrusive in the context of instant messaging.

    8. +
+

Naturally, the receipt rule can be combined wiith rules specified in JEP-0079 (e.g., the deliver rule) for more complete reporting.

+ + +

This document covers one use case: sending messages with return receipt requested, for which succcess is defined as the sender receiving a message receipt. As described above, there are seven possible scenarios. These are described in more detail in the following sections.

+ +

In the "happy path", the sender sends the message and the recipient returns a receipt within the sender's timeout period.

+ + My lord, dispatch; read o'er these articles. + + + + + ]]> + + + + + + ]]> + + +

In this scenario the sender sends the message but it is not received for whatever reason; therefore the sender resends the message after the timeout period expires, the resent message is received, and the recipient returns a receipt within the sender's (second) timeout period.

+ + My lord, dispatch; read o'er these articles. + + + + + ]]> +

The message is not received and the sender does not receive a receipt within the sender's timeout period; therefore the sender resends the message.

+ + My lord, dispatch; read o'er these articles. + + + + + ]]> +

Now the message is received and the recipient returns a receipt.

+ + + + + + ]]> + + +

In this scenario the sender sends the message and it not received, but the message receipt is not received for whatever reason; therefore the sender resends the message after the timeout period expires, the resent message is received, and the recipient returns a receipt within the sender's (second) timeout period.

+ + My lord, dispatch; read o'er these articles. + + + + + ]]> +

The message is received and the recipient returns a receipt.

+ + + + + + ]]> +

The message receipt is not received by the sender within the sender's timeout period; therefore the sender resends the message.

+ + My lord, dispatch; read o'er these articles. + + + + + ]]> +

The resent message is received and the recipient returns a receipt, which is received by the sender within the sender's (second) timeout period.

+ + + + + + ]]> + + +

In this scenario the sender sends the message but immediately goes offline. Therefore the recipient MUST NOT send a receipt.

+ + My lord, dispatch; read o'er these articles. + + + + + ]]> + + ]]> +

The use case ends unsuccessfully, since the sender did not receive a receipt.

+ + +

In this scenario the sender sends the message but immediately goes offline, however the sender's presence unavailable is not delivered to the recipient so the recipient sends a receipt but the sender's timeout is not triggered.

+ + My lord, dispatch; read o'er these articles. + + + + + ]]> + + ]]> +

The recipient does not receive the presence unavailable so sends a message receipt.

+ + + + + + ]]> +

However, the sender does not receive the receipt within its timeout period (since it is now offline), so the use case ends unsuccessfully.

+ + +

In this scenario the sender sends the message but receives unavailable presence from the recipient before receiving a receipt within the timeout period.

+ + My lord, dispatch; read o'er these articles. + + + + + ]]> + + ]]> +

The use case ends unsuccessfully, since the sender did not receive a receipt.

+ + +

In this scenario the sender sends the message and the recipient sends unavailable presence before sending a receipt, but the presence unavailable is not delivered so the sender retries but does not receive a receipt since the recipient is now offline; after some number of retries the sender gives up and cannot be sure that the message was ever received.

+ + My lord, dispatch; read o'er these articles. + + + + + ]]> + + ]]> +

The sender does not receive the presence unavailable so sends a retry.

+ + My lord, dispatch; read o'er these articles. + + + + + ]]> +

After sending some number of retries the sender gives up and the use case ends unsuccessfully.

+ + + +

If a sender wishes to request message receipts, it SHOULD first discover whether the intended recipient supports message receipts. Support can be discovered indirectly via Entity Capabilities or directly via Service Discovery.

+

If an entity supports Advanced Message Processing, it MUST report that by including a service discovery feature of "http://jabber.org/protocol/amp" as described in JEP-0079:

+ + + + ]]> + + + ... + + ... + + + ]]> +

An entity that supports Advanced Message Processing SHOULD also maintain a service discovery node named "http://jabber.org/protocol/amp", at which it advertises the individual actions and conditions it supports. If an entity supports message receipts, it SHOULD respond to service discovery information requests sent to that node with a reply that includes the 'http://jabber.org/protocol/amp?condition=receipt' condition:

+ + + + ]]> + + + ... + + ... + + + ]]> + + +

Two entities MAY negotiate the use of message receipts for a given session using Chat Session Negotiation. The parameter to be negotiated is named "http://jabber.org/protocol/amp?condition=receipt". Its use is illustrated in the following examples.

+ + ffd7076498744578d10edabfe7f4a866 + + + + http://jabber.org/protocol/chatneg + + + true + + + + 0 + + + + + ]]> + + ffd7076498744578d10edabfe7f4a866 + + + + http://jabber.org/protocol/chatneg + + + true + + + 1 + + + + + ]]> + + +

It is possible for a recipient to leak its presence when returning message receipts; therefore, a recipient SHOULD NOT return message receipts to senders who are not otherwise authorized to view its presence.

+ + +

No interaction with &IANA; is necessary as a result of this document.

+ + + +

The ®ISTRAR; maintains a registry of Advanced Message Processing <rule/> conditions (see &CONDITIONS;). The Registrar shall add the following condition to the registry:

+ + receipt + http://jabber.org/protocol/amp?condition=receipt + false + received + + The condition is met if a message processing application (client) + controlled by the intended recipient has received and processed + the message, including presentation to a human user if appropriate. + + JEP-xxxx + + ]]> + + +

&jep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace and the Jabber Registrar maintains a registry of such fields (see &FORMTYPES;). The Registrar shall add the following field for use in Chat Session Negotiation forms:

+ + http://jabber.org/protocol/chatneg + + + ]]> + + + +

Thanks to Joe Kemp for his input.

+ + diff --git a/xep-0185.xml b/xep-0185.xml new file mode 100644 index 00000000..e781e228 --- /dev/null +++ b/xep-0185.xml @@ -0,0 +1,253 @@ + + +%ents; +]> + + +
+ Dialback Key Generation and Validation + This document explains how to generate and validate the keys used in the XMPP server dialback protocol. + &LEGALNOTICE; + 0185 + Experimental + Informational + Standards JIG + Council + + XMPP Core + + + + N/A + + Philipp + Hancke + fippo@goodadvice.pages.de + fippo@goodadvice.pages.de + + + 0.2 + ph + 2006-05-10 + +

Clarified and corrected roles of originating and receiving servers; updated recommendation and main example to use HMAC-SHA256 for key generation.

+ + + + 0.1 + 2006-04-11 + psa +

Initial JEP version.

 + + + 0.0.1 + 2006-03-30 + ph +

First draft.

 + +
+ + &BISNOTE; +

RFC 3920 does not specify how to generate the keys used in the server dialback protocol, and why each of the variables used in key generation is crucial for security. This document is provided for discussion purposes and aims at clarifying the key generation and its validation mechanism and to show common attacks on weak mechanisms. It is not meant to supercede the text in RFC 3920.

+ + +

The Originating Server, which generates the dialback key, and the Authoritative Server, which validates the dialback key, may reside on different hosts or be running in separate processes. The method used in key generation and validation should not require interactive communication between Originating Server, Authoritative Server and optionally a third party like a database.

+

The key is generated based on

+
    +
  • the (hostname of) Originating Server,
    • +
  • the (hostname of) Receiving Server,
    • +
  • the Stream ID,
    • +
  • and a secret known by the Authoritative Server's network.
    • +
+

The last item, a shared secret known to Originating Server and Authoritative Server, is used in a Keyed-Hash Message Authentication Code (HMAC) to generate and validate the dialback keys. This key must either be set up in a configuration option for each host or process or generated as a random string when starting the server. &nistfips198a; recommends that the length of the key should be at least half of the size of the hash function output.

+

The recommended hash for usage in HMAC is SHA-256 described in &nistfips180-2;, hence the secret's length should be at least 128 bits or 16 characters long.

+ +key = HEX( HMAC-SHA256( Secret, { Stream ID, + Receiving Server, Originating or Authoritative server } ) ) + +

To avoid problems of encoding, a hexadecimal representation of the digest algorithm output SHOULD be used.

+ + + + + + + + + + + + + + + + + + + +
Originating and Authoritative Serverexample.com
Receiving Serverexample.org
Secretthesecret
Stream ID457F9224A0
+ + +

This document closely follows the description of the dialback protocol in RFC 3920, but omits steps that are not important for the generation and validation of the dialback keys. For ease of comparison the numbering of the steps is the same as in section 8.3 of RFC 3920.

+

3. Receiving Server sends a stream header back to the Originating Server, including a unique ID for this interaction:

+ + ]]> +

The Originating Server now generates a dialback key to be sent to the Receiving Server:

+ +key = HMAC-SHA256( secret, { Receiving server, Originating server, Stream ID}) + = HMAC-SHA256( 'thesecret', { 'example.org', 'example.com', '457F9224A0' }) + = HMAC-SHA256( 'thesecret', { 'example.orgexample.com457F9224A0' }) + = 'a85748c59049b700dfa728da3eae5ea93aac1e0fc89713b490e441486653dd8c' + +

4. The Originating Server sends the generated dialback key to the Receiving Server:

+ + a85748c59049b700dfa728da3eae5ea93aac1e0fc89713b490e441486653dd8c + + ]]> +

8. The Receiving Server sends the Authoritative Server a request for verification of the key:

+ + a85748c59049b700dfa728da3eae5ea93aac1e0fc89713b490e441486653dd8c + + ]]> +

The Authoritative Server calculates the valid key for this verify request, using data supplied in the packet and the secret shared with the Originating Server.

+ +key = HMAC-SHA256( secret, { Receiving Server, Authoritative Server, Stream ID }) + = HMAC-SHA256( 'thesecret', { 'example.org', 'example.com', '457F9224A0' }) + = HMAC-SHA256( 'thesecret', { 'example.orgexample.com457F9224A0' }) + = 'a85748c59049b700dfa728da3eae5ea93aac1e0fc89713b490e441486653dd8c' + +

9. The Authoritative Server compares this value to the key contained in the verification requests and informs the Originating Server of the result, in our example a success:

+ + ]]> + + +

This section contains attack scenarios that illustrate why each of the factors used in key generation is important.

+

An attacker will assume the role of the Originating Server and try to send a dialback key that the Authoritative Server acknowledges as valid. If this is successful, the attacker is allowed to send packets for the hostname of the Authoritative Server.

+

In each subsection, the example hash method, which uses the SHA1 algorithm as described in &rfc3174; for simplicity, ignores one of the variables,

+
    +
  • Originating Server,
    • +
  • Stream ID,
    • +
  • Receiving Server,
    • +
  • or Secret,
    • +
+

and it is shown how an attacker might exploit this behavior to get a valid result from the Authoritative Server.

+ +

This subsection demonstrates what can happen if the key generation method ignores the hostname of the Originating Server, e.g. for the hash function

+ +key = SHA1({ Secret, Receiving Server, Stream ID }) + +

The dialback keys generated for the originating domains 'example.com' and 'example.net' are the same, which might disclose that the secret used to generate the keys for these domains is equal. An attacker cannot exploit this any further.

+ + 807ccee5541ed9332559513797df75c1dd18ae8e + + ]]> +

This key is generated using:

+ +SHA1('thesecretexample.org457F9224A0') = + '807ccee5541ed9332559513797df75c1dd18ae8e' + + + +

This subsection demonstrates a replay attack that is possible if the key generation method ignores the Stream ID, e.g. for the hash function

+ +key = SHA1({ Secret, Receiving Server, Originating Server }) + +

If the attacker is able to obtain a single valid dialback key exchanged between the two domains, this key can be used to validate any stream.

+ + 14cbd71d0f127be89b7004c2242424918d8fad95 + + ]]> +

This key is generated using the empty string instead of the id:

+ +SHA1('thesecretexample.orgexample.com') = + '14cbd71d0f127be89b7004c2242424918d8fad95' + +

This key is also valid for

+ + 14cbd71d0f127be89b7004c2242424918d8fad95 + + ]]> + + +

This subsection demonstrates against a key generation method that ignores the hostname of the receiving server, e.g. for the hash function

+ +key = SHA1({ Secret, Originating Server, Stream ID }) + +

The attacker can use a dialback key and stream ID we have sent a domain under his control.

+ + c04ca426a81b3fa04bd4a9df2e24482372b4b874 + + ]]> +

This key is generated using:

+ +SHA1('thesecretexample.com457F9224A0') = + 'c04ca426a81b3fa04bd4a9df2e24482372b4b874' + + + +

If the key generation method does not take into account a shared secret in the Authoritative Servers network or if this secret is disclosed and the key generation method is known, an attacker can generate valid dialback keys.

+ +key = SHA1({ Receiving Server, Originating Server, Stream ID }) + +

In both cases the attacker is able to generate an arbitrary number of dialback keys.

+ + 30e59d3ee62926a29f012822769e58e67571d750 + + ]]> +

This key is generated using:

+ +SHA1('example.orgexample.com457F9224A0') = + '30e59d3ee62926a29f012822769e58e67571d750' + + + + +

This JEP introduces no security considerations or concerns above and beyond those discussed in RFC3920, but describes what might happen if the security considerations are ignored.

+ + +

This JEP requires no interaction with &IANA;.

+ + +

This JEP requires no interaction with the ®ISTRAR;.

+ + diff --git a/xep-0186.xml b/xep-0186.xml new file mode 100644 index 00000000..ada81a1b --- /dev/null +++ b/xep-0186.xml @@ -0,0 +1,170 @@ + + +%ents; +]> + + +
+ Invisible Command + This document specifies an XMPP-compatible protocol for user invisibility. + &LEGALNOTICE; + 0186 + Experimental + Standards Track + Standards JIG + + XMPP Core + XMPP IM + JEP-0030 + + None + None + invisibility + &stpeter; + + 0.4 + 2006-08-09 + psa +

Added Jabber Registrar considerations and XML schema.

 + + + 0.3 + 2006-08-02 + psa +

Added inbound presence rule to server handling section.

 + + + 0.2 + 2006-07-07 + psa +

Clarified that invisibility mode does not carry across sessions.

 + + + 0.1 + 2006-05-30 + psa +

Initial JEP version.

 + + + 0.0.2 + 2006-05-15 + psa +

Recommended delivery of messages sent to bare JID.

 + + + 0.0.1 + 2006-05-11 + psa +

First draft.

 + +
+ +

Jabber instant messaging technologies have long supported the ability for IM users to be online but appear invisible. The existing protocols for doing so are:

+
    +

  • &jep0018; -- this protocol is not compatible with &xmppcore; and &xmppim;, and it does not provide reliable documentation of the protocol in use since many server implementations support presence of type "invisible" but not presence of type "visible".

    • +

  • &jep0126; -- this protocol is in many ways a mis-use of privacy lists for the temporary purpose of appearing invisible rather than the intended purpose of permanently blocking communications.

    • +
+

In order to provide a standards-compliant protocol that can be used in the long term, this document defines an IQ-based protocol that enables an IM user to "go invisible" and "go visible" at will within the context of a given session.

+ + +

The requirements for invisible mode are straightforward:

+
    +
  1. A user should be able to become visible or invisible at any time within an XMPP session.
    2. +
  2. Invisible mode is active only for the current session; if the user ends that session and starts another session, the invisibility set for the previous session does not carry over to the new session.
    3. +
  3. When in invisible mode, a user should be able to send directed presence to particular contacts.
    4. +
+ + + +

In order for a client to discover whether its server supports the protocol defined herein, it MUST send a &jep0030; information request to the server:

+ + + + ]]> +

If the server supports the protocol defined herein, it MUST return a feature of "http://jabber.org/protocol/invisibility":

+ + + ... + + ... + + + ]]> +

A client SHOULD complete this service discovery process before sending initial presence to its server.

+ + +

In order for a client to go invisible, it shall send an IQ-set with no 'to' address (thus handled by the user's server) containing an <invisible/> element qualified by the 'http://jabber.org/protocol/invisibility' namespace:

+ + + + ]]> +

If the server can successfully process the invisibility command, it MUST return an IQ-result:

+ + ]]> +

(Standard XMPP stanza errors apply; see RFC 3920 and &jep0086;.)

+

If the client enters invisible mode after having previously sent undirected presence with no 'type' attribute (e.g., after sending initial presence), the server MUST send &UNAVAILABLE; presence from the client's resource to all contacts who would receive unavailable presence if the client sent &UNAVAILABLE;.

+

While the client is in invisible mode, the server:

+
    +

  1. MUST NOT broadcast presence notifications as a result of receiving any subsequent undirected presence notifications from the client.

    2. +

  2. MUST deliver directed presence stanzas generated by the client.

    3. +

  3. MUST deliver inbound &PRESENCE; stanzas.

    4. +

  4. SHOULD deliver inbound &MESSAGE; stanzas whose 'to' address is the bare JID of the user (subject to standard XMPP stanza handling rules).

    5. +

  5. MUST deliver inbound &MESSAGE; and &IQ; stanzas whose 'to' address is the resource of the client.

    6. +

  6. MUST deliver outbound &MESSAGE; and &IQ; stanzas generated by the client (for an important note regarding presence leaks, see the Security Considerations section of this document).

    7. +
+

If after sending directed presence the client then sends &UNAVAILABLE;, the server MUST deliver that unavailable presence only to the entities to which the client sent directed presence after going invisible.

+ + +

In order for a client to become visible again, it shall send an IQ-set with no 'to' address (thus handled by the user's server) containing a <visible/> element qualified by the 'http://jabber.org/protocol/invisibility' namespace:

+ + + + ]]> +

If the server can successfully process the visibility command, it MUST return an IQ-result:

+ + ]]> +

When the client becomes visible, the server MUST treat that state as equivalent to an active session before receiving initial presence from the client. It is the responsibility of the client to send an undirected presence notification to the server, which the server MUST broadcast to all entities who would normally receive presence broadcasts from the client (as well as any other entities to which the client sent directed presence while invisible).

+ + + +

It is possible to leak presence while in invisible mode (for example, by sending a message, IQ, or presence stanza to a contact). A client SHOULD warn a user before allowing the client to generate any outbound traffic and MUST NOT respond to IQ requests received from entities with which it has not initiated communications while in invisible mode (e.g., by sending messages, IQs, or directed presence).

+ + +

No interaction with &IANA; is required as a result of this JEP.

+ + + +

The ®ISTRAR; shall include 'http://jabber.org/protocol/invisibility' in its registry of protocol namespaces (see &NAMESPACES;).

+ + + + + + + + + + + + + + + + + + + ]]> + + diff --git a/xep-0187.xml b/xep-0187.xml new file mode 100644 index 00000000..a85cf43c --- /dev/null +++ b/xep-0187.xml @@ -0,0 +1,422 @@ + + +%ents; +y"> +x"> +x"> +y"> +A"> +B"> +A"> +B"> +A"> +B"> +A"> +B"> +A"> +B"> +A"> +B"> +32"> +2n-1"> +n-1"> +A"> +B"> +A"> +B"> +A"> +B"> +A"> +B"> +A"> +B"> +A"> +B"> +A"> +B"> +A"> +A"> +1...xZ"> +1...eZ"> +]> + + +
+ Offline Encrypted Sessions + This document specifies an end-to-end encryption protocol for offline XMPP communication sessions. + &LEGALNOTICE; + 0187 + Experimental + Standards Track + Standards JIG + + XMPP Core + RFC 2104 + RFC 2409 + RFC 3526 + RFC 3548 + xml-c14n + JEP-0004 + JEP-0020 + JEP-0068 + JEP-0079 + JEP-0116 + JEP-0155 + JEP-0163 + + None + None + offlineesession + &ianpaterson; + + 0.2 + 2006-07-19 + ip +

Removed public key IDs from Offline options; harmonised session termination with the protocol added to JEP-0155; renamed logging field to otr

 + + + 0.1 + 2006-07-18 + ip +

Initial version (extracted from JEP-0116 version 0.9).

 + +
+ + +

The convenience of sending stanzas to other entities that are offline ("offline messages") is an important and popular feature of most XMPP implementations (see &jep0160;). Without offline messages delivery would have to wait until both entities managed to be online at the same time. So many urgent messages could not be delivered in time. For example, the sender might want to send an urgent message before jumping on a flight.

+

End-to-end encryption is another desirable feature for any communication technology. Unfortunately it is not possible to make offline encryption quite so secure as online encryption (see Security Considerations). However, offline encryption has a long history and is certainly preferable to having no encryption at all. This protocol does not stop paranoid users avoiding sending offline messages. Unfortunately, for reasons described in &jep0188;, the existing proposals (including &jep0027; and &rfc3923;) have not been widely implemented and deployed. This document describes a different approach to offline end-to-end encryption for use by entities that communicate using XMPP. It builds on the existing online &jep0116; protocol. As a result it offers important advantages over the existing "Object Encryption" proposals:

+
    +
  • Perfect Forward Secrecy Long-lived keys are typically used for a few years, whereas Offline ESession decryption keys typically exist for just a few hours. So the Perfect Forward Secrecy feature significantly enhances the security of Offline ESessions.
    • +
  • Other security features described in Cryptographic Design of Encrypted Sessions
    • +
  • Most of the code can be borrowed from implementations of Encrypted Sessions
    • +
+

The requirements and the consequent cryptographic design that underpin this protocol are described in Cryptographic Design of Encrypted Sessions. The basic concept is that of an encrypted session which acts as a secure tunnel between the online endpoint and the offline endpoint. The offline endpoint completes its part of the tunnel "negotiation" by publishing its preferences before it goes offline. Once the tunnel is established by the online endpoint, the content of each one-to-one XML stanza sent by the online endpoint is encrypted and then transmitted within a "wrapper" stanza.

+ + + +

This JEP introduces two characters to help the reader follow the necessary exchanges:

+
    +
  1. "Bob" is the name of the online participant in the offline ESession. Within the scope of this JEP, his fully-qualified JID is: <bob@example.com/laptop>.
    2. +
  2. "Alice" is the name of the offline participant in the offline ESession started by Bob. Within the scope of this JEP, we stipulate that her fully-qualified JID is: <alice@example.org/pda>.
    3. +
+

While Bob and Alice are introduced as "end users", they are simply meant to be examples of Jabber entities. Any directly addressable Jabber entity may participate in an offline ESession.

+ + + +

The approach to establishing a secure session with an entity that is offline is in essence a special case of 3-message negotiation employed for online ESessions (see Encrypted Sessions).

+

Alice MAY publish a set of offline ESession options just before she goes offline. If Bob subscribes to Alice's presence and wishes to establish an online ESession with her, but he finds that she is offline, then if she published her offline ESession options before going offline, he may use the protocol described below to perform the initial Diffie-Hellman key exchange, establish an offline ESession and send encrypted stanzas to her while she is offline. Note: Bob MUST NOT initiate a new ESession with Alice if he already has an ESession established with her.

+

Note: Alice MAY also publish another similar set of relatively long-lived The more often Alice changes her published ESession options, the shorter the Perfect Forward Secrecy window of vulnerability. However, whenever she changes them she divulges her presence to all the entities that are monitoring them. offline ESession options that any entity MAY use for the same purpose.

+ + +

In order to publish either set of her offline ESession options Alice MUST create an options data form in exactly the same way as she would create an online ESession request data form (see the ESession Request section in Encrypted Sessions) except she MUST omit The 'accept' and 'pk_hash' fields. Note: The list of stanza types she is willing to decrypt MUST NOT include the value 'iq'.

+

Alice MUST append to the content of the form an 'expires' field containing the UTC time (see &jep0082;) that she decides her offline ESession options will expire (see Options Expiry Time Security Considerations).

+

Alice MUST store her value of &NsubA; (her ESession ID), all her values of x (one for each MODP group) and the time she decides her offline ESession options will expire in a secure way, so that she can retrieve them when she comes back online (idealy even if that is using a different client and/or a different machine).

+

If Alice would not be able to decrypt stanzas if she came back online using a different client and/or a different machine then she SHOULD also encapsulate the resource of her client in a 'match_resource' field and append it to her options data form. In this case, the list of stanza types she is willing to decrypt MUST include only 'message'.

+

Alice MUST also append to the content of the form a list of signatures (see Signature Generation) of the content of the data form (excluding the 'signs' field). The list SHOULD include one signature for each of the public signature-verification keys that other entities may use to authenticate her.

+

Alice MUST publish the ESession options data form through her own server using &jep0163;.

+

If the pubkey PEP node does not exist already then Alice MUST create it first. In this case, Alice SHOULD specify the "Presence" access model for the set of options for presence subscribers (or the "Open" model for the set for other entities), unless she wants greater control over access to her identity (see Identity Protection Security Considerations). Alice SHOULD specify that the options will never be pushed to subscribers (even when she publishes new options) - especially if she specifies the "Whitelist" access model.

+ + + + + + + http://jabber.org/protocol/pubsub#node_config + + + + + + + + + + + + + + + ]]> + + + + + + + http://jabber.org/protocol/pubsub#node_config + + + + + + + + + + + + + + + ]]> +

Once the publishing node has been created, Alice can update her options for subscribers to her presence whenever she goes offline:

+ + + + + + + http://jabber.org/protocol/chatneg + + + 0 + + + 0 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 1 + + + 2006-06-09T02:56:15Z + + + ** Base64 encoded ESession ID ** + + + ** Base64 encoded value of e5 ** + ** Base64 encoded value of e14 ** + ** Base64 encoded value of e2 ** + + + pda + + + ** signature of form ** + ** signature of form ** + + + + + + + ]]> +

At the risk of divulging her presence, Alice MAY also update her options for all entities:

+ + + + ... + + + + ]]> + + +

If Bob believes Alice is offline he SHOULD request her ESession options and, if he does not have a local copy of any of her public keys, her long-term public signature-verification keys from her server using Personal Eventing via Pubsub (see &jep0189;). There is no need for Bob to discover Alice's support for the Offline ESessions protocol via &jep0030;.

+

If Bob is subscribing to Alice's presence he MUST request her ESession Options exclusively for subscribers.

+ + + + + + ]]> +

If Bob is not subscribing to Alice's presence (or if Alice has no ESession options exclusively for subscribers) he MUST use the following request instead.

+ + + + + + ]]> +

If, after receiving Alice's offline ESession options, Bob is unable to verify any of Alice's signatures of her options data form (see Signature Verification) with any of her public keys already in his possession (or with any of her keys he is able to acquire and trust) then he MUST proceed no further, since he cannot be sure who will be able to decrypt his stanzas.

+

If Bob cannot acquire Alice's ESession options, or he does not support one or more of the options in each Alice's ESession fields, or if the 'expires' field indicates that Alice's options have expired, then he MUST NOT send encrypted stanzas to her while she is offline.

+ + + +

Bob MUST now continue as if Alice had requested an online ESession, performing the steps described in three of the sections of Encrypted Sessions:

+
    +

  1. Diffie-Hellman Preparation (Bob) Note: If the value of e he selected is not valid, Bob SHOULD terminate the ESession without sending an error.

    2. +

  2. Generating Session Keys

    3. +

  3. Hiding Identity Note: Since Bob did not receive a 'pk_hash' field, he MUST assume its value is false. Bob SHOULD NOT include a 'pk_hash' field in &formB; since Alice has already proved her identity.

    4. +
+

As with 3-message ESession negotiation, Bob should encapsulate the Base64 encoded values of &IDB; and &MsubB; in data form fields ('identity' and 'mac'), and append the new fields to &formB;.

+

Bob MAY also send encrypted content (see the Exchanging Stanzas section of Encrypted Sessions) in the same stanza. Note: If he also includes a field named "terminate" set to a value of "1" or "true" within the data form (see the ESession Termination section of Encrypted Sessions) then the ESession is terminated immediately. This special case, where a single stanza is encrypted and sent in isolation, is equivalent to object encryption (or object signing if no encryption is specified) and offers several significant advantages over non-session approaches - including perfect forward secrecy.

+

If Alice included a 'match_resource' field in her ESession options, then Bob MUST address all the stanzas he sends within the offline ESession to the specified resource and use the Advanced Message Processing protocol to ensure that they are not delivered to any other resource.

+

After sending &formB; to Alice, Bob can assume that the ESession negotiation is complete.

+ + + + + http://jabber.org/protocol/chatneg + + 1 + 0 + 5 + aes256-ctr + sha256 + rsa + none + message + 1.3 + 50 + + ** Base64 encoded ESession ID ** + + + ** Base64 encoded value of d ** + + + ** Base64 encoded ESession ID ** + + + ** Base64 encoded block counter ** + + + ** Encrypted identity ** + + + ** Integrity of identity ** + + + + + ** Base64 encoded m_final ** + ** Base64 encoded a_mac ** + + + + + + ]]> + + +

When Alice comes online she MUST perform the following steps:

+
    +

  1. Ensure she is no longer publishing offline ESession options exclusively for entities that are subscribing to her presence.

    + + + + + + + + ]]> +
    2. +

  2. Retrieve any values of &NsubA;, x (one for each MODP group for each &NsubA;) and her offline ESession options expiry time that she stored before going offline, and destroy in a secure way any persistently stored copies that correspond to ESession options exclusively for subscribers.

    3. +
+

If the current time is after her offline ESession options expiry time then she MUST discard all stanzas from offline ESessions without decrypting them. Otherwise, when Alice receives an offline ESession request stanza from Bob then she MUST perform the following steps:

+
    +

  1. Select her value of x that corresponds to the 'nonce' and 'modp' fields she received from Bob. Alice may not be able to find the specified value of x if, for example, she went offline using a different client and/or a different machine without publishing a 'match_resource' field. In this case Alice cannot decrypt the offline ESession!

    2. +

  2. Confirm that she has not already received a key exchange stanza from Bob with the same value of d or &NsubB; ('my_nonce' field) since she published her ESession options (see the Replay Attacks subsection of the Security Considerations section of Encrypted Sessions). If the options were for subscribers, that means since she came online.

    3. +

  3. Alice MUST now continue as if Bob had responded to her online ESession request, performing the steps described in two of the sections of Encrypted Sessions:

    +
      +

    • Diffie-Hellman Preparation (Alice) Note: If she is not prepared to support any of the ESession options specified by Bob, or if the value of d she selected is not valid, then Alice SHOULD terminate the ESession without sending an error.

      • +

    • Verifying Bob's Identity Note: Since Alice did not send a 'pk_hash' field to Bob, she MUST assume its value is false. If the value of &MsubB; she calculated does not match the one she received, or if she cannot confirm that &pubKeyB; really is Bob's public key, or if she cannot confirm that &signB; is the signature of the HMAC result, then Alice SHOULD terminate the ESession without sending an error.

      • +
    4. +
+ + + + + +

Alice MUST NOT send encrypted content within an offline ESession started by Bob. If Bob is conducting an offline ESession with Alice when she is online (e.g., if he is not subscribing to her presence), then if Alice wants to send a stanza to Bob, she MUST terminate the offline ESession and start a new online ESession first.

+

For Offline ESessions, Bob SHOULD include a 'Created' SHIM header in the encrypted content. Assuming she trusts Bob, Alice SHOULD trust this header and ignore the unencrypted &jep0091; element inserted by her server.

+ + Hello, Alice! + + + + +
2005-02-10T03:01:52Z
+ + + +]]> + Hello, Alice! + +
2005-02-10T03:01:52Z
+ + + ]]> + + + + +

If Bob notices that Alice comes online during his offline ESession with her then he MUST terminate the ESession immediately. If required he may then negotiate a new (more secure) online ESession.

+

When Alice receives the offline ESession termination stanza from Bob, she SHOULD NOT send a termination stanza back to him.

+ + + + +

For more security considerations refer to the Security Considerations section of Encrypted Sessions

+ +

Since Alice supplies the same set of values of e for all offline ESessions, to prevent complete offline ESessions being replayed to her, she MUST take care to securely store new values (or destroy existing values) of &NsubA; and x for subscribers whenever she goes offline (see Publishing ESession Options). Also, when Alice comes online again, she MUST remember all the values of d he receives in offline ESession negotiation stanzas, and reject any offline ESessions that specify a value of d she has already received (see Accepting an Offline ESession).

+

Note: If Alice publishes ESession options for non-subscribers, and if she does not update them whenever she comes online then, until she updates the options, she MUST save all the values of d she receives to secure persistent storage (along with the values of &NsubA; and x).

+ + +

If Alice's offline private Diffie-Hellman keys are compromised before she destroys them, and the attacker also controls communications between Bob and Alice's server, then the attacker could prevent Bob discovering if she comes online, and resend her compromised ESession options to Bob whenever he asks for them. This would allow the attacker to decrypt all messages sent to Alice before her offline ESession options expire. Alice would probably never receive the messages sent to her after she comes back online. If an attack is discovered before the compromised ESession options expire then Alice SHOULD change her long-term signing key. Alice SHOULD mitigate this attack by choosing an expiry time for her ESession options that is not too long after she expects to be online again.

+ + +

Alice's Offline ESession options include her signatures. Although the signatures are public information, any entity that possesses one of Alice's corresponding public keys may confirm whether or not she is the entity using the JID. If it is important for Alice to protect her identity (i.e. hide the fact that she is the user of the JID), then she MUST carefully control who has access to her public keys.

+ + +

In addition to the issues above, the Perfect Forward Secrecy window of vulnerability is longer. More seriously, Alice MUST store her private Diffie-Hellman keys, &x1xZ;, to local disk or to a server (perhaps symmetrically encrypted with a password). It is really hard to securely erase something from a disk. Note: Once compromised, her private Diffie-Hellman keys could only be used to decrypt messages sent to her within offline Esessions until her offline ESession options expire. They could not be used to negotiate online ESessions The online ESessions protocol forces both Alice and Bob to produce a signature of both their Diffie-Hellman keys together., or to send messages that appear to be from Alice. This is a significant benefit when compared to the existing "object encryption" schemes.

+

Alice could decide not to support Offline ESessions since they are less secure than online ESessions. However, if Alice does that then, while she is offline, Bob, or Aunt Tillie, will probably send her completely unprotected messages!

+ + + + +

This JEP requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; shall add 'http://jabber.org/protocol/esession#subscription' to its registry of protocol namespaces.

+ + + diff --git a/xep-0188.xml b/xep-0188.xml new file mode 100644 index 00000000..603a6cd4 --- /dev/null +++ b/xep-0188.xml @@ -0,0 +1,748 @@ + + +%ents; +y"> +x"> +x"> +y"> +A"> +B"> +A"> +B"> +A"> +B"> +A"> +B"> +A"> +B"> +A"> +B"> +32"> +2n-1"> +n-1"> +A"> +B"> +A"> +B"> +A"> +B"> +A"> +B"> +A"> +B"> +A"> +B"> +A"> +B"> +A"> +A"> +1...xZ"> +1...eZ"> +]> + + +
+ Cryptographic Design of Encrypted Sessions + This document describes the requirements and cryptographic design that underpin the XMPP protocol extensions Encrypted Sessions and Offline Encrypted Sessions. + &LEGALNOTICE; + 0188 + Experimental + Informational + Standards JIG + + XMPP Core + RFC 2104 + + None + None + cryptoesession + &ianpaterson; + + 0.2 + 2006-07-19 + ip +

Removed public key IDs from Offline options

 + + + 0.1 + 2006-07-18 + ip +

Initial version (extracted from JEP-0116 version 0.9).

 + +
+ + +

Note: The protocols developed according to the requirements and cryptographic design described in this JEP are documented in &jep0116; and &jep0187;. The information in those JEPs should be sufficient for implementors. This purely informative JEP is primarily for people interested in the design and analysis of those protocols.

+

As specified in &rfc3920;, XMPP is an XML streaming protocol that enables the near-real-time exchange of XML fragments between any two (or more) network endpoints. To date, the main application built on top of the core XML streaming layer is instant messaging (IM) and presence, the base extensions for which are specified in &rfc3921;. There are three first-level elements of XML streams (&MESSAGE;, &PRESENCE;, and &IQ;); each of these "XML stanza" types has different semantics, which can complicate the task of defining a generalized approach to end-to-end encryption for XMPP. In addition, XML stanzas can be extended (via properly-namespaced child elements) for a wide variety of functionality.

+

XMPP is a session-oriented communication technology: normally, a client authenticates with a server and maintains a long-lived connection that defines the client's XMPP session. Such stream-level sessions may be secured via channel encryption using Transport Level Security (&rfc2246;), as specified in Section 5 of RFC 3920. However, there is no guarantee that all hops will implement or enforce channel encryption (or that intermediate servers are trustworthy), which makes end-to-end encryption desirable.

+

The encrypted stanzas should be understood by an intermediate server only to the extent required to route them. (One complicating factor is that routing information may include not only the stanza's 'to', 'from', 'type, and 'id' attributes, but also &jep0079; extensions.)

+

The session metaphor also applies to communication between endpoints: for instance, in IM applications, most instant messaging exchanges occur in bursts within limited time periods (e.g., two people may send a fairly large number of messages during a five-minute chat and then not exchange messages again for hours or even days). The XML stanzas exchanged during such a session may not be limited to &MESSAGE; stanzas; for instance, the session may be triggered by a change in one of the parties' presence status (e.g., changing from away to available) and the session may involve the exchange of &IQ; stanzas (e.g., to transfer a file as specified in &jep0096;).

+

The foregoing XMPP communications exist in the context of a one-to-one communication session between two entities. However, several forms of XMPP communication exist outside the context of one-to-one communication sessions:

+
    +
  • Many-to-many sessions, such as a text conference in a chatroom as specified in &jep0045;.
    • +
  • One-to-many "broadcast", such as undirected presence stanzas sent from one user to many contacts (see RFC 3921) and data syndication implemented using &jep0060;.
    • +
  • One-to-one communications that are stored for later delivery rather than delivered immediately, such as so-called "offline messages".
    • +
+ + + +

Ideally, any technology for end-to-end encryption in XMPP could be extended to cover all the scenarios above as well as one-to-one communication sessions. However, both many-to-many sessions and one-to-many broadcast are deemed out of scope for this JEP.

+

Offline communications are handled via a simple extension to the protocol for one-to-one sessions between two entities that are online simultaneously (see below).

+ + + +

Existing approaches to encryption of Internet communications have generally assumed that the "thing" to be encrypted has a stable identity or is best understood as a standalone object (e.g., a file or email message); the term "object encryption" well captures this assumption. Both &jep0027; and &rfc3923; assume that XMPP communications are more like the exchange of email messages than they are like an interactive session -- while Current Jabber OpenPGP Usage uses "old-style" PGP object encryption and RFC 3923 uses "new-style" S/MIME object encryption, both specify the use of object encryption.

+

However, because XMPP is a session-oriented communication technology, encryption schemes that are appropriate for other Internet technologies may not be appropriate for XMPP. XMPP, with its in-order delivery of XML stanzas, is able to take advantage of more secure approaches to encryption that are not feasible for less dynamic technologies (like email).

+

The session-oriented nature of XMPP implies that the focus should be on "session encryption" rather than "object encryption". The paradigm for XMPP encryption should be something closer to the widely-deployed Secure Shell technology (see &rfc4301; and &rfc4253;) than to traditional encryption of files and standalone email messages.

+

Therefore, this JEP specifies a method for encrypted sessions ("ESessions") that takes advantage of the inherent possibilities and strengths of session encryption as opposed to object encryption. The conceptual model for this approach was inspired by "off-the-record" (OTR) communication, as implemented in the Gaim encryption plugin and described in &otr;. The basic concept is that of an encrypted session which acts as a secure tunnel between two endpoints. Once the tunnel is established, the content of all one-to-one XML stanzas exchanged between the endpoints will be encrypted and then transmitted within a "wrapper" protocol element.

+

Note: In order to gain a thorough understanding of this JEP, it is recommended that the Off-the-Record Communication paper is read first.

+ + + +

This JEP introduces two characters to help the reader follow the necessary exchanges:

+
    +
  1. "Alice" is the name of the initiator of the ESession.
    2. +
  2. "Bob" is the name of the other participant in the ESession started by Alice.
    3. +
+

While Alice and Bob are introduced as "end users", they are simply meant to be examples of Jabber entities. Any directly addressable Jabber entity may participate in an ESession.

+ + + + +

This JEP stipulates the following security requirements for end-to-end encryption of XMPP communications:

+
    +
  • Confidentiality
    • +
  • Integrity
    • +
  • Replay protection
    • +
  • Perfect forward secrecy
    • +
  • Authentication
    • +
  • Identity Protection
    • +
  • Repudiability
    • +
  • Upgradability
    • +
+

Each of these requirements is explained in greater depth below.

+ +

The one-to-one XML stanzas exchanged between two entities MUST NOT be understandable to any other entity that might intercept the communications.

+ + +

Alice and Bob MUST be sure that no other entity may change the content of the XML stanzas they exchange, or remove or insert stanzas into the ESession undetected.

+ + +

Alice or Bob MUST be able to identify and reject any communications that are copies of their previous communications resent by another entity.

+ + +

The encrypted communication MUST NOT be revealed even if long-lived keys are compromised in the future (e.g., Steve steals Bob's computer). Long-lived keys are typically used for a few years, whereas Offline ESession keys are destroyed as soon as the stanza is decrypted - they typically exist for just a few hours. So Perfect Forward Secrecy should significantly enhance the security even of Offline ESessions.

+ + +

Each party to a conversation MUST know that the other party is who he says he is (Alice must be able to know that Bob really is Bob, and vice versa). The reliable association between an entity and its public keys is beyond the scope of this JEP.

+ + +

No other entity should be able to identify Alice or Bob. The JIDs they use to route their stanzas are unavoidably vulnerable to interception. However, the public keys they use SHOULD NOT be revealed to other entities using a passive attack. Bob SHOULD also be able to choose between protecting either his public key or Alice's public key from disclosure through active ("man-in-the-middle") attacks.

+ + +

Alice and Bob MUST be able to repudiate any stanza that occurs within an ESession. After an ESession has finished, it SHOULD NOT be possible to prove cryptographically that any transcript has not been modified by a third party. Naturally, it is possible that Alice or Bob may retain cleartext versions of the exchanged communications; however, that threat is out of scope for this JEP.

+ + +

The protocol must be upgradable so that, if a vulnerability is discovered, a new version can fix it. Alice MUST tell Bob which versions of the protocol she is prepared to support. Then Bob MUST either choose one or reject the ESession. It is exceptionally difficult to design a truly secure authenticated key-exchange protocol. Weaknesses are often only discovered after years of expert cryptographic analysis. In many cases, only the widespread use of a protocol will motivate experts to undertake exhaustive analyses and recommend enhancements.

+ + + +

In addition to the foregoing security profile, this JEP also stipulates the following application-specific requirements for encrypted communication in the context of Jabber/XMPP technologies:

+
    +
  • Generality
    • +
  • Implementability
    • +
  • Usability
    • +
  • Efficiency
    • +
  • Flexibility
    • +
  • Interoperability
    • +
  • Offline "sessions"
    • +
  • Object encryption
    • +
+

Each of these is explained in greater depth below.

+ +

The solution should be generally applicable to the full content of any XML stanza type (&MESSAGE;, &PRESENCE;, &IQ;) sent between two entities. It is deemed acceptable for now if the solution does not apply to many-to-many stanzas (e.g., groupchat messages sent within the context of multi-user chat) or one-to-many stanzas (e.g., presence "broadcasts" and pubsub notifications); end-to-end encryption of such stanzas may require separate solutions or extensions to the one-to-one session solution.

+ + +

The only good security technology is an implemented security technology. The solution should be one that typical client developers can implement in a relatively straightforward and interoperable fashion.

+ + +

The requirement of usability takes implementability one step further by stipulating that the solution must be one that organizations may deploy and humans may use with 100% transparency (with the ease-of-use of https:). Experience has shown that: solutions requiring a full public key infrastructure do not get widely deployed, and solutions requiring any user action are not widely used. We can do better.

+ + +

Cryptographic operations are highly CPU intensive, particularly public key and Diffie-Hellman operations. Cryptographic data structures can be relatively large especially public keys and certificates. The solution should perform efficiently even when CPU and network bandwidth are constrained. The number of stanzas required for ESession negotiation should be minimized.

+ + +

The solution should be compatible with existing (and future) cryptographic algorithms and identity certification schemes (including X.509 and PGP). The protocol should also be able to evolve to correct the weaknesses that are inevitably discovered once any cryptographic protocol is in widespread use.

+ + +

Ideally, it would be possible for an XMPP user to exchange encrypted messages (and, potentially, presence information) with users of non-XMPP messaging systems.

+ + +

Ideally, it should be possible to encrypt one-to-one communications that are stored for later delivery instead of being delivered immediately, such as so-called "offline messages". However, any vulnerabilities introduced to enable offline communications must not make online communications more vulnerable.

+ + +

For cases where a session is not desired, it should be possible to encrypt, sign and send a single stanza in isolation, so-called "object encryption".

+ + + + + + +

Authenticated key-exchange is the most challenging part of the design of any secure communication protocol. The ESessions key exchange essentially translates the σLike RFC 2409, this protocol uses variant (ii), as described in Secion 5.4 of the SIGMA paper. key-exchange protocol into the syntax of XMPP. The SIGMA approach to Diffie-Hellman Key Agreement (see &rfc2631;) underpins several standard key-exchange protocols including the Internet Key Exchange (IKE) protocol versions 1 and 2 (see &rfc2409; and &rfc4306;).

+

Note: Although this section provides an overview of SIGMA, it is recommended that the SIGMA paper is read first in order to gain a thorough understanding of this JEP.

+

The 3-message SIGMA-I-based key exchange protects the identity of the initiator against active attacks. The 4-message SIGMA-R-based key exchange defends the responder's identity against active attacks. The differences between the two versions of the SIGMA protocol are highlighted in the diagrams below.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterDescription
gDiffie-Hellman generator
x, yAlice and Bob's private Diffie-Hellman keys
&gsupx;, &gsupy;Alice and Bob's public Diffie-Hellman keys
&KSsubA;, &KSsubB;The MAC keys that Alice and Bob use to calculate &macA; and &macB;
&pubKeyA;, &pubKeyB;The public keys that represent the identity of Alice and Bob, and are used to verify their signatures
&macA;, &macB;The MAC values that associate the shared secret with the identity of Alice or Bob
&signKeyA;, &signKeyB;The private keys that Alice and Bob use to sign
&signA;, &signB;Alice's and Bob's signatures of the shared secret
&KCsubA;, &KCsubB;The cipher keys that Alice and Bob use to encrypt
&IDA;, &IDB;The encrypted parameters that identify Alice and Bob to each other
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterDescription
pDiffie-Hellman prime
e, dAlice and Bob's public Diffie-Hellman keys (the same as &gsupx;, &gsupy;)
KShared secret
HASHSelected hash algorithm
&NsubA;, &NsubB;Alice and Bob's session freshness nonces (ESession IDs)
&CsubA;, &CsubB;Block cipher initial counter value for blocks sent by Alice and Bob
nBlock size of selected cipher algorithm in bits
&KMsubA;, &KMsubB;The MAC keys that Alice and Bob use to protect the integrity of encrypted data
&MsubA;, &MsubB;The MAC values that Alice and Bob use to confirm the integrity of encrypted data
+ + + +

The diagram below demonstrates the barest cryptographic skeleton of the SIGMA-I key exchange protocol. Here Bob allows Alice to protect her identity from active attacks, by allowing her to authenticate him before she communicates her identity. Note: The cipher keys (&KCsubA; and &KCsubB;) are different in each direction, making this exchange slightly more conservative than SIGMA.

+ 
+ALICE                                                BOB 
+                                            &gsupx;
+                                      ------------>
+
+                                                     &macB; = HMAC(&KSsubB;, {&gsupx;, &gsupy;, &pubKeyB;})
+                                                     &signB; = sign(&signKeyB;, &macB;)
+                                                     &IDB; = cipher(&KCsubB;, {&pubKeyB;, &signB;})
+                                         &gsupy;, &IDB; 
+                                      <------------
+
+authenticate(&IDB;) 
+&macA; = HMAC(&KSsubA;, {&gsupy;, &gsupx;, &pubKeyA;})
+&signA; = sign(&signKeyA;, &macA;)
+&IDA; = cipher(&KCsubA;, {&pubKeyA;, &signA;})
+                                            &IDA;
+                                      ------------>
+
+                                                     authenticate(&IDA;)
+
+ + + +

The logic of the SIGMA-R protocol is similar to the SIGMA-I protocol. The diagram below demonstrates the skeleton of the key exchange. After receiving the first message from Alice, Bob chooses to protect his identity from active attacks by by delaying communicating his identity to Alice until he has authenticated her.

+ 
+ALICE                                                BOB 
+                                            &gsupx;
+                                      ------------>
+
+                                                     &macB; = HMAC(&KSsubB;, {&gsupx;, &gsupy;, &pubKeyB;})
+                                                     &signB; = sign(&signKeyB;, &macB;)
+                                                     &IDB; = cipher(&KCsubB;, {&pubKeyB;, &signB;})
+                                            &gsupy;
+                                      <------------
+
+&macA; = HMAC(&KSsubA;, {&gsupy;, &gsupx;, &pubKeyA;})
+&signA; = sign(&signKeyA;, &macA;)
+&IDA; = cipher(&KCsubA;, {&pubKeyA;, &signA;})
+                                           &IDA;
+                                      ------------>
+
+                                                     authenticate(&IDA;)
+                                           &IDB;
+                                      <------------
+
+authenticate(&IDB;)
+
+

Note: In practice, Bob could delay calculating &IDB; until after he has authenticated &IDA;.

+ + + +

The diagram below describes exactly the same SIGMA-I key exchange protocol as the SIGMA-I skeleton above. It provides much more detail, without specifying any ESession-specific details. Note: The block cipher function, cipher, uses CTR mode.

+ 
+ALICE                                        BOB 
+
+x = random()
+e = &gsupx; mod p
+&NsubA; = random()
+                                 e, &NsubA;
+                             ------------>
+                                             &CsubA; = random()
+                                             y = random()
+                                             d = &gsupy; mod p
+                                             &CBeCAx2n1; 
+                                             assert 1 < e < p-1
+                                             K = HASH(&esupy; mod p)
+                                             &KCsubA; = HASH(0, K)
+                                             &KCsubB; = HASH(1, K)
+                                             &KMsubA; = HASH(2, K)
+                                             &KMsubB; = HASH(3, K)
+                                             &KSsubA; = HASH(4, K)
+                                             &KSsubB; = HASH(5, K)
+                                             &NsubB; = random()
+                                             &macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &CsubA;})
+                                             &signB; = sign(&signKeyB;, &macB;)
+                                             &IDB; = cipher(&KCsubB;, &CsubB;, {&pubKeyB;, &signB;})
+                                             &MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)
+                               d, &CsubA;, &NsubB;
+                             <------------
+                                &IDB;, &MsubB; 
+&CBeCAx2n1; 
+assert 1 < d < p-1
+K = HASH(&dsupx; mod p)
+&KCsubA; = HASH(0, K)
+&KCsubB; = HASH(1, K)
+&KMsubA; = HASH(2, K)
+&KMsubB; = HASH(3, K)
+&KSsubA; = HASH(4, K)
+&KSsubB; = HASH(5, K)
+assert &MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)
+{&pubKeyB;, &signB;} = decipher(&KCsubB;, &CsubB;, &IDB;)
+&macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &CsubA;})
+verify(&signB;, &pubKeyB;, &macB;) 
+&macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;})
+&signA; = sign(&signKeyA;, &macA;)
+&IDA; = cipher(&KCsubA;, &CsubA;, {&pubKeyA;, &signA;})
+&MsubA; = HMAC(HASH, &KMsubA;, &CsubA;, &IDA;)
+                                  &IDA;
+                             ------------>
+                                   &MsubA; 
+                                             assert &MsubA; = HMAC(HASH, &KMsubA;, &CsubA;, &IDA;)
+                                             {&pubKeyA;, &signA;} = decipher(&KCsubA;, &CsubA;, &IDA;)
+                                             &macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;})
+                                             verify(&signA;, &pubKeyA;, &macA;)
+
+ + + +

The diagram below describes exactly the same SIGMA-R key exchange protocol as the SIGMA-R skeleton above. It provides much more detail, without specifying any ESession-specific details. Note: The block cipher function, cipher, uses CTR mode.

+ 
+ALICE                                        BOB 
+
+x = random()
+e = &gsupx; mod p
+&NsubA; = random()
+                                 e, &NsubA;
+                             ------------>
+                                             &CsubA; = random()
+                                             y = random()
+                                             d = &gsupy; mod p
+                                             &CBeCAx2n1; 
+                                             assert 1 < e < p-1
+                                             K = HASH(&esupy; mod p)
+                                             &KCsubA; = HASH(0, K)
+                                             &KCsubB; = HASH(1, K)
+                                             &KMsubA; = HASH(2, K)
+                                             &KMsubB; = HASH(3, K)
+                                             &KSsubA; = HASH(4, K)
+                                             &KSsubB; = HASH(5, K)
+                                             &NsubB; = random()
+                                             &macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &CsubA;})
+                                             &signB; = sign(&signKeyB;, &macB;)
+                                             &IDB; = cipher(&KCsubB;, &CsubB;, {&pubKeyB;, &signB;})
+                                             &MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)
+                               d, &CsubA;, &NsubB;
+                             <------------
+&CBeCAx2n1; 
+assert 1 < d < p-1
+K = HASH(&dsupx; mod p)
+&KCsubA; = HASH(0, K)
+&KCsubB; = HASH(1, K)
+&KMsubA; = HASH(2, K)
+&KMsubB; = HASH(3, K)
+&KSsubA; = HASH(4, K)
+&KSsubB; = HASH(5, K)
+&macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;})
+&signA; = sign(&signKeyA;, &macA;)
+&IDA; = cipher(&KCsubA;, &CsubA;, {&pubKeyA;, &signA;})
+&MsubA; = HMAC(HASH, &KMsubA;, &CsubA;, &IDA;)
+                                  &IDA;
+                             ------------>
+                                   &MsubA; 
+                                             assert &MsubA; = HMAC(HASH, &KMsubA;, &CsubA;, &IDA;)
+                                             {&pubKeyA;, &signA;} = decipher(&KCsubA;, &CsubA;, &IDA;)
+                                             &macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;})
+                                             verify(&signA;, &pubKeyA;, &macA;)
+                                  &IDB;
+                             <------------
+                                   &MsubB; 
+
+assert &MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)
+{&pubKeyB;, &signB;} = decipher(&KCsubB;, &CsubB;, &IDB;)
+&macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &CsubA;})
+verify(&signB;, &pubKeyB;, &macB;)
+
+ + + + +

This section provides an overview of the full ESession key-exchange protocol from a cryptographic point of view. This protocol is based on the full fledge protocol, as described in Appendix B of the SIGMA paper. It also uses variant (ii), as described in Secion 5.4 of the same paper.

+ +

The table below describes the parameters that are not found in the Parameter Descriptions tables at the start of the previous section.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterDescription
optionsIncludes a set of possible values for each and every ESession parameter (see the ESession Request sub-section in Encrypted Sessions), including sets of possible values for p, g, HASH, CIPHER, SIGN
chosenIncludes a chosen value for each ESession parameter
CIPHERSelected CTR-mode block cipher algorithm
DECIPHERSelected CTR-mode block decipher algorithm (corresponds to CIPHER)
SIGNSelected signature algorithm
VERIFYThe selected signature verification algorithm (corresponds to SIGN)
&x1xZ;Alice's private Diffie-Hellman keys - each value corresponds to one of Z different DH groups
&e1eZ;The choice of public Diffie-Hellman keys that Alice offers Bob - each value corresponds to one of Z different DH groups (and a different value of x)
*&signKeysA;All the private keys that Alice is able to use to create signatures
*&signsB;The set of signatures of &formB; (one for each of Bob's private keys)
*&pubKeysA;All of Alice's public keys that Bob has access to
+

* Offline negotiation only

+ + +

Alice uses this protocol when Bob is Online. In addition to the key exchange described in the SIGMA-I Key Exchange protocol above, she offers Bob a choice of Diffie-Hellman groups with her corresponding values of e, various algorithms and other parameters.

+ + 
+ALICE                                    BOB 
+
+for g,p ∈ options
+    x = random()
+    e = &gsupx; mod p
+&NsubA; = random()
+&formA; = {&e1eZ;, options, &NsubA;}
+                                &formA;
+                             --------->
+
+                                         chosen = {p,g,HASH,CIPHER,SIGN...} = choose(options)
+                                         e = choose(&e1eZ;, p)
+                                         &CsubA; = random()
+                                         y = random()
+                                         d = &gsupy; mod p
+                                         &CBeCAx2n1; 
+                                         assert 1 < e < p-1
+                                         K = HASH(&esupy; mod p)
+                                         &KCsubA; = HASH(0, K)
+                                         &KCsubB; = HASH(1, K)
+                                         &KMsubA; = HASH(2, K)
+                                         &KMsubB; = HASH(3, K)
+                                         &KSsubA; = HASH(4, K)
+                                         &KSsubB; = HASH(5, K)
+                                         &NsubB; = random()
+                                         &formB; = {&CsubA;, chosen, d, &NsubA;, &NsubB;}
+                                         &macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;})
+                                         &signB; = SIGN(&signKeyB;, &macB;)
+                                         &IDB; = CIPHER(&KCsubB;, &CsubB;, {&pubKeyB;, &signB;})
+                                         &MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)
+                                &formB;
+                             <---------
+                               &IDB;, &MsubB; 
+assert chosen ∈ options
+x = choose(&x1xZ;, p)
+e = &gsupx; mod p
+&CBeCAx2n1; 
+assert 1 < d < p-1
+K = HASH(&dsupx; mod p)
+&KCsubA; = HASH(0, K)
+&KCsubB; = HASH(1, K)
+&KMsubA; = HASH(2, K)
+&KMsubB; = HASH(3, K)
+&KSsubA; = HASH(4, K)
+&KSsubB; = HASH(5, K)
+assert &MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)
+{&pubKeyB;, &signB;} = DECIPHER(&KCsubB;, &CsubB;, &IDB;)
+&macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;})
+VERIFY(&signB;, &pubKeyB;, &macB;) 
+&macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &formA;})
+&signA; = SIGN(&signKeyA;, &macA;)
+&IDA; = CIPHER(&KCsubA;, &CsubA;, {&pubKeyA;, &signA;})
+&MsubA; = HMAC(HASH, &KMsubA;, &CsubA;, &IDA;)
+                                 &IDA;
+                             --------->
+                               &NsubB;, &MsubA; 
+                                         assert &MsubA; = HMAC(HASH, &KMsubA;, &CsubA;, &IDA;)
+                                         {&pubKeyA;, &signA;} = DECIPHER(&KCsubA;, &CsubA;, &IDA;)
+                                         &macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &formA;})
+                                         VERIFY(&signA;, &pubKeyA;, &macA;)
+
+ + + +

This protocol is similar to the Online ESession-I Negotiation above, except that after receiving the first message from Alice, Bob chooses to protect his identity from active attacks (by by delaying communicating his identity to Alice until he has authenticated her).

+ 
+ALICE                                    BOB 
+
+for g,p ∈ options
+    x = random()
+    e = &gsupx; mod p
+&NsubA; = random()
+&formA; = {&e1eZ;, options, &NsubA;}
+                                &formA;
+                             --------->
+
+                                         chosen = {p,g,HASH,CIPHER,SIGN...} = choose(options)
+                                         e = choose(&e1eZ;, p)
+                                         &CsubA; = random()
+                                         y = random()
+                                         d = &gsupy; mod p
+                                         &CBeCAx2n1; 
+                                         assert 1 < e < p-1
+                                         K = HASH(&esupy; mod p)
+                                         &KCsubA; = HASH(0, K)
+                                         &KCsubB; = HASH(1, K)
+                                         &KMsubA; = HASH(2, K)
+                                         &KMsubB; = HASH(3, K)
+                                         &KSsubA; = HASH(4, K)
+                                         &KSsubB; = HASH(5, K)
+                                         &NsubB; = random()
+                                         &formB; = {&CsubA;, chosen, d, &NsubA;, &NsubB;}
+                                         &macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;})
+                                         &signB; = SIGN(&signKeyB;, &macB;)
+                                         &IDB; = CIPHER(&KCsubB;, &CsubB;, {&pubKeyB;, &signB;})
+                                         &MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)
+
+                                &formB;
+                             <---------
+assert chosen ∈ options
+x = choose(&x1xZ;, p)
+e = &gsupx; mod p
+&CBeCAx2n1; 
+assert 1 < d < p-1
+K = HASH(&dsupx; mod p)
+&KCsubA; = HASH(0, K)
+&KCsubB; = HASH(1, K)
+&KMsubA; = HASH(2, K)
+&KMsubB; = HASH(3, K)
+&KSsubA; = HASH(4, K)
+&KSsubB; = HASH(5, K)
+&macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &formA;})
+&signA; = SIGN(&signKeyA;, &macA;)
+&IDA; = CIPHER(&KCsubA;, &CsubA;, {&pubKeyA;, &signA;})
+&MsubA; = HMAC(HASH, &KMsubA;, &CsubA;, &IDA;)
+                                 &IDA;
+                             --------->
+                               &NsubB;, &MsubA; 
+                                        assert &MsubA; = HMAC(HASH, &KMsubA;, &CsubA;, &IDA;)
+                                        {&pubKeyA;, &signA;} = DECIPHER(&KCsubA;, &CsubA;, &IDA;)
+                                        &macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &formA;})
+                                        VERIFY(&signA;, &pubKeyA;, &macA;)
+                                 &IDB;
+                             <---------
+                               &NsubA;, &MsubB; 
+
+assert &MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)
+{&pubKeyB;, &signB;} = DECIPHER(&KCsubB;, &CsubB;, &IDB;)
+&macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;})
+VERIFY(&signB;, &pubKeyB;, &macB;)
+
+ + + +

Bob uses this protocol to send stanzas to Alice when she is Offline. Note: Since the full SIGMA protocol cannot be used if Alice is offline, her identity is not protected.

+

The diagram is split into three phases. First Alice publishes her ESession options before going offline. Later Bob completes the key exchange (and sends her encrypted stanzas that are not shown below) these are all stored by Alice's server. Finally when Alice comes online again she verifies and calculates the decryption key.

+

The differences between this offline protocol and the Online ESession-I Negotiation protocol above are highlighted in the diagram below.

+ 
+ALICE                    ALICE'S SERVER              BOB 
+
+for g,p ∈ options
+    x = random()
+    e = &gsupx; mod p
+&NsubA; = random()
+&formA; = {&e1eZ;, options, &NsubA;}
+&signsA; = multi_sign(&signKeysA;, &formA;)
+store(&NsubA;, &x1xZ;, expireTime)
+                   &formA;
+                 -------->
+                   &signsA; 
+
+                         store(&formA;, &signsA;)
+---------------------------------------------------------------------------------------------------------
+                         retrieve(&formA;, &signsA;)
+
+                                             &formA;
+                                           -------->
+                                             &signsA; 
+
+                                                     verify_one(&signsA;, &pubKeysA;, &formA;)
+                                                     chosen = {p,g,HASH,CIPHER,SIGN...} = choose(options)
+                                                     e = choose(&e1eZ;, p)
+                                                     &CsubA; = random()
+                                                     y = random()
+                                                     d = &gsupy; mod p
+                                                     &CBeCAx2n1; 
+                                                     assert 1 < e < p-1
+                                                     K = HASH(&esupy; mod p)
+                                                     &KCsubA; = HASH(0, K)
+                                                     &KCsubB; = HASH(1, K)
+                                                     &KMsubA; = HASH(2, K)
+                                                     &KMsubB; = HASH(3, K)
+                                                     &KSsubA; = HASH(4, K)
+                                                     &KSsubB; = HASH(5, K)
+                                                     &NsubB; = random()
+                                                     &formB; = {&CsubA;, chosen, d, &NsubA;, &NsubB;}
+                                                     &macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;})
+                                                     &signB; = SIGN(&signKeyB;, &macB;)
+                                                     &IDB; = CIPHER(&KCsubB;, &CsubB;, {&pubKeyB;, &signB;})
+                                                     &MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)
+
+                                             &formB;
+                                           <--------
+                                            &IDB;, &MsubB; 
+
+                         store(&formB;,&IDB;,&MsubB;)
+---------------------------------------------------------------------------------------------------------
+                         retrieve(&formB;,&IDB;,&MsubB;) 
+                   &formB;
+                 <--------
+                  &IDB;, &MsubB; 
+
+retrieve(&NsubA;, &x1xZ;, expireTime) 
+assert now < expireTime
+assert chosen ∈ options
+x = choose(&x1xZ;, p)
+e = &gsupx; mod p
+&CBeCAx2n1; 
+assert 1 < d < p-1
+K = HASH(&dsupx; mod p)
+&KCsubA; = HASH(0, K)
+&KCsubB; = HASH(1, K)
+&KMsubA; = HASH(2, K)
+&KMsubB; = HASH(3, K)
+&KSsubA; = HASH(4, K)
+&KSsubB; = HASH(5, K)
+assert &MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)
+{&pubKeyB;, &signB;} = DECIPHER(&KCsubB;, &CsubB;, &IDB;)
+&macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;})
+VERIFY(&signB;, &pubKeyB;, &macB;)
+
+

Note: &KMsubB; is necessary only to allow Bob to terminate the ESession if he comes online before Alice terminates it. The calculation of &KCsubB; and &KSsubB; is not strictly necessary.

+ + + + +

The security considerations are described in Encrypted Sessions and Offline Encrypted Sessions.

+ + + +

This JEP requires no interaction with &IANA;.

+ + + +

This JEP requires no interaction with the ®ISTRAR;.

+ + + +

The authors would like to thank Ian Goldberg for the time he spent reviewing this protocol and for his invaluable suggestions and comments.

+ + + diff --git a/xep-0189.xml b/xep-0189.xml new file mode 100644 index 00000000..a7ac7b56 --- /dev/null +++ b/xep-0189.xml @@ -0,0 +1,287 @@ + + +%ents; +]> + + +
+ Public Key Publishing + This document specifies how an entity may publish its public keys over XMPP. + &LEGALNOTICE; + 0189 + Experimental + Standards Track + Standards JIG + + XMPP Core + JEP-0060 + JEP-0163 + W3C XML Signature + + None + None + pubkeys + + http://jabber.org/protocol/pubkeys/pubkeys.xsd + + &ianpaterson; + + 0.2 + 2006-09-29 + ip +

Replaced pubkey and key elements with the KeyInfo element defined in W3C XML Signature

 + + + 0.1 + 2006-07-18 + ip +

Initial version.

 + +
+ +

This JEP defines different methods an entity may use for publishing its long-term public keys:

+
    +
  • Publishing public keys to a set of subscribers.
    • +
  • Querying another entity for its public keys.
    • +
+

An entity MAY have multiple public keys with different formats, signatures, algorithms, strengths and expiry dates. Each client used by a user may use different keys.

+ + + +

An entity SHOULD use &jep0163; to publish all its long-term public keys via its own server.

+

If the pubkeys PEP node does not exist already then the entity MUST create it first. In this case, the entity SHOULD specify that the keys will only be pushed to subscribers whenever new keys are published (i.e. not when subscribers become newly available or when a new subscription is created). If the user wants to control access to his/her identity (see Security Considerations) then the entity MUST also specify an appropriate access model other than "Open".

+ + + + + + + http://jabber.org/protocol/pubsub#node_config + + + + + + + + + + + + + + + ]]> +

Once the publishing node has been created, the entity can update the keys at any time. Each public key MUST be wrapped in a <KeyInfo/> element as specified in &w3xmlsig;. Each <KeyInfo/> element MUST contain a <KeyName/> element with a unique (for the user) name to allow the key to be referenced by other protocols. All the <KeyInfo/> elements MUST be wrapped in a single <pubkeys/> element.

+

Note: Any change to the list of keys requires all keys to be republished. So clients SHOULD take care to request (see third example below) and then include all keys for the JID that were published previously by other clients (unless the keys have expired). The keys are long-term so they will only be republished infrequently.

+ + + + + + + julietRSAkey1 + + + ... + AQAB + + + + + julietDSAkey1 + + +

...

......... + + + + + julietX509cert1 + + + CN=TAMURA Kent, OU=TRL, O=IBM, L=Yamato-shi, ST=Kanagawa, C=JP + 12345678 + + 31d97bd7 + Subject of Certificate B + ... + ... + ... + + + + julietPGPkey1 + + ... + ... + + + + + + + + ]]> + + + + + + + julietRSAkey1 + ... + + + julietDSAkey1 + ... + + + julietX509cert1 + ... + + + julietPGPkey1 + ... + + + + + + +
+ + + ]]> +

Note: The stanza containing the event notification (see example above) MAY also include 'replyto' data (as specified by the &jep0033; protocol) to provide an explicit association between the published data and the resource that published it.

+ + + + + + ]]> + + + + + + + julietRSAkey1 + ... + + + julietDSAkey1 + ... + + + julietX509cert1 + ... + + + julietPGPkey1 + ... + + + + + + + ]]> + + + +

If an entity wishes to request the public keys of another entity and it cannot access the keys via Personal Eventing via Pubsub, then the entity MAY send an IQ to the other entity:

+ + + + ]]> +

The other entity MUST make a careful access control decision before returning only those public keys for which it holds the corresponding private key (not necessarily the full list of keys being published via Personal Eventing via Pubsub):

+ + + + julietRSAkey1 + ... + + + julietX509cert1 + ... + + + + ]]> +

If the receiving entity decides not to return the public keys, it MUST return an IQ error, which SHOULD be &unavailable; (to avoid divulging presence to unauthorized entities), but MAY be some other appropriate error, such as &forbidden; or ¬allowed;:

+ + + + + + + ]]> + + + +

The reliable association between a user or entity and its public keys is beyond the scope of this JEP. However, it is RECOMMENDED that each client maintains its own secure library of the public keys (or the "fingerprints" of the keys) it associates with other users (not necessarily JIDs).

+

Whenever public keys are published an identity is typically associated with a JID. Although the public keys are public information, it may be critically important for the user of the JID to keep his identity secret from all but a few specified people. Implementors MUST take great care to ensure the identity of the user of a JID is never divulged to anyone except the entities who have been permitted by the user to access the public key.

+ + + +

This JEP requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; shall add 'http://jabber.org/protocol/pubkeys' to its registry of protocol namespaces.

+ + + + + + + + + + The protocol documented by this schema is defined in + JEP-0189: http://www.jabber.org/jeps/jep-0189.html + + + + + + + + + + + + + ]]> + + diff --git a/xep-0190.xml b/xep-0190.xml new file mode 100644 index 00000000..eb9d8732 --- /dev/null +++ b/xep-0190.xml @@ -0,0 +1,123 @@ + + +%ents; +]> + + +
+ Best Practice for Closing Idle Streams + This document specifies best practice for closing an idle XMPP stream. + &LEGALNOTICE; + 0190 + Experimental + Informational + Standards JIG + + XMPP Core + + + + N/A + + Carlo + von Loesch + lynX@jabber.getting.psyced.org + lynX@ve.symlynX.com + + + 0.1 + 2006-07-26 + psa +

Initial JEP version.

 + + + 0.0.2 + 2006-06-30 + cvl + Second draft. + + + 0.0.1 + 2006-05-31 + cvl + First draft. + +
+ + + &BISNOTE; +

RFC 3920 offers several ways on how to terminate an XMPP stream, but + doesn't always make a clear statement which one to take. This can lead + to faulty implementations. In particular, closing a stream that hasn't + been in use for a while is very often achieved using a connection-timeout + error, then closing the socket. This can lead to loss of data. Therefore + this document proposes a practice that will avoid such data loss.

+ + + + + + +

As shown in the basic "session" example in the + Simplified Stream Examples (4.8 of RFC 3920), + it is a valid transaction to close the outgoing stream by sending + ]]> + then wait for the other entity to close its stream, like this: + ]]> + and shut down the underlying TCP connection.

+

This will ensure that, should the other entity have transmitted + any data, it will arrive and be processed before the TCP connection + is terminated.

+

Special care MUST be taken that under no circumstance further + packets may be written to the socket after the stream was closed, + until the other side shuts down the socket.

+

On the outgoing TCP connection you MAY do a read-only shutdown + of the socket, as long as the other side will safely be able to + send its stream termination token.

+ + +

In case the other entity fails to close the stream within a + reasonable time frame, the entity that started the handshake is + entitled to terminate the TCP connection. Since the stream has + already been closed, it is correct not to produce an error condition.

+ + + + +

Please update your implementations to use the 'Handshake Stream Shutdown' + strategy when shutting down streams you no longer need.

+

Even not to shut down idle streams at all is a better strategy than to + shut them down by creating an error condition, so if your application + has no necessity for shutting down idle connections, just don't do it.

+ + + +

This proposal introduces no new security aspects.

+ + +

This proposal requires no interaction with &IANA;.

+ + +

This proposal requires no interaction with the ®ISTRAR;.

+ + + diff --git a/xep-0191.xml b/xep-0191.xml new file mode 100644 index 00000000..06753265 --- /dev/null +++ b/xep-0191.xml @@ -0,0 +1,262 @@ + + +%ents; +]> + + +
+ Simple Communications Blocking + This document specifies an XMPP protocol extension for simple communications blocking. + &LEGALNOTICE; + 0191 + Experimental + Standards Track + Standards JIG + + XMPP Core + XMPP IM + JEP-0030 + + None + None + blocking + &stpeter; + + 0.2 + 2006-08-30 + psa +

Added implementation notes regarding polite blocking and filtering of search results; recommended retrieval of block list after authentication; defined protocol flow for unblocking all contacts.

 + + + 0.1 + 2006-08-16 + psa +

Initial JEP version.

 + + + 0.0.2 + 2006-08-10 + psa +

Added block list retrieval use case; modified block and unblock syntax to use item child element.

 + + + 0.0.1 + 2006-08-09 + psa +

First draft.

 + +
+ +

&rfc3921; includes an XMPP protocol extension for communications blocking. Unfortunately, because that extension (privacy lists) is quite complex, it has not been widely implemented in servers and has been implemented virtually not at all in clients. This is problematic, since the ability to block communications from selected users is an important feature for an instant messaging system (and is required by &rfc2779;). However, the full power of privacy lists is not needed in order to block communications, so this document proposes a much simpler blocking protocol that meets the requirement specified in RFC 2779 and can be implemented much more easily in Jabber/XMPP clients and servers.

+ + +

The requirements for simple communications blocking are straightforward:

+
    +
  1. A user must be able to block communications from a specific contact.
    2. +
  2. A user should be able to determine which contacts are blocked.
    3. +
  3. A user should be able to unblock communications from a specific contact.
    4. +
+ + + +

In order for a client to discover whether its server supports the protocol defined herein, it MUST send a &jep0030; information request to the server:

+ + + + ]]> +

If the server supports the protocol defined herein, it MUST return a feature of "http://jabber.org/protocol/blocking":

+ + + ... + + ... + + + ]]> + + +

In order for a user to block communications from a contact, the user's client shall send an IQ-set with no 'to' address (thus handled by the user's server) containing a <block/> element qualified by the 'http://jabber.org/protocol/blocking' namespace, where the JID to be blocked is encapsulated as the 'jid' attribute of the <item/> child element:

+ + + + + + ]]> +

If the server can successfully process the block command, it MUST return an IQ-result:

+ + ]]> +

(Standard XMPP stanza errors apply; see &xmppcore; and &jep0086;.)

+

Note: The <block/> element MAY contain more than one <item/> child.

+

Once the user has blocked communications from the contact, the user's server MUST NOT deliver any XML stanzas from the contact to the user.

+

If the contact attempts to send a stanza to the user (i.e., an inbound stanza from the user's perspective), the user's server shall return an error according to the following rules:

+
    +
  • For presence stanzas, it is NOT RECOMMENDED to return an error.
    • +
  • For message stanzas, the server MAY return an error, which SHOULD be &unavailable;.
    • +
  • For IQ stanzas, the server MUST return an error, which SHOULD be &unavailable;.
    • +
+

If the user attempts to send an outbound stanza to the contact, the user's server MUST NOT route the stanza to the contact but instead MUST return a ¬acceptable; error containing an application-specific error condition of <blocked/> qualified by the 'http://jabber.org/protocol/blocking#errors' namespace:

+ + Can you hear me now? + + + + + + ]]> + + +

In order for a client to request a user's list of blocked contacts (e.g., in order to determine whether to unblock a contact), it shall send an IQ-get with no 'to' address (thus handled by the user's server) containing a <blocklist/> element qualified by the 'http://jabber.org/protocol/blocking' namespace:

+ + + + ]]> +

If the user has any contacts in its blocklist, the server MUST return an IQ-result containing a <blocklist/> element that in turn contains one child <item/> element for each blocked contact:

+ + + + + + + ]]> +

If the user has no contacts in its blocklist, the server MUST return an IQ-result containing an empty <blocklist/> element:

+ + + + ]]> +

A client SHOULD retrieve the block list after authenticating with its server.

+ + +

In order for a user to unblock communications from a contact, the user's client shall send an IQ-set with no 'to' address (thus handled by the user's server) containing an <unblock/> element qualified by the 'http://jabber.org/protocol/blocking' namespace, where the JID to be unblocked is encapsulated as the 'jid' attribute of the <item/> child element:

+ + + + + + ]]> +

If the server can successfully process the unblock command, it MUST return an IQ-result:

+ + ]]> +

Once the user has unblocked communications from the contact, the user's server MUST deliver any XML stanzas from the contact to the user.

+ + +

In order for a user to unblock communications from all contacts, the user's client shall send an IQ-set with no 'to' address (thus handled by the user's server) containing an empty <unblock/> element qualified by the 'http://jabber.org/protocol/blocking' namespace:

+ + + + ]]> +

If the server can successfully process the unblock command, it MUST return an IQ-result:

+ + ]]> +

Once the user has unblocked communications from all contacts, the user's server MUST deliver any XML stanzas from those contacts to the user.

+ + + +

When a server receives a block command from a user, it MAY cancel any existing presence subscriptions between the user and the blocked user and MAY send a message to the blocked user; however, it is RECOMMENDED to deploy so-called "polite blocking" instead (i.e., to not cancel the presence subscriptions or send a notification). Which approach to follow is a matter of local service policy.

+

A service MAY also filter blocking users out of searches performed on user directories (see, for example, &jep0055;); however, that functionality is out of scope for this specification.

+ + +

If properly implemented, this protocol extension does not introduce any new security concerns above and beyond those defined in RFC 3920 and RFC 3921.

+ + +

No interaction with &IANA; is required as a result of this specification.

+ + + +

The ®ISTRAR; shall include 'http://jabber.org/protocol/blocking' and 'http://jabber.org/protocol/blocking#errors' in its registry of protocol namespaces (see &NAMESPACES;).

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + + + + + + + + + + + + + + + ]]> + + + +

Thanks to Valerie Mercier, Maciek Niedzielski, and Remko Tronçon for their feedback.

+ + diff --git a/xep-0192.xml b/xep-0192.xml new file mode 100644 index 00000000..e00ffa43 --- /dev/null +++ b/xep-0192.xml @@ -0,0 +1,451 @@ + + +%ents; +]> + + +
+ Proposed Stream Feature Improvements + This document proposes improvements to the XML stream features definition for inclusion in the specification that supersedes RFC 3920. + &LEGALNOTICE; + 0192 + Experimental + Informational + Standards JIG + + XMPP Core + + None + None + N/A + &stpeter; + + 0.1 + 2006-08-16 + psa +

Initial JEP version.

 + + + 0.0.1 + 2006-08-10 + psa +

First draft.

 + +
+ + &BISNOTE; +

RFC 3920 introduced the concept of stream features. Implementation experience has revealed several shortcomings in the current definition and usage of stream features:

+
    +
  • Because not all stream features include a mechanism for specifying that negotiation of the feature is required, servers and clients cannot know with certainty when the stream negotiation has been completed and therefore when it is acceptable to begin sending XML stanzas over the stream.
    • +
  • The server dialback protocol does not have a stream feature associated with it.
    • + +
+

Those shortcomings are addressed in this document.

+ + +

The XMPP stream feature for Transport Layer Security (TLS) includes a <required/> child element that can be used to indicate that negotiation of TLS must be completed before proceeding with the rest of the stream negotiation. However, as defined in RFC 3920 the remaining stream features do not include the ability to flag that negotiation of the feature is required in order either to proceed with the negotiation or to begin sending XML stanzas. Because the non-TLS features lack a required flag, it is not possible for the initiating entity to know definitively how to proceed at any given stage in the stream negotiation, and the only way for the initiating entity to know whether it may begin sending XML stanzas is to attempt to send them (the receiving entity will return a ¬authorized; stream error if not all required features have been negotiated). This state of affairs is suboptimal. Therefore, we recommend that every stream feature must include the ability to flag the feature as required or not required.

+

The following examples show a possible flow of stream negotiation between a client and a server, using the required flag for all but one of the features. (This example is more verbose than a typical stream negotiation flow, but is provided here for the sake of completeness.)

+ + +S: + +S: + + + + + +C: + +S: + +[TLS negotiation] + +C: + +S: + +S: + + EXTERNAL + DIGEST-MD5 + PLAIN + + + + +C: + +S: + cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi + LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== + + +C: + dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i + T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw + MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i + LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo + YXJzZXQ9dXRmLTgK + + +S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= + + +C: + +S: + +C: + +S: + +S: + + zlib + + + + +C: + zlib + + +S: + +C: + +S: + +S: + + + + + + + + + +C: + + someresource + + + +S: + + somenode@example.com/someresource + + + +C: + + + +S: + + ]]> + + +

As specified in RFC 3920, suupport for the server dialback protocol is currently adverised through inclusion of a dialback namespace prefix in the stream header:

+ + + ]]> +

However, it is not clear if inclusion of the dialback namespace indicates that a server supports the server dialback protocol or it if requires negotiation of server dialback. To make this clear, we define a stream feature for server dialback.

+

Consider the following scenario, in which Server1 provides a self-signed certificate. According to Server2's local service policy, it does not consider self-signed certificates to be trustworthy and therefore requires negotiation of server dialback in this case.

+ + +S2: + +S2: + + + + + +S2: + +[TLS negotiation with self-signed certificate] + +S1: + +S2: + +S2: + + + + + +[Dialback negotiation] + + ]]> + + +

The improvements described herein do not introduce any new security concerns above and beyond those defined in RFC 3920.

+ + +

No interaction with &IANA; is required as a result of this JEP.

+ + + +

The ®ISTRAR; shall include 'http://jabber.org/features/dialback' in its registry of stream features.

+

The submission is as follows:

+ + http://jabber.org/features/dialback + dialback + dialback + Support for Server Dialback + rfc3920bis + + ]]> + + + + +

Note: The following provisional schema is intended to replace the existing schema for the SASL stream feature.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + +

Note: The following provisional schema is intended to replace the existing schema for the Resource Binding stream feature.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + +

Note: The following provisional schema is intended to replace the existing schema for the Session Establishment stream feature.

+ + + + + + + + + + + + + + + + + + + ]]> + + +

Note: The following defines a schema for the proposed Server Dialback stream feature.

+ + + + + + + + + + + + + + + + + + + ]]> + + + +

Thanks to Ralph Meijer and Joe Hildebrand for their comments.

+ + diff --git a/xep-0193.xml b/xep-0193.xml new file mode 100644 index 00000000..00304d8f --- /dev/null +++ b/xep-0193.xml @@ -0,0 +1,260 @@ + + +%ents; +]> + + +
+ Proposed Resource Binding Improvements + This document proposes improvements to the definition of resource binding for inclusion in the specification that supersedes RFC 3920. + &LEGALNOTICE; + 0193 + Experimental + Informational + Standards JIG + + XMPP Core + + None + None + N/A + &stpeter; + + 0.1 + 2006-08-16 + psa +

Initial JEP version.

 + + + 0.0.2 + 2006-08-15 + psa +

Added stream feature for unbind.

 + + + 0.0.1 + 2006-08-15 + psa +

First draft.

 + +
+ + &BISNOTE; +

RFC 3920 introduced the concept of binding a resource to an XML stream (this concept superseded part of the older jabber:iq:auth protocol described in &jep0078;). As defined in RFC 3920, resource binding enables a client to bind one resource to a stream but does not enable a client to unbind a resource and leaves underspecified what a server and client should do if a client binds more than one resource to a stream. Because the ability to bind multiple resources to a stream is desirable in certain environments (e.g., for devices that are unable to open more than one TCP connection or when a machine runs a client daemon that is used by multiple applications), this document proposes improvements to resource binding in order to address these shortcomings.

+ + +

In order to properly manage the resources associated with an XML stream, a client must be able to unbind resources. This shall be completed by sending an IQ-set with a child element of <unbind/> qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace, which in turn has a child element of <resource/> whose XML character data specifies the resource to be unbound:

+ + + someresource + + + ]]> +

If the server does not understand the <unbind/> element, it MUST return an error of &badrequest;. Otherwise, if there is no such resource, the server MUST return an error of ¬found;. When the client unbinds the only resource associated with the stream, the server SHOULD close the stream and terminate the TCP connection.

+

A server SHOULD advertise its support for the 'urn:ietf:params:xml:ns:xmpp-bind' namespace by returning an appropriate stream feature as shown below:

+ + + + + + + ]]> + + +

When a client binds multiple resources to a stream, proper management of 'from' addresses is imperative. The following rules apply:

+
    +
  1. A client SHOULD specify a 'from' address on every stanza.
    2. +
  2. If a client does not specify a 'from' address, the server MUST stamp a 'from' address, which SHOULD be the "default" resource as specified below.
    3. +
+

The "default" resource SHOULD be the oldest resource bound to the stream; normally that will be the initial resource, but it may be a resource bound later (i.e., if subsequently the initial resource has been unbound).

+

Naturally, the existing rules from RFC 3920 regarding validation of asserted 'from' addresses still apply.

+ + +

The following examples show a possible flow of resource binding and unbinding.

+

First, the client binds an initial resource to the stream.

+ + + core + + + + + + juliet@capulet.com/core + + + ]]> +

Now the client sends some stanzas, making sure to set its 'from' address:

+ + + + + + + + + + + + ]]> +

Now the client binds a second resource to the stream.

+ + + balcony + + + + + + juliet@capulet.com/balcony + + + ]]> +

If the server does not allow entities to bind multiple resources to the stream, it MUST return a ¬allowed; error as described in RFC 3920.

+

Now the client sends more stanzas.

+ + + + + + + + + + + + + + Wherefore art thou? + + ]]> +

Note that the last stanza sent will be stamped by the server as from <juliet@capulet.com/core>, not as from <juliet@capulet.com/balcony>.

+

Now the client binds a third resource to the stream.

+ + + softphone + + + + + + juliet@capulet.com/softphone + + + ]]> +

Now the client unbinds its initial resource.

+ + + core + + + + + ]]> +

Now the client sends another stanza without a 'from' address, which the server stamps as from the new default resource (i.e., no longer the initial resource):

+ + Art thou not Romeo, and a Montague? + + ]]> + + Art thou not Romeo, and a Montague? + + ]]> +

Now the client unbinds another resource.

+ + + softphone + + + + + ]]> +

Now the client unbinds its last remaining resource.

+ + + balcony + + + + + ]]> +

The server now SHOULD close the stream and terminate the underlying TCP connection.

+ + ]]> + + +

If properly implemented, the modifications described herein do not introduce any new security concerns above and beyond those defined in RFC 3920. However, care must be taken to properly manage 'from' addresses in order to avoid the delivery of stanzas from an unintended resource (which may, for example, leak presence information).

+ + +

No interaction with &IANA; is required as a result of this document.

+ + +

No interaction with the ®ISTRAR; is required as a result of this document.

+ + +

Note: The following provisional schema is intended to replace the existing schema for the Resource Binding stream feature.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + diff --git a/xep-0194.xml b/xep-0194.xml new file mode 100644 index 00000000..261aa09c --- /dev/null +++ b/xep-0194.xml @@ -0,0 +1,173 @@ + + +%ents; +]> + + +
+ User Chatting + This document defines an XMPP protocol extension for communicating information about the chatrooms a user visits. + &LEGALNOTICE; + 0194 + Experimental + Standards Track + Standards JIG + + XMPP Core + XMPP IM + JEP-0060 + JEP-0163 + + + + chatting + &stpeter; + + 0.1 + 2006-08-30 + psa +

Initial JEP version.

 + + + 0.0.1 + 2006-08-28 + psa +

First draft.

 + +
+ +

&jep0060; and &jep0163; can be used to publish a wide variety of "extended presence" information about users. This document specifies an extended presence payload format that communicates information about the chatrooms a user visits. This information may be of interest to a user's contacts and can also be used in social networking applications.

+ + + +

Information about chatrooms is provided by the user (or automated integration with Jabber, IRC, or other systems) and is propagated on the network by the user's client. The information container for chatting data is a <room/> element that is qualified by the 'http://jabber.org/protocol/chatting' namespace. The chatting information itself is provided as the XML character data of the following children of the <room/> element:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ElementDescriptionExampleDatatypeInclusion
nameThe name of the chatroomjdevxs:stringOPTIONAL
topicThe current topic of discussion in the roomWhiteboard protocol meetingxs:stringOPTIONAL
uriA URI for the room (this SHOULD be an XMPP URI in accordance with &rfc4622; but MAY use some other URI scheme, such as the irc: scheme)xmpp:jdev@conference.jabber.orgxs:anyURIREQUIRED
+

NOTE: The datatypes specified above are defined in &w3xmlschema2;.

+ + +

When a user joins a room, its client may publish that fact to a special pubsub or PEP node (if a PEP node, the NodeID is "http://jabber.org/protocol/chatting"). The chatting information SHOULD be communicated and transported by means of the JEP-0060 protocol, especially the subset specified in JEP-0163 (as shown in the following examples). Because chatroom information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to the &PRESENCE; stanza type.

+ + + + + + jdev + xmpp:jdev@conference.jabber.org + + + + + + ]]> +

The chatting information is then delivered to all subscribers:

+ + + + + + jdev + xmpp:jdev@conference.jabber.org + + + + + +. +. +. + ]]> +

When the user exits the room, the user's client SHOULD send an empty <room/> element to the node with the same ItemID:

+ + + + + + + + + + ]]> + + + + + + + + + +. +. +. + ]]> + + + +

The chat rooms that a user visits may be sensitive. A client must provide a way for a user to configure which rooms or types of rooms will not be published (e.g., via user preferences).

+ + +

This document requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; shall include 'http://jabber.org/protocol/chatting' in its registry of protocol namespaces.

+ + + + + + + + + + + + + + + + + + + ]]> + + diff --git a/xep-0195.xml b/xep-0195.xml new file mode 100644 index 00000000..a6e96ceb --- /dev/null +++ b/xep-0195.xml @@ -0,0 +1,179 @@ + + +%ents; +]> + + +
+ User Browsing + This document defines an XMPP protocol extension for communicating information about the web pages a user visits. + &LEGALNOTICE; + 0195 + Experimental + Standards Track + Standards JIG + + XMPP Core + XMPP IM + JEP-0060 + JEP-0163 + + + + browsing + &stpeter; + + 0.1 + 2006-08-30 + psa +

Initial JEP version.

 + + + 0.0.1 + 2006-08-28 + psa +

First draft.

 + +
+ +

&jep0060; and &jep0163; can be used to publish a wide variety of "extended presence" information about users. This document specifies an extended presence payload format that communicates information about the web pages a user visits. This information may be of interest to a user's contacts and can also be used in social networking applications (e.g., co-browsing and web swarms).

+ + + +

Information about web pages is provided by the user (or automated integration with browsers or other systems) and is propagated on the network by the user's client. The information container for web page data is a <page/> element that is qualified by the 'http://jabber.org/protocol/browsing' namespace. The web page information itself is provided as the XML character data of the following children of the <page/> element:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ElementDescriptionExampleDatatypeInclusion
descriptionThe value of the "description" META tagThe weblog of Peter Saint-Andrexs:stringOPTIONAL
keywordsThe value of the "keywords" META tagstpeter, Peter Saint-Andre, weblog, jabber, xmppxs:stringOPTIONAL
titleThe title of the web page (i.e., value of the <title/> element)one small voicexs:stringOPTIONAL
uriThe URI of the page (usually but not necessarily an HTTP URL)http://www.saint-andre.com/blog/xs:anyURIREQUIRED
+

NOTE: The datatypes specified above are defined in &w3xmlschema2;.

+ + +

When a user visits a web page, its client may publish that fact to a special pubsub or PEP node (if a PEP node, the NodeID is "http://jabber.org/protocol/browsing"). The web page information SHOULD be communicated and transported by means of the JEP-0060 protocol, especially the subset specified in JEP-0163 (as shown in the following examples). Because browsing information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to the &PRESENCE; stanza type.

+ + + + + + http://www.saint-andre.com/blog/ + + + + + + ]]> +

The browsing information is then delivered to all subscribers:

+ + + + + + http://www.saint-andre.com/blog/ + + + + + +. +. +. + ]]> +

When the user stops browsing the page (e.g., by closing the browser window or tab), the user's client SHOULD send an empty <page/> element to the node with the same ItemID:

+ + + + + + + + + + ]]> + + + + + + + + + +. +. +. + ]]> + + + +

The web pages that a user visits may be sensitive. A client must provide a way for a user to configure which pages or types of pages will not be published (e.g., via user preferences).

+ + +

This document requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; shall include 'http://jabber.org/protocol/browsing' in its registry of protocol namespaces.

+ + + + + + + + + + + + + + + + + + + + ]]> + + diff --git a/xep-0196.xml b/xep-0196.xml new file mode 100644 index 00000000..d915d5b2 --- /dev/null +++ b/xep-0196.xml @@ -0,0 +1,205 @@ + + +%ents; +]> + + +
+ User Gaming + This document defines an XMPP protocol extension for communicating information about the games a user plays. + &LEGALNOTICE; + 0196 + Experimental + Standards Track + Standards JIG + + XMPP Core + XMPP IM + JEP-0060 + JEP-0163 + + + + gaming + &stpeter; + + 0.1 + 2006-08-30 + psa +

Initial JEP version; added several more fields.

 + + + 0.0.1 + 2006-08-28 + psa +

First draft.

 + +
+ +

&jep0060; and &jep0163; can be used to publish a wide variety of "extended presence" information about users. This document specifies an extended presence payload format that communicates information about the games a user plays. This information may be of interest to a user's contacts and can also be used in social networking applications.

+ + + +

Information about games is provided by the user (or automated integration with gaming systems) and is propagated on the network by the user's client. The information container for gaming data is a <game/> element that is qualified by the 'http://jabber.org/protocol/gaming' namespace. The game information itself is provided as the XML character data of the following children of the <game/> element:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ElementDescriptionExampleDatatypeInclusion
character_nameThe name of the user's character in the gameStentorxs:stringOPTIONAL
character_profileA URI for a profile of the user's characterhttp://wow.example.com/profile.html?12345xs:anyURIOPTIONAL
nameThe name of the gameWorlds of Warfarexs:stringREQUIRED
levelThe user's level in the game66xs:stringOPTIONAL
server_addressThe hostname or IP address of the server where the user is playingwow6.example.comxs:stringOPTIONAL
server_nameThe name of the server where the user is playingWOW Examplexs:stringOPTIONAL
uriA URI for the game or relevant gaming servicehttp://wow.example.com/xs:anyURIOPTIONAL
+

NOTE: The datatypes specified above are defined in &w3xmlschema2;.

+ + +

When a user starts playing a game, its client may publish that fact to a special pubsub or PEP node (if a PEP node, the NodeID is "http://jabber.org/protocol/gaming"). The gaming information SHOULD be communicated and transported by means of the JEP-0060 protocol, especially the subset specified in JEP-0163 (as shown in the following examples). Because gaming information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to the &PRESENCE; stanza type.

+ + + + + + chess + http://www.chesspark.com/ + + + + + + ]]> +

The gaming information is then delivered to all subscribers:

+ + + + + + chess + http://www.chesspark.com/ + + + + + +. +. +. + ]]> +

When the user stops playing the game, the user's client SHOULD send an empty <game/> element to the node with the same ItemID:

+ + + + + + + + + + ]]> + + + + + + + + + +. +. +. + ]]> + + + +

The games that a user plays may be sensitive. A client must provide a way for a user to configure which games or types of games will not be published (e.g., via user preferences).

+ + +

This document requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; shall include 'http://jabber.org/protocol/gaming' in its registry of protocol namespaces.

+ + + + + + + + + + + + + + + + + + + + + + + ]]> + + diff --git a/xep-0197.xml b/xep-0197.xml new file mode 100644 index 00000000..ea98f0d2 --- /dev/null +++ b/xep-0197.xml @@ -0,0 +1,257 @@ + + +%ents; +]> + + +
+ User Viewing + This document defines an XMPP protocol extension for communicating information about the television shows, movies, or other videos that a user watches. + &LEGALNOTICE; + 0197 + Experimental + Standards Track + Standards JIG + + XMPP Core + XMPP IM + JEP-0060 + JEP-0163 + + + + viewing + &stpeter; + + Kevin + Hoekman + kevin.hoekman@pandora.be + kevinh@jabber.org + + + 0.1 + 2006-08-30 + psa +

Initial JEP version.

 + + + 0.0.1 + 2006-08-28 + psa +

First draft.

 + +
+ +

&jep0060; and &jep0163; can be used to publish a wide variety of "extended presence" information about users. This document specifies an extended presence payload format that communicates information about the television shows, movies, or other videos that a user watches. This information may be of interest to a user's contacts and can also be used in social networking applications (e.g., IPTV systems).

+ + + +

Information about video viewing is provided by the user (or automated integration with video systems) and is propagated on the network by the user's client. The information container for video viewing data is a <video/> element that is qualified by the 'http://jabber.org/protocol/viewing' namespace. The video information itself is provided as the XML character data of the following children of the <video/> element:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ElementDescriptionExampleDatatype
authorThe author of the programRobert Duncanxs:string
castThe cast members of the programTrace Beaulieu, Frank Conniff, Joel Hodgson, Jim Mallon, Kevin Murphy, Michael J. Nelson, Mary Jo Pehlxs:string
channel_nameThe name of the channel showing the programSci-Fi Channelxs:string
descriptionA description of the programTerror From The Year 5000xs:string
durationThe duration of the program (in seconds)1800xs:positiveInteger
end_timeThe end time of the program2006-08-29T03:30Zxs:dateTime
episodeThe episode number of the program807xs:string
program_nameThe name of the programMystery Science Theater 3000xs:string
program_typeThe type of the programComedyxs:string
start_timeThe start time of the program2006-08-29T03:00Zxs:dateTime
subprogram_typeThe type of the sub-program (e.g., outtakes on an extended DVD)Cast interviewxs:string
uriA URI for the video or relevant servicehttp://www.mst3kinfo.com/xs:anyURI
user_commentA user's free-form comments about the programThis is one of my favorite episodes! MST3K forever!xs:string
user_ratingThe user's personal rating of the program (on a scale of 1 to 10, with 10 being highest)9xs:string
+

All elements are OPTIONAL.

+

NOTE: The datatypes specified above are defined in &w3xmlschema2;.

+ + +

When a user starts watching a video, its client may publish that fact to a special pubsub or PEP node (if a PEP node, the NodeID is "http://jabber.org/protocol/viewing"). The viewing information SHOULD be communicated and transported by means of the JEP-0060 protocol, especially the subset specified in JEP-0163 (as shown in the following examples). Because viewing information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to the &PRESENCE; stanza type.

+ + + + + + + + + + ]]> +

The viewing information is then delivered to all subscribers:

+ + + + + + + + + +. +. +. + ]]> +

When the user stops watching the video, the user's client SHOULD send an empty <video/> element to the node with the same ItemID:

+ + + + + + + + + ]]> + + + + + + + + +. +. +. + ]]> + + + +

The videos that a user watches may be sensitive. A client must provide a way for a user to configure which videos or types of videos will not be published (e.g., via user preferences).

+ + +

This document requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; shall include 'http://jabber.org/protocol/viewing' in its registry of protocol namespaces.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + diff --git a/xep-README.xml b/xep-README.xml new file mode 100644 index 00000000..03a0d209 --- /dev/null +++ b/xep-README.xml @@ -0,0 +1,274 @@ + + +%ents; +]> + + +
+ JEP Editor README + This document describes work processes followed by the JEP Editor. + &LEGALNOTICE; + README + Experimental + Procedural + N/A + N/A + + JEP-0001 + JEP-0053 + + + + N/A + + Peter + Saint-Andre + stpeter@jabber.org + stpeter@jabber.org + + + 0.5 + 2005-05-26 + psa + Adjusted to reflect ProtoJEP status. + + + 0.4 + 2005-03-16 + psa + Converted to JEP format; adjusted to reflect server move. + + + 0.3 + 2004-10-22 + psa + Clarified schema handling. + + + 0.2 + 2004-10-11 + psa + Defined Jabber Registrar processes. + + + 0.1 + 2004-10-01 + psa + Initial version. + +
+ + + +

Since the inception of the &JSF;, the &EDITOR; has been Peter Saint-Andre. However, if he gets hit by a bus or is replaced by someone else, this document may prove useful.

+

The JEP Editor manages the JEP process as defined in &jep0001;. In addition, the JEP Editor functions as the Jabber Registrar as defined in &jep0053;. Read those documents first, since this README focuses on mechanics rather than philosophy.

+ + + + +

There are several JEP-related functions performed by the JEP Editor:

+
    +
  1. Accepting a JEP
    2. +
  2. Updating a JEP
    3. +
  3. Deferring a JEP
    4. +
  4. Retracting a JEP
    5. +
  5. Issuing a Last Call
    6. +
  6. Counting Council Votes
    7. +
  7. Advancing a JEP
    8. +
+

These functions are specified below.

+ + +

Periodically, people send mail to editor@jabber.org with new proposals. Here is how to process such submissions.

+
    +
  1. Receive proposal from author.
    2. +
  2. Give it a descriptive filename that does not include the string 'jep' or a JEP number.
    3. +
  3. Set the version to 0.0.1 if no version found.
    4. +
  4. Set the status to ProtoJEP.
    5. +
  5. Convert XML to HTML and check the results for accuracy.
    6. +
  6. Place HTML at http://www.jabber.org/jeps/inbox/ (/var/www/jabber.org/jeps/inbox/)
    7. +
  7. Place XML in the editor's working CVS directory on webserver (e.g., ~/cvs/jeps/inbox/docname.xml)
    8. +
  8. Send a note to the Standards-JIG list by running the "protojep.py" script.
    9. +
  9. Wait until the Council decides whether to accept the proposal as a JEP (this may involve poking the Council Chair).
    10. +
  10. If rejected, retain in the "inbox".
    11. +
  11. +

    If accepted, do the following:

    +
      +
    1. Assign the JEP the next available number in the JEP series.
      2. +
    2. Modify the <number/> element in the XML file.
      3. +
    3. Set the version to 0.1.
      4. +
    4. Set the status to Experimental.
      5. +
    5. Check the file for egregious errors.
      6. +
    6. Add the directory and XML file to the "jeps" CVS module.
      7. +
    7. Add a reference for the new JEP in the jep.ent file.
      8. +
    8. Update CVS on the server.
      9. +
    9. Run the "gen.sh" script.
      10. +
    10. Run the "announce.py" script (see below), which updates the database and sends a message to the Standards-JIG list.
      11. +
    11. Redirect the "inbox" file to the new JEP URL.
      12. +
    +
    12. +
+ + + +

Once a JEP has been published, it will be periodically updated in CVS, and sometimes those changes are significant enough to warrant a new version (e.g., version 0.2 after 0.1). Often a request to release a new version will come from the JEP author, sometimes from the Council (e.g., after the JEP has reached version 1.0 or version 2.0). Here is how to update JEPs.

+
    +
  1. Compile the file locally and check the content for accuracy (including the correct date and version number).
    2. +
  2. Check your changes into CVS.
    3. +
  3. Update CVS on the server.
    4. +
  4. Run the "archive.sh" script to put the previous JEP version in the "attic".
    5. +
  5. Run the "gen.sh" script.
    6. +
  6. Run the "announce.py" script.
    7. +
+ + + +

The status of a JEP shall be automatically changed to Deferred if a new version has not been released in 6 months, except if the JEP is actively in the Council queue for consideration of issuance of a Last Call. Here is the process.

+
    +
  1. Change the <status/> element to "Deferred" in the XML file.
    2. +
  2. Check your changes into CVS (note: do not modify the version number!).
    3. +
  3. Update CVS on the server.
    4. +
  4. Run the "gen.sh" script.
    5. +
  5. Run the "deferred.py" script.
    6. +
+ + + +

Sometimes an author retracts a JEP because it is no longer worthy of consideration. Here is the process.

+
    +
  1. Change the <status/> element to "Retracted" in the XML file.
    2. +
  2. Modify the <abstract/> element with appropriate content (see existing Retracted JEPs).
    3. +
  3. Add a new revision block with an incremented version number, explaining that the JEP has been Retracted and why (see existing Retracted JEPs).
    4. +
  4. Check your changes into CVS.
    5. +
  5. Update CVS on the server.
    6. +
  6. Run the "gen.sh" script.
    7. +
  7. Run the "announce.py" script.
    8. +
+ + + +

The Jabber Council determines whether and when to issue a Last Call on an Experimental JEP. Here is the process.

+
    +
  1. Receive notice from the Council Chair that a Last Call shall be issued.
    2. +
  2. Determine the ending date, which must be at least 10 days in the future and usually is 2 weeks (sometimes 3 weeks if much discussion is expected).
    3. +
  3. Change the <status/> element to "Proposed" in the XML file.
    4. +
  4. Check your changes into CVS.
    5. +
  5. Update CVS on the server.
    6. +
  6. Run the "lastcall.py" script, which updates the database and sends a message to the Standards-JIG list.
    7. +
  7. Review the Jabber Registrar Considerations section to ensure accuracy.
    8. +
+ + + +

The JEP Editor is responsible for counting the votes of Council members. The process is as follows.

+
    +
  1. Inform the Council of the vote (see examples in the council@jabber.org archives).
    2. +
  2. Monitor the Council list and Council meetings for votes.
    3. +
  3. Update the votes XML file contained in the "council" CVS module.
    4. +
  4. Check your changes into CVS.
    5. +
  5. Update CVS on the server.
    6. +
  6. Run the "gen.sh" script in the "council" module (don't confuse this with the JEP gen.sh script).
    7. +
  7. When all Council members have voted, update the JEP accordingly (see below on Advancing a JEP).
    8. +
+ + + +

When the Council approves a JEP, it advances to either Draft (Standards Track JEPs) or Active (other JEP types). Here is the process.

+
    +
  1. Change the <status/> element to "Active" or "Draft" as appropriate.
    2. +
  2. Add a new revision block with a version number of "1.0" (see existing JEPs for appropriate remarks).
    3. +
  3. If there are any XML schemas associated with the JEP, do the following: +
      +
    1. Add an annotation to each schema (see existing examples).
      2. +
    2. In the directory for this JEP, create one .xsd file for each schema.
      3. +
    3. For each schema, add a <schemaloc/> element to the JEP file.
      4. +
    4. Create a /var/www/jabber.org/protocol/shortname/ directory on the server (replace "shortname" with the short name of the JEP).
      5. +
    5. Update the "schemagen.sh" script.
      6. +
    +
    4. +
  4. Add the protocol namespace (if any) to the protocol namespaces registry and complete any other Jabber Registrar actions called for in the JEP (see below).
    5. +
  5. Check your changes into CVS.
    6. +
  6. Update CVS on the server.
    7. +
  7. Run the "archive.sh" script to put the previous JEP version in the "attic".
    8. +
  8. Run the "schemagen.sh" script if appropriate.
    9. +
  9. Run the "gen.sh" script.
    10. +
  10. Run the "announce.py" script.
    11. +
  11. Add a link to JEP from the appropriate section of the http://www.jabber.org/protocol/ page.
    12. +
+ + + + + + +

Registry files are contained in the "registry" CVS module. In general, there are several files that may need to be updated when a JEP advances to Active or Draft. In particular, most JEPs specify one or more protocol namespaces, which need to be added to the namespaces.xml file in the "registry" module. Refer to the list of registries at http://www.jabber.org/registrar/ in order to determine which other registries may need to be updated. The reg.ent file will probably need to be updated as well. Once the Registrar actions have been completed, update the text of the JEP's Jabber Registrar Considerations section accordingly (e.g., to change "shall include" to "includes").

+ + + +

A JEP may call for one or more new registries to be created. If so, carefully review the Jabber Registrar Considerations section of the JEP before it advances to Draft or Active in order to provide appropriate feedback to the JEP author. (Alternatively, make the changes directly in the JEP file in consultation with the author.)

+

When creating a new registry, it is best to copy the DTD, XML, and XSL files for an existing registry, then modify them in accordance with the definition of the new registry in the relevant JEP. The gen.sh script will need to be updated to reflect the existence of the new registry, as will the index file for the http://www.jabber.org/registrar/ web page.

+

Check all your changes into CVS, update your CVS directory on the web server, and run the gen.sh script to update the Jabber Registrar web pages.

+ + + + + + +

In order to convert XML files into HTML and other formats, the JEP Editor currently uses the xsltproc tool, which is part of libxml2 (created by Daniel Veillard). This tool is extremely handy and it is recommended that use of xsltproc be continued, especially since the shell scripts (described below) make calls to xsltproc.

+ + + +

Most the "magic" behind creating the HTML-formatted JEPs, as well as the IETF-style reference files, is perfomed by XSL stylesheets. The main file here is jep.xsl, although ref.xsl is used to create the reference files. A future version of this README may explain these files in more depth.

+ + + +

The jep.ent file contains handy references that can be incorporated into any JEP XML document, thus providing a centralized location for various document references. The JEP Editor must keep this file up to date (e.g., by adding all new JEPs to it), and should be the only person who makes changes to the file.

+ + + +

Several Python scripts are under source control. These are:

+
    +
  1. +

    announce.py

    +

    This script announces a new version of a JEP by updating the database and sending a message to standards-jig@jabber.org.

    +
    2. +
  2. +

    deferrred.py

    +

    This script updates the database and sends a message to standards-jig@jabber.org when the status of a JEP is changed to Deferred. Before running this script, make sure that you modify the <status/> element in the JEP itself and run the gen.sh shell script.

    +
    3. +
  3. +

    lastcall.py

    +

    This script announces a Last Call for a JEP by updating the database and sending a message to standards-jig@jabber.org.

    +
    4. +
  4. +

    protojep.py

    +

    This script announces availability of a new "proto-JEP" (i.e., a document not yet accepted as a JEP by the Jabber Council) by sending a message to standards-jig@jabber.org. Before running this script, place the new proto-JEP so that it is available at http://www.jabber.org/jeps/inbox/ (normally this is done by running 'xsltproc inbox/docname.xml > /var/www/jabber.org/jeps/inbox/docname.html' from the editor's working CVS directory on the web server).

    +
    5. +
+ + + +

Several shell scripts are under source control. These are:

+
    +
  1. +

    all.sh

    +

    This script converts all JEP XML files into HTML. Use this if the jep.xsl file changes in ways that affect all JEPs. But make sure that CVS is synced up first -- you don't want to be publishing interim versions of JEPs!

    +
    2. +
  2. +

    archive.sh

    +

    This script archives the version of a JEP currently on the website. Run this script before publishing a new version!

    +
    3. +
  3. +

    gen.sh

    +

    This script converts one JEP XML file into HTML. Run this script before announcing a new version. This script can also be used for minor edits to the current version.

    +
    4. +
  4. +

    schemagen.sh

    +

    This script updates all of the XML schemas located at http://www.jabber.org/protocol/ (more accurately, the subdirectories there). Update this file every time a protocol JEP with an associated schema advances to Active or Draft.

    +
    5. +
+ + + + diff --git a/xep-template.xml b/xep-template.xml new file mode 100644 index 00000000..f22be195 --- /dev/null +++ b/xep-template.xml @@ -0,0 +1,71 @@ + + +%ents; +]> + + +
+ JEP Template + An example of the format for Jabber Enhancement Proposals. + This Jabber Enhancement Proposal is copyright 1999 - 2005 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy (http://jabber.org/jsf/ipr-policy.php). This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). + xxxx + ProtoJEP + Standards Track + Standards JIG + Council + + XMPP Core + JEP-0001 + Etc. + + + + Not yet assigned + + Peter + Saint-Andre + stpeter@jabber.org + stpeter@jabber.org + + + 0.0.1 + 2001-09-14 + psa +

First draft.

 + +
+ +

This is a template for use in writing Jabber Enhancement Proposals. For detailed information about the JEP process and how to write a JEP, refer to "JEP-0001: Jabber Enhancement Proposals" and "JEP-0143: Guidelines for JEP Authors".

+ + +

STRONGLY RECOMMENDED.

+ + +

OPTIONAL.

+ + +

STRONGLY RECOMMENDED.

+ + +

OPTIONAL.

+ + +

OPTIONAL.

+ + +

OPTIONAL.

+ + +

REQUIRED.

+ + +

REQUIRED.

+ + +

REQUIRED.

+ + +

REQUIRED for protocol JEPs.

+ + diff --git a/xep.dtd b/xep.dtd new file mode 100644 index 00000000..271db089 --- /dev/null +++ b/xep.dtd @@ -0,0 +1,92 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/xep.ent b/xep.ent new file mode 100644 index 00000000..278c790c --- /dev/null +++ b/xep.ent @@ -0,0 +1,761 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +http://www.jabber.org/registrar/amp-actions.html>"> +http://www.jabber.org/registrar/amp-conditions.html>"> +http://www.jabber.org/registrar/errors.html>"> +http://www.jabber.org/registrar/compress.html>"> +http://www.jabber.org/registrar/disco-categories.html>"> +http://www.jabber.org/registrar/disco-features.html>"> +http://www.jabber.org/registrar/disco-nodes.html>"> +http://www.jabber.org/registrar/formtypes.html>"> +http://www.jabber.org/registrar/mucstatus.html>"> +http://www.jabber.org/registrar/namespaces.html>"> +http://www.jabber.org/registrar/querytypes.html>"> +http://www.jabber.org/registrar/shim.html>"> +http://www.jabber.org/registrar/si-profiles.html>"> +http://www.jabber.org/registrar/stream-features.html>"> +http://www.jabber.org/registrar/xdv-prefixes.html>"> +http://www.jabber.org/registrar/xdv-datatypes.html>"> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +This Jabber Enhancement Proposal is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>)." > + + + +Note: This document describes a protocol or best practice that is intended for addition to the specification that will supersede either &rfc3920; or &rfc3921; within the Internet Standards Process. This document is provided only for the purpose of open community discussion of the potential modification and will be obsoleted as soon as the relevant RFC is published.

" > + +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." > + +In order to submit new values to this registry, the registrant must define an XML fragment of the following form and either include it in the relevant Jabber Enhancement Proposal or send it to the email address <registrar@jabber.org>:

" > + + + +The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in &rfc2119;.

' > + + + +JSF Board of Directors The JSF Board of Directors is an elected body that possesses overall responsibility for the affairs of the Jabber Software Foundation. For further information, see <http://www.jabber.org/board/>." > +JSF Bylaws The Bylaws of the Jabber Software Foundation (JSF) define the legal basis and operating procedures of the JSF. For further information, see <http://www.jabber.org/jsf/bylaws.shtml>." > +Jabber Council The Jabber Council is a technical steering committee, authorized by the JSF Board of Directors and elected by JSF members, that approves of new Jabber protocols and oversees the JSF's standards process. For further information, see <http://www.jabber.org/council/>." > +JEP Editor The JEP Editor is the individual appointed by the JSF Board of Directors to handle protocol submissions and provide day-to-day management of the JSF's standards process. For further information, see <http://www.jabber.org/jeps/editor.shtml>." > +Jabber Software Foundation (JSF) The Jabber Software Foundation (JSF) is an independent, non-profit organization that develops open application protocols on top of the IETF's Extensible Messaging and Presence Protocol (XMPP). For further information, see <http://www.jabber.org/jsf/>." > +JSF-IETF list The JSF-IETF list is for discussion of matters of mutual interest to the Jabber Software Foundation and the Internet Engineering Task Force. The primary focus of the list is technical, mainly regarding JSF use of IETF technologies (e.g., references to RFCs in JEPs) and IETF use of JSF technologies (e.g., references to JEPs in Internet-Drafts and RFCs). To subscribe to the list or view the list archives, visit <http://mail.jabber.org/mailman/listinfo/jsf-ietf/>." > +JSF IPR Policy The JSF IPR Policy defines the Jabber Software Foundation's official policy regarding intellectual property rights (IPR) as they pertain to Jabber Enhancement Proposals (JEPs). For further information, see <http://www.jabber.org/jsf/ipr-policy.shtml>." > +Jabber Registrar The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>." > +Standards JIG The Standards JIG is a standing Jabber Interest Group devoted to discussion of Jabber Enhancement Proposals. The discussion list of the Standards JIG is the primary venue for discussion of Jabber protocol development, as well as for announcements by the JEP Editor and Jabber Registrar. To subscribe to the list or view the list archives, visit <http://mail.jabber.org/mailman/listinfo/standards-jig/>." > + + + +jabberd The jabberd server is the original server implementation of the Jabber protocols, first developed by Jeremie Miller, inventor of Jabber. For further information, see <http://jabberd.jabberstudio.org/>." > + + + +The General Public License The General Public License is the primary code license for free software as defined by the Free Software Foundation. For further information, see <http://www.gnu.org/licenses/gpl.txt>." > +The Lesser General Public License The Lesser General Public License is a secondary code license for free software as defined by the Free Software Foundation. For further information, see <http://www.gnu.org/licenses/lgpl.txt>." > +The Open Source Initiative The Open Source Initiative defines the term 'open source' and maintains a list of a open-source code licenses. For further information, see <http://www.opensource.org/>." > + + + +CAcert CAcert is a community-driven certificate authority which issues validated certificates based on participation in a web of trust rather than payment of a fee. For further information, see <http://www.cacert.org/>." > +Dublin Core Metadata Initiative (DCMI) The Dublin Core Metadata Initiative (DCMI) is an organization dedicated to promoting the widespread adoption of interoperable metadata standards. For further information, see <http://www.dublincore.org/>." > +FIX Protocol, Ltd. FIX Protocol, Ltd. is a securities industry consortium that has developed the Financial Information eXchange Protocol (FIX). For further information, see <http://www.fixprotocol.org/>." > +Internet Assigned Numbers Authority (IANA) 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/>." > +Internet Engineering Task Force (IETF) The Internet Engineering Task Force is the principal body engaged in the development of new Internet standard specifications, best known for its work on standards such as HTTP and SMTP. For further information, see <http://www.ietf.org/>." > +International Telecommunication Union (ITU) The International Telecommunication Union develops technical and operating standards (such as H.323) for international telecommunication services. For further information, see <http://www.itu.int/>." > +OASIS OASIS is a not-for-profit, international consortium that drives the development, convergence and adoption of e-business standards. For further information, see <http://www.oasis-open.org/>." > +Open Mobile Alliance (OMA) The Open Mobile Alliance is the focal point for the development of mobile service enabler specifications, which support the creation of interoperable end-to-end mobile services. For further information, see <http://www.openmobilealliance.org/>." > +XMPP Working Group The XMPP Working Group was created by the Internet Engineering Task Force to define an adaptation of the base Jabber protocols that could be considered an IETF-approved instant messaging and presence technology. For further information, see <http://www.ietf.org/html.charters/xmpp-charter.html>." > +World Wide Web Consortium (W3C) The World Wide Web Consortium defines data formats and markup languages (such as HTML and XML) for use over the Internet. For further information, see <http://www.w3.org/>." > + + + +Canonical XML Canonical XML 1.0 <http://www.w3.org/TR/xml-c14n>." > +Cascading Style Sheets Cascading Style Sheets, level 1 <http://www.w3.org/TR/REC-CSS1>." > +HTML 4.0 HTML 4.0 <http://www.w3.org/TR/REC-html40>." > +W3C Process Document W3C Process Document <http://www.w3.org/Consortium/Process-20010719/process.html>." > +Simple Object Access Protocol (SOAP) Simple Object Access Protocol (SOAP) <http://www.w3.org/TR/SOAP/>." > +SOAP Version 1.2 Part 0 SOAP Version 1.2 Part 0: Primer <http://www.w3.org/TR/soap12-part0>." > +SOAP Version 1.2 Part 1 SOAP Version 1.2 Part 1: Messaging <http://www.w3.org/TR/soap12-part1>." > +SOAP Version 1.2 Part 2 SOAP Version 1.2 Part 2: Adjuncts <http://www.w3.org/TR/soap12-part2>." > +SOAP 1.2 Attachment Feature SOAP 1.2 Attachment Feature <http://www.w3.org/TR/soap12-af/>." > +SOAP Email Binding SOAP Version 1.2 Email Binding <http://www.w3.org/TR/soap12-email>." > +SOAP Message Transmission Optimization Mechanism SOAP Message Transmission Optimization Mechanism <http://www.w3.org/TR/soap12-mtom>." > +Resource Representation SOAP Header Block Resource Representation SOAP Header Block <http://www.w3.org/TR/soap12-rep>." > +Inaccessibility of Visually-Oriented Anti-Robot Tests Inaccessibility of Visually-Oriented Anti-Robot Tests <http://www.w3.org/TR/turingtest/>." > +XForms 1.0 XForms 1.0 <http://www.w3.org/TR/xforms>." > +XHTML 1.0 XHTML 1.0 <http://www.w3.org/TR/xhtml1>." > +XHTML 2.0 XHTML 2.0 <http://www.w3.org/TR/xhtml2>." > +XHTML Basic XHTML Basic <http://www.w3.org/TR/xhtml-basic>." > +Modularization of XHTML Modularization of XHTML <http://www.w3.org/TR/2004/WD-xhtml-modularization-20040218/>." > +Resource Description Framework Resource Description Framework (RDF) <http://www.w3.org/RDF/>." > +XML 1.0 Extensible Markup Language (XML) 1.0 (Third Edition) <http://www.w3.org/TR/REC-xml/>." > +XML Encryption XML Encryption Syntax and Processing <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/>." > +Namespaces in XML Namespaces in XML <http://www.w3.org/TR/REC-xml-names/>." > +XML Schema Part 1 XML Schema Part 1: Structures <http://www.w3.org/TR/xmlschema-1/>." > +XML Schema Part 2 XML Schema Part 2: Datatypes <http://www.w3.org/TR/xmlschema-2/>." > +XML Signature XML Signature Syntax and Processing <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>." > +XML-binary Optimized Packaging XML-binary Optimized Packaging <http://www.w3.org/TR/xop10/>." > +XPath XML Path Language <http://www.w3.org/TR/xpath>." > +XSL Transformations XSL Transformations <http://www.w3.org/TR/xslt/>." > +WSDL WSDL 1.1 Specification <http://www.w3.org/TR/wsdl>." > + + + +Common Alerting Protocol Common Alerting Protocol, v. 1.0 <http://www.oasis-open.org/committees/documents.php?wg_abbrev=emergency>." > + + + +ANSI X9.52 ANSI X9.52: Triple Data Encryption Algorithm Modes of Operation (1998)." > +Arcfour A Stream Cipher Encryption Algorithm 'Arcfour' <http://www.watersprings.org/pub/id/draft-kaukonen-cipher-arcfour-03.txt>." > +Blowfish Description of a New Variable-Length Key, 64-Bit Block Cipher (Blowfish) <http://www.schneier.com/paper-blowfish-fse.html>." > +IDEA The IDEA Block Cipher <http://perso.ens-lyon.fr/jean-luc.beuchat/IDEA/>." > +Data Encryption Standard Data Encryption Standard: Federal Information Processing Standards Publication 46-3 <http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf>." > +Secure Hash Standard Secure Hash Standard: Federal Information Processing Standards Publication 180-2 <http://csrc.nist.gov/publications/fips/fips180-2/fips186-2withchangenotice.pdf>." > +Digital Signature Standard Digital Signature Standard: Federal Information Processing Standards Publication 186 <http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf>." > +Advanced Encryption Standard Advanced Encryption Standard: Federal Information Processing Standards Publication 197 <http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>." > +The Keyed-Hash Message Authentication Code (HMAC) The Keyed-Hash Message Authentication Code (HMAC): Federal Information Processing Standards Publication 198 <http://csrc.nist.gov/publications/fips/fips198/fips-198a.pdf>." > + Recommendation for Block Cipher Modes of Operation Recommendation for Block Cipher Modes of Operation: Federal Information Processing Standards Publication 800-38a <http://csrc.nist.gov/publications/ nistpubs/800-38a/sp800-38a.pdf>." > +Off-the-Record Communication Off-the-Record Communication, or, Why Not to Use PGP <http://www.isaac.cs.berkeley.edu/~iang/pubs/otr-wpes.pdf>." > +Serpent The Serpent Block Cipher <http://www.cl.cam.ac.uk/~rja14/serpent.html>." > +SIGMA SIGMA: the 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols (Hugo Krawczyk, June 12 2003) <http://www.ee.technion.ac.il/~hugo/sigma.ps>." > +SSL SSL V3.0 <http://wp.netscape.com/eng/ssl3/draft302.txt>." > +Twofish The Twofish Block Cipher <http://www.schneier.com/twofish.html>." > +Whirlpool The Whirlpool Hash Function <http://paginas.terra.com.br/informatica/paulobarreto/WhirlpoolPage.html>." > + + + +US-ASCII Coded Character Set - 7-bit American Standard Code for Information Interchange (American National Standards Institute X3.4, 1986)." > +DCMI Metadata Terms Dublin Core Metadata Initiative: DCMI Metadata Terms <http://dublincore.org/documents/dcmi-terms/>." > +Standard ECMA-151 Standard ECMA-151: Data Compression for Information Interchange - Adaptive Coding with Embedded Dictionary - DLCZ Algorithm <http://www.ecma-international.org/publications/standards/Ecma-151.htm>." > +Financial Information eXchange Protocol (FIX) The Financial Information eXchange Protocol (FIX) is a messaging standard developed specifically for the real-time electronic exchange of securities transactions. For further information, see <http://www.fixprotocol.org/>." > +FIXML FIXML is an XML representation of the data format used in Financial Information eXchange Protocol (FIX), which abstracts the FIX data format from the underlying FIX transport mechanism. For further information, see <http://www.fixprotocol.org/cgi-bin/Spec.cgi?menu=4>." > +Friend of a Friend (FOAF) Friend of a Friend (FOAF) <http://xmlns.com/foaf/0.1/>." > +H.323 ITU Recommendation H.323: Packet-based Multimedia Communications Systems (September 1999)." > +Information and Content Exchange Information and Content Exchange <http://www.icestandard.org/>." > +ISO 8601 ISO 8601: Representation of Dates and Times (2000). This specification is not freely available; however, a good summary is located at <http://www.cl.cam.ac.uk/~mgk25/iso-time.html>." > +ITU E.164 ITU Recommendation E.164/I.331: The International Public Telecommunication Numbering Plan (1997). This specification is not freely available; a short summary is located at <http://en.wikipedia.org/wiki/E.164>." > +Introduction to Petname Systems Introduction to Petname Systems <http://www.skyhunter.com/marcs/petnames/IntroPetNames.html>." > +Rich Text Format (RTF) Rich Text Format (RTF) Version 1.5 Specification <http://msdn.microsoft.com/library/en-us/dnrtfspec/html/rtfspec.asp>." > +Unicode The Unicode Standard, Version 3.2.0 (The Unicode Consortium, 2000)." > +Wireless Access Protocol (WAP) Wireless Access Protocol (WAP) <http://www.wapforum.org/>." > +WV Client-Server Protocol v1.1 Wireless Village Client-Server Protocol v1.1 <http://www.openmobilealliance.org/tech/affiliates/wv/wvindex.html>." > +XHTML Friends Network (XFN) XHTML Friends Network (XFN) <http://gmpg.org/xfn/index>." > +XML-RPC XML-RPC <http://www.xmlrpc.com/spec>." > + + + +RFC 768 RFC 768: User Datagram Protocol <http://www.ietf.org/rfc/rfc0768.txt>." > +RFC 793 RFC 793: Transmission Control Protocol <http://www.ietf.org/rfc/rfc0793.txt>." > +RFC 822 RFC 822: Standard for the Format of ARPA Internet Text Messages <http://www.ietf.org/rfc/rfc0822.txt>." > +RFC 958 RFC 958: Network Time Protocol (NTP) <http://www.ietf.org/rfc/rfc0958.txt>." > +RFC 959 RFC 959: File Transfer Protocol <http://www.ietf.org/rfc/rfc0959.txt>." > +RFC 1034 RFC 1034: Domain Names - Concepts and Facilities <http://www.ietf.org/rfc/rfc1034.txt>." > +RFC 1035 RFC 1035: Domain Names - Implementation and Specification <http://www.ietf.org/rfc/rfc1035.txt>." > +RFC 1123 RFC 1123: Requirements for Internet Hosts -- Application and Support <http://www.ietf.org/rfc/rfc1123.txt>." > +RFC 1305 RFC 1305: Network Time Protocol (Version 3) <http://www.ietf.org/rfc/rfc1305.txt>." > +RFC 1321 RFC 1321: The MD5 Message-Digest Algorithm <http://www.ietf.org/rfc/rfc1321.txt>." > +RFC 1459 RFC 1459: Internet Relay Chat <http://www.ietf.org/rfc/rfc1459.txt>." > +RFC 1464 RFC 1464: Using the Domain Name System To Store Arbitrary String Attributes <http://www.ietf.org/rfc/rfc1464.txt>." > +RFC 1750 RFC 1750: Randomness Recommendations for Security <http://www.ietf.org/rfc/rfc1750.txt>." > +RFC 1808 RFC 1808: Uniform Resource Locators <http://www.ietf.org/rfc/rfc1808.txt>." > +RFC 1886 RFC 1886: DNS Extensions to support IP version 6 <http://www.ietf.org/rfc/rfc1886.txt>." > +RFC 1889 RFC 1889: RTP: A Transport Protocol for Real-Time Applications <http://www.ietf.org/rfc/rfc1889.txt>." > +RFC 1893 RFC 1893: Enhanced Mail System Status Codes <http://www.ietf.org/rfc/rfc1893.txt>." > +RFC 1928 RFC 1928: SOCKS Protocol Version 5 <http://www.ietf.org/rfc/rfc1928.txt>." > +RFC 1929 RFC 1929: Username/Password Authentication for SOCKS V5 <http://www.ietf.org/rfc/rfc1929.txt>." > +RFC 1939 RFC 1939: Post Office Protocol - Version 3 <http://www.ietf.org/rfc/rfc1939.txt>." > +RFC 1945 RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0 <http://www.ietf.org/rfc/rfc1945.txt>." > +RFC 1950 RFC 1950: ZLIB Compressed Data Format Specification version 3.3 <http://www.ietf.org/rfc/rfc1950.txt>." > +RFC 2026 RFC 2026: The Internet Standards Process <http://www.ietf.org/rfc/rfc2026.txt>." > +RFC 2045 RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies <http://www.ietf.org/rfc/rfc2045.txt>." > +RFC 2068 RFC 2068: Hypertext Transport Protocol -- HTTP/1.1 <http://www.ietf.org/rfc/rfc2068.txt>." > +RFC 2104 RFC 2104: HMAC: Keyed-Hashing for Message Authentication <http://www.ietf.org/rfc/rfc2104.txt>." > +RFC 2109 RFC 2109: HTTP State Mangement Mechanism <http://www.ietf.org/rfc/rfc2109.txt>." > +RFC 2119 RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <http://www.ietf.org/rfc/rfc2119.txt>." > +RFC 2142 RFC 2142: Mailbox Names for Common Services, Roles and Functions <http://www.ietf.org/rfc/rfc2142.txt>." > +RFC 2144 RFC 2144: The CAST-128 Encryption Algorithm <http://www.ietf.org/rfc/rfc2144.txt>." > +RFC 2222 RFC 2222: Simple Authentication and Security Layer (SASL) <http://www.ietf.org/rfc/rfc2222.txt>." > +RFC 2251 RFC 2251: Lightweight Directory Access Protocol (v3) <http://www.ietf.org/rfc/rfc2251.txt>." > +RFC 2252 RFC 2252: Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions <http://www.ietf.org/rfc/rfc2252.txt>." > +RFC 2253 RFC 2253: Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names <http://www.ietf.org/rfc/rfc2253.txt>." > +RFC 2256 RFC 2256: A Summary of the X.500(96) User Schema for use with LDAPv3 <http://www.ietf.org/rfc/rfc2256.txt>." > +RFC 2277 RFC 2277: IETF Policy on Character Sets and Languages <http://www.ietf.org/rfc/rfc2277.txt>." > +RFC 2246 RFC 2246: The TLS Protocol Version 1.0 <http://www.ietf.org/rfc/rfc2246.txt>." > +RFC 2317 RFC 2317: Classless IN-ADDR.ARPA delegation <http://www.ietf.org/rfc/rfc2317.txt>." > +RFC 2326 RFC 2326: Real Time Streaming Protocol (RTSP) <http://www.ietf.org/rfc/rfc2326.txt>." > +RFC 2327 RFC 2327: SDP: Session Description Protocol <http://www.ietf.org/rfc/rfc2327.txt>." > +RFC 2368 RFC 2368: The mailto URL scheme <http://www.ietf.org/rfc/rfc2368.txt>." > +RFC 2405 RFC 2405: The ESP DES-CBC Cipher Algorithm With Explicit IV <http://www.ietf.org/rfc/rfc2405.txt>." > +RFC 2406 RFC 2406: IP Encapsulating Security Payload (ESP) <http://www.ietf.org/rfc/rfc2406.txt>." > +RFC 2409 RFC 2409: The Internet Key Exchange (IKE) <http://www.ietf.org/rfc/rfc2409.txt>." > +RFC 2412 RFC 2412: The OAKLEY Key Determination Protocol <http://www.ietf.org/rfc/rfc2412.txt>." > +RFC 2413 RFC 2413: Dublin Core Metadata for Resource Discovery <http://www.ietf.org/rfc/rfc2413.txt>." > +RFC 2414 RFC 2414: Increasing TCP's Initial Window <http://www.ietf.org/rfc/rfc2414.txt>." > +RFC 2420 RFC 2420: The PPP Triple-DES Encryption Protocol (3DESE) <http://www.ietf.org/rfc/rfc2420.txt>." > +RFC 2426 RFC 2426: vCard MIME Directory Profile <http://www.ietf.org/rfc/rfc2426.txt>." > +RFC 2437 RFC 2437: PKCS #1: RSA Cryptography Specifications Version 2.0 <http://www.ietf.org/rfc/rfc2437.txt>." > +RFC 2440 RFC 2440: OpenPGP Message Format <http://www.ietf.org/rfc/rfc2440.txt>." > +RFC 2451 RFC 2451: The ESP CBC-Mode Cipher Algorithms <http://www.ietf.org/rfc/rfc2451.txt>." > +RFC 2510 RFC 2510: Internet X.509 Public Key Infrastructure Certificate Management Protocols <http://www.ietf.org/rfc/rfc2510.txt>." > +RFC 2518 RFC 2518: HTTP Extensions for Distributed Authoring -- WEBDAV <http://www.ietf.org/rfc/rfc2518.txt>." > +RFC 2606 RFC 2606: Reserved Top Level DNS Names <http://www.ietf.org/rfc/rfc2606.txt>." > +RFC 2616 RFC 2616: Hypertext Transport Protocol -- HTTP/1.1 <http://www.ietf.org/rfc/rfc2616.txt>." > +RFC 2617 RFC 2617: HTTP Authentication: Basic and Digest Access Authentication <http://www.ietf.org/rfc/rfc2617.txt>." > +RFC 2631 RFC 2631: Diffie-Hellman Key Agreement Method <http://www.ietf.org/rfc/rfc2631.txt>." > +RFC 2633 RFC 2633: S/MIME Version 3 Message Specification <http://www.ietf.org/rfc/rfc2633.txt>." > +RFC 2648 RFC 2648: A URN Namespace for IETF Documents <http://www.ietf.org/rfc/rfc2648.txt>." > +RFC 2778 RFC 2778: A Model for Presence and Instant Messaging <http://www.ietf.org/rfc/rfc2778.txt>." > +RFC 2779 RFC 2779: A Model for Presence and Instant Messaging <http://www.ietf.org/rfc/rfc2779.txt>." > +RFC 2782 RFC 2782: A DNS RR for specifying the location of services (DNS SRV) <http://www.ietf.org/rfc/rfc2782.txt>." > +RFC 2798 RFC 2798: Definition of the inetOrgPerson LDAP Object Class <http://www.ietf.org/rfc/rfc2798.txt>." > +RFC 2806 RFC 2806: URLs for Telephone Calls <http://www.ietf.org/rfc/rfc2806.txt>." > +RFC 2810 RFC 2810: Internet Relay Chat: Architecture <http://www.ietf.org/rfc/rfc2810.txt>." > +RFC 2811 RFC 2811: Internet Relay Chat: Channel Management <http://www.ietf.org/rfc/rfc2811.txt>." > +RFC 2812 RFC 2812: Internet Relay Chat: Client Protocol <http://www.ietf.org/rfc/rfc2812.txt>." > +RFC 2813 RFC 2813: Internet Relay Chat: Server Protocol <http://www.ietf.org/rfc/rfc2813.txt>." > +RFC 2817 RFC 2817: Upgrading to TLS Within HTTP/1.1 <http://www.ietf.org/rfc/rfc2817.txt>." > +RFC 2818 RFC 2818: HTTP Over TLS <http://www.ietf.org/rfc/rfc2818.txt>." > +RFC 2821 RFC 2821: Simple Mail Transfer Protocol <http://www.ietf.org/rfc/rfc2821.txt>." > +RFC 2822 RFC 2822: Internet Message Format <http://www.ietf.org/rfc/rfc2822.txt>." > +RFC 2831 RFC 2831: Using Digest Authentication as a SASL Mechanism <http://www.ietf.org/rfc/rfc2831.txt>." > +RFC 2833 RFC 2833: RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals <http://www.ietf.org/rfc/rfc2833.txt>." > +RFC 2965 RFC 2965: HTTP State Management Mechanism <http://www.ietf.org/rfc/rfc2965.txt>." > +RFC 3023 RFC 3023: XML Media Types <http://www.ietf.org/rfc/rfc3023.txt>." > +RFC 3066 RFC 3066: Tags for the Identification of Languages <http://www.ietf.org/rfc/rfc3066.txt>." > +RFC 3080 RFC 3080: The Blocks Extensible Exchange Protocol Core (BEEP) <http://www.ietf.org/rfc/rfc3080.txt>." > +RFC 3117 RFC 3117: On the Design of Application Protocols <http://www.ietf.org/rfc/rfc3117.txt>." > +RFC 3174 RFC 3174: US Secure Hash Algorithm 1 (SHA1) <http://www.ietf.org/rfc/rfc3174.txt>." > +RFC 3217 RFC 3217: Triple-DES and RC2 Key Wrapping <http://www.ietf.org/rfc/rfc3217.txt>." > +RFC 3261 RFC 3261: Session Initiation Protocol (SIP) <http://www.ietf.org/rfc/rfc3261.txt>." > +RFC 3264 RFC 3264: An Offer/Answer Model with the Session Description Protocol (SDP) <http://www.ietf.org/rfc/rfc3264.txt>." > +RFC 3269 RFC 3269: UTF-8, a transformation format of ISO 10646 <http://www.ietf.org/rfc/rfc3269.txt>." > +RFC 3261 RFC 3261: Session Initiation Protocol <http://www.ietf.org/rfc/rfc3261.txt>." > +RFC 3288 RFC 3288: Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) <http://www.ietf.org/rfc/rfc3288.txt>." > +RFC 3312 RFC 3312: Integration of Resource Management and Session Initiation Protocol (SIP) <http://www.ietf.org/rfc/rfc3312.txt>." > +RFC 3330 RFC 3330: Special-Use IPv4 Addresses <http://www.ietf.org/rfc/rfc3330.txt>." > +RFC 3340 RFC 3340: The Application Exchange Core (APEX) <http://www.ietf.org/rfc/rfc3340.txt>." > +RFC 3341 RFC 3341: The Application Exchange (APEX) Access Service <http://www.ietf.org/rfc/rfc3341.txt>." > +RFC 3342 RFC 3342: The Application Exchange (APEX) Option Party Pack, Part Deux! <http://www.ietf.org/rfc/rfc3342.txt>." > +RFC 3343 RFC 3343: The Application Exchange (APEX) Presence Service <http://www.ietf.org/rfc/rfc3343.txt>." > +RFC 3370 RFC 3370: Cryptographic Message Syntax (CMS) Algorithms <http://www.ietf.org/rfc/rfc3370.txt>." > +RFC 3394 RFC 3394: Advanced Encryption Standard (AES) Key Wrap Algorithm <http://www.ietf.org/rfc/rfc3394.txt>." > +RFC 3401 RFC 3401: Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS <http://www.ietf.org/rfc/rfc3401.txt>." > +RFC 3404 RFC 3404: Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application <http://www.ietf.org/rfc/rfc3404.txt>." > +RFC 3428 RFC 3428: Session Initiation Protocol (SIP) Extension for Instant Messaging <http://www.ietf.org/rfc/rfc3428.txt>." > +RFC 3447 RFC 3447: Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 <http://www.ietf.org/rfc/rfc3447.txt>." > +RFC 3454 RFC 3454: Preparation of Internationalized Strings (stringprep) <http://www.ietf.org/rfc/rfc3454.txt>." > +RFC 3489 RFC 3489: STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) <http://www.ietf.org/rfc/rfc3489.txt>." > +RFC 3490 RFC 3490: Internationalizing Domain Names in Applications (IDNA) <http://www.ietf.org/rfc/rfc3490.txt>." > +RFC 3514 RFC 3514: The Security Flag in the IPv4 Header <http://www.ietf.org/rfc/rfc3514.txt>." > +RFC 3526 RFC 3526: More Modular Exponential (MODP) Diffie-Hellman Groups <http://www.ietf.org/rfc/rfc3526.txt>." > +RFC 3548 RFC 3548: The Base16, Base32, and Base64 Data Encodings <http://www.ietf.org/rfc/rfc3548.txt>." > +RFC 3550 RFC 3550: RTP: A Transport Protocol for Real-Time Applications <http://www.ietf.org/rfc/rfc3550.txt>." > +RFC 3551 RFC 3551: RTP Profile for Audio and Video Conferences with Minimal Control <http://www.ietf.org/rfc/rfc3551.txt>." > +RFC 3552 RFC 3552: Guidelines for Writing RFC Text on Security Considerations <http://www.ietf.org/rfc/rfc3552.txt>." > +RFC 3555 RFC 3555: MIME Type Registration of RTP Payload Formats <http://www.ietf.org/rfc/rfc3555.txt>." > +RFC 3605 RFC 3605: Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) <http://www.ietf.org/rfc/rfc3605.txt>." > +RFC 3749 RFC 3749: Transport Layer Security Protocol Compression Methods <http://www.ietf.org/rfc/rfc3749.txt>." > +RFC 3766 RFC 3766: Determining Strengths For Public Keys Used For Exchanging Symmetric Keys <http://www.ietf.org/rfc/rfc3766.txt>." > +RFC 3859 RFC 3859: Common Profile for Presence (CPP) <http://www.ietf.org/rfc/rfc3859.txt>." > +RFC 3860 RFC 3860: Common Profile for Instant Messaging (CPIM) <http://www.ietf.org/rfc/rfc3860.txt>." > +RFC 3861 RFC 3861: Address Resolution for Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3861.txt>." > +RFC 3862 RFC 3862: Common Presence and Instant Messaging (CPIM): Message Format <http://www.ietf.org/rfc/rfc3862.txt>." > +RFC 3863 RFC 3863: Presence Information Data Format (PIDF) <http://www.ietf.org/rfc/rfc3863.txt>." > +RFC 3920 RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>." > +RFC 3921 RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>." > +RFC 3922 RFC 3922: Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM) <http://www.ietf.org/rfc/rfc3922.txt>." > +RFC 3923 RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) <http://www.ietf.org/rfc/rfc3923.txt>." > +RFC 3927 RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses <http://www.ietf.org/rfc/rfc3927.txt>." > +RFC 3958 RFC 3958: Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS) <http://www.ietf.org/rfc/rfc3958.txt>." > +RFC 3959 RFC 3959: The Early Session Disposition Type for the Session Initiation Protocol (SIP) <http://www.ietf.org/rfc/rfc3959.txt>." > +RFC 3960 RFC 3960: Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP) <http://www.ietf.org/rfc/rfc3960.txt>." > +RFC 3966 RFC 3966: The tel URI for Telephone Numbers <http://www.ietf.org/rfc/rfc3966.txt>." > +RFC 3986 RFC 3986: Uniform Resource Identifiers (URI): Generic Syntax <http://www.ietf.org/rfc/rfc3986.txt>." > +RFC 3987 RFC 3987: Internationalized Resource Identifiers (IRIs) <http://www.ietf.org/rfc/rfc3987.txt>." > +RFC 4032 RFC 4032: Update to the Session Initiation Protocol (SIP) Preconditions Framework <http://www.ietf.org/rfc/rfc4032.txt>." > +RFC 4119 RFC 4119: A Presence-based GEOPRIV Location Object Format <http://www.ietf.org/rfc/rfc4119.txt>." > +RFC 4251 RFC 4251: The Secure Shell (SSH) Protocol Architecture <http://www.ietf.org/rfc/rfc4251.txt>." > +RFC 4252 RFC 4252: The Secure Shell (SHS) Authentication Protocol <http://www.ietf.org/rfc/rfc4252.txt>." > +RFC 4253 RFC 4253: The Secure Shell (SSH) Transport Layer Protocol <http://www.ietf.org/rfc/rfc4253.txt>." > +RFC 4287 RFC 4287: The Atom Syndication Format <http://www.ietf.org/rfc/rfc4287.txt>." > +RFC 4301 RFC 4301: Security Architecture for the Internet Protocol <http://www.ietf.org/rfc/rfc4301.txt>." > +RFC 4306 RFC 4306: Internet Key Exchange (IKEv2) Protocol <http://www.ietf.org/rfc/rfc4306.txt>." > +RFC 4344 RFC 4344: SSH Transport Layer Encryption Modes <http://www.ietf.org/rfc/rfc4344.txt>." > +RFC 4346 RFC 4346: The Transport Layer Security (TLS) Protocol Version 1.1 <http://www.ietf.org/rfc/rfc4346.txt>." > +RFC 4395 RFC 4395: Guidelines and Registration Procedures for New URI Schemes <http://www.ietf.org/rfc/rfc4395.txt>." > +RFC 4422 RFC 4422: Simple Authentication and Security Layer (SASL) <http://www.ietf.org/rfc/rfc4422.txt>." > +RFC 4480 RFC 4480: RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) <http://www.rfc-editor.org/rfc/rfc4480.txt>." > +RFC 4481 RFC 4481: Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals <http://www.rfc-editor.org/rfc/rfc4481.txt>." > +RFC 4505 RFC 4505: The SASL ANONYMOUS Mechanism <http://www.ietf.org/rfc/rfc4505.txt>." > +RFC 4566 RFC 4566: SDP: Session Description Protocol <http://www.ietf.org/rfc/rfc4566.txt>." > +RFC 4622 RFC 4622: Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) <http://www.ietf.org/rfc/rfc4622.txt>." > + + + +draft-dawson-vcard-xml-dtd-03 draft-dawson-vcard-xml-dtd-03 <http://www.watersprings.org/pub/id/draft-dawson-vcard-xml-dtd-03.txt>. Work in progress." > +DNS-Based Service Discovery DNS-Based Service Discovery <http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt>. Work in progress." > +Geopriv Policy Geopriv Policy <http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-08.txt>. Work in progress." > +IAX IAX: Inter-Asterisk eXchange Version 2 <http://www.ietf.org/internet-drafts/draft-ietf-guy-iax-01.txt>. Work in progress." > +Interactive Connectivity Establishment (ICE) Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols <http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-10.txt>. Work in progress." > +TCP Candidates with Interactive Connectivity Establishment (ICE) TCP Candidates with Interactive Connectivity Establishment (ICE) <http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-01.txt>. Work in progress." > +Multicast DNS Multicast DNS <http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt>. Work in progress." > +Presence Information Data Format (PIDF) RFC 3863: Presence Information Data Format (PIDF) <http://www.ietf.org/rfc/rfc3863.txt>." > +RTP Over DTLS Real-Time Transport Protocol (RTP) over Datagram Transport Layer Security (DTLS) <http://scm.sipfoundry.org/rep/ietf-drafts/ekr/draft-tschofenig-avt-rtp-dtls-00.txt>. Work in progress." > +Sieve Extension: Notifications Sieve Extension: Notifications <http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-03.txt>. Work in progress." > +Sieve Notification Mechanism: xmpp Sieve Notification Mechanism: xmpp <http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-xmpp-01.txt>. Work in progress." > +Session Description and Capability Negotiation (SDPng) Session Description and Capability Negotiation (SDPng) <http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdpng-09.txt>. Work in progress." > +X.509 Authentication in SSH2 X.509 Authentication in SSH2 <http://www.ietf.org/internet-drafts/draft-ietf-secsh-x509-03.txt>. Work in progress." > +ZRTP ZRTP: Extensions to RTP for Diffie-Hellman Key Agreement for SRTP <http://www.ietf.org/internet-drafts/draft-zimmermann-avt-zrtp-01.txt>. Work in progress." > + + + +IANA MIME Media Types Registry IANA registry of MIME media types <http://www.iana.org/assignments/media-types>." > +IANA Port Numbers Registry IANA registry of port numbers <http://www.iana.org/assignments/port-numbers>." > +IANA Session Description Protocol Parameters Registry IANA registry of parameters related to the Session Description Protocol <http://www.iana.org/assignments/sdp-parameters>." > +IANA Session Initiation Protocol Parameters Registry IANA registry of parameters related to the Session Initiation Protocol <http://www.iana.org/assignments/sip-parameters>." > +IANA Secure Shell Protocol Parameters Registry IANA registry of parameters related to secure shell <http://www.iana.org/assignments/ssh-parameters>." > + + + +XMPP Extensible Messaging and Presence Protocol (XMPP) <http://www.xmpp.org/>." > +XMPP Core RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>." > +XMPP IM RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>." > +XMPP CPIM RFC 3922: Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM) <http://www.ietf.org/rfc/rfc3922.txt>." > +XMPP E2E RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) <http://www.ietf.org/rfc/rfc3923.txt>." > +XMPP URI Scheme Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) <http://www.ietf.org/rfc/rfc4622.txt>." > +draft-saintandre-xmpp-simple Basic Messaging and Presence Interoperability between the Extensible Messaging and Presence Protocol (XMPP) and Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) <http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-simple-05.txt> (work in progress)." > +XMPP URI A Uniform Resource Identifier (URI) Scheme for the Extensible Messaging and Presence Protocol (XMPP) <http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-uri-08.txt> (work in progress)." > + + + + + Peter + Saint-Andre + stpeter@jabber.org + stpeter@jabber.org + +" > + + Dave + Smith + dizzyd@jabber.org + dizzyd@jabber.org + +" > + + Thomas + Muldowney + temas@jabber.org + temas@jabber.org + +" > + + Matthew + Miller + linuxwolf@outer-planes.net + linuxwolf@outer-planes.net + +" > + + Peter + Millard + + +" > + + Joe + Hildebrand + jhildebrand@jabber.com + hildjj@jabber.org + +" > + + Ryan + Eatmon + reatmon@jabber.org + reatmon@jabber.org + +" > + + Jeremie + Miller + jer@jabber.org + jer@jabber.org + +" > + + Justin + Karneges + justin@affinix.com + justin@andbit.net + +" > + + Ralph + Meijer + ralphm@ik.nu + ralphm@ik.nu + +" > + + Julian + Missig + julian@jabber.org + julian@jabber.org + +" > + + Ian + Paterson + ian.paterson@clientside.co.uk + ian@zoofy.com + +" > + + Scott + Ludwig + scottlu@google.com + scottlu@google.com + +" > + + Joe + Beda + jbeda@google.com + jbeda@google.com + +" > + + Valerie + Mercier + valerie.mercier@francetelecom.com + vmercier@jabber.com + +" > + + Sean + Egan + seanegan@google.com + seanegan@google.com + +" > + + Robert + McQueen + robert.mcqueen@collabora.co.uk + robert.mcqueen@collabora.co.uk + +" > + + + +Jabber Enhancement Proposals JEP-0001: Jabber Enhancement Proposals <http://www.jabber.org/jeps/jep-0001.html>." > +Jabber Interest Groups JEP-0002: Jabber Interest Groups <http://www.jabber.org/jeps/jep-0002.html>." > +Proxy Accept Socket Service JEP-0002: Proxy Accept Socket Service <http://www.jabber.org/jeps/jep-0003.html>." > +Data Forms JEP-0004: Data Forms <http://www.jabber.org/jeps/jep-0004.html>." > +IQ-Based Avatars JEP-0008: IQ-Based Avatars <http://www.jabber.org/jeps/jep-0008.html>." > +Jabber-RPC JEP-0009: Jabber-RPC <http://www.jabber.org/jeps/jep-0009.html>." > +Jabber Browsing JEP-0011: Jabber Browsing <http://www.jabber.org/jeps/jep-0011.html>." > +Last Activity JEP-0012: Last Activity <http://www.jabber.org/jeps/jep-0012.html>." > +Flexible Offline Message Retrieval JEP-0013: Flexible Offline Message Retrieval <http://www.jabber.org/jeps/jep-0013.html>." > + + +Server-Based Privacy Rules JEP-0016: Server-Based Privacy Rules <http://www.jabber.org/jeps/jep-0016.html>." > + +Invisible Presence JEP-0018: Invisible Presence <http://www.jabber.org/jeps/jep-0018.html>." > +Streamlining the JIGs JEP-0019: Streamlining the JIGs <http://www.jabber.org/jeps/jep-0019.html>." > +Feature Negotiation JEP-0020: Feature Negotiation <http://www.jabber.org/jeps/jep-0020.html>." > +Jabber Event Notification Service JEP-0021: Jabber Event Notification Service <http://www.jabber.org/jeps/jep-0021.html>." > +Message Events JEP-0022: Message Events <http://www.jabber.org/jeps/jep-0022.html>." > +Message Expiration JEP-0023: Message Expiration <http://www.jabber.org/jeps/jep-0023.html>." > +Publish/Subscribe JEP-0024: Publish/Subscribe <http://www.jabber.org/jeps/jep-0024.html>." > +Jabber HTTP Polling JEP-0025: Jabber HTTP Polling <http://www.jabber.org/jeps/jep-0025.html>." > +Internationalization JEP-0026: Internationalization <http://www.jabber.org/jeps/jep-0026.html>." > +Current Jabber OpenPGP Usage JEP-0027: Current Jabber OpenPGP Usage <http://www.jabber.org/jeps/jep-0027.html>." > + +Definition of Jabber Identifiers JEP-0029: Definition of Jabber Identifiers <http://www.jabber.org/jeps/jep-0029.html>." > +Service Discovery JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>." > +A Framework for Securing Jabber Conversations JEP-0031: A Framework for Securing Jabber Conversations <http://www.jabber.org/jeps/jep-0031.html>." > +Jabber URI Scheme JEP-0032: Jabber URI Scheme <http://www.jabber.org/jeps/jep-0032.html>." > +Extended Stanza Addressing JEP-0033: Extended Stanza Addressing <http://www.jabber.org/jeps/jep-0033.html>." > +SASL Integration JEP-0034: SASL Integration <http://www.jabber.org/jeps/jep-0034.html>." > +SSL/TLS Integration JEP-0035: SSL/TLS Integration <http://www.jabber.org/jeps/jep-0035.html>." > +Pub-sub Subscriptions JEP-0036: Pub-sub Subscriptions <http://www.jabber.org/jeps/jep-0036.html>." > + +Icon Styles JEP-0038: Icon Styles <http://www.jabber.org/jeps/jep-0038.html>." > +Statistics Gathering JEP-0039: Statistics Gathering <http://www.jabber.org/jeps/jep-0039.html>." > +Robust Publish-Subscribe JEP-0040: Robust Publish-Subscribe <http://www.jabber.org/jeps/jep-0040.html>." > +Jidlink JEP-0041: Jidlink <http://www.jabber.org/jeps/jep-0041.html>." > +Jabber OOB Broadcast Service JEP-0042: Jabber OOB Broadcast Service <http://www.jabber.org/jeps/jep-0042.html>." > +Jabber Database Access JEP-0043: Jabber Database Access <http://www.jabber.org/jeps/jep-0043.html>." > +Full Namespace Support in XML Streams JEP-0044: Full Namespace Support in XML Streams <http://www.jabber.org/jeps/jep-0044.html>." > +Multi-User Chat JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>." > +Direct TCP JEP-0046: Direct TCP <http://www.jabber.org/jeps/jep-0046.html>." > +In-Band Bytestreams JEP-0047: In-Band Bytestreams <http://www.jabber.org/jeps/jep-0047.html>." > +Bookmark Storage JEP-0048: Bookmark Storage <http://www.jabber.org/jeps/jep-0048.html>." > +Private XML Storage JEP-0049: Private XML Storage <http://www.jabber.org/jeps/jep-0049.html>." > +Ad-Hoc Commands JEP-0050: Ad-Hoc Commands <http://www.jabber.org/jeps/jep-0050.html>." > +Redirect and Connection Transfer JEP-0051: Redirect and Connection Transfer <http://www.jabber.org/jeps/jep-0051.html>." > +File Transfer JEP-0052: File Transfer <http://www.jabber.org/jeps/jep-0052.html>." > +Jabber Registrar JEP-0053: Jabber Registrar <http://www.jabber.org/jeps/jep-0053.html>." > +vcard-temp JEP-0054: vcard-temp <http://www.jabber.org/jeps/jep-0054.html>." > +Jabber Search JEP-0055: Jabber Search <http://www.jabber.org/jeps/jep-0055.html>." > +Business Data Interchange JEP-0056: Business Data Interchange <http://www.jabber.org/jeps/jep-0056.html>." > +Extended Roster JEP-0057: Extended Roster <http://www.jabber.org/jeps/jep-0057.html>." > +Multi-User Text Editing JEP-0058: Multi-User Text Editing <http://www.jabber.org/jeps/jep-0058.html>." > +Result Set Management JEP-0059: Result Set Management <http://www.jabber.org/jeps/jep-0059.html>." > +Publish-Subscribe JEP-0060: Publish-Subscribe <http://www.jabber.org/jeps/jep-0060.html>." > +Shared Notes JEP-0061: Shared Notes <http://www.jabber.org/jeps/jep-0061.html>." > +Packet Filtering JEP-0062: Packet Filtering <http://www.jabber.org/jeps/jep-0062.html>." > +Basic Filtering Operations JEP-0063: Basic Filtering Operations <http://www.jabber.org/jeps/jep-0063.html>." > +XPath Filtering JEP-0064: XPath Filtering <http://www.jabber.org/jeps/jep-0064.html>." > +SOCKS5 Bytestreams JEP-0065: SOCKS5 Bytestreams <http://www.jabber.org/jeps/jep-0065.html>." > +Out-of-Band Data JEP-0066: Out of Band Data <http://www.jabber.org/jeps/jep-0066.html>." > +Stock Data Transmission JEP-0067: Stock Data Transmission <http://www.jabber.org/jeps/jep-0067.html>." > +Field Standardization for Data Forms JEP-0068: Field Data Standardization for Data Forms <http://www.jabber.org/jeps/jep-0068.html>." > +Compliance JIG JEP-0069: Compliance JIG <http://www.jabber.org/jeps/jep-0069.html>." > +Verifying HTTP Requests via XMPP JEP-0070: Verifying HTTP Requests via XMPP <http://www.jabber.org/jeps/jep-0070.html>." > +XHTML-IM JEP-0071: XHTML-IM <http://www.jabber.org/jeps/jep-0071.html>." > +SOAP over XMPP JEP-0072: SOAP over XMPP <http://www.jabber.org/jeps/jep-0072.html>." > +Basic IM Protocol Suite JEP-0073: Basic IM Protocol Suite <http://www.jabber.org/jeps/jep-0073.html>." > +Simple Access Control JEP-0074: Simple Access Control <http://www.jabber.org/jeps/jep-0074.html>." > +Jabber Object Access Protocol JEP-0075: Jabber Object Access Protocol <http://www.jabber.org/jeps/jep-0075.html>." > +Malicious Stanzas JEP-0076: Malicious Stanzas <http://www.jabber.org/jeps/jep-0076.html>." > +In-Band Registration JEP-0077: In-Band Registration <http://www.jabber.org/jeps/jep-0077.html>." > +Non-SASL Authentication JEP-0078: Non-SASL Authentication <http://www.jabber.org/jeps/jep-0078.html>." > +Advanced Message Processing JEP-0079: Advanced Message Processing <http://www.jabber.org/jeps/jep-0079.html>." > +User Geolocation JEP-0080: User Geolocation <http://www.jabber.org/jeps/jep-0080.html>." > +Jabber MIME Type JEP-0081: Jabber MIME Type <http://www.jabber.org/jeps/jep-0081.html>." > +Jabber Date and Time Profiles JEP-0082: Jabber Date and Time Profiles <http://www.jabber.org/jeps/jep-0082.html>." > +Nested Roster Groups JEP-0083: Nested Roster Groups <http://www.jabber.org/jeps/jep-0083.html>." > +User Avatar JEP-0084: User Avatar <http://www.jabber.org/jeps/jep-0084.html>." > +Chat State Notifications JEP-0085: Chat State Notifications <http://www.jabber.org/jeps/jep-0085.html>." > +Error Condition Mappings JEP-0086: Error Condition Mappings <http://www.jabber.org/jeps/jep-0086.html>." > +Stream Initiation JEP-0087: Stream Initiation <http://www.jabber.org/jeps/jep-0087.html>." > +Client Webtabs JEP-0088: Client Webtabs <http://www.jabber.org/jeps/jep-0088.html>." > +Generic Alerts JEP-0089: Generic Alerts <http://www.jabber.org/jeps/jep-0089.html>." > +Entity Time JEP-0090: Entity Time <http://www.jabber.org/jeps/jep-0090.html>." > +Delayed Delivery JEP-0091: Delayed Delivery <http://www.jabber.org/jeps/jep-0091.html>." > +Software Version JEP-0092: Software Version <http://www.jabber.org/jeps/jep-0092.html>." > +Roster Item Exchange JEP-0093: Roster Item Exchange <http://www.jabber.org/jeps/jep-0093.html>." > +Agent Information JEP-0094: Agent Information <http://www.jabber.org/jeps/jep-0094.html>." > +Stream Initiation JEP-0095: Stream Initiation <http://www.jabber.org/jeps/jep-0095.html>." > +File Transfer JEP-0096: File Transfer <http://www.jabber.org/jeps/jep-0096.html>." > +iCal Envelope JEP-0097: iCal Envelope <http://www.jabber.org/jeps/jep-0097.html>." > +Enchanced Private XML Storage JEP-0098: Enchanced Private XML Storage <http://www.jabber.org/jeps/jep-0098.html>." > +IQ Query Action Protocol JEP-0099: IQ Query Action Protocol <http://www.jabber.org/jeps/jep-0099.html>." > +Gateway Interaction JEP-0100: Gateway Interaction <http://www.jabber.org/jeps/jep-0100.html>." > +HTTP Authentication using Jabber Tickets JEP-0101: HTTP Authentication using Jabber Tickets <http://www.jabber.org/jeps/jep-0101.html>." > +Security Extensions JEP-0102: Security Extensions <http://www.jabber.org/jeps/jep-0102.html>." > +URL Address Information JEP-0103: URL Address Information <http://www.jabber.org/jeps/jep-0103.html>." > +HTTP Scheme for URL Data JEP-0104: HTTP Scheme for URL Data <http://www.jabber.org/jeps/jep-0104.html>." > +Tree Transfer Stream Initiation Profile JEP-0105: Tree Transfer Stream Initiation Profile <http://www.jabber.org/jeps/jep-0105.html>." > +JID Escaping JEP-0106: JID Escaping <http://www.jabber.org/jeps/jep-0106.html>." > +User Mood JEP-0107: User Mood <http://www.jabber.org/jeps/jep-0107.html>." > +User Activity JEP-0108: User Activity <http://www.jabber.org/jeps/jep-0108.html>." > +Vacation Messages JEP-0109: Vacation Messages <http://www.jabber.org/jeps/jep-0109.html>." > +Generic Maps JEP-0110: Generic Maps <http://www.jabber.org/jeps/jep-0110.html>." > +A Transport for Initiating and Negotiating Sessions JEP-0111: A Transport for Initiating and Negotiating Sessions <http://www.jabber.org/jeps/jep-0111.html>." > +User Physical Location JEP-0112: User Physical Location <http://www.jabber.org/jeps/jep-0112.html>." > +Simple Whiteboarding JEP-0113: Simple Whiteboarding <http://www.jabber.org/jeps/jep-0113.html>." > +Jabber Component Protocol JEP-0114: Jabber Component Protocol <http://www.jabber.org/jeps/jep-0114.html>." > +Entity Capabilities JEP-0115: Entity Capabilities <http://www.jabber.org/jeps/jep-0115.html>." > +Encrypted Sessions JEP-0116: Encrypted Sessions <http://www.jabber.org/jeps/jep-0116.html>." > +Intermediate IM Protocol Suite JEP-0117: Intermediate IM Protocol Suite <http://www.jabber.org/jeps/jep-0117.html>." > +User Tune JEP-0118: User Tune <http://www.jabber.org/jeps/jep-0118.html>." > +Extended Presence Protocol Suite JEP-0119: Extended Presence Protocol Suite <http://www.jabber.org/jeps/jep-0119.html>." > +Infobits JEP-0120: Infobits <http://www.jabber.org/jeps/jep-0120.html>." > +Dublin Core Infobits Mapping JEP-0121: Dublin Core Infobits Mapping <http://www.jabber.org/jeps/jep-0121.html>." > +Data Forms Validation JEP-0122: Data Forms Validation <http://www.jabber.org/jeps/jep-0122.html>." > +Entity Metadata JEP-0123: Entity Metadata <http://www.jabber.org/jeps/jep-0123.html>." > +HTTP Binding JEP-0124: HTTP Binding <http://www.jabber.org/jeps/jep-0124.html>." > +vCard Infobits Mapping JEP-0125: vCard Infobits Mapping <http://www.jabber.org/jeps/jep-0125.html>." > +Invisibility JEP-0126: Invisibility <http://www.jabber.org/jeps/jep-0126.html>." > +Common Alerting Protocol (CAP) over XMPP JEP-0127: Common Alerting Protocol (CAP) over XMPP <http://www.jabber.org/jeps/jep-0127.html>." > +Service Discovery Extensions JEP-0128: Service Discovery Extensions <http://www.jabber.org/jeps/jep-0128.html>." > +WebDAV File Transfers JEP-0129: WebDAV File Transfers <http://www.jabber.org/jeps/jep-0129.html>." > +Waiting Lists JEP-0130: Waiting Lists <http://www.jabber.org/jeps/jep-0130.html>." > +Stanza Headers and Internet Metadata JEP-0131: Stanza Headers and Internet Metadata <http://www.jabber.org/jeps/jep-0131.html>." > +Presence Obtained via Kinesthetic Excitation (POKE) JEP-0132: Presence Obtained via Kinesthetic Excitation (POKE) <http://www.jabber.org/jeps/jep-0132.html>." > +Service Administration JEP-0133: Service Administration <http://www.jabber.org/jeps/jep-0133.html>." > +Protocol Design Guidelines JEP-0134: Protocol Design Guidelines <http://www.jabber.org/jeps/jep-0134.html>." > +File Sharing JEP-0135: File Sharing <http://www.jabber.org/jeps/jep-0135.html>." > +Message Archiving JEP-0136: Message Archiving <http://www.jabber.org/jeps/jep-0136.html>." > +Publishing Stream Initiation Requests JEP-0137: Publishing Stream Initiation Requests <http://www.jabber.org/jeps/jep-0137.html>." > +Stream Compression JEP-0138: Stream Compression <http://www.jabber.org/jeps/jep-0138.html>." > +Security JIG JEP-0139: Security JIG <http://www.jabber.org/jeps/jep-0139.html>." > +Shared Groups JEP-0140: Shared Groups <http://www.jabber.org/jeps/jep-0140.html>." > +Data Forms Layout JEP-0141: Data Forms Layout <http://www.jabber.org/jeps/jep-0141.html>." > +Workgroup Queues JEP-0142: Workgroup Queues <http://www.jabber.org/jeps/jep-0142.html>." > +Guidelines for JEP Authors JEP-0143: Guidelines for JEP Authors <http://www.jabber.org/jeps/jep-0143.html>." > +Roster Item Exchange JEP-0144: Roster Item Exchange <http://www.jabber.org/jeps/jep-0144.html>." > +Annotations JEP-0145: Annotations <http://www.jabber.org/jeps/jep-0145.html>." > +Remote Controlling Clients JEP-0146: Remote Controlling Clients <http://www.jabber.org/jeps/jep-0146.html>." > +XMPP URI Query Components JEP-0147: XMPP URI Query Components <http://www.jabber.org/jeps/jep-0147.html>." > +Instant Messaging Intelligence Quotient (IM IQ) JEP-0148: Instant Messaging Intelligence Quotient (IM IQ) <http://www.jabber.org/jeps/jep-0148.html>." > +Time Periods JEP-0149: Time Periods <http://www.jabber.org/jeps/jep-0149.html>." > +Use of Entity Tags in XMPP Extensions JEP-0150: Use of Entity Tags in XMPP Extensions <http://www.jabber.org/jeps/jep-0150.html>." > +Virtual Presence JEP-0151: Virtual Presence <http://www.jabber.org/jeps/jep-0151.html>." > +Reachability Addresses JEP-0152: Reachability Addresses <http://www.jabber.org/jeps/jep-0152.html>." > +vCard-Based Avatars JEP-0153: vCard-Based Avatars <http://www.jabber.org/jeps/jep-0153.html>." > +User Profile JEP-0154: User Profile <http://www.jabber.org/jeps/jep-0154.html>." > +Chat Session Negotiation JEP-0155: Chat Session Negotiation <http://www.jabber.org/jeps/jep-0155.html>." > +A DNS TXT Resource Record Format for XMPP Connection Methods JEP-0156: A DNS TXT Resource Record Format for XMPP Connection Methods <http://www.jabber.org/jeps/jep-0156.html>." > +Contact Addresses for XMPP Services JEP-0157: Contact Addresses for XMPP Services <http://www.jabber.org/jeps/jep-0157.html>." > +Robot Challenges JEP-0158: Robot Challenges <http://www.jabber.org/jeps/jep-0158.html>." > +SPIM-Blocking Control JEP-0159: SPIM-Blocking Control <http://www.jabber.org/jeps/jep-0159.html>." > +Best Practices for Handling Offline Messages JEP-0160: Best Practices for Handling Offline Messages <http://www.jabber.org/jeps/jep-0160.html>." > +SPIM Reporting JEP-0161: SPIM Reporting <http://www.jabber.org/jeps/jep-0161.html>." > +Best Practices for Roster and Subscription Management JEP-0162: Best Practices for Roster and Subscription Management <http://www.jabber.org/jeps/jep-0162.html>." > +Personal Eventing via Pubsub JEP-0163: Personal Eventing via Pubsub <http://www.jabber.org/jeps/jep-0163.html>." > +vCard Filtering JEP-0164: vCard Filtering <http://www.jabber.org/jeps/jep-0164.html>." > +Prevention of JID Spoofing JEP-0165: Prevention of JID Spoofing <http://www.jabber.org/jeps/jep-0165.html>." > +Jingle JEP-0166: Jingle <http://www.jabber.org/jeps/jep-0166.html>." > +Jingle Audio Content Description Format JEP-0167: Jingle Audio Content Description Format <http://www.jabber.org/jeps/jep-0167.html>." > +Resource Application Priority JEP-0168: Resource Application Priority <http://www.jabber.org/jeps/jep-0168.html>." > +Twas The Night Before Christmas (Jabber Version) JEP-0169: Twas The Night Before Christmas (Jabber Version) <http://www.jabber.org/jeps/jep-0169.html>." > +Recommended Order of Stream Feature Negotiation JEP-0170: Recommended Order of Stream Feature Negotiation <http://www.jabber.org/jeps/jep-0170.html>." > +Language Translation JEP-0171: Language Translation <http://www.jabber.org/jeps/jep-0171.html>." > +User Nickname JEP-0172: User Nickname <http://www.jabber.org/jeps/jep-0172.html>." > +Pubsub Subscription Storage JEP-0173: Pubsub Subscription Storage <http://www.jabber.org/jeps/jep-0173.html>." > +Link-Local Messaging JEP-0174: Link-Local Messaging <http://www.jabber.org/jeps/jep-0174.html>." > +Best Practices for Use of SASL ANONYMOUS JEP-0175: Best Practices for Use of SASL ANONYMOUS <http://www.jabber.org/jeps/jep-0175.html>." > +Jingle RTP-ICE Transport Method JEP-0176: Jingle RTP-ICE Transport Method <http://www.jabber.org/jeps/jep-0176.html>." > +Jingle Raw UDP Transport Method JEP-0177: Jingle Raw UDP Transport Method <http://www.jabber.org/jeps/jep-0177.html>." > +Best Practices for Use of SASL EXTERNAL JEP-0178: Best Practices for Use of SASL EXTERNAL <http://www.jabber.org/jeps/jep-0178.html>." > +Jingle IAX Transport Method JEP-0179: Jingle IAX Transport Method <http://www.jabber.org/jeps/jep-0179.html>." > +Jingle Video Content Description Format JEP-0180: Jingle Video Content Description Format <http://www.jabber.org/jeps/jep-0180.html>." > +Jingle DTMF JEP-0181: Jingle DTMF <http://www.jabber.org/jeps/jep-0181.html>." > +Application-Specific Error Conditions JEP-0182: Application-Specific Error Conditions <http://www.jabber.org/jeps/jep-0182.html>." > +Jingle Telepathy Transport Method JEP-0183: Jingle Telepathy Transport Method <http://www.jabber.org/jeps/jep-0183.html>." > +Message Receipts JEP-0184: Message Receipts <http://www.jabber.org/jeps/jep-0184.html>." > +Dialback Key Generation and Validation JEP-0185: Dialback Key Generation and Validation <http://www.jabber.org/jeps/jep-0185.html>." > +Invisible Command JEP-0186: Invisible Command <http://www.jabber.org/jeps/jep-0186.html>." > +Offline Encrypted Sessions JEP-0187: Offline Encrypted Sessions <http://www.jabber.org/jeps/jep-0187.html>." > +Cryptographic Design of Encrypted Sessions JEP-0188: Cryptographic Design of Encrypted Sessions <http://www.jabber.org/jeps/jep-0188.html>." > +Public Key Publishing JEP-0189: Public Key Publishing <http://www.jabber.org/jeps/jep-0189.html>." > +Best Practice for Closing Idle Streams JEP-0190: Best Practice for Closing Idle Streams <http://www.jabber.org/jeps/jep-0190.html>." > +Simple Communications Blocking JEP-0191: Simple Communications Blocking <http://www.jabber.org/jeps/jep-0191.html>." > +Proposed Stream Feature Improvements JEP-0192: Proposed Stream Feature Improvements <http://www.jabber.org/jeps/jep-0192.html>." > +Proposed Resource Binding Improvements JEP-0193: Proposed Resource Binding Improvements <http://www.jabber.org/jeps/jep-0193.html>." > +User Chatting JEP-0194: User Chatting <http://www.jabber.org/jeps/jep-0194.html>." > +User Browsing JEP-0195: User Browsing <http://www.jabber.org/jeps/jep-0195.html>." > +User Gaming JEP-0196: User Gaming <http://www.jabber.org/jeps/jep-0196.html>." > +User Viewing JEP-0197: User Viewing <http://www.jabber.org/jeps/jep-0197.html>." > diff --git a/xep.xsd b/xep.xsd new file mode 100644 index 00000000..6865ef1a --- /dev/null +++ b/xep.xsd @@ -0,0 +1,355 @@ + + + + + + + + + This schema defines the document format for Jabber Enhancement + Proposals (JEPs). For further information about JEPs, visit: + + http://www.jabber.org/jeps/ + + The canonical URL for this schema is: + + http://www.jabber.org/jeps/jep.xsd + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/xep.xsl b/xep.xsl new file mode 100644 index 00000000..f95391ba --- /dev/null +++ b/xep.xsl @@ -0,0 +1,844 @@ + + + + + + + + + + + JEP-<xsl:value-of select='/jep/header/number'/>:<xsl:text> </xsl:text><xsl:value-of select='/jep/header/title' /> + + + + + DC.Title + + + + + DC.Description + + + + DC.Publisher + Jabber Software Foundation + + + DC.Contributor + JEP Editor + + + DC.Date + + + + DC.Type + Jabber Enhancement Proposal + + + DC.Format + XHTML + + + DC.Identifier + JEP- + + + DC.Language + en + + + DC.Rights + + + + + + +

JEP-:

+ +

+ +

+ + + +

NOTICE: This Historical JEP provides canonical documentation of a protocol that is in use within the Jabber/XMPP community. This JEP is not a standards-track specification within the Jabber Software Foundation's standards process; however, it may be converted to standards-track in the future or may be obsoleted by a more modern protocol.

+ + +

NOTICE: This JEP is Humorous. It MAY provide amusement but SHOULD NOT be taken seriously.

+ + +

NOTICE: This Informational JEP defines a best practice or protocol profile that has been approved by the Jabber Council and/or the JSF Board of Directors. Implementations are encouraged and the best practice or protocol profile is appropriate for deployment in production systems.

+ + +

NOTICE: This Procedural JEP defines a process or activity of the Jabber Software Foundation (JSF) that has been approved by the Jabber Council and/or the JSF Board of Directors. The JSF is currently following the process or activity defined herein and will do so until this JEP is deprecated or obsoleted.

+ + +

WARNING: Consideration of this JEP has been Deferred by the Jabber Software Foundation. Implementation of the protocol described herein is not recommended.

+ + +

WARNING: This JEP has been deprecated by the Jabber Software Foundation. Implementation of the protocol described herein is not recommended. Developers desiring similar functionality should implement the protocol that supersedes this one (if any).

+ + +

NOTICE: The protocol defined herein is a Draft Standard of the Jabber Software 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.

+ + +

NOTICE: This Historical JEP attempts to provide canonical documentation of a protocol that is in use within the Jabber/XMPP community. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. This JEP is not a standards-track specification within the Jabber Software Foundation's standards process; however, it may be converted to standards-track in the future or may be obsoleted by a more modern protocol.

+ + +

WARNING: This Informational JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the best practice or protocol profile described herein is encouraged in exploratory implementations, although production systems should not deploy implementations of this protocol until it advances to a status of Draft.

+ + +

NOTICE: This Procedural JEP proposes that the process or activity defined herein shall be followed by the Jabber Software Foundation (JSF). However, this process or activity has not yet been approved by the Jabber Council and/or the JSF Board of Directors and is therefore not currently in force.

+ + +

WARNING: This Standards-Track JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.

+ + +

NOTICE: The protocol defined herein is a Final Standard of the Jabber Software Foundation and may be considered a stable technology for implementation and deployment.

+ + +

WARNING: This JEP has been obsoleted by the Jabber Software Foundation. Implementation of the protocol described herein is not recommended. Developers desiring similar functionality should implement the protocol that supersedes this one (if any).

+ + +

NOTICE: This JEP is currently within Last Call or under consideration by the Jabber Council for advancement to the next stage in the JSF standards process.

+ + +

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the Jabber Software Foundation, and this document must not be referred to as a Jabber Enhancement Proposal (JEP). If this document is accepted as a JEP by the Jabber Council, it will be published at <http://www.jabber.org/jeps/> and announced on the <standards-jig@jabber.org> mailing list.

+ + +

WARNING: This JEP has been Rejected by the Jabber Council. Implementation of the protocol described herein is not recommended under any circumstances.

+ + +

WARNING: This JEP has been retracted by the author(s). Implementation of the protocol described herein is not recommended. Developers desiring similar functionality should implement the protocol that supersedes this one (if any).

+ +

+ +

JEP Information

+

+ Status: + + http://www.jabber.org/jeps/jep-0001.html#states- + + +
+ Type: + + http://www.jabber.org/jeps/jep-0001.html#types- + + +
+ Number:
+ Version:
+ Last Updated:
+ + + Expires:
+ + JIG:
+ + + + Approving Body: JSF Board of Directors
+ + + Approving Body: Jabber Council
+ + + + + + Dependencies: + + + +
+ + + Dependencies: None
+ + + + + + Supersedes: + + + +
+ + + Supersedes: None
+ + + + + + Superseded By: + + + +
+ + + Superseded By: None
+ + + Short Name:
+ + + + + + + Registry: + + http://www.jabber.org/registrar/ + + .html + + <> +
+ + + http://wiki.jabber.org/index.php/ + + (JEP- + + ) + + + Wiki Page: <> + +

+ +

Author Information

+
+ +
+ + + +

Discussion Venue

+ + + +

The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.

+

Discussion by the membership of the JSF may also be appropriate (see <http://mail.jabber.org/mailman/listinfo/members> for details).

+ + +

The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.

+ +

Given that this JEP normatively references IETF technologies, discussion on the JSF-IETF list may also be appropriate (see <http://mail.jabber.org/mailman/listinfo/jsf-ietf> for details).

+ + + + + + +

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 Jabber Software 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 JEP 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.

+

Conformance Terms

+

The following 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".

+ + +

+ + +

+ + +

+

Notes

+
+ +
+ +

+

Revision History

+
+ +
+

+

END

+ + + + + + + + + + + + + + + + + + +

Table of Contents

+
+
+ +
Notes
+
Revision History
+
+
+ + + + + DC.Creator + + + + + +

+

+ + + + + + See Author Note
+ + + Organization:
+ + + Email: + + + mailto: + + + + +
+ + + JID: + + + xmpp: + + + + + +

+ + + +

Legal Notice

+

+ + + + + + + + , + + + + + + + + + + + + + XML Schema for namespace: <>
+ + + Schema: <>
+ + + + + +

Version ()

+
+ + () +
+ + + + + + + + + + + . + + +
+ + + + # + + + + + + sect- + + + + + + +
+ +
+ + + +
+ + + + + + + + + + +

+ . + + + + + + + + + sect- + + + + + +

+ + + + + + + + + + + + + . + + +
+ + + + # + + + + + + sect- + + + + + +
+ +
+ + + +
+ + + + + + + + + + +
+

+ . + + + + + + + + + sect- + + + + + +

+ +
+ + + + + + + + + + + + . + + +
+ + + + # + + + + + + sect- + + + + + +
+ +
+ + + +
+ + + + + + + + + + +
+

+ .. + + + + + + + + + sect- + + + + + +

+ +
+ + + + + + + + + + + + . + +
+ + + + # + + + + + + sect- + + + + + +
+ + + + + + + + + +
+

+ ... + + + + + + + + + sect- + + + + + +

+ +
+ + + + + + + +

+ + + + + + + + + +

+ + + +
    + + + + + + + + + +
+ + + +
    + + + + + + + + + + + + + + + + + +
+ + + +
  • + + + + + + + + + +
    • +     + + + + + + + + + +

    Example .

    +
    +
    +
    +     + + +

    +
    +
    +
    +     + + +
    +     + + + + + + + + +

    Table :

    + + +
    +     + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + [ + + ] + + + +

    + + + + + . + +

    +     + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + + + + + + + + + +
    +     + + + + + + + + + + + + + + + + + +