From 5d6f916f9900233385eb0843b01277aa6106440f Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 5 Mar 2008 22:06:46 +0000 Subject: [PATCH] initial version git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1746 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0234.xml | 359 +++++++++++++++++++++++++++++++++++++++++++++++++++ xep-0235.xml | 142 ++++++++++++++++++++ xep-0236.xml | 342 ++++++++++++++++++++++++++++++++++++++++++++++++ xep-0237.xml | 213 ++++++++++++++++++++++++++++++ 4 files changed, 1056 insertions(+) create mode 100644 xep-0234.xml create mode 100644 xep-0235.xml create mode 100644 xep-0236.xml create mode 100644 xep-0237.xml diff --git a/xep-0234.xml b/xep-0234.xml new file mode 100644 index 00000000..7c50059b --- /dev/null +++ b/xep-0234.xml @@ -0,0 +1,359 @@ + + +%ents; +]> + + +
+ Jingle File Transfer + This specification defines a Jingle application type for transferring files between two entities. The protocol provides a modular framework that enables the exchange of information about the file to be transferred as well as the negotiation of parameters such as the transport to be used. + &LEGALNOTICE; + 0234 + Experimental + Standards Track + Standards + + XMPP Core + XEP-0096 + XEP-0166 + + + + NOT YET ASSIGNED + &stpeter; + + 0.1 + 2008-03-05 + psa +

Initial published version.

+
+ + 0.0.3 + 2008-02-29 + psa +

Corrected use of content-replace action; specified that the In-Band Bytestreams transport method is mandatory-to-implement but must have the lowest preference order.

+
+ + 0.0.2 + 2008-02-28 + psa + Modified negotiation flow to use new content-replace action. + + + 0.0.1 + 2008-01-29 + psa + First draft. + +
+ + +

&xep0096; defines the current XMPP protocol extension for file transfer. However, that protocol has several drawbacks, most related to the &xep0095; protocol on which it depends:

+
    +
  1. It does not enable a true, bidirectional negotiation; instead, the initiator sets the terms for the file transfer and the receiver either accepts the terms or cancels the negotiation.
  2. +
  3. It is the only technology in the Jabber/XMPP protocol "stack" that uses XEP-095: Stream Initiation. More modern technologies such as voice and video session negotiation use &xep0166;, and it would be helpful if implementors could use the same code for all negotiation use cases.
  4. +
+

To overcome these drawbacks, this specification defines a file transfer negotiation method that meets the following requirements:

+
    +
  • Reuse the session negotiation semantics from XEP-0166.
  • +
  • Reuse the file description format from XEP-0096.
  • +
  • Define a clear upgrade path from XEP-0096 to this specification.
  • +
+
+ + +

This section provides a friendly introduction to Jingle file transfer.

+

First, the party that wishes to initiate the file transfer determines the receiver's capabilities (via &xep0030; or &xep0115;). In this example, we assume that the receiver supports the following service discovery features (note: these features may not reflect final namespace assignments):

+
    +
  • urn:xmpp:tmp:jingle
  • +
  • urn:xmpp:tmp:jingle:apps:file-transfer
  • +
  • urn:xmpp:tmp:jingle:transports:bytestreams
  • +
  • urn:xmpp:tmp:jingle:transports:ibb
  • +
+

The initiator then sends a Jingle session-initiation request to a potential receiver. The content-type of the request specifies two things:

+
    +
  1. An application type of "urn:xmpp:tmp:jingle:apps:file-transfer" &NSNOTE;. In particular, the <description/> element contains an <offer/> or <request/> element that in turn contains a <file/> element qualified by the existing 'http://jabber.org/protocol/si/profile/file-transfer' namespace from XEP-0096.
  2. +
  3. An appropriate transport method. Because the existing transport methods used in XEP-0096 (i.e., &xep0065; and &xep0047;) are not yet defined as Jingle transport methods, this specification registers those definitions.
  4. +
+

In this example, the initiation request specifies a file offer and a transport method of bytestreams (i.e., XEP-065).

+ + + + + + + This is a test. If this were a real file... + + + + + + + + ]]> +

The responder immediately acknowledges receipt of the session-initiate.

+ + ]]> +

The parties would then attempt to negotiate use of the SOCKS5 Bytestreams transport method, as described in XEP-0065.

+

More detailed scenarios follow.

+
+ + + +

Currently, XEP-0096 does not enable the parties to fall back to a second method (e.g., In-Band Bytestreams) if the first method tried (e.g., SOCKS5 Bytestreams) does not work. This problem is addressed by Jingle. Consider the following protocol flow.

+ + + + + + + This is a test. If this were a real file... + + + + + + + + ]]> +

The responder immediately acknowledges receipt of the session-initiate.

+ + ]]> +

The receiver would then send a session-accept.

+ + + + + + + This is a test. If this were a real file... + + + + + + + + ]]> +

The initiator acknowledges the session-accept action.

+ + ]]> +

Now the parties attempt to negotiate use of SOCKS5 Bytestreams as defined in XEP-0065.

+

However, let us imagine that the SOCKS5 Bytestreams negotiation fails. The initiator or responder can then suggest the use of In-Band Bytestreams by sending a content-replace action. Here we assume that the responder sends a content-replace action including a request for the file originally offered and a transport of IBB.

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

The initiator then acknowledges the content-replace action.

+ + ]]> +

If the content definition is acceptable, the initiator then sends a content-accept action to the responder.

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

The responder then acknowledges the content-accept action.

+ + ]]> +

The parties then attempt to use In-Band Bytestreams.

+
+
+ + + +

All implementations MUST support the In-Band Bytestreams transport method.

+
+ +

An application MAY present transport methods in any order, except that the In-Band Bytestreams method MUST be the lowest preference.

+
+ +

Support for Jingle file transfer can be determined through discovery of the 'urn:xmpp:tmp:jingle:apps:file-transfer' namespace &NSNOTE;, via either service discovery or entity capabilities. If the initiator knows that the receiver supports Jingle file transfer, it SHOULD attempt negotiation using XEP-0166 rather than XEP-0095.

+
+
+ + +

In order to secure the data stream, implementations SHOULD use encryption methods appropriate to the transport method being used. For details, refer to the specifications for those transport methods.

+
+ + +

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

+
+ + + +

Until this specification advances to a status of Draft, its associated namespaces shall be:

+
    +
  • urn:xmpp:tmp:jingle:apps:file-transfer
  • +
+

Upon advancement of this specification, the ®ISTRAR; shall issue permanent namespaces in accordance with the process defined in Section 4 of &xep0053;.

+

The following namespaces are requested, and are thought to be unique per the XMPP Registrar's requirements:

+
    +
  • urn:xmpp:jingle:apps:file-transfer
  • +
+
+ +

The XMPP Registrar shall include "file-transfer" in its registry of Jingle application formats. The registry submission is as follows:

+ + file-transfer + Jingle sessions for the transfer of a file + reliable + XEP-xxxx + + ]]> +
+ +

The XMPP Registrar shall add to its registry of Jingle transport methods definitions for the reliable transport methods defined in XEP-0047 and XEP-0065. The registry submissions are as follows:

+ + bytestreams + A method for exchanging data over SOCKS5 Bytestreams. + reliable + XEP-0065 + + + ibb + A method for exchanging data over In-Band Bytestreams. + reliable + XEP-0047 + + ]]> +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + +
diff --git a/xep-0235.xml b/xep-0235.xml new file mode 100644 index 00000000..0e35cd51 --- /dev/null +++ b/xep-0235.xml @@ -0,0 +1,142 @@ + + +%ents; +]> + + +
+ Direct Invitations + This specification defines an XMPP extension for generating, requesting, and providing invitations, which can be used in the context of Multi-User Chat rooms and other services. + &LEGALNOTICE; + 0235 + Experimental + Standards Track + Standards + Council + + XMPP Core + + + + NOT YET ASSIGNED + &stpeter; + + 0.1 + 2008-03-05 + psa +

Initial published version.

+
+ + 0.0.1 + 2008-02-20 + psa +

First draft.

+
+
+ +

&xep0045; includes a protocol for inviting a contact to a chatroom. That protocol results in the sending of an invitation from the chatroom to the contact (a "mediated invitation"), not from the inviting user to the contact (a "direct invitation"). Because use of &xep0016; may result in blocking of XML stanzas from entities that are not in the contact's roster, mediated invitations may never be delivered to the contact. Therefore, this specification defines an XMPP extension that enables a user to directly send an invitation to a contact, thus routing around the blocking of mediated invitations. While the main use case for this protocol is multi-user chat, nothing in the protocol prevents it from being used to invite contacts to other types of services, such as &xep0060; services or future collaboration services.

+
+ +

In order to obtain an invitation that can be directly sent to a contact, a user requests an invitation token from the relevant service. For example, let us imagine that the user <crone1@shakespeare.lit> wishes to invite the contact <hecate@shakespeare.lit> to the chatroom <darkcave@macbeth.shakespeare.lit>. The user would send the following request to the room &NSNOTE;.

+ + + + ]]> +

If the room supports the direct invitation protocol and the user is allowed to invite contacts to the room, the room returns an invitation token to the user.

+ + + 37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643 + + + ]]> +

The syntax of the invitation is as follows.

+
    +
  • The 'expires' attribute defines a date and time when the invitation expires. Inclusion of this attribute is OPTIONAL. If included, it MUST be a DateTime as specified in &xep0082;.
  • +
  • The 'for' attribute defines the JabberID of the invitee. Inclusion of this attribute is REQUIRED.
  • +
  • The 'jid' attribute defines the JabberID of the service to which the invitee is being invited. Inclusion of this attribute is REQUIRED.
  • +
  • The XML character data of the <invitation/> element is the invitation token itself. The token MAY be generated according to any method deemed appropriate by the service implementation. It is RECOMMENED that the token be the hexadecimal representation of a Keyed-Hash Message Authentication Code (see &nistfips198a;) generated using the SHA256 hashing algorithm (see &nistfips180-2;), as described elsewhere in this document.
  • +
+
+ +

The user can then send the invitation to the contact in an XMPP message stanza:

+ + + 37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643 + + + ]]> +
+ +

The contact then MUST then determine the identity of the service (via &xep0030;) so that it can determine how to use the invitation.

+

In this example, the service is a multi-user chat service. Therefore if the contact wishes to join the designated chatroom, it will include the invitation in its join request.

+ + 37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643 + + + ]]> +

If the invitation is acceptable, the service will then allow the contact to enter the room.

+

Note: Detailed error flows will be added to a future version of this specification.

+
+ +

To follow.

+
+ +

This document requires no interaction with &IANA;.

+
+ + +

Until this specification advances to a status of Draft, its associated namespace shall be "urn:xmpp:tmp:invite"; upon advancement of this specification, the ®ISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.

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

Thanks to Dave Cridland for his suggestions. Aspects of this specification were inspired by &rfc4467;.

+
+
diff --git a/xep-0236.xml b/xep-0236.xml new file mode 100644 index 00000000..6120e530 --- /dev/null +++ b/xep-0236.xml @@ -0,0 +1,342 @@ + + +%ents; +]> + + +
+ Abuse Reporting + This specification defines an XMPP protocol extension for reporting abusive traffic between two XMPP servers. + &LEGALNOTICE; + 0236 + Experimental + Standards Track + Standards + Council + + XMPP Core + XEP-0030 + + + + NOT YET ASSIGNED + &stpeter; + + 0.1 + 2008-03-05 + psa +

Initial published version.

+
+ + 0.0.3 + 2008-02-29 + psa +

Added reason element containing machine-readable conditions and optional human-readable text; added note about forwarding of abuse reports.

+
+ + 0.0.2 + 2008-02-26 + psa +

Limited scope to reporting between two servers; more clearly defined what is abusive; changed protocol to use IQ request-response exchange; limited use of error condition to stream termination.

+
+ + 0.0.1 + 2008-02-19 + psa +

First draft.

+
+
+ + +

Unfortunately, not all XMPP entities are well-behaved. Currently, if an XMPP entity sends abusive stanzas over a server-to-server connection, there is no way for the receiving server to inform the sending server that the sender is generating abusive traffic. In practice, the receiving server may need to terminate the server-to-server connection (again without explicitly informing the sending server about the reason for the termination) rather than continue to accept the abusive traffic.

+

This situation is far from desirable. Therefore, this specification defines three small XMPP protocol functions that can help to improve the reliability of server-to-server connections:

+
    +
  1. A method by which the receiving server can send an abuse report to the sending server, including the JID(s) of the sender(s).
  2. +
  3. An application-specific stanza error condition that can be combined with the standard ¬acceptable; stanza error condition to inform the sending server that a particular XMPP stanza is considered abusive.
  4. +
  5. An application-specific stream error condition that can be combined with the standard &policy; stream error condition to inform the sending server about the reason for termination of an XML stream.
  6. +
+
+ + +

An abuse report MUST be sent in an IQ stanza of type "set" containing an <abuse/> element qualified by the 'urn:xmpp:tmp:abuse' namespace &NSNOTE;. The allowable children of the <abuse/> element are:

+
    +
  • One or more <jid/> elements whose XML character data specifies the JID(s) of the abusive sender(s)
  • +
  • An optional <reason/> element that specifies the reason for the abuse report, via a machine-readable abuse condition defined in this specification, (optionally) human-readable text about the report, and (optionally) an application-specific condition defined outside this specification.
  • +
+

This specification intentionally does not define exactly what constitutes abuse, since "abuse is in the eye of the beholder". However, the following machine-readable conditions are defined as children of the <reason/> element.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ConditionDefinition
<gateway/>Attempting to inappropriately use a gateway on the receiving server (see &xep0100;)
<muc/>Attempting to take over or otherwise abuse &xep0045; rooms on the receiving server
<proxy/>Attempting to inappropriately use a &xep0065; proxy, TURN server, or other proxy on the receiving server
<pubsub/>Attempting to inappropriately use a &xep0060; service on the receiving server
<service/>Attempting to inappropriately use any other kind of service on the receiving server
<spam/>Sending spam (unsolicited bulk messages)
<stanza-too-big/>Sending extremely large stanzas
<too-many-recipients/>Sending messages that contain too many recipients (see &xep0033;)
<too-many-stanzas/>Sending an extremely large number of stanzas
<unacceptable-payload/>Sending messages that contain unacceptable payloads such as malicious executables
<unacceptable-text/>Sending messages that contain unacceptable human-readable text
<undefined-abuse/>The abuse condition is undefined (should be used with an application-specific condition)
+

Note: The foregoing list of conditions is not exhaustive. The list may be augmented or otherwise modified in a future version of this specification as a result of implementation and deployment experience.

+
+ + + +

If an XMPP server receives abusive stanzas over a server-to-server connection, the receiving server SHOULD send an abuse report to the sending server.

+ + + abuser@example.com/foo + + + + + + + + ]]> +
+ +

Upon receiving the abuse report, the sending server MUST proceed as follows.

+ +

If the sending server does not understand the abuse reporting protocol, it MUST return a &unavailable; error to the receiving server.

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

If none of the JIDs contained in the abuse report exist at the sending server, the sending server MUST return an ¬found; error to the receiving server.

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

If the sending server accepts the abuse report for one or more JIDs, it MUST return an IQ stanza of type "result" to the receiving server.

+ + ]]> +

This specification does not define how a sending server shall behave when it receives an abuse report. In general it is expected that the sending server (1) will notify the human administrators of the server in some implementation-specific or deployment-specific fashion, and (2) may use the abuse report in an automated fashion (e.g., as input to a rate-limiting algorithm, reputation system, or decision about temporarily suspending the privileges of the sending entity or entities). In addition, the sending server MAY the report to trusted parties such as third-party reporting services.

+
+
+
+ + +

The receiving server MAY report that a particular stanza is considered abusive. The stanza error condition MUST be ¬acceptable; and the error stanza MUST include an application-specific error condition of <abuse/> qualified by the 'urn:xmpp:tmp:abuse' &NSNOTE;. The <abuse/> element MUST include one or more <jid/> elements whose XML character data specifies the JID(s) of the abusive sender(s).

+ + [ ... some abusive payload here ... ] + + ]]> + + + + + + abuser@example.com/foo + + + + + + + + ]]> +
+ + +

If the sending entity continues to generate abusive stanzas via the sending server, the receiving server MAY close the stream between the receiving server and the sending server. The stream error condition MUST be &policy; and the stream error MUST include an application-specific error condition of <abuse/> qualified by the 'urn:xmpp:tmp:abuse'. The <abuse/> element MUST include one or more <jid/> elements whose XML character data specifies the JID(s) of the abusive sender(s).

+ + + + abuser@example.com/foo + + + + + + + + + ]]> +

The receiving entity then SHOULD terminate the TCP connection between the receiving server and the sending server.

+
+ + +

If a server supports the abuse reporting protocol, it MUST report that fact by including a service discovery feature of "urn:xmpp:tmp:abuse" &NSNOTE; in response to a &xep0030; information request:

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

It is possible for an abusive sender to launch a denial of service attack against legitimate users of the sending server by generating abusive traffic over the server-to-server connection (in fact such attacks have already been observed on XMPP networks). Although use of the abuse reporting protocol does not completely prevent such attacks, it may at least enable sending servers to react to abusive traffic in close to real time, thus helping to "heal" the network when denial of service attacks are launched.

+
+ +

If a malicious entity can inject information into the server-to-server connection, it can falsely send abuse reports to the sending server. Therefore the connection SHOULD be encrypted using Transport Layer Security as specified in &xmppcore;.

+
+
+ + +

This document requires no interaction with &IANA;.

+
+ + + +

Until this specification advances to a status of Draft, its associated namespace shall be "urn:xmpp:tmp:abuse"; upon advancement of this specification, the ®ISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.

+
+ +

The XMPP Registrar shall add <abuse/> to its registry of application-specific error conditions (see &APPERRORS;), where the element is qualified by the 'urn:xmpp:tmp:abuse' namespace &NSNOTE;.

+

The registry submission is as follows:

+ + urn:xmpp:tmp:abuse + abuse + the sending entity has generated traffic that the receiving server considers abusive + XEP-xxxx + + ]]> +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + +
diff --git a/xep-0237.xml b/xep-0237.xml new file mode 100644 index 00000000..9da13677 --- /dev/null +++ b/xep-0237.xml @@ -0,0 +1,213 @@ + + +%ents; +]> + + +
+ Roster Versioning + This specification proposes a modification to the XMPP roster management protocol to support versioning of rosters for more efficient downloading of the roster information. + &LEGALNOTICE; + 0237 + Experimental + Standards Track + Standards + Council + + XMPP Core + XMPP IM + + + + NOT YET ASSIGNED + &stpeter; + + 0.1 + 2008-03-05 + psa +

Initial published version; per Council consensus, removed optionality regarding semantics of the version attribute.

+
+ + 0.0.3 + 2008-03-05 + psa +

Corrected semantics of version attribute (should be a strictly increasing sequence number but may be any unique identifier).

+
+ + 0.0.2 + 2008-03-04 + psa +

Clarified description of roster diff; added diff attribute and specified its use in roster results; specified use of version attribute in roster pushes.

+
+ + 0.0.1 + 2008-03-04 + psa +

First draft.

+
+
+ + &RFC3921BISNOTE; +

RFC 3921 specifies that an XMPP client must retrieve the entire roster on login. However, XMPP rosters can be quite large and often the roster has not changed since it was last retrieved. If the client could cache the roster and retrieve only changes to the roster, the login process could be significantly streamlined, which could be especially valuable over low-bandwidth connections such as those common in mobile environments. This document defines a method for such streamlining, via the concept of roster versioning.

+

Note: This document is provided for discussion purposes in order to improve roster management in XMPP systems. It is not meant to supersede the text in RFC 3921. However, the recommendations in this document may be folded into rfc3921bis.

+
+ +

This document specifies the addition of a 'version' attribute to the &QUERY; element qualified by the 'jabber:iq:roster' namespace, as well as a 'diff' attribute for use in roster results.

+

The value of the 'version' attribute MUST be a non-negative integer representing a strictly increasing sequence number that is increased with any change to the roster (whether or not the client supports this extension) but MAY be a unique identifer that is opaque to the client but understood by the server. In any case, the 'version' attribute contained in roster pushes MUST be unique. A "change to the roster" is any addition, update, or removal of a roster item that would result in a roster push, including changes in subscription states, as described in RFC 3921 or rfc3921bis.

+

The attribute is used as described in the following sections.

+ +

If a server supports roster versioning, it MUST inform the client when returning stream features during the stream setup process, at the latest when informing the client that resource binding is required. This is done by including a <roster-versioning/> element qualified by the 'urn:xmpp:tmp:roster-versioning' namespace &NSNOTE;.

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

If a client supports roster versioning and knows that the server does so, it SHOULD include the 'version' attribute in its request for the roster, set to the last version it has cached.

+ + + + ]]> +

If the client has not yet cached the roster or the cache is lost or corrupted, but the client wishes to bootstrap the use of roster versioning, it SHOULD include the 'version' attribute set to a value of zero (0).

+
+ +

If the roster has not changed since the version enumerated by the client, the server MUST return an empty IQ-result.

+ + ]]> +
+ +

If the roster version has increased since the version enumerated by the client, the server MUST return a &QUERY; element that includes the latest version number.

+

The &QUERY; element SHOULD include the effective "diff" since the roster version enumerated by the client (including the complete roster item with name, group, and subscription state). If the roster result is a diff and not the complete roster, the server MUST include a 'diff' attribute set to a value of "true" or "1" &BOOLEANNOTE;. If the roster result is the complete roster and not a diff, the server SHOULD NOT include the 'diff' attribute (which defaults to "false" or "0").

+ + + + + Servants + + + + ]]> +

The "roster diff" can be understood as follows:

+
    +
  1. Imagine that the client had an active presence session for the entire time between its cached roster version (in this case, 305) and the new roster version (317).
  2. +
  3. During that time, the client would have received roster pushes related to roster versions 306, 307, 308, 309, 310, 311, 312, 313, 314, 315, 316, and 317.
  4. +
  5. However, some of those roster pushes might have contained intermediate updates to the same roster item (e.g., changes in the subscription state for bill@shakespeare.lit from "none" to "to" and from "to" to "both").
  6. +
  7. The roster result would not include all of the intermediate steps, only the final result of all changes applied while the client was in fact offline.
  8. +
+
+ +

When the server sends subsequent roster pushes to the client, it MUST include the updated roster version number.

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

It is possible that caching of the roster (rather than holding it in memory only for the life of the session) could introduce new vulnerabilities. Client implementations should take care to appropriately protect the cached roster information.

+
+ +

This document requires no interaction with &IANA;.

+
+ + +

Until this specification advances to a status of Draft, the associated namespace for its stream feature shall be "urn:xmpp:tmp:roster-versioning"; upon advancement of this specification, the ®ISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.

+
+
+ + +

If this modification to the roster management protocol is added to rfc3921bis and approved by the IESG in the speficiation that supersedes RFC 3921, the schema for the roster management namespace would be changed as follows.

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

Thanks to Dave Cridland, Richard Dobson, Alexander Gnauck, and Pedro Melo for their comments.

+
+