From 716f9d91176a10a324263cc2b8b80d1e92411160 Mon Sep 17 00:00:00 2001 From: stpeter Date: Tue, 12 Apr 2011 08:37:30 -0600 Subject: [PATCH] updated RFC references --- xep-0013.xml | 2 +- xep-0016.xml | 14 +- xep-0045.xml | 591 +++++++++++++++++++++++++++++++++------------------ xep-0070.xml | 4 +- xep-0072.xml | 28 +-- xep-0077.xml | 6 +- xep-0078.xml | 22 +- xep-0100.xml | 16 +- xep-0111.xml | 6 +- xep-0124.xml | 8 +- xep-0130.xml | 4 +- xep-0133.xml | 10 +- xep-0150.xml | 4 +- xep-0152.xml | 6 +- xep-0153.xml | 2 +- xep-0156.xml | 8 +- xep-0157.xml | 2 +- xep-0158.xml | 2 +- xep-0159.xml | 2 +- xep-0160.xml | 8 +- xep-0165.xml | 4 +- xep-0168.xml | 2 +- xep-0171.xml | 4 +- xep-0198.xml | 2 +- xep-0199.xml | 16 +- xep-0200.xml | 4 +- xep-0205.xml | 8 +- xep-0211.xml | 9 +- xep-0212.xml | 15 +- xep-0219.xml | 8 +- xep-0233.xml | 4 +- xep-0238.xml | 4 +- xep-0242.xml | 5 +- xep-0243.xml | 5 +- xep-0246.xml | 10 +- xep-0261.xml | 2 +- xep-0270.xml | 15 +- xep-0271.xml | 4 +- xep-0274.xml | 2 +- xep-0279.xml | 2 +- xep-0283.xml | 5 +- xep-0288.xml | 2 +- xep.ent | 3 - 43 files changed, 525 insertions(+), 355 deletions(-) diff --git a/xep-0013.xml b/xep-0013.xml index 04149445..c2a238e9 100644 --- a/xep-0013.xml +++ b/xep-0013.xml @@ -100,7 +100,7 @@ -

Although not required to do so by &rfc3920; and &rfc3921;, many existing Jabber/XMPP instant messaging servers will store messages received while a user is offline and deliver them when the user is next online. Such messages are commonly called "offline messages". The current means of retrieving one's offline messages is simple: one sends available presence to the server and, as a consequence, the server sends a one-time "flood" of all the messages that have been stored while one was offline. This simplification has the following deficiencies:

+

Although not required to do so by &xmppcore; and &xmppim;, many existing Jabber/XMPP instant messaging servers will store messages received while a user is offline and deliver them when the user is next online. Such messages are commonly called "offline messages". The current means of retrieving one's offline messages is simple: one sends available presence to the server and, as a consequence, the server sends a one-time "flood" of all the messages that have been stored while one was offline. This simplification has the following deficiencies:

  1. It can be overwhelming, which is undesirable for the vacationer or heavy user. Many individuals upon returning to work from a weeklong vacation spend the first few hours wading through the dozens, even hundreds, of emails that they received during their absence. Unlucky, however, is this user who then logs onto their Jabber server and is bombarded by hundreds of instant messages, possibly in scores of popup dialogs, simultaneously. Should their client crash, they have lost all communication that occurred while they were away.

  2. It can be difficult to integrate with web-based email clients, which is undesirable for some portals. Several large portals are currently trying to blur the distinction between IM and email -- providing both through one web interface. With offline retrieval semantics so vastly different between the two, this is quite difficult.

    3. diff --git a/xep-0016.xml b/xep-0016.xml index a5de7176..021288bd 100644 --- a/xep-0016.xml +++ b/xep-0016.xml @@ -138,7 +138,7 @@
  3. <domain> (the domain itself matches, as does any user@domain or domain/resource)

If the type is "group", then the 'value' attribute SHOULD contain the name of a group in the user's roster. (If a client attempts to update, create, or delete a list item with a group that is not in the user's roster, the server SHOULD return to the client an <item-not-found/> stanza error.)

-

If the type is "subscription", then the 'value' attribute MUST be one of "both", "to", "from", or "none" as defined RFC 3921, where "none" includes entities that are totally unknown to the user and therefore not in the user's roster at all. These values are exact matches, so that "both" means a bidirectional subscription (not "from" or "to" only).

+

If the type is "subscription", then the 'value' attribute MUST be one of "both", "to", "from", or "none" as defined RFC 6121, where "none" includes entities that are totally unknown to the user and therefore not in the user's roster at all. These values are exact matches, so that "both" means a bidirectional subscription (not "from" or "to" only).

If no 'type' attribute is included, the rule provides the "fall-through" case.

The 'action' attribute MUST be included and its value MUST be either "allow" or "deny". An implementation MUST NOT block communications from one of a user's resources to another, even if the user happens to define a rule that would otherwise result in that behavior.

The 'order' attribute MUST be included and its value MUST be a non-negative integer that is unique among all items in the list. (If a client attempts to create or update a list with non-unique order values, the server MUST return to the client a <bad-request/> stanza error.)

@@ -157,8 +157,8 @@

  1. If there is an active list set for a session, it affects only the session(s) for which it is activated, and only for the duration of the session(s); the server MUST apply the active list only and MUST NOT apply the default list (i.e., there is no "layering" of lists).

  2. The default list applies to the user as a whole, and is processed if there is no active list set for the target session/resource to which a stanza is addressed, or if there are no current sessions for the user.

    3. -

  3. If there is no active list set for a session (or there are no current sessions for the user), and there is no default list, then all stanzas SHOULD BE accepted or appropriately processed by the server on behalf of the user in accordance with the server rules for handling XML stanzas defined in RFC 3921.

    4. -

  4. Privacy lists MUST be the first delivery rule applied by a server, superseding (1) the routing and delivery rules specified in server rules for handling XML stanzas defined in RFC 3921 and (2) the handling of subscription-related presence stanzas (and corresponding generation of roster pushes) specified in RFC 3921.

    5. +

  5. If there is no active list set for a session (or there are no current sessions for the user), and there is no default list, then all stanzas SHOULD BE accepted or appropriately processed by the server on behalf of the user in accordance with the server rules for handling XML stanzas defined in RFC 6121.

    6. +

  6. Privacy lists MUST be the first delivery rule applied by a server, superseding (1) the routing and delivery rules specified in server rules for handling XML stanzas defined in RFC 6121 and (2) the handling of subscription-related presence stanzas (and corresponding generation of roster pushes) specified in RFC 6121.

  7. The order in which privacy list items are processed by the server is important. List items MUST be processed in ascending order determined by the integer values of the 'order' attribute for each <item/>.

  8. As soon as a stanza is matched against a privacy list rule, the server MUST appropriately handle the stanza in accordance with the rule and cease processing.

  9. If no fall-through item is provided in a list, the fall-through action is assumed to be "allow".

    10. @@ -415,7 +415,7 @@ ]]> -

    In accordance with the semantics of IQ stanzas defined in &rfc3920;, each connected resource MUST return an IQ result to the server as well:

    +

    In accordance with the semantics of IQ stanzas defined in &xmppcore;, each connected resource MUST return an IQ result to the server as well:

    ]]>

    As a result of creating and applying the foregoing list, the user will not send presence notifications to any other users.

    -

    Note: When a user blocks outbound presence to a contact, the user's server MUST send unavailable presence information to the contact (but only if the contact is allowed to receive presence notifications from the user in accordance with the rules defined in RFC 3921).

    +

    Note: When a user blocks outbound presence to a contact, the user's server MUST send unavailable presence information to the contact (but only if the contact is allowed to receive presence notifications from the user in accordance with the rules defined in RFC 6121).

    Server-side privacy lists enable a user to block incoming IQ stanzas from other entities based on the entity's JID, roster group, or subscription status (or globally). The following examples illustrate the protocol.

    @@ -743,7 +743,7 @@

    If a blocked entity attempts to send a stanza to the user (i.e., an inbound stanza from the user's perspective), the user's server shall handle the stanza according to the following rules:

    • For presence stanzas (including notifications, subscriptions, and probes), the server MUST NOT respond and MUST NOT return an error.
      • -
    • For message stanzas, the server SHOULD return an error, which SHOULD be &unavailable;. Until version 1.5 of this document (therefore also in RFC 3921), it was recommended to silently ignore message stanzas, which unfortunately resulted in a delivery "black hole" regarding message stanzas.
      • +
    • For message stanzas, the server SHOULD return an error, which SHOULD be &unavailable;. Until version 1.5 of this document (therefore also in RFC 6121), it was recommended to silently ignore message stanzas, which unfortunately resulted in a delivery "black hole" regarding message stanzas.
    • For IQ stanzas of type "get" or "set", the server MUST return an error, which SHOULD be &unavailable;. IQ stanzas of other types MUST be silently dropped by the server.

    If the foregoing suggestions are followed, the user will appear offline to the contact.

    @@ -807,7 +807,7 @@

    A service MAY also filter blocking users out of searches performed on user directories (see, for example, &xep0055;); 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.

    +

    If properly implemented, this protocol extension does not introduce any new security concerns above and beyond those defined in RFC 6120 and RFC 6121.

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

    diff --git a/xep-0045.xml b/xep-0045.xml index 7b6228ab..ce02892f 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -51,8 +51,8 @@ &stpeter; - 1.25rc1 - in progress, last updated 2010-01-21 + 1.25rc2 + in progress, last updated 2011-01-21 psa
      @@ -428,8 +428,9 @@ -

      Traditionally, instant messaging is thought to consist of one-to-one chat rather than many-to-many chat, which is called variously "groupchat" or "text conferencing". Groupchat functionality is familiar from systems such as Internet Relay Chat (IRC) and the chatroom functionality offered by popular consumer IM services. The Jabber/XMPP community developed and implemented a basic groupchat protocol as long ago as 1999. That "groupchat 1.0" protocol provided a minimal feature set for chat rooms but was rather limited in scope. This specification (Multi-User Chat or MUC) builds on the older "groupchat 1.0" protocol in a backwards-compatible manner but provides advanced features such as invitations, room moderation and administration, and specialized room types.

      +

      Traditionally, instant messaging is thought to consist of one-to-one chat rather than many-to-many chat, which is called variously "groupchat" or "text conferencing". Groupchat functionality is familiar from systems such as Internet Relay Chat (IRC) and the chatroom functionality offered by popular consumer IM services. The Jabber/XMPP community developed and implemented a basic groupchat protocol as long ago as 1999. That "groupchat 1.0" (GC) protocol provided a minimal feature set for chat rooms but was rather limited in scope. This specification (Multi-User Chat or MUC) builds on the older GC protocol in a backwards-compatible manner but provides advanced features such as invitations, room moderation and administration, and specialized room types.

       +

      This document addresses common requirements related to configuration of, participation in, and administration of individual text-based conference rooms. All of the requirements addressed herein apply at the level of the individual room and are "common" in the sense that they have been widely discussed within the Jabber community or are familiar from existing text-based conference environments (e.g., Internet Relay Chat as defined in &rfc1459; and its successors: &rfc2810;, &rfc2811;, &rfc2812;, &rfc2813;).

      This document explicitly does not address the following:

      @@ -444,8 +445,9 @@

    This limited scope is not meant to disparage such topics, which are of inherent interest; however, it is meant to focus the discussion in this document and to present a comprehensible protocol that can be implemented by client and component developers alike. Future specifications might address the topics mentioned above.

     + -

    This document addresses the minimal functionality provided by Jabber-based multi-user chat services that existed in 2002 when development of MUC began. For the sake of backwards-compatibility, this document uses the original "groupchat 1.0" protocol for this baseline functionality, with the result that:

    +

    This document addresses the minimal functionality provided by Jabber-based multi-user chat services that existed in 2002 when development of MUC began. For the sake of backwards-compatibility, this document uses the original GC protocol for this baseline functionality, with the result that:

    • Each room is identified as &ROOM; (e.g., <jdev@conference.jabber.org>), where "room" is the name of the room and "service" is the hostname at which the multi-user chat service is running.
    • Each occupant in a room is identified as &ROOMJID;, where "nick" is the room nickname of the occupant as specified on entering the room or subsequently changed during the occupant's visit.
      • @@ -482,6 +484,7 @@

The extensions needed to implement these requirements are qualified by the 'http://jabber.org/protocol/muc' namespace (and the #owner, #admin, and #user fragments on the main namespace URI).

 +
@@ -498,6 +501,7 @@
Member
A user who is on the "whitelist" for a members-only room or who is registered with an open room. A member has an affiliation of "member".
Moderator
A room role that is usually associated with room admins but that may be granted to non-admins; is allowed to kick users, grant and revoke voice, etc. A moderator has a role of "moderator".
MUC
The multi-user chat protocol for text-based conferencing specified in this document.
 +
Multi-Session Nick
If allowed by the service, a user can associate more than one full JID with the same room JID (e.g., the user juliet@capulet.lit is allowed to log in simultaneously as the nick "JuliC" in the characters@chat.shakespeare.lit chatroom from both juliet@capulet.lit/balcony and juliet@capulet.lit/chamber). Multi-session nicks are not currently defined in this document.
Occupant
Any user who is in a room (this is an "abstract class" and does not correspond to any specific role).
Outcast
A user who has been banned from a room. An outcast has an affiliation of "outcast".
Participant
An occupant who does not have administrative privileges; in a moderated room, a participant is further defined as having voice (in contrast to a visitor). A participant has a role of "participant".
 @@ -519,6 +523,7 @@
Voice
In a moderated room, the privilege to send messages to all occupants.
+
Fully-Anonymous Room
A room in which the full JIDs or bare JIDs of occupants cannot be discovered by anyone, including room admins and room owners; such rooms are NOT RECOMMENDED or explicitly supported by MUC, but are possible using this protocol if a service implementation offers the appropriate configuration options; contrast with Non-Anonymous Room and Semi-Anonymous Room.
 @@ -536,6 +541,7 @@
Unsecured Room
A room that anyone is allowed to enter without first providing the correct password; antonym: Password-Protected Room.
+

Most of the examples in this document use the scenario of the witches' meeting held in a dark cave at the beginning of Act IV, Scene I of Shakespeare's Macbeth, represented here as the "coven@chat.shakespeare.lit" chatroom. The characters are as follows:

@@ -561,7 +567,9 @@
+ +

A user might be allowed to perform any number of actions in a room, from joining or sending a message to changing configuration options or destroying the room altogether. We call each permitted action a "privilege". There are two ways we might structure privileges:

    @@ -705,6 +713,49 @@

    ** An implementation MAY grant voice by default to visitors in unmoderated rooms.

    *** A moderator MUST NOT be able to revoke voice privileges from an admin or owner.

    + + +

    The following table summarizes the initial default roles that a service SHOULD set based on the user's affiliation (there is no role associated with the "outcast" affiliation, since such users are not allowed to enter the room).

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Room TypeNoneMemberAdminOwner
    ModeratedVisitorParticipantModeratorModerator
    UnmoderatedParticipantParticipantModeratorModerator
    Members-OnlyN/A *ParticipantModeratorModerator
    OpenParticipantParticipantModeratorModerator
    +

    * Entry is not permitted.

    +     +

    The ways in which an occupant's role changes are well-defined. Sometimes the change results from the occupant's own action (e.g., entering or exiting the room), whereas sometimes the change results from an action taken by a moderator, admin, or owner. If an occupant's role changes, a MUC service implementation MUST change the occupant's role to reflect the change and communicate the change to all occupants (if the room is configured to broadcast presence for a given role). Role changes and their triggering actions are specified in the following table.

    @@ -747,7 +798,9 @@

    * A moderator MUST NOT be able to revoke moderator privileges from an occupant who is equal to or above the moderator in the hierarchy of affiliations.

    Note: Certain roles are typically implicit in certain affiliations. For example, an admin or owner is automatically a moderator, so if an occupant is granted an affiliation of admin then the occupant will by that fact be granted a role of moderator; similarly, when an occupant is granted an affiliation of member in a moderated room, the occupant automatically has a role of participant. However, the loss of the admin affiliation does not necessarily mean that the occupant no longer has a role of moderator (since a "mere" occupant can be a moderator). Therefore, the role that is gained when an occupant is granted a certain affiliation is stable, whereas the role that is lost when an occupant loses a certain affilitation is not hardcoded and is left up to the implementation. Since a client cannot predict what the role will be after revoking a certain affiliation, if it wants to remove both the admin/owner affiliation and the moderator role at the same time then it must specifically request the role change in addition to the affiliation change by including both the 'role' attribute and the 'affiliation' attribute.

    + +

    The following affiliations are defined:

      @@ -866,6 +919,7 @@

      * As a default, an unaffiliated user enters a moderated room as a visitor, and enters an open room as a participant. A member enters a room as a participant. An admin or owner enters a room as a moderator.

      ** An admin or owner MUST NOT be able to revoke moderation privileges from another admin or owner.

      +

      The ways in which a user's affiliation changes are well-defined. Sometimes the change results from the user's own action (e.g., registering as a member of the room), whereas sometimes the change results from an action taken by an admin or owner. If a user's affiliation changes, a MUC service implementation MUST change the user's affiliation to reflect the change and communicate that to all occupants (if the room is configured to broadcast presence for a given role). Affiliation changes and their triggering actions are specified in the following table.

    @@ -919,8 +973,11 @@
    + + +

    A MUC implementation MUST support &xep0030; ("disco"). Any entity can complete the following disco-related use cases.

    @@ -949,6 +1006,7 @@ ]]> +

    The service discovery items ("disco#items") protocol enables an entity to query a service for a list of associated items, which in the case of a chat service would consist of the specific chat rooms hosted by the service.

    ]]>     +

    Using the disco#info protocol, an entity may also query a specific chat room for more detailed information about the room. An entity SHOULD do so before entering a room in order to determine the privacy and security profile of the room configuration (see the Security Considerations for details).

    Some extended room information is dynamically generated (e.g., the URL for discussion logs, which may be based on service-wide configuration), whereas other information is based on the more-stable room configuration, which is why any field defined for the muc#roomconfig FORM_TYPE can be included in the extended service discovery fields (as shown above for the muc#roomconfig_changesubject field).

    Note: The foregoing extended service discovery fields for the 'http://jabber.org/protocol/muc#roominfo' FORM_TYPE are examples only and might be supplemented in the future via the mechanisms described in the Field Standardization section of this document.

     +

    An entity MAY also query a specific chat room for its associated items:

    ]]>     +

    If a non-occupant attempts to send a disco request to an address of the form &ROOMJID;, a MUC service MUST return a &badrequest; error. If an occupant sends such a request, the service MAY pass it through the intended recipient; see the Implementation Guidelines section of this document for details.

     +

    An entity might want to discover if one of the entity's contacts supports the Multi-User Chat protocol (e.g., before attempting to invite the contact to a room). This can be done using Service Discovery.

    If this information is private, the user MUST return an empty &QUERY; element, in accordance with XEP-0030.

     +     +

    The main actor in a multi-user chat environment is the occupant, who can be said to be located "in" a multi-user chat room and to participate in the discussions held in that room (for the purposes of this specification, participants and visitors are considered to be "mere" occupants, since they possess no administrative privileges). As will become clear, the protocol elements proposed in this document to fulfill the occupant use cases fall into three categories:

      -

    1. the basic functionality for joining a room, exchanging messages with all occupants, etc. (supported by the "groupchat 1.0" protocol that preceded MUC)

      2. +

    2. the basic functionality for joining a room, exchanging messages with all occupants, etc. (supported by the GC protocol that preceded MUC)

    3. straightforward additions to the basic functionality, such as handling of errors related to new room types

      4. -

    4. additional protocol elements to handle functionality not covered by "groupchat 1.0" (room invites, room passwords, extended presence related to room roles and affiliations); these are qualified by the 'http://jabber.org/protocol/muc#user' namespace

      5. +

    5. additional protocol elements to handle functionality not covered by GC (room invites, room passwords, extended presence related to room roles and affiliations); these are qualified by the 'http://jabber.org/protocol/muc#user' namespace

    -

    Note: All client-generated examples herein are presented from the perspective of the service, with the result that all stanzas received by a service contain a 'from' attribute corresponding to the sender's full JID as added by a normal XMPP router or session manager. In addition, normal IQ result stanzas sent upon successful completion of a request (as required by &rfc3920;) are not shown.

    +

    Note: All client-generated examples herein are presented from the perspective of the service, with the result that all stanzas received by a service contain a 'from' attribute corresponding to the sender's full JID as added by a normal XMPP router or session manager. In addition, normal IQ result stanzas sent upon successful completion of a request (as required by &xmppcore;) are not shown.

    The order of events involved in joining a room needs to be consistent so that clients can know which events to expect when. After a client sends presence to join a room, the MUC service MUST send it events in the following order:

      @@ -1206,10 +1270,11 @@
    1. Live messages, presence updates, new user joins, etc.
     + -

    In order to participate in the discussions held in a multi-user chat room, a user MUST first become an occupant by entering the room. In the old "groupchat 1.0" protocol, this was done by sending presence to &ROOMJID;, where "room" is the room ID, "service" is the hostname of the chat service, and "nick" is the user's desired nickname within the room:

    - In order to participate in the discussions held in a multi-user chat room, a user MUST first become an occupant by entering the room. In the old GC protocol, this was done by sending presence to &ROOMJID;, where "room" is the room ID, "service" is the hostname of the chat service, and "nick" is the user's desired nickname within the room:

    + @@ -1227,8 +1292,9 @@ ]]>     + -

    Compliant multi-user chat services MUST accept the foregoing as a request to enter a room from any client that knows either the "groupchat 1.0" (GC) protocol or the multi-user chat (MUC) protocol; however, MUC clients SHOULD signal their ability to speak the MUC protocol by including in the initial presence stanza an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace (note the absence of the '#user' fragment):

    +

    Compliant multi-user chat services MUST accept the foregoing as a request to enter a room from any client that knows either the GC protocol or the multi-user chat (MUC) protocol; however, MUC clients SHOULD signal their ability to speak the MUC protocol by including in the initial presence stanza an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace (note the absence of the '#user' fragment):

    ]]>

    Note: If an error occurs in relation to joining a room, the service SHOULD include the MUC child element (i.e., <x xmlns='http://jabber.org/protocol/muc'/>) in the &PRESENCE; stanza of type "error".

    + + + + + + + ]]>

    Before attempting to enter the room, a MUC-compliant client SHOULD first discover its reserved room nickname (if any) by following the protocol defined in the Discovering Reserved Room Nickname section of this document.

     +

    If the service is able to add the user to the room, it MUST send presence from all the existing occupants' room JIDs to the new occupant's full JID, including extended presence information about roles in a single <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "moderator", "participant", or "visitor", and with the 'affiliation' attribute set to a value of "owner", "admin", "member", or "none" as appropriate. The &PRESENCE; element MUST NOT include more than once instance of the &X; qualified by the 'http://jabber.org/protocol/muc#user' namespace.

    ]]>

    In this example, the user from the previous example has entered the room, by which time two other people had already entered the room: a user with a room nickname of "firstwitch" (who is a room owner) and a user with a room nickname of "secondwitch" (who is a room admin).

    -

    The service MUST also send presence from the new occupant's room JID to the full JIDs of all the occupants (including the new occupant).

    +

    Unless the room is configured to not broadcast presence for new occupants below a certain affiliation level as controlled by the 'muc#roomconfig_presencebroadcast' room configuration option, the service MUST also send presence from the new occupant's room JID to the full JIDs of all the occupants (including the new occupant).

    ]]> -

    In this example, initial room presence is being sent from the new occupant (thirdwitch) to all occupants, including the new occupant. As shown in the last stanza, the presence sent by the room to a user from itself as an occupant SHOULD include a status code of 110 so that the user knows this presence refers to itself as an occupant.

    +

    In this example, initial room presence is being sent from the new occupant (thirdwitch) to all occupants, including the new occupant.

    +

    As shown in the last stanza, the "self-presence" sent by the room to the new user MUST include a status code of 110 so that the user knows this presence refers to itself as an occupant. This self-presence MUST NOT be sent to the new occupant until the room has sent the presence of all other occupants to the new occupant; this enables the new occupant to know when it has finished receiving the room roster.

    The service MAY rewrite the new occupant's roomnick (e.g., if roomnicks are locked down). If the service does not accept the new occupant's requested roomnick but instead assigns a new roomnick, it MUST include a status code of "210" in the presence broadcast that it sends to the new occupant.

    ]]>

    Note: The order of the presence stanzas sent to the new occupant is important. The service MUST first send the complete list of the existing occupants to the new occupant and only then send the new occupant's own presence to the new occupant. This helps the client know when it has received the complete "room roster".

    -

    After sending the presence broadcast (and only after doing so), the service may then send discussion history, live messages, presence updates, and other in-room traffic.

    -     - -

    The following table summarizes the initial default roles that a service should set based on the user's affiliation (there is no role associated with the "outcast" affiliation, since such users are not allowed to enter the room).

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Room TypeNoneMemberAdminOwner
    ModeratedVisitorParticipantModeratorModerator
    UnmoderatedParticipantParticipantModeratorModerator
    Members-OnlyN/A *ParticipantModeratorModerator
    OpenParticipantParticipantModeratorModerator
    -

    * Entry is not permitted.

    +

    After sending the presence broadcast (and only after doing so), the service may then send discussion history, the room subject, live messages, presence updates, and other in-room traffic.

     +

    If the room is non-anonymous, the service MUST send the new occupant's full JID to all occupants using extended presence information in an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with a 'jid' attribute specifying the occupant's full JID:

    -

    If the user is entering a room that is non-anonymous (i.e., which informs all occupants of each occupant's full JID as shown above), the service SHOULD allow the user to enter the room but MUST also warn the user that the room is not anonymous. This SHOULD be done by including a status code of "100" in the initial presence that the room sends to the new occupant:

    +

    If the user is entering a room that is non-anonymous (i.e., which informs all occupants of each occupant's full JID as shown above), the service SHOULD allow the user to enter the room but MUST also warn the user that the room is not anonymous. Subject to local security policies, this MUST be done by including a status code of "100" in the initial presence that the room sends to the new occupant:

    - ]]> -

    However, it MAY be done by sending a message of type "groupchat" to the new occupant containing an <x/> child with a <status/> element that has the 'code' attribute set to a value of "100":

    - - This room is not anonymous. - - - - ]]>

    The inclusion of the status code assists clients in presenting their own notification messages (e.g., information appropriate to the user's locality).

     + -

    If the room is semi-anonymous, the service MUST send presence from the new occupant to all occupants as specified above, but MUST include the new occupant's full JID only in the presence notifications it sends to occupants with a role of "moderator" and not to non-moderator occupants.

    +

    If the room is semi-anonymous, the service MUST send presence from the new occupant to all occupants as specified above (i.e., unless the room is configured to not broadcast presence for new occupants below a certain affiliation level as controlled by the 'muc#roomconfig_presencebroadcast' room configuration option), but MUST include the new occupant's full JID only in the presence notifications it sends to occupants with a role of "moderator" and not to non-moderator occupants.

    (Note: All subsequent examples include the 'jid' attribute for each <item/> element, even though this information is not sent to non-moderators in semi-anonymous rooms.)

     +

    If the room requires a password and the user did not supply one (or the password provided is incorrect), the service MUST deny access to the room and inform the user that they are unauthorized; this is done by returning a presence stanza of type "error" specifying a ¬authorized; error:

    ]]>     +

    If the room is members-only but the user is not on the member list, the service MUST deny access to the room and inform the user that they are not allowed to enter the room; this is done by returning a presence stanza of type "error" specifying a ®istration; error condition:

    ]]>     + -

    If the user has been banned from the room (i.e., has an affiliation of "outcast"), the service MUST deny access to the room and inform the user of the fact that he or she is banned; this is done by returning a presence stanza of type "error" specifying a &forbidden; error condition:

    +

    If the user has been banned from the room (i.e., has an affiliation of "outcast"), the service MUST deny access to the room and inform the user of the fact that they are banned; this is done by returning a presence stanza of type "error" specifying a &forbidden; error condition:

    ]]>     +

    If the room already contains another user with the nickname desired by the user seeking to enter the room (or if the nickname is reserved by another user on the member list), the service MUST deny access to the room and inform the user of the conflict; this is done by returning a presence stanza of type "error" specifying a &conflict; error condition:

    ]]> -

    However, if the bare JID &LOCALBARE; of the present occupant matches the bare JID of the user seeking to enter the room, then the service SHOULD allow entry to the user, so that the user has two (or more) in-room "sessions" with the same roomnick, one for each resource. If a service allows more than one occupant with the same bare JID and the same room nickname, it SHOULD route in-room messages to all of the user's resources and allow all of the user's resources to send messages to the room; it is up to the implementation to determine how to appropriately handle presence from the user's resources and how to route private messages to all or only one resource (based on presence priority or some other algorithm).

    +

    However, if the bare JID &LOCALBARE; of the present occupant matches the bare JID of the user seeking to enter the room, then the service SHOULD allow entry to the user, so that the user has two (or more) in-room "sessions" with the same roomnick, one for each resource. If a service allows more than one occupant with the same bare JID and the same room nickname, it MUST route in-room messages to all of the user's resources and allow all of the user's resources to send messages to the room; it is up to the implementation whether to route private messages to all resources or only one resource (based on presence priority or some other algorithm); however, it is RECOMMENDED to route to all resources.

    How nickname conflicts are determined is up to the implementation (e.g., whether the service applies a case folding routine, a stringprep profile such as Resourceprep or Nodeprep, etc.).

     +

    If the room has reached its maximum number of occupants, the service SHOULD deny access to the room and inform the user of the restriction; this is done by returning a presence stanza of type "error" specifying a &unavailable; error condition:

    ]]> -

    Alternatively, the room could kick an "idle user" in order to free up space.

    -

    If the room has reached its maximum number of occupants and a room admin or owner attempts to join, the room SHOULD allow the admin or owner to join, up to some reasonable number of additional occupants, which number MAY be configurable.

    +

    Alternatively, the room could kick an "idle user" in order to free up space (whether the definition of "idle user" is up to the implementation).

    +

    If the room has reached its maximum number of occupants and a room admin or owner attempts to join, the room MUST allow the admin or owner to join, up to some reasonable number of additional occupants.

     +

    If a user attempts to enter a room while it is "locked" (i.e., before the room creator provides an initial configuration and therefore before the room officially exists), the service MUST refuse entry and return an ¬found; error to the user:

    - ]]>     +

    If the room does not already exist when the user seeks to enter it, the service SHOULD create it; however, this is not required, since an implementation or deployment MAY choose to restrict the privilege of creating rooms. For details, see the Creating a Room section of this document.

     + -

    If the user is entering a room in which the discussions are logged to a public archive (often accessible via HTTP), the service SHOULD allow the user to enter the room but MUST also warn the user that the discussions are logged. This SHOULD be done by including a status code of "170" in the initial presence that the room sends to the new occupant:

    +

    If the user is entering a room in which the discussions are logged to a public archive (often accessible via HTTP), the service SHOULD allow the user to enter the room but MUST also warn the user that the discussions are logged. This is done by including a status code of "170" in the initial presence that the room sends to the new occupant:

    ]]>     + -

    After sending initial presence as shown above, a room MAY send discussion history to the new occupant. (The room MUST NOT send any discussion history before it finishes sending room presence as specified in the Presence Broadcast section of this document.) Whether such history is sent, and how many messages comprise the history, shall be determined by the chat service implementation or specific deployment.

    +

    After sending initial presence as shown above, depending on local service policy or room configuration a room MAY send discussion history to the new occupant. (The room MUST NOT send any discussion history before it finishes sending room presence as specified in the Presence Broadcast section of this document.) Whether such history is sent, and how many messages comprise the history, shall be determined by the chat service implementation or specific deployment depending on local service policy or room configuration.

    ]]> -

    Discussion history messages MUST be stamped with &xep0203; information qualified by the 'urn:xmpp:delay' namespace to indicate that they are sent with delayed delivery and to specify the times at which they were originally sent. (Note: The 'urn:xmpp:delay' namespace defined in XEP-0203 supersedes the older 'jabber:x:delay' namespace defined in &xep0091;; until the status of XEP-0091 is changed to Obsolete, implementations SHOULD include both datetime formats.) The 'from' attribute SHOULD be the full JID of the original sender in non-anonymous rooms, but MUST NOT be in semi-anonymous rooms (where the 'from' attribute SHOULD be set to the JID of the room itself). The service SHOULD send all discussion history messages before delivering any "live" messages sent after the user enters the room.

    +

    Discussion history messages MUST be stamped with &xep0203; information qualified by the 'urn:xmpp:delay' namespace to indicate that they are sent with delayed delivery and to specify the times at which they were originally sent. (Note: The 'urn:xmpp:delay' namespace defined in XEP-0203 supersedes the older 'jabber:x:delay' namespace defined in &xep0091;; some implementations include both formats for backward compatibility.)

    +

    In a non-anonymous room, the 'from' attribute of a discussion history message SHOULD be the full JID of the original sender. In a semi-anonymous room, the 'from' attribute MUST be set to the JID of the room itself.

    +

    The service MUST send all discussion history messages before delivering the room subject and any "live" messages sent after the user enters the room.

     + -

    A user MAY want to manage the amount of discussion history provided on entering a room (perhaps because the user is on a low-bandwidth connection or is using a small-footprint client). This MUST be accomplished by including a <history/> child in the initial presence stanza sent when joining the room. There are four allowable attributes for this element:

    +

    A user might want to manage the amount of discussion history provided on entering a room (perhaps because the user is on a low-bandwidth connection or is using a small-footprint client). This is accomplished by including a <history/> child in the initial presence stanza sent when joining the room. There are four allowable attributes for this element:

    @@ -1567,11 +1607,20 @@ - +
    Attribute
    since dateTimeSend only the messages received since the datetime specified (which MUST conform to the DateTime profile specified in &xep0082;).Send only the messages received since the UTC datetime specified (which MUST conform to the DateTime profile specified in &xep0082;).

    The service MUST send the smallest amount of traffic that meets any combination of the above criteria, taking into account service-level and room-level defaults. The service MUST send complete message stanzas only (i.e., it MUST not literally truncate the history at a certain number of characters, but MUST send the largest number of complete stanzas that results in a number of characters less than or equal to the 'maxchars' value specified). If the client wishes to receive no history, it MUST set the 'maxchars' attribute to a value of "0" (zero).

    -

    The following examples illustrate the use of this protocol.

    +

    The following examples illustrate the use of this feature.

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

    After the room has optionally sent the discussion history to the new occupant, it SHALL send the current room subject (if any). This is a &MESSAGE; stanza from the room itself (or from the room JID of the entity that set the subject), with no &BODY; and only a &SUBJECT;, as shown in the following example.

    + + Fire Burn and Cauldron Bubble! + + ]]> +     + + +

    After the room has optionally sent the room subject, it SHALL begin to send live messages, presence changes, occupant "joins" and "leaves", and other real-time traffic ot the new occupant, as described in other sections of this document.

    +     +     - -

    In order to exit a multi-user chat room, an occupant sends a presence stanza of type "unavailable" to the &ROOMJID; it is currently using in the room.

    - +

    If allowed in accordance with room configuration, a mere occupant MAY be allowed to change the subject in a room. For details, see the Modifying the Room Subject section of this document.

    +     + + +

    An occupant sends a message to all other occupants in the room by sending a message of type "groupchat" to the &ROOM; itself (a service MAY ignore or reject messages that do not have a type of "groupchat"). In a moderated room, this privilege is restricted to occupants with a role of participant or higher.

    + + to='coven@chat.shakespeare.lit' + type='groupchat'> + Harpier cries: 'tis time, 'tis time. + ]]> -

    The service MUST then send presence stanzas of type "unavailable" from the departing occupant's room JID to the full JIDs of the departing occupant and of the remaining occupants:

    - - - - - - -If the sender has voice in the room (this is the default except in moderated rooms), the service MUST change the 'from' attribute to the sender's room JID and reflect the message out to the full JID of each occupant.

    + - - - -     - + Harpier cries: 'tis time, 'tis time. + + - - - - + type='groupchat'> + Harpier cries: 'tis time, 'tis time. + + + Harpier cries: 'tis time, 'tis time. + ]]>     -

    Presence stanzas of type "unavailable" reflected by the room MUST contain extended presence information about roles and affiliations; the 'role' attribute SHOULD be set to a value of "none" to denote that the individual is no longer an occupant.

    -

    The occupant MAY include normal <status/> information in the unavailable presence stanzas; this enables the occupant to provide a custom exit message if desired:

    - - gone where the goblins go - - ]]> -

    Normal presence stanza generation rules apply as defined in &xmppim;, so that if the user sends a general unavailable presence stanza, the user's server will broadcast that stanza to the &ROOMJID; to which the user's client has sent directed presence.

    -

    It is possible that a user may not be able to gracefully exit the room by sending unavailable presence directly to the room. If the user goes offline without sending unavailable presence, the user's server is responsible for sending unavailable presence on behalf of the user (in accordance with RFC 3921). If the user's server goes offline or connectivity is lost between the user's server and the MUC service to which the user is connected (e.g., in federated communications), the MUC service is responsible for monitoring error stanzas it receives in order to determine if the user has gone offline. If the MUC service determines that the user has gone offline, it must treat the user as if the user had itself sent unavailable presence.

    -

    Note: If the room is not persistent and this occupant is the last to exit, the service is responsible for destroying the room.

    +

    If the sender is a visitor (i.e., does not have voice in a moderated room), the service MAY return a &forbidden; error to the sender and MUST NOT reflect the message to all occupants. If the sender is not an occupant of the room, the service SHOULD return a ¬acceptable; error to the sender and SHOULD NOT reflect the message to all occupants; the only exception to this rule is that an implementation MAY allow users with certain privileges (e.g., a room owner, room admin, or service-level admin) to send messages to the room even if those users are not occupants.

     + + +

    Since each occupant has a unique room JID, an occupant MAY send a "private message" to a selected occupant via the service by sending a message to the occupant's room JID. The message type SHOULD be "chat" and MUST NOT be "groupchat", but MAY be left unspecified (i.e., a normal message). This privilege SHOULD be allowed to any occupant (even a visitor in a moderated room).

    + + I'll give thee a wind. + + ]]> +

    The service is responsible for changing the 'from' address to the sender's room JID and delivering the message to the intended recipient's full JID.

    + + I'll give thee a wind. + + ]]> +

    If the sender attempts to send a private message of type "groupchat" to a particular occupant, the service MUST refuse to deliver the message (since the recipient's client would expect in-room messages to be of type "groupchat") and return a &badrequest; error to the sender:

    + + I'll give thee a wind. + + + + I'll give thee a wind. + + + + + ]]> +

    If the sender attempts to send a private message to a room JID that does not exist, the service MUST return an ¬found; error to the sender.

    +

    If the sender is not an occupant of the room in which the intended recipient is visiting, the service MUST return a ¬acceptable; error to the sender.

    +     +

    A common feature of multi-user chat rooms is the ability for an occupant to change his or her nickname within the room. In MUC this is done by sending updated presence information to the room, specifically by sending presence to a new room JID in the same room (changing only the resource identifier in the room JID).

    The user SHOULD then discover its reserved nickname as specified in the Discovering Reserved Room Nickname section of this document.

     +

    In multi-user chat systems such as IRC, one common use for changing one's room nickname is to indicate a change in one's availability (e.g., changing one's room nickname to "thirdwitch|away"). In XMPP, availability is of course noted by a change in presence (specifically the <show/> and <status/> elements), which can provide important context within a chatroom. An occupant changes availability status within the room by sending the updated presence to its &ROOMJID;.

     +

    A method for sending a direct invitation (not mediated by the room itself) is defined in &xep0249;. Sending the invitation directly can help to work around communications blocking on the part of the invitee (which might refuse communication with entities not in its roster).

     +

    It can be useful to invite another user to a room in which one is an occupant. To do this, a MUC client MUST send XML of the following form to the &ROOM; itself (the reason is OPTIONAL and the message MUST be explicitly or implicitly of type "normal"):

    It may be wondered why the invitee does not send the decline message directly to the invitor. The main reason is that certain implementations MAY choose to base invitations on room JIDs rather than bare JIDs (so that, for example, an occupant could invite someone from one room to another without knowing that person's bare JID). Thus the service MUST handle both the invites and declines.

     +     +

    Sometimes it is desirable to convert a one-to-one chat into a multi-user conference. The process flow is shown in the following examples.

    First, two users begin a one-to-one chat.

    @@ -2020,83 +2122,7 @@ ]]>

    Note: The fact that the messages come from the &ROOM; itself rather than &ROOMJID; is a clue to the receiving client that these messages are prior chat history, since any message from a room occupant will have a 'from' address equal to the sender's room JID.

     - -

    If allowed in accordance with room configuration, a mere occupant MAY be allowed to change the subject in a room. For details, see the Modifying the Room Subject section of this document.

    -     - -

    Since each occupant has a unique room JID, an occupant MAY send a "private message" to a selected occupant via the service by sending a message to the occupant's room JID. The message type SHOULD be "chat" and MUST NOT be "groupchat", but MAY be left unspecified (i.e., a normal message). This privilege SHOULD be allowed to any occupant (even a visitor in a moderated room).

    - - I'll give thee a wind. - - ]]> -

    The service is responsible for changing the 'from' address to the sender's room JID and delivering the message to the intended recipient's full JID.

    - - I'll give thee a wind. - - ]]> -

    If the sender attempts to send a private message of type "groupchat" to a particular occupant, the service MUST refuse to deliver the message (since the recipient's client would expect in-room messages to be of type "groupchat") and return a &badrequest; error to the sender:

    - - I'll give thee a wind. - - - I'll give thee a wind. - - - - - ]]> -

    If the sender attempts to send a private message to a room JID that does not exist, the service MUST return an ¬found; error to the sender.

    -

    If the sender is not an occupant of the room in which the intended recipient is visiting, the service MUST return a ¬acceptable; error to the sender.

    -     - -

    An occupant sends a message to all other occupants in the room by sending a message of type "groupchat" to the &ROOM; itself (a service MAY ignore or reject messages that do not have a type of "groupchat"). In a moderated room, this privilege is restricted to occupants with a role of participant or higher.

    - - Harpier cries: 'tis time, 'tis time. - - ]]> -

    If the sender has voice in the room (this is the default except in moderated rooms), the service MUST change the 'from' attribute to the sender's room JID and reflect the message out to the full JID of each occupant.

    - - Harpier cries: 'tis time, 'tis time. - - - Harpier cries: 'tis time, 'tis time. - - - Harpier cries: 'tis time, 'tis time. - - ]]> -

    If the sender is a visitor (i.e., does not have voice in a moderated room), the service MAY return a &forbidden; error to the sender and MUST NOT reflect the message to all occupants. If the sender is not an occupant of the room, the service SHOULD return a ¬acceptable; error to the sender and SHOULD NOT reflect the message to all occupants; the only exception to this rule is that an implementation MAY allow users with certain privileges (e.g., a room owner, room admin, or service-level admin) to send messages to the room even if those users are not occupants.

    -

    An implementation MAY allow an unaffiliated user (in a moderated room, normally a participant) to register with a room and thus become a member of the room (conversely, an implementation MAY restrict this privilege and allow only room admins to add new members). In particular, it is not possible to join a members-only room without being on the member list, so an entity may need to request membership in order to join such a room.

    If allowed, this functionality SHOULD be implemented by enabling a user to send a request for registration requirements to the room qualified by the 'jabber:iq:register' namespace as described in &xep0077;:

    @@ -2253,9 +2279,11 @@ ]]>

    If a user has registered with a room, the room MAY choose to restrict the user to use of the registered nickname only in that room. If it does so, it SHOULD return a ¬acceptable; error to the user if the user attempts to join the room with a roomnick other than the user's registered roomnick (this enables a room to "lock down" roomnicks for consistent identification of occupants).

     +

    If allowed in accordance with room configuration, an occupant MAY be allowed to retrieve the list of room members. For details, see the Modifying the Member List section of this document.

     +

    A user MAY have a reserved room nickname, for example through explicit room registration, database integration, or nickname "lockdown". A user SHOULD discover his or her reserved nickname before attempting to enter the room. This is done by sending a Service Discovery information request to the room JID while specifying a well-known Service Discovery node of "x-roomuser-item".

    Even if a user has registered one room nickname, the service SHOULD allow the user to specify a different nickname on entering the room (e.g., in order to join from different client resources), although the service MAY choose to "lock down" nicknames and therefore deny entry to the user, including a ¬acceptable; error. The service MUST NOT return an error to the user if his or her client sends the foregoing request after having already joined the room, but instead SHOULD reply as previously described.

    If another user attempts to join the room with a nickname reserved by the first user, the service MUST deny entry to the second user and return a &conflict; error as previously described.

     +

    It is not possible for a visitor to speak (i.e., send a message to all occupants) in a moderated room. To request voice, a visitor SHOULD send a &MESSAGE; stanza containing a data form to the room itself, where the data form contains only a 'muc#role' field with a value of "participant".

    The service then SHOULD forward the request to the room moderator(s) as described in the Approving Voice Requests section of this document.

     + + +

    In order to exit a multi-user chat room, an occupant sends a presence stanza of type "unavailable" to the &ROOMJID; it is currently using in the room.

    + + ]]> +

    The service MUST then send a presence stanzas of type "unavailable" from the departing occupant's room JID to the departing occupant's full JIDs, including a status code of "110" to indicate that this notification is "self-presence":

    + + + + + + + ]]> +

    The service MUST then send presence stanzas of type "unavailable" from the departing occupant's room JID to the full JIDs of the remaining occupants:

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

    Presence stanzas of type "unavailable" reflected by the room MUST contain extended presence information about roles and affiliations; in particular, the 'role' attribute MUST be set to a value of "none" to denote that the individual is no longer an occupant.

    +

    The occupant MAY include normal <status/> information in the unavailable presence stanzas; this enables the occupant to provide a custom exit message if desired:

    + + gone where the goblins go + + ]]> +

    Note that normal presence stanza generation rules apply as defined in &xmppim;, so that if the user sends a general unavailable presence stanza, the user's server will broadcast that stanza to the client's &ROOMJID;; as a result, there is no need for the leaving client to send directed unavailable presence to its room JID. It is possible that a user might not be able to gracefully exit the room by sending unavailable presence. If the user goes offline without sending unavailable presence, the user's server is responsible for sending unavailable presence on behalf of the user (in accordance with RFC 6121). However, if there is no activity in the room then the room MAY periodically poll its occupants to ensure that there are no "ghost users" in the room (e.g., by using presence probes or &xep0199;). If the user's server goes offline or connectivity is lost between the user's server and the MUC service to which the user is connected (e.g., in federated communications), the MUC service is responsible for monitoring error stanzas it receives in order to determine if the user has gone offline. If the MUC service determines that the user has gone offline, it must treat the user as if the user had itself sent unavailable presence.

    +

    Note: If the room is not persistent and this occupant is the last to exit, the service is responsible for destroying the room.

    +     +     +

    A moderator has privileges to perform certain actions within the room (e.g., to change the roles of some occupants) but does not have rights to change persistent information about affiliations (which may be changed only by an admin or owner) or defining information about the room. Exactly which actions may be performed by a moderator is subject to configuration. However, for the purposes of the MUC framework, moderators are stipulated to have privileges to perform the following actions:

      @@ -2364,6 +2465,7 @@ ]]> +

      A moderator has permissions kick certain kinds of occupants from a room (which occupants are "kickable" depends on service provisioning, room configuration, and the moderator's affiliation -- see below). The kick is normally performed based on the occupant's room nickname (though it MAY be based on the full JID) and is completed by setting the role of a participant or visitor to a value of "none".

      If a moderator attempts to kick himself, the service MAY deny the request and return a &conflict; error to the sender. (Although the act of kicking oneself may seem odd, it is common in IRC as a way of apologizing for one's actions in the room.)

       +

      In a moderated room, a moderator may want to manage who does and does not have "voice" in the room (i.e., the ability to send messages to all occupants). Voice is granted based on the visitor's room nickname, which the service will convert into the visitor's full JID internally. The moderator grants voice to a visitor by changing the visitor's role to "participant".

       +

      In a moderated room, a moderator may want to revoke a participant's privileges to speak. The moderator can revoke voice from a participant by changing the participant's role to "visitor":

      ]]>       +

      A moderator in a moderated room may want to modify the voice list. To do so, the moderator first requests the voice list by querying the room for all occupants with a role of 'participant'.

      ]]>       +

      As noted in the Requesting Voice section of this document, when a service receives a request for voice from an occupant it SHOULD forward that request to the room moderator(s). To do so, the service SHOULD send a &MESSAGE; stanza to the room moderator(s), where the &MESSAGE; stanza contains a data form asking for approval or denial of the request, as shown below.

      If a moderator approves the voice request, the service shall grant voice to the occupant and send a presence update as described in the Granting Voice to a Visitor section of this document.

       + +

      A room administrator has privileges to modify persistent information about user affiliations (e.g., by banning users) and to grant and revoke moderator privileges, but does not have rights to change the defining features of the room, which are the sole province of the room owner(s). Exactly which actions may be performed by a room admin will be subject to configuration. However, for the purposes of the MUC framework, room admins are stipulated to at a minimum have privileges to perform the following actions:

        @@ -2789,6 +2897,7 @@ ]]>

        If an admin or owner attempts to ban himself, the service MUST deny the request and return a &conflict; error to the sender. (Note: This is different from the recommended service behavior on kicking oneself, which a service may allow.)

        +

        A room admin may want to modify the ban list. Note: The ban list is always based on a user's bare JID. To modify the list of banned JIDs, the admin first requests the ban list by querying the room for all users with an affiliation of 'outcast'.

        ]]>

        The service MUST then remove the affected occupants (if they are in the room) and send updated presence (including the appropriate status code) from them to all the remaining occupants as described in the "Banning a User" use case. (The service SHOULD also remove each banned user's reserved nickname from the list of reserved roomnicks, if appropriate.)

        -

        When an entity is banned from a room, an implementation SHOULD match JIDs in the following order (these matching rules are the same as those defined for privacy lists in RFC 3921):

        +

        When an entity is banned from a room, an implementation SHOULD match JIDs in the following order (these matching rules are the same as those defined for privacy lists in &xep0016;):

        1. <user@domain/resource> (only that resource matches)
        2. <user@domain> (any resource matches)
          3. @@ -2854,6 +2963,7 @@

        Some administrators may wish to ban all users associated with a specific domain from all rooms hosted by a MUC service. Such functionality is a service-level feature and is therefore out of scope for this document, instead being defined in XEP-0133.

         +

        An admin can grant membership to a user; this is done by changing the user's affiliation to "member" (normally based on nick if the user is in the room, or on bare JID if not; in either case, if the nick is provided, that nick becomes the user's default nick in the room if that functionality is supported by the implementation):

         +

        An admin may want to revoke a user's membership; this is done by changing the user's affiliation to "none":

         +

        In the context of a members-only room, the member list is essentially a "whitelist" of people who are allowed to enter the room. Anyone who is not a member is effectively banned from entering the room, even if their affiliation is not "outcast".

        In the context of an open room, the member list is simply a list of users (bare JID and reserved nick) who are registered with the room. Such users may appear in a room roster, have their room nickname reserved, be returned in search results or FAQ queries, and the like.

        @@ -3103,6 +3215,7 @@ [ ... ] ]]>         +

        An admin may want to grant moderator privileges to a participant or visitor; this is done by changing the user's role to "moderator":

         +

        An admin may want to revoke a user's moderator privileges. An admin MAY revoke moderator privileges only from a user whose affiliation is "member" or "none" (i.e., not from an owner or admin). The privilege is revoked by changing the user's role to "participant":

        ]]>         +

        An admin may want to modify the moderator list. To do so, the admin first requests the moderator list by querying the room for all users with a role of 'moderator'.

        ]]>         +

        If a service does not automatically accept requests to register with a room, it MAY provide a way for room admins to approve or deny registration requests over XMPP (alternatively, it could provide a web interface or some other admin tool). The simplest way to do so is for the service to send a &MESSAGE; stanza to the room admin(s) when the registration request is received, where the &MESSAGE; stanza contains a Data Form asking for approval or denial of the request. The following Data Form is RECOMMENDED but implementations MAY use a different form entirely, or supplement the following form with additional fields.

        If the admin approves the registration request, the service shall register the user with the room.

        More advanced registration approval mechanisms (e.g., retrieving a list of registration requests using &xep0050; as is done in &xep0060;) are out of scope for this document.

         + +

        Every room MUST have at least one owner, and that owner (or a successor) is a long-lived attribute of the room for as long as the room exists (e.g., the owner does not lose ownership on exiting a persistent room). This document assumes that the (initial) room owner is the individual who creates the room and that only a room owner has the right to change defining room configuration settings such as the room type. Ideally, room owners will be able to specify not only the room types (password-protected, members-only, etc.) but also certain attributes of the room as listed in the Requirements section of this document. In addition, it would be good if an owner were able to specify the JIDs of other owners, but that shall be determined by the implementation.

        -

        In order to provide the necessary flexibility for a wide range of configuration options, Data Forms (XEP-0004) shall be used for room configuration, triggered by use of the 'http://jabber.org/protocol/muc' namespace. That is, if an entity does not include the MUC namespace in its room join/create request, then the service shall create the room and not wait for configuration via Data Forms before creating the room (this ensures backwards-compatibility with the old "groupchat 1.0" protocol); however, if the room join/create request includes the MUC extension, then the service shall require configuration via Data Forms before creating and unlocking the room.

        +

        In order to provide the necessary flexibility for a wide range of configuration options, Data Forms (XEP-0004) shall be used for room configuration, triggered by use of the 'http://jabber.org/protocol/muc' namespace. That is, if an entity does not include the MUC namespace in its room join/create request, then the service shall create the room and not wait for configuration via Data Forms before creating the room (this ensures backwards-compatibility with the old GC protocol); however, if the room join/create request includes the MUC extension, then the service shall require configuration via Data Forms before creating and unlocking the room.

        Note: The configuration options shown below address all of the features and room types listed in the requirements section of this document; however, the exact configuration options and form layout shall be determined by the implementation or specific deployment. Also, these are examples only and are not intended to define the only allowed or required configuration options for rooms. A given implementation or deployment MAY choose to provide additional configuration options (profanity filters, setting the default language for a room, message logging, etc.), which is why the use of the 'jabber:x:data' protocol is valuable here.

        @@ -3395,8 +3513,9 @@ ]]>

        After receiving notification that the room has been created, the room owner needs to decide whether to accept the default room configuration (i.e., create an "instant room") or configure the room to have something other than the default room configuration (i.e., create a "reserved room"). The protocol flows for completing those two use cases are shown in the following sections.

        -

        Note: If the presence stanza sent to a nonexistent room does not include an &X; element qualified by the 'http://jabber.org/protocol/muc' namespace as shown above, the service SHOULD create a default room without delay (i.e., it MUST assume that the client supports "groupchat 1.0" rather than Multi-User Chat and therefore it MUST NOT lock the room while waiting for the room creator to either accept an instant room or configure a reserved room).

        +

        Note: If the presence stanza sent to a nonexistent room does not include an &X; element qualified by the 'http://jabber.org/protocol/muc' namespace as shown above, the service SHOULD create a default room without delay (i.e., it MUST assume that the client supports GC rather than MUC and therefore it MUST NOT lock the room while waiting for the room creator to either accept an instant room or configure a reserved room).

         +

        If the initial room owner wants to accept the default room configuration (i.e., create an "instant room"), the room owner MUST decline an initial configuration form by sending an IQ set to the &ROOM; itself containing a &QUERY; element qualified by the 'http://jabber.org/protocol/muc#owner' namespace, where the only child of the &QUERY; is an empty &X; element that is qualified by the 'jabber:x:data' namespace and that possesses a 'type' attribute whose value is "submit":

        The service MUST then unlock the room and allow other entities to join it.

         +

        If the initial room owner wants to create and configure a reserved room, the room owner MUST request an initial configuration form by sending an IQ get to the &ROOM; itself containing an empty &QUERY; element qualified by the 'http://jabber.org/protocol/muc#owner' namespace:

        If the room owner cancels the initial configuration, the service SHOULD destroy the room, making sure to send unavailable presence to the room owner (see the "Destroying a Room" use case for protocol details).

        If the room owner becomes unavailable for any reason before submitting the form (e.g., a lost connection), the service will receive a presence stanza of type "unavailable" from the owner to the owner's &ROOMJID; or to &ROOM; (or both). The service MUST then destroy the room, sending a presence stanza of type "unavailable" from the room to the owner including a <destroy/> element and reason (if provided) as defined in the Destroying a Room section of this document.

         +

        In some situations (e.g., when Converting a One-to-One Chat Into a Conference), the room creator may want to request a unique room name before attempting to create the room (e.g., to avoid the possibility of a room conflict). In order to facilitate this, a service MAY support the feature described in this section. (If a service does support this feature, it MUST return a feature of "http://jabber.org/protocol/muc#unique" in its response to service discovery information requests.)

        The room creator requests a unique room name by sending an IQ-get to the service itself, containing an empty <unique/> element qualified by the 'http://jabber.org/protocol/muc#unique' namespace:

        @@ -3723,7 +3844,9 @@ ]]>         +         +

        At any time after specifying the initial configuration of the room, a room owner may want to change the configuration. In order to initiate this process, a room owner MUST request a new configuration form from the room by sending an IQ to &ROOM; containing an empty <query/> element qualified by the 'http://jabber.org/protocol/muc#owner' namespace.

        For any other configuration change, the room SHOULD send status code 104 so that interested occupants can retrieve the updated room configuration if desired.

        +         +

        If allowed by an implementation, an owner MAY grant ownership privileges to another user; this is done by changing the user's affiliation to "owner":

         +

        An implementation MAY allow an owner to revoke another user's ownership privileges; this is done by changing the user's affiliation to something other than "owner":

         +

        If allowed by an implementation, a room owner may want to modify the owner list. To do so, the owner first requests the owner list by querying the room for all users with an affiliation of 'owner'.

        The service MUST also send presence notifications related to any affiliation changes that result from modifying the owner list as previously described.

         +

        An owner can grant administrative privileges to a member or unaffiliated user; this is done by changing the user's affiliation to "admin":

         +

        An owner may want to revoke a user's administrative privileges; this is done by changing the user's affiliation to something other than "admin" or "owner":

         +

        A room owner may want to modify the admin list. To do so, the owner first requests the admin list by querying the room for all users with an affiliation of 'admin'.

        The service MUST also send presence notifications related to any affiliation changes that result from modifying the admin list as previously described.

         +

        A room owner MUST be able to destroy a room, especially if the room is persistent. The workflow is as follows:

          @@ -4471,7 +4602,9 @@ ]]> + +

          The error codes associated with the 'http://jabber.org/protocol/muc#user' namespace are fairly straightforward, as summarized in the following table. For detailed information about mapping legacy error codes to XMPP-style error types and conditions, refer to &xep0086;; implementations SHOULD support both legacy and XMPP error handling.

          @@ -4542,34 +4675,43 @@

          This document does not stipulate text strings (i.e., values of the XMPP <text/> element) associated with the foregoing error conditions.

           +

          Multi-User Chat uses a <status/> element (specifically, the 'code' attribute of the <status/> element) to communicate information about a user's status in a room. Over time, the number of status codes has grown quite large, and new status codes continue to be requested of the author. Therefore, these codes are now documented in a registry maintained by the XMPP Registrar. For details, refer to the Status Codes Registry section of this document.

          Note: In general, MUC status codes tend to follow the "philosophy" of status codes that is implicit in &rfc2616; and &rfc1893; (1xx codes are informational, 2xx codes specify that it is fine to continue, 3xx codes specify redirects such as being kicked or banned, x3x codes refer to system status, x7x codes refer to security or policy matters, etc.).

          -

          Note: If the MUC protocol were being designed today, it would specify a more flexible, XML-friendly approach rather than hardcoded status numbers; however, at this point the pain of changing the status reporting system would be greater than the benefit of doing so, which is why the status code numbers remain in use. A future version of this document may define a more XMPP-like approach to status conditions, retaining the code numbers but supplementing them with more descriptive child elements as is done in RFC 3920.

          +

          Note: If the MUC protocol were being designed today, it would specify a more flexible, XML-friendly approach rather than hardcoded status numbers; however, at this point the pain of changing the status reporting system would be greater than the benefit of doing so, which is why the status code numbers remain in use. A future version of this document may define a more XMPP-like approach to status conditions, retaining the code numbers but supplementing them with more descriptive child elements as is done in RFC 6120.

           +           + -

          As specified in RFC 3920, XMPP entities (including MUC rooms and MUC services) SHOULD respect the value of the 'xml:lang' attribute provided with any given stanza. However, simultaneous translation of groupchat messages is out of scope for this document.

          +

          As specified in RFC 6120, XMPP entities (including MUC rooms and MUC services) SHOULD respect the value of the 'xml:lang' attribute provided with any given stanza. However, simultaneous translation of groupchat messages is out of scope for this document.

          The status and error codes defined herein enable a client implementation to present a localized interface; however, definition of the localized text strings for any given language community is out of scope for this document.

          Although the labels for various data form fields are shown here in English, MUC clients SHOULD present localized text for these fields rather than the English text.

           + -

          No room entrance authentication or authorization method more secure than cleartext passwords is defined or required by this document. However, the risks involved can mitigated by the use of channel encryption and strong authentication via TLS and SASL as described in RFC 3920.

          +

          No room entrance authentication or authorization method more secure than cleartext passwords is defined or required by this document. However, the risks involved can mitigated by the use of channel encryption and strong authentication via TLS and SASL as described in RFC 6120.

           +

          No end-to-end message or session encryption method is specified herein. Users SHOULD NOT trust a service to keep secret any text sent through a room.

           +

          Depending on room configuration, a room may publicly log all discussions held in the room. A service MUST warn the user that the room is publicly logged by returning a status code of "170" with the user's initial presence, and the user's client MUST so warn the user if the room discussion is logged (a user's client SHOULD also query the room for its configuration prior to allowing the user to enter in order to "pre-discover" whether the room is logged). A client MUST also warn the user if the room's configuration is subsequently modified to allow room logging (which the client will discover when the room sends status code 170). Note: In-room history is different from public room logging, and naturally a room cannot effectively prevent occupants from separately maintaining their own room logs, which may become public; users SHOULD exercise due caution and consider any room discussions to be effectively public.

           +

          The "roominfo" data form used in extended service discovery can result in information leaks, e.g., the current discussion topic (via the "roominfo_subject" field). The same is true of service discovery items (disco#items) requests from outside the room (which could be used to discover the list of room occupants).

          Implementations and deployments are advised to carefully consider the possibility that this information might be leaked, and to turn off information sharing by default for sensitive data.

           +

          Depending on room configuration, a room MAY expose each occupant's real JID to other occupants (if the room is non-anonymous) and will almost certainly expose each occupant's real JID to the room owners and administrators (if the room is not fully-anonymous). A service MUST warn the user that real JIDs are exposed in the room by returning a status code of "100" with the user's initial presence, and the user's client MUST so warn the user (a user's client SHOULD also query the room for its configuration prior to allowing the user to enter in order to "pre-discover" whether real JIDs are exposed in the room). A client MUST also warn the user if the room's configuration is subsequently modified from semi-anonymous or fully-anonymous to non-anonymous (which the client will discover when the room sends status code 172) and SHOULD warn the user if the room's configuration is subsequently modified from fully-anonymous to semi-anonymous (which the client will discover when the room sends status code 173).

           +

          Public MUC rooms can be subject to a number of attacks, most of which reduce to denial of service attacks. Such attacks include but are not limited to:

            @@ -4583,13 +4725,17 @@

          These attacks can be mitigated but not completely prevented through the liberal use of administrative actions such as banning, the presence of automated room bots with administrative privileges, implementation of intelligent content filtering, checking the IP addresses of connected users (not always possible in a distributed system), applying voice rules to presence as well as messaging, matching room nicks using more stringent rules than the Resourceprep profile of stringprep, etc. However, experience has shown that it is impossible to fully prevent attacks of this kind.

           +

          See XEP-0203 for security considerations regarding the inclusion and processing of delayed delivery notations.

           +           +

          This document requires no interaction with &IANA;.

           +

          The ®ISTRAR; includes the following information in its registries.

          @@ -4601,9 +4747,11 @@
        1. http://jabber.org/protocol/muc#user
          2.  +

          A Multi-User Chat service or room is identified by the "conference" category and the "text" type within Service Discovery.

           +

          There are many features related to a MUC service or room that can be discovered by means of Service Discovery. The most fundamental of these is the 'http://jabber.org/protocol/muc' namespace. In addition, a MUC room SHOULD provide information about the specific room features it implements, such as password protection and room moderation.

          ]]>           +

          The well-known Service Discovery node 'http://jabber.org/protocol/muc#rooms' enables discovery of the rooms in which a user is an occupant.

          The well-known Service Discovery node 'x-roomuser-item' enables a user to discover his or her registered roomnick from outside the room.

          The well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' enables discovery of the namespaces that are allowed in traffic sent through a room (see the Allowable Traffic section of this document).

           +

          &xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. Within MUC, there are four uses of such forms: room registration (the "muc#register" FORM_TYPE), requesting voice and approving voice requests ("muc#request"), room configuration ("muc#roomconfig"), and service discovery extensions for room information ("muc#roominfo"). The reserved fields are defined below.

          @@ -4737,6 +4887,7 @@ ]]> + @@ -4762,6 +4913,7 @@ ]]> + @@ -4850,6 +5002,7 @@ ]]> + @@ -4897,7 +5050,9 @@ ]]> +           +

          The XMPP Registrar maintains a registry of values for the 'code' attribute of the <status/> element when qualified by the 'http://jabber.org/protocol/muc#user' namespace.

          @@ -4913,6 +5068,7 @@ ]]>

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

           +

          As part of this document, the following status codes are registered:

          ]]>           +           +

          As authorized by &xep0147;, the XMPP Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).

          @@ -5079,6 +5237,7 @@ xmpp:coven@chat.shakespeare.lit?join;password=cauldronburn ]]> +

          The "invite" querytype is registered as a MUC-related action, with an optional key of "jid".

          ]]>           +           +           + -

          In order to provide consistency regarding the addresses captured in room JIDs, Room IDs MUST match the Nodeprep profile of Stringprep and Room Nicknames MUST match the Resourceprep profile of Stringprep (both of these are defined in RFC 3920). Although not explicitly stated in RFC 3920, both the Room ID (node) and Room Nickname (resource) portions of a Room JID MUST be of non-zero length. In addition, a MUC service MUST NOT allow empty or invisible Room Nicknames (i.e., Room Nicknames that consist only of one or more space characters).

          +

          In order to provide consistency regarding the addresses captured in room JIDs, Room IDs MUST match the Nodeprep profile of Stringprep and Room Nicknames MUST match the Resourceprep profile of Stringprep (both of these are defined in &rfc3920;). As explicitly stated in RFC 6120, both the Room ID (node) and Room Nickname (resource) portions of a Room JID MUST be of non-zero length. In addition, a MUC service MUST NOT allow empty or invisible Room Nicknames (i.e., Room Nicknames that consist only of one or more space characters).

          It is up to the service implementation whether it will further restrict roomnicks (e.g., by applying case folding routines, the Nodeprep profile of stringprep, or other restrictions).

           +

          1. If an occupant wants to send a message to all other occupants, a MUC client MUST set the 'type' attribute to a value of "groupchat". A service MAY ignore messages that are improperly typed, or reject them with a &badrequest; error.

            2. @@ -5161,6 +5324,7 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld

          2. A MUC client MAY generate extensions that conform to the &xep0022; or &xep0085; specification; however, a MUC service MAY disallow these extensions (see the Allowable Traffic section of this document).

           +

          1. A room MUST silently ignore unavailable presence received from a user who has a role of "none".

            2. @@ -5168,11 +5332,12 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld

          2. A MUC service SHOULD allow all other presence information to pass through, although it MAY choose to block extended presence information; see the Allowable Traffic section of this document.

          3. In order to appropriately inform occupants of room roles and affiliations, and to make it easier for clients to track the current state of all users in the room, MUC service implementations MUST provide extended presence information about roles and affiliations in all presence stanzas, including presence stanzas of type "unavailable" sent when a user exits the room for any reason.

          4. If a privilege is revoked, the service MUST note that by sending an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child element with the 'role' and/or 'affiliation' attributes set to a value that indicates the loss of the relevant privilege. All future presence stanzas for the occupant MUST include the updated role and affiliation, until and unless they change again.

            5. -

          5. A MUC service MUST send extended presence to a client even if the client did not send an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace on entering the room; naturally, a client MUST ignore such information if it does not understand it (in accordance with RFC 3920).

            6. +

          6. A MUC service MUST send extended presence to a client even if the client did not send an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace on entering the room; naturally, a client MUST ignore such information if it does not understand it (in accordance with RFC 6120).

          7. Extended presence about roles and affiliations sent in the muc#user namespace MUST include the full JID (not the bare JID) as the value of the 'jid' attribute.

          8. A client MAY send a custom exit message if desired (as is often done in IRC channels) by including a <status/> element in the presence stanza of type "unavailable" sent when exiting a room.

           +

          1. MUC is designed for sharing of messages and presence, not IQs. An IQ sent to the JID of the room itself is handled by the room and is not reflected to all of the room occupants.

            2. @@ -5183,7 +5348,9 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld

          2. In IQ sets regarding affiliations, a MUC client MUST include the 'jid' attribute only (with the value set to the bare JID); in IQ results regarding affiliations, a MUC service MUST NOT include the 'role' attribute, MUST include the 'affiliation' attribute and the 'jid' attribute (with the value set to the bare JID), and SHOULD include the 'nick' attribute (except if the affiliation is "outcast", since outcasts SHOULD NOT have reserved nicknames).

           +           +

          The following guidelines may assist client and component developers in creating MUC implementations.

          @@ -5192,7 +5359,7 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld

        2. It is common for MUC services to provide in-room messages when certain events occur, such as when the subject changes, when an occupant enters or exits, or when a room is destroyed. Such messages are entirely OPTIONAL and are left up to the implementation or deployment, but if used MUST be messages of type "groupchat" sent from the room JID itself (&ROOM;) rather than a specific occupant (&ROOMJID;). However, in general it is preferable for the receiving client to generate such messages based on events in the room (e.g., user entrances and exits) as well as specific status codes provided in MUC; this will help ensure correct localization of such messages.

        3. Out of courtesy, a MUC service MAY send an out-of-room <message/> to an occupant who is kicked or banned, and MAY broadcast an in-room <message/> to all remaining occupants informing them that the occupant has been kicked or banned from the room. However, such messages are OPTIONAL, and indeed are unnecessary since the information required for a receiving client to generate such messages is communicated in the presence stanzas (specifically the status codes) sent by a MUC service.

        4. Out of courtesy, a MUC service MAY send an out-of-room <message/> if a user's affiliation changes while the user is not in the room; the message SHOULD be sent from the room to the user's bare JID, MAY contain a <body/> element describing the affiliation change, and MUST contain a status code of 101.

          5. -

        5. There is no requirement that a MUC service shall provide special treatment for users of the older "groupchat 1.0" protocol, such as messages that contain equivalents to the extended presence information that is qualified by the 'http://jabber.org/protocol/muc#user' namespace.

          6. +

        6. There is no requirement that a MUC service shall provide special treatment for users of the older GC protocol, such as messages that contain equivalents to the extended presence information that is qualified by the 'http://jabber.org/protocol/muc#user' namespace.

        7. Room types MAY be configured in any combination. A MUC service MAY support or allow any desired room types or combinations thereof.

        8. A MUC service MAY limit the number of configuration options presented to an owner after initial configuration has been completed, e.g. because certain options cannot take effect without restarting the service.

        9. A MUC service MAY provide an interface to room creation and configuration (e.g., in the form of a special XMPP entity or a Web page), so that the ostensible room owner is actually the application instead of a human user.

          10. @@ -5240,7 +5407,9 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld ]]> +           +

          1. Clients MAY present room roles by showing ad-hoc groups for each role within a room roster. This will enable occupants to clearly visualize which occupants are moderators, participants, and visitors. However, such a representation is OPTIONAL.

            2. @@ -5348,8 +5517,11 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld

            Note: Because MUC roomnicks follow the Resourceprep profile of stringprep, they are allowed to contain a space character, whereas IRC nicknames do not. Although a given client MAY support quotation characters for this purpose (resulting in commands such as '/ban "king lear" insanity is no defense'), most common quotation characters (such as " and ') are also allowed by Resourceprep, thus leading to added complexity and potential problems with quotation of roomnicks that contain both spaces and quotation characters. Therefore it is NOT RECOMMENDED for XMPP clients to support IRC-style shortcut commands with roomnicks that contain space characters.

            Note: Many XMPP clients also implement a '/me ' command as described in &xep0245;. This command does not result in any MUC or IRC protocol action and is therefore not shown in the foregoing table.

            + + + ]]> + @@ -5535,6 +5708,7 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld ]]> + @@ -5613,6 +5787,7 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld ]]> + @@ -5662,6 +5837,7 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld ]]> + @@ -5684,8 +5860,11 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld ]]> + +

            The author would like to especially recognize the following individuals for their many helpful comments on various drafts of this proposal: Gaston Dombiak, Joe Hildebrand, Craig Kaes, Jacek Konieczny, Peter Millard, Jean-Louis Seguineau, Alexey Shchepin, David Sutton, and David Waite. Thanks also to members of the XSF Technical Review Team for their edits and suggestions, in particular Peter Mount and Luca Tagliaferri. In addition, more people than the author can count have have provided feedback in the jdev@conference.jabber.org conference room and on the standards@xmpp.org and muc@xmpp.org mailing lists.

             + diff --git a/xep-0070.xml b/xep-0070.xml index 1b4e11b4..9657c59a 100644 --- a/xep-0070.xml +++ b/xep-0070.xml @@ -97,7 +97,7 @@ -

            HTTP (see &rfc2616;) is a nearly-ubiquitous mechanism for the publication and retrieval of information over the Internet. Sometimes it is appropriate for an HTTP Server to allow access to that information only if the HTTP Client first provides authentication credentials. While there exist several standardized HTTP authentication schemes (see &rfc2617;), it may be useful in some applications to enforce verification of an HTTP request by requiring an XMPP entity (normally an IM user) to confirm that it made the request. This request verification can be combined with native HTTP authentication to provide a stronger association between the request and a particular user, as well as to take advantage of the strong user authentication provided in XMPP (see &rfc3920;).

            +

            HTTP (see &rfc2616;) is a nearly-ubiquitous mechanism for the publication and retrieval of information over the Internet. Sometimes it is appropriate for an HTTP Server to allow access to that information only if the HTTP Client first provides authentication credentials. While there exist several standardized HTTP authentication schemes (see &rfc2617;), it may be useful in some applications to enforce verification of an HTTP request by requiring an XMPP entity (normally an IM user) to confirm that it made the request. This request verification can be combined with native HTTP authentication to provide a stronger association between the request and a particular user, as well as to take advantage of the strong user authentication provided in XMPP (see &xmppcore;).

             @@ -334,7 +334,7 @@ Content-Length: 3032

            To reduce the likelihood of man-in-the-middle attacks, channel encryption SHOULD be used for both the XMPP channel and the HTTP channel. In particular:

            1. The channel used for HTTP requests and responses SHOULD be encrypted via SSL (secure HTTP via https: URLs) or TLS (&rfc2817;).
              2. -
            2. If the standard binding of XMPP to TCP is used, TLS SHOULD be negotiated for the XMPP channel in accordance with RFC 3920.
              3. +
            3. If the standard binding of XMPP to TCP is used, TLS SHOULD be negotiated for the XMPP channel in accordance with RFC 6120.
            4. If a binding of XMPP to HTTP is used (e.g., as specified in XEP-0124), exchanges between the XMPP Client and XMPP Server (connection manager) SHOULD be sent over a channel that is encrypted using SSL or TLS.
             diff --git a/xep-0072.xml b/xep-0072.xml index e73208b9..43198ce7 100644 --- a/xep-0072.xml +++ b/xep-0072.xml @@ -122,14 +122,14 @@

            &w3soap; is a lightweight protocol that defines a method for the exchange of messages independently from the programming language and platform. For interoperability, the SOAP specification is also agnostic about possible transport protocols, though almost all existing implementations use mainly HTTP.

            The primary limitation of HTTP consists in the fact that HTTP-based message exchanges allow only synchronous request-response semantics. To overcome this limitation, SMTP is often used to carry asynchronous messages, but it is a complex protocol and inefficient for passing short and frequent messages that should be delivered in close to real time.

            -

            Thus XMPP (see &rfc3920;) can be the ideal transport protocol for many of the application fields of web services, since it can carry efficiently and reliably both types of messages, synchronous and asynchronous. Moreover, XMPP-based web services will not need complex support protocols, such as WS-Routing and WS-Referral, in order to deliver messages to entities that cannot be identified by static public IP addresses. Therefore, this document defines a binding of SOAP to XMPP as an alternative to the existing HTTP and SMTP bindings.

            +

            Thus XMPP (see &xmppcore;) can be the ideal transport protocol for many of the application fields of web services, since it can carry efficiently and reliably both types of messages, synchronous and asynchronous. Moreover, XMPP-based web services will not need complex support protocols, such as WS-Routing and WS-Referral, in order to deliver messages to entities that cannot be identified by static public IP addresses. Therefore, this document defines a binding of SOAP to XMPP as an alternative to the existing HTTP and SMTP bindings.

            (Note: The main body of this document provides descriptive text suitable for use by XMPP developers. A formal description of the SOAP XMPP Binding itself is provided in the section of this document entitled SOAP XMPP Binding.)

             -

            The usual architecture of XMPP is described in Section 2 of RFC 3920. In essence, XMPP is most commonly deployed using a client-server (or logical peer-to-peer) architecture quite similar to that of the email system, except that XMPP does not have multiple hops between servers, enforces domain names to prevent address spoofing, and enables channel encryption (via TLS) and authentication (via SASL) between client and server as well as among servers.

            +

            The usual architecture of XMPP is described in RFC 6120. In essence, XMPP is most commonly deployed using a client-server (or logical peer-to-peer) architecture quite similar to that of the email system, except that XMPP does not have multiple hops between servers, enforces domain names to prevent address spoofing, and enables channel encryption (via TLS) and authentication (via SASL) between client and server as well as among servers.

            The binding of SOAP to XMPP assumes that most SOAP-enabled XMPP entities will be implemented as XMPP clients that communicate with other entities as logical peers. However, in order to deploy more scalable services, such entities could also be implemented as server-side components (see &xep0114;) or even as special-purpose XMPP servers.

            -

            The SOAP specification defines the concepts of "SOAP intermediary" and "ultimate SOAP receiver" (see Section 1.5.3 of SOAP Version 1.2 Part 1). In general, this specification assumes that XMPP entities that support the SOAP XMPP Binding will be ultimate SOAP receivers, since SOAP intermediaries tend to be artifacts of the existing SOAP bindings (HTTP and SMTP) rather than applicable to all possible bindings. SOAP intermediaries are usually deployed in order to (1) cross trust boundaries in protocols that do not enforce domain names or authenticate end-points, (2) ensure scalability, (3) secure messages sent over unencrypted channels, and (4) provide message tracing. However, these issues are addressed natively in XMPP (e.g., channel encryption is defined in RFC 3920), in XMPP extensions (e.g., message tracing is defined in &xep0079;), or in deployment decisions such as business level agreements between XMPP domains. One final justification for SOAP intermediaries is to act as gateways between different transport mechanisms (e.g., between HTTP and SMTP), and XMPP entities may well be SOAP intermediaries for that reason. For further details about gateways between XMPP and other SOAP bindings, refer to the Implementation Notes section of this document.

            +

            The SOAP specification defines the concepts of "SOAP intermediary" and "ultimate SOAP receiver" (see Section 1.5.3 of SOAP Version 1.2 Part 1). In general, this specification assumes that XMPP entities that support the SOAP XMPP Binding will be ultimate SOAP receivers, since SOAP intermediaries tend to be artifacts of the existing SOAP bindings (HTTP and SMTP) rather than applicable to all possible bindings. SOAP intermediaries are usually deployed in order to (1) cross trust boundaries in protocols that do not enforce domain names or authenticate end-points, (2) ensure scalability, (3) secure messages sent over unencrypted channels, and (4) provide message tracing. However, these issues are addressed natively in XMPP (e.g., channel encryption is defined in RFC 6120), in XMPP extensions (e.g., message tracing is defined in &xep0079;), or in deployment decisions such as business level agreements between XMPP domains. One final justification for SOAP intermediaries is to act as gateways between different transport mechanisms (e.g., between HTTP and SMTP), and XMPP entities may well be SOAP intermediaries for that reason. For further details about gateways between XMPP and other SOAP bindings, refer to the Implementation Notes section of this document.

             @@ -362,7 +362,7 @@

            The recommended approaches (file transfer and including a link) are described more fully below.

            The recommended method for sending associated data is to use the file transfer protocol described in XEP-0096. Because this is the common and standardized method for XMPP entities to transfer large or binary files outside the XMPP band, it SHOULD be used.

            -

            In particular, the entity that has the file SHOULD advertise the availability of the associated stream using XEP-0137 by including the SI-pub data extension along with the XMPP &MESSAGE; stanza with which the data is associated: In accordance with RFC 3920, an &IQ; stanza MUST NOT include multiple payload child elements; therefore, a &MESSAGE; stanza must be used when sending associated data.

            +

            In particular, the entity that has the file SHOULD advertise the availability of the associated stream using XEP-0137 by including the SI-pub data extension along with the XMPP &MESSAGE; stanza with which the data is associated: In accordance with RFC 6120, an &IQ; stanza MUST NOT include multiple payload child elements; therefore, a &MESSAGE; stanza must be used when sending associated data.

            For details regarding file transfer and advertising of file transfer stream initiation requests, refer to XEP-0096 and XEP-0137.

             -

            If the file transfer method is not possible (e.g., because file transfer is not implemented or transfer attempts fails), the entity that is sending the associated data MAY as a fallback publish the associated data as a file (e.g., at an HTTP or FTP URL) and include a link to the file as out-of-band content by including the out-of-band data extension along with the XMPP &MESSAGE; stanza with which the data is associated: As above, in accordance with RFC 3920, an &IQ; stanza MUST NOT include multiple payload child elements; therefore, a &MESSAGE; stanza must be used when sending associated data.

            +

            If the file transfer method is not possible (e.g., because file transfer is not implemented or transfer attempts fails), the entity that is sending the associated data MAY as a fallback publish the associated data as a file (e.g., at an HTTP or FTP URL) and include a link to the file as out-of-band content by including the out-of-band data extension along with the XMPP &MESSAGE; stanza with which the data is associated: As above, in accordance with RFC 6120, an &IQ; stanza MUST NOT include multiple payload child elements; therefore, a &MESSAGE; stanza must be used when sending associated data.

            -

            XMPP is a pure XML streaming protocol used to exchange snippets of structured data called "XML stanzas" (see Section 4.1 of RFC 3920) between any two network endpoints.

            +

            XMPP is a pure XML streaming protocol used to exchange snippets of structured data called "XML stanzas" (see RFC 6120) between any two network endpoints.

            Because XMPP is a direct messaging protocol, it does not possess the equivalent of web methods such as the HTTP GET, PUT, POST, and DELETE methods. Therefore, it is NOT RECOMMENDED for a SOAP node that supports only the SOAP XMPP Binding to provide the "SOAP Web Method Feature" described in Section 6.4 of SOAP Version 1.2 Part 2. (A SOAP gateway between XMPP and HTTP should support the SOAP Web Method Feature in order to ensure interoperability; however, description of such gateways is outside the scope of this document.)

            Because XMPP is a pure XML protocol, it does not use MIME types (&rfc2045;) or XML media types (&rfc3023;), but rather sends XML directly over the wire. Therefore, it is NOT RECOMMENDED for a SOAP node that supports only the SOAP XMPP Binding to provide the "SOAP Action Feature" described in Section 6.5 of SOAP Version 1.2 Part 2. (A SOAP gateway between XMPP and HTTP should support the SOAP Action Feature in order to ensure interoperability; however, description of such gateways is outside the scope of this document.)

             @@ -646,7 +646,7 @@
          2. A SOAP node instantiated at an XMPP entity may assume the role (i.e., the http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role property) of "RequestingSOAPNode".
          3. A SOAP node instantiated at an XMPP entity may assume the role (i.e., the http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role property) of "RespondingSOAPNode".
            4. -

            The remainder of this section describes the message exchange pattern (MEP) state machine and its relation to XMPP as described in RFC 3920. For the sake of brevity, relative URIs are used (the base URI being http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role), the string "fail:" is used as a conventional prefix for the namespace http://www.example.org/2001/12/soap/mep/FailureReasons/, and the string "reqresp:" is used as a conventional prefix for the namespace http://www.example.org/2001/12/soap/mep/request-response/. In the state tables below, the states are defined as values of the http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State property (see Section 6.2 of SOAP Version 1.2 Part 2) and are of type xs:anyURI.

            +

            The remainder of this section describes the message exchange pattern (MEP) state machine and its relation to XMPP as described in RFC 6120. For the sake of brevity, relative URIs are used (the base URI being http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role), the string "fail:" is used as a conventional prefix for the namespace http://www.example.org/2001/12/soap/mep/FailureReasons/, and the string "reqresp:" is used as a conventional prefix for the namespace http://www.example.org/2001/12/soap/mep/request-response/. In the state tables below, the states are defined as values of the http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State property (see Section 6.2 of SOAP Version 1.2 Part 2) and are of type xs:anyURI.

            The overall flow of the behavior of a Requesting SOAP Node follows the outline state machine description contained in Section 6.2 of SOAP Version 1.2 Part 2. The following subsections describe each state in more detail, where "Requesting SOAP Node" is to be understood as a logical entity made up of the binding and the local SOAP node associated with the XMPP entity that generates a SOAP request.

            @@ -777,7 +777,7 @@ fail:ReceptionFailure -

            For a listing of relevant XMPP error conditions, refer to Sections 9.3.3 and 4.7.3 of RFC 3920.

            +

            For a listing of relevant XMPP error conditions, refer to RFC 6120.

            The following table formally describes the "Sending+Receiving" state of the Requesting SOAP Node in the SOAP XMPP Binding:

            @@ -834,7 +834,7 @@ fail:BadRequestMessage -

            For a listing of relevant XMPP error conditions, refer to Sections 9.3.3 and 4.7.3 of RFC 3920.

            +

            For a listing of relevant XMPP error conditions, refer to RFC 6120.

            A given instance of a request-response transport message exchange terminates when the state "Success" or "Fail" is reached; control over the transport message exchange context returns to the Requesting SOAP Node.

            @@ -897,7 +897,7 @@ fail:BadRequestMessage -

            For a listing of relevant XMPP error conditions, refer to Section 9.3.3 of RFC 3920.

            +

            For a listing of relevant XMPP error conditions, refer to RFC 6120.

            The following table formally describes the "Receiving" state of the Responding SOAP Node in the SOAP XMPP Binding:

            @@ -1039,12 +1039,12 @@

            This specification addresses SOAP 1.2 only. This specification may be superseded or supplemented in the future by a XMPP Extension Protocol specification that defines methods for encapsulating content defined by future versions of SOAP as published by the W3C.

            -

            Per RFC 3920, XMPP supports XML 1.0 only. If future versions of XMPP support XML 1.1 or subsequent versions, this specification may be modified to address handling of SOAP messages that are encoded in versions other than XML 1.0.

            +

            Per RFC 6120, XMPP supports XML 1.0 only. If future versions of XMPP support XML 1.1 or subsequent versions, this specification may be modified to address handling of SOAP messages that are encoded in versions other than XML 1.0.

                         -

            SOAP provides its own encoding scheme for errors due to message processing or application execution, and it uses SOAP envelopes for reporting. In the SOAP HTTP Binding, these errors are mapped to corresponding HTTP status codes. In the SOAP XMPP Binding, they are mapped to the catch-all XMPP error of &undefined; along with application-specific error condition elements qualified by the 'http://jabber.org/protocol/soap#fault' namespace (this is consistent with Section 9.3.3 of RFC 3920, see also &xep0086;). The element names of these application-specific error conditions map directly to the SOAP fault codes specified in Section 5.4.6 of SOAP Version 1.2 Part 1.

            +

            SOAP provides its own encoding scheme for errors due to message processing or application execution, and it uses SOAP envelopes for reporting. In the SOAP HTTP Binding, these errors are mapped to corresponding HTTP status codes. In the SOAP XMPP Binding, they are mapped to the catch-all XMPP error of &undefined; along with application-specific error condition elements qualified by the 'http://jabber.org/protocol/soap#fault' namespace (this is consistent with RFC 6120, see also &xep0086;). The element names of these application-specific error conditions map directly to the SOAP fault codes specified in Section 5.4.6 of SOAP Version 1.2 Part 1.

            The following table provides a mapping between SOAP, HTTP, and application-specific XMPP errors.

            @@ -1083,7 +1083,7 @@ -

            Because XMPP does not require the parsing of arbitrary and complete XML documents and does not require implementations to support the full XML specification, transported SOAP envelopes MUST comply with the XML restrictions specified in Section 11 ("XML Usage Within XMPP") of RFC 3920. In particular, all envelope elements MUST be properly namespaced (SOAP allows elements within the default namespace, but they are deprecated since SOAP 1.2).

            +

            Because XMPP does not require the parsing of arbitrary and complete XML documents and does not require implementations to support the full XML specification, transported SOAP envelopes MUST comply with the XML restrictions specified in RFC 6120. In particular, all envelope elements MUST be properly namespaced (SOAP allows elements within the default namespace, but they are deprecated since SOAP 1.2).

            SOAP envelopes may contain arbitrary data encoded in valid XML as well as byte arrays encoded with SOAP-specific elements. The SOAP specification recommends to encode byte arrays in Base 64 (see &rfc3548;), with the result that envelopes with binary data can be transported within regular XMPP stanzas. All the remaining PCDATA MUST be encoded as UTF-8 in order to match the XML stream encoding.

                         @@ -1188,7 +1188,7 @@ ]]> -

            Generic XMPP routers that conform to RFC 3920 may also "store and forward" Jabber messages. This feature is usually called "offline message handling": the router makes a decision as to whether to deliver the message to the local intended recipient based on the recipient's presence, and if the recipient is offline when the router processes the message then it may store the message for delivery when the recipient next comes online (rather than returning an error to the sender). Although it is possible to write an XMPP router that directly supports the SOAP XMPP binding and implements the SOAP processing model, generic XMPP routers do not contain such support. Accordingly, generic XMPP routers will not forward an XMPP message to an alternate SOAP transport such as HTTP or SMTP, or provide other functions of a SOAP intermediary or ultimate receiver. When a generic XMPP router delivers a message to the intended recipient (whether immediately or as delayed in "offline storage") and the intended recipient supports the SOAP XMPP binding, SOAP processing is performed; such an intended recipient MAY act either as a SOAP intermediary or as an ultimate SOAP receiver.

            +

            Generic XMPP routers that conform to RFC 6120 may also "store and forward" Jabber messages. This feature is usually called "offline message handling": the router makes a decision as to whether to deliver the message to the local intended recipient based on the recipient's presence, and if the recipient is offline when the router processes the message then it may store the message for delivery when the recipient next comes online (rather than returning an error to the sender). Although it is possible to write an XMPP router that directly supports the SOAP XMPP binding and implements the SOAP processing model, generic XMPP routers do not contain such support. Accordingly, generic XMPP routers will not forward an XMPP message to an alternate SOAP transport such as HTTP or SMTP, or provide other functions of a SOAP intermediary or ultimate receiver. When a generic XMPP router delivers a message to the intended recipient (whether immediately or as delayed in "offline storage") and the intended recipient supports the SOAP XMPP binding, SOAP processing is performed; such an intended recipient MAY act either as a SOAP intermediary or as an ultimate SOAP receiver.

            With regarding to exchange of associated data, an XMPP entity that functions as a gateway to other SOAP bindings it SHOULD use W3C-recommended protocols for transporting SOAP attachments over non-XMPP SOAP bindings (e.g., HTTP and SMTP) when communicating with non-XMPP entities.

            diff --git a/xep-0077.xml b/xep-0077.xml index c0f2fdbe..ab548189 100644 --- a/xep-0077.xml +++ b/xep-0077.xml @@ -319,7 +319,7 @@ ]]>

            There are two scenarios:

              -

            1. If the entity cancels its registration with its "home" server (i.e., the server at which it has maintained its XMPP account), then the entity SHOULD NOT include a 'from' or 'to' address in the remove request the server SHOULD then return a <not-authorized/> stream error and terminate all active sessions for the entity. The server SHOULD perform the remove based on the bare JID &LOCALBARE; associated with the current session or connection over which it received the remove request. If the server is an instant messaging and presence server that conforms to &rfc3921;, the server SHOULD also cancel all existing presence subscriptions related to that entity (as stored in the entity's roster).

              2. +

            2. If the entity cancels its registration with its "home" server (i.e., the server at which it has maintained its XMPP account), then the entity SHOULD NOT include a 'from' or 'to' address in the remove request the server SHOULD then return a <not-authorized/> stream error and terminate all active sessions for the entity. The server SHOULD perform the remove based on the bare JID &LOCALBARE; associated with the current session or connection over which it received the remove request. If the server is an instant messaging and presence server that conforms to &xmppim;, the server SHOULD also cancel all existing presence subscriptions related to that entity (as stored in the entity's roster).

            3. If the entity cancels its registration with a service other than its home server, its home server MUST stamp a 'from' address on the remove request, which in accordance with XMPP Core will be the entity's full JID &LOCALFULL;. The service MUST perform the remove based on the bare JID &LOCALBARE; portion of the 'from' address.

            As specified below, several error cases are possible.

            @@ -504,7 +504,7 @@

            The fields defined for the 'jabber:iq:register' namespace are strictly limited to those specified in the schema. If a host needs to gather additional information, XEP-0004: Data Forms ("x:data") SHOULD be used according to the following rules:

            1. A host MUST NOT add new fields to the 'jabber:iq:register' namespace; instead, extensibility SHOULD be pursued via the Data Forms protocol as specified herein.
              2. -
            2. The x:data form shall be contained as a child element of the <query xmlns='jabber:iq:register'/> element (it cannot be a child of the &IQ; stanza and comply with Section 9.2.3 of &rfc3920;).
              3. +
            3. The x:data form shall be contained as a child element of the <query xmlns='jabber:iq:register'/> element (it cannot be a child of the &IQ; stanza and comply with &rfc6120;).
            4. The x:data form SHOULD contain x:data fields that correspond to all of the iq:register fields (e.g., username and password).
            5. The x:data form SHOULD use a hidden FORM_TYPE field for the purpose of standardizing field names within the form, as defined in &xep0068;.
            6. The x:data form shall take precedence over the iq:register fields; if the submitting entity supports the Data Forms protocol, it SHOULD submit the data form rather than the predefined 'jabber:iq:register' fields, and MUST NOT submit both the data form and the predefined fields (see the Precedence Order section of this document).
              7. @@ -593,7 +593,7 @@

              The <key/> element was also used during registration removal.

              -

              RFC 3920 defines methods for advertising feature support during stream negotiation. For the sake of efficiency, it may be desirable for a server to advertise support for in-band registration as a stream feature. The namespace for reporting support within <stream:features/> is "http://jabber.org/features/iq-register". Upon receiving a stream header qualified by the 'jabber:client' namespace, a server returns a stream header to the client and MAY announce support for in-band registration by including the relevant stream feature:

              +

              RFC 6120 defines methods for advertising feature support during stream negotiation. For the sake of efficiency, it may be desirable for a server to advertise support for in-band registration as a stream feature. The namespace for reporting support within <stream:features/> is "http://jabber.org/features/iq-register". Upon receiving a stream header qualified by the 'jabber:client' namespace, a server returns a stream header to the client and MAY announce support for in-band registration by including the relevant stream feature:

              diff --git a/xep-0078.xml b/xep-0078.xml index e58e3915..371b1399 100644 --- a/xep-0078.xml +++ b/xep-0078.xml @@ -7,7 +7,7 @@
              Non-SASL Authentication - This document specifies a protocol for authentication with Jabber servers and services using the jabber:iq:auth namespace. Note Well: The protocol specified herein has been superseded in favor of SASL authentication as specified in RFC 3920, and is now obsolete. + This document specifies a protocol for authentication with Jabber servers and services using the jabber:iq:auth namespace. Note Well: The protocol specified herein has been superseded in favor of SASL authentication as specified in RFC 3920 / RFC 6120, and is now obsolete. &LEGALNOTICE; 0078 Obsolete @@ -19,7 +19,7 @@ - RFC 3920 + RFC 6120 iq-auth @@ -166,7 +166,7 @@
              -

              Note Well: The protocol specified herein has been superseded in favor of SASL authentication as specified in &rfc3920;, and is now obsolete.

              +

              Note Well: The protocol specified herein has been superseded in favor of SASL authentication as specified in &rfc3920; and &rfc6120;, and is now obsolete.

              Jabber technologies have long included a wire protocol that enables a client to authenticate with a server. Component authentication is out of scope for this document, and is specified separately in &xep0114;. The method originally used in the Jabber community makes use of the 'jabber:iq:auth' namespace and has been documented variously in Internet-Drafts and elsewhere. When the core Jabber protocols were formalized by the IETF, the 'jabber:iq:auth' protocol was replaced by the Simple Authentication and Security Layer (SASL) as specified in &rfc4422;. SASL was incorporated into XMPP because it provides a more flexible approach to authentication by enabling XMPP entities to use a wide variety of authentication methods (e.g., PLAIN, DIGEST-MD5, EXTERNAL, and ANONYMOUS), some of which are more secure than the 'jabber:iq:auth' protocol.

              The 'jabber:iq:auth' protocol specified herein is now obsolete. However, because it will take some time for existing implementations and deployments to be upgraded to SASL, client and server software implementations still need to include support for 'jabber:iq:auth' in order to interoperate, and this document provides canonical documentation of the 'jabber:iq:auth' protocol. Nevertheless, implementation and deployment of SASL authentication is strongly recommended, since the 'jabber:iq:auth' protocol will eventually be obsoleted entirely.

               @@ -196,8 +196,8 @@ ]]>               -

              If the client included a username with the IQ-get but there is no such username, the server SHOULD NOT return an error, but instead SHOULD return the normal authentication fields (this helps to prevent unknown users from discovering which usernames are in use). If the server does not support non-SASL authentication (e.g., because it supports only SASL authentication as defined in RFC 3920), it MUST return a &unavailable; error. If the client previously attempted SASL authentication but that attempt failed, the server MUST return a <policy-violation/> stream error (see RFC 3920 regarding stream error syntax).

              -

              Both the username and the resource are REQUIRED for client authentication using the 'jabber:iq:auth' namespace; if more flexible authentication and resource provisioning are desired, a server SHOULD implement SASL authentication and resource binding as defined in RFC 3920 (e.g., to enable the server to provide the resource). The <username/> and <resource/> elements MUST be included in the IQ result returned by the server in response to the initial IQ get, and also MUST be included in the IQ set sent by the client when providing authentication credentials.

              +

              If the client included a username with the IQ-get but there is no such username, the server SHOULD NOT return an error, but instead SHOULD return the normal authentication fields (this helps to prevent unknown users from discovering which usernames are in use). If the server does not support non-SASL authentication (e.g., because it supports only SASL authentication as defined in RFC 6120), it MUST return a &unavailable; error. If the client previously attempted SASL authentication but that attempt failed, the server MUST return a <policy-violation/> stream error (see RFC 6120 regarding stream error syntax).

              +

              Both the username and the resource are REQUIRED for client authentication using the 'jabber:iq:auth' namespace; if more flexible authentication and resource provisioning are desired, a server SHOULD implement SASL authentication and resource binding as defined in RFC 6120 (e.g., to enable the server to provide the resource). The <username/> and <resource/> elements MUST be included in the IQ result returned by the server in response to the initial IQ get, and also MUST be included in the IQ set sent by the client when providing authentication credentials.

              The foregoing stanza shows that the server supports both plaintext authentication (via the <password/> element) and digest authentication with SHA1-encrypted passwords (via the <digest/> element).

              Therefore, in order to successfully authenticate with the server in this example, a client MUST provide a username, a resource, and one of password or digest.

              ]]> -

              Plaintext passwords are straightforward (obviously, characters that map to predefined XML entities MUST be escaped according to the rules defined in section 4.6 of the XML specification, and any non-US-ASCII characters MUST be encoded according to the encoding of XML streams as specified in RFC 3920, i.e., UTF-8 as defined in &rfc3269;).

              +

              Plaintext passwords are straightforward (obviously, characters that map to predefined XML entities MUST be escaped according to the rules defined in section 4.6 of the XML specification, and any non-US-ASCII characters MUST be encoded according to the encoding of XML streams as specified in RFC 6120, i.e., UTF-8 as defined in &rfc3269;).

              The value of the <digest/> element MUST be computed according to the following algorithm:

              1. Concatenate the Stream ID received from the server with the password. In Digest authentication, password characters that map to predefined XML entities SHOULD NOT be escaped as they are for plaintext passwords, but non-US-ASCII characters MUST be encoded as UTF-8 since the SHA-1 hashing algorithm operates on byte arrays.
                2. @@ -237,7 +237,7 @@
              2. There is a resource conflict (i.e., there is already an active session with that resource identifier associated with the same username). The RECOMMENDED behavior is for the server to terminate the existing session and create the new one; however, the server MAY provide the opposite behavior if desired, leading to a conflict error for the newly requested login.
              3. The user did not provide all of the required information (e.g., did not provide a username or resource).
              -

              Although RFC 3920 specifies that error stanzas SHOULD include the original XML sent, error stanzas qualified by the 'jabber:iq:auth' namespace SHOULD NOT do so given the sensitive nature of the information being exchanged.

              +

              Although RFC 6120 specifies that error stanzas SHOULD include the original XML sent, error stanzas qualified by the 'jabber:iq:auth' namespace SHOULD NOT do so given the sensitive nature of the information being exchanged.

              @@ -262,7 +262,7 @@               -

              RFC 3920 defines methods for advertising feature support during stream negotiation. It may be desirable for a server to advertise support for non-SASL authentication as a stream feature. The namespace for reporting support within <stream:features/> is "http://jabber.org/features/iq-auth". Upon receiving a stream header qualified by the 'jabber:client' namespace, a server that returns stream features SHOULD also announce support for non-SASL authentication by including the relevant stream feature. Exactly when a server advertises the iq-auth stream feature is up to the implementation or deployment (e.g., a server MAY advertise this feature only after successful TLS negotiation or if the channel is encrypted via the older SSL method). Obviously, this does not apply to servers that do not support stream features (e.g., older servers that do not comply with XMPP 1.0).

              +

              RFC 6120 defines methods for advertising feature support during stream negotiation. It may be desirable for a server to advertise support for non-SASL authentication as a stream feature. The namespace for reporting support within <stream:features/> is "http://jabber.org/features/iq-auth". Upon receiving a stream header qualified by the 'jabber:client' namespace, a server that returns stream features SHOULD also announce support for non-SASL authentication by including the relevant stream feature. Exactly when a server advertises the iq-auth stream feature is up to the implementation or deployment (e.g., a server MAY advertise this feature only after successful TLS negotiation or if the channel is encrypted via the older SSL method). Obviously, this does not apply to servers that do not support stream features (e.g., older servers that do not comply with XMPP 1.0).

              @@ -275,7 +275,7 @@

              A server SHOULD NOT advertise non-SASL authentication to another server (i.e., if the initial stream header was qualified by the 'jabber:server' namespace).

               -

              As defined herein, the 'jabber:iq:auth' namespace supports both the old (HTTP-style) error codes and the extensible error classes and conditions specified in RFC 3920. A compliant server or service implementation MUST support both old-style and new-style error handling. A compliant client implementation SHOULD support both.

              +

              As defined herein, the 'jabber:iq:auth' namespace supports both the old (HTTP-style) error codes and the extensible error classes and conditions specified in RFC 6120. A compliant server or service implementation MUST support both old-style and new-style error handling. A compliant client implementation SHOULD support both.

              In accordance with Section 8 of &xep0001;, on 2004-10-20 this document was advanced to a status of Final with the understanding that it would expire in six months. On 2006-09-13, the Jabber Council (now XMPP Council) changed the status of this document to Deprecated. The Jabber Council will review this document every six months to determine whether to change its status to Obsolete or to extend the expiration date for an additional six months; this process will continue until the document is obsoleted. For the latest expiration date, refer to the XEP Information block at the beginning of this document.

              @@ -310,7 +310,7 @@ NOTE WELL: Non-SASL Authentication via the jabber:iq:auth protocol has been superseded by SASL Authentication as - defined in RFC 3920, and is now obsolete. + defined in RFC 3920 and RFC 6120, and is now obsolete. For historical purposes, the protocol documented by this schema is defined in XEP-0078: @@ -349,7 +349,7 @@ NOTE WELL: Non-SASL Authentication via the jabber:iq:auth protocol has been superseded by SASL Authentication as - defined in RFC 3920, and is now obsolete. + defined in RFC 3920 and RFC 6120, and is now obsolete. For historical purposes, the protocol documented by this schema is defined in XEP-0078: diff --git a/xep-0100.xml b/xep-0100.xml index f83b3a8e..65dfc5e4 100644 --- a/xep-0100.xml +++ b/xep-0100.xml @@ -119,7 +119,7 @@
              Server
              -
              An instant messaging server as defined in RFC 3921.
              +
              An instant messaging server as defined in RFC 6121.
                             @@ -258,7 +258,7 @@

            7. If Gateway logged into Legacy Service in preceding step, Gateway buffers any translatable events (e.g., messages and presence) queued up for Jabber User on Legacy Service.

            8. -

              Optionally, Jabber User sends IQ-set qualified by the 'jabber:iq:roster' namespace to its server (see &rfc3921;), containing a roster item for Gateway.

              +

              Optionally, Jabber User sends IQ-set qualified by the 'jabber:iq:roster' namespace to its server (see &xmppcore;), containing a roster item for Gateway.

              ]]> -

              Note: As specified in RFC 3921, Jabber User's server will generate a "roster push" at this point if client did not previously perform a roster set to add Gateway to user's roster (as mentioned above).

              +

              Note: As specified in RFC 6121, Jabber User's server will generate a "roster push" at this point if client did not previously perform a roster set to add Gateway to user's roster (as mentioned above).

            9. Jabber User sends subscription request to Gateway (i.e., by sending a presence stanza of type "subscribe" to Gateway).

              @@ -608,7 +608,7 @@ from='romeo@montague.lit' to='CapuletNurse@aim.shakespeare.lit'/> ]]> -

              Note: As specified in RFC 3921, sending this packet will result in a "roster push" from the Server to all of the Jabber User's available resources.

              +

              Note: As specified in RFC 6121, sending this packet will result in a "roster push" from the Server to all of the Jabber User's available resources.

            10. Gateway transforms subscription request and routes it to Legacy User.

            11. @@ -682,7 +682,7 @@ ]]>
            12. -

              Server sends normal "roster push" to Jabber User (see RFC 3921) and sends presence stanzas of type "unsubscribe", "unsubscribed", and "unavailable" to Legacy User.

              +

              Server sends normal "roster push" to Jabber User (see RFC 6121) and sends presence stanzas of type "unsubscribe", "unsubscribed", and "unavailable" to Legacy User.

              ]]>
              13. -

            13. Jabber User's server performs defined functionality for handling presence stanzas of type "unsubscribe" and "unsubscribed" (see RFC 3921).

              14. +

            14. Jabber User's server performs defined functionality for handling presence stanzas of type "unsubscribe" and "unsubscribed" (see RFC 6121).

            15. Use Case Ends.

            @@ -850,7 +850,7 @@ Art thou not Romeo, and a Montague? ]]> -

            Note: If the Legacy Service to which the Gateway connects does not support a concept equivalent to that of Jabber "resources" as described in &rfc3920;, the 'from' address of message stanzas generated by a gateway SHOULD NOT include a resource identifier (i.e., they SHOULD be of the form <user@host> rather than <user@host/resource>). However, the 'from' address MAY include a resource if the Gateway determines that this is appropriate in the context of its communications with the Legacy Service.

            +

            Note: If the Legacy Service to which the Gateway connects does not support a concept equivalent to that of Jabber "resources" as described in &rfc6120;, the 'from' address of message stanzas generated by a gateway SHOULD NOT include a resource identifier (i.e., they SHOULD be of the form <user@host> rather than <user@host/resource>). However, the 'from' address MAY include a resource if the Gateway determines that this is appropriate in the context of its communications with the Legacy Service.

          4. Jabber User's Server delivers message or (optionally) stores it for later retrieval.

          5. Use Case Ends.

            6. @@ -950,7 +950,7 @@ -

            Some legacy services maintain server-side contact lists, which are sent to the gateway when it logs in to the legacy service on behalf of the user. The gateway MAY initiate adding of the legacy contact list items to the user's Jabber roster. Some existing gateways do this by sending a presence stanza of type "subscribed" from the legacy contact's JID (e.g., <LegacyUser@gateway.jabberserver.com>) to the Jabber user; unfortunately, this behavior violates the presence stanza handling rules specified in RFC 3921. Therefore, a gateway SHOULD instead send the legacy contact list items to the Jabber User via the &xep0144; protocol.

            +

            Some legacy services maintain server-side contact lists, which are sent to the gateway when it logs in to the legacy service on behalf of the user. The gateway MAY initiate adding of the legacy contact list items to the user's Jabber roster. Some existing gateways do this by sending a presence stanza of type "subscribed" from the legacy contact's JID (e.g., <LegacyUser@gateway.jabberserver.com>) to the Jabber user; unfortunately, this behavior violates the presence stanza handling rules specified in RFC 6121. Therefore, a gateway SHOULD instead send the legacy contact list items to the Jabber User via the &xep0144; protocol.

            The following business rules apply:

            diff --git a/xep-0111.xml b/xep-0111.xml index c4db77d4..cf834d45 100644 --- a/xep-0111.xml +++ b/xep-0111.xml @@ -76,7 +76,7 @@

            Note Well: This proposal has been retracted by the authors in favor of &xep0166;.

            -

            The Session Description Protocol (SDP; see &rfc2327;) provides a mechanism for describing multimedia sessions that are advertised and negotiated over the Internet. The "Transport for Initiating and Negotiating Sessions" (TINS) specified herein describes how to use SDP to build a framework for media stream/session initiation and negotiation between entities that natively support XMPP (see &rfc3920;). +

            The Session Description Protocol (SDP; see &rfc2327;) provides a mechanism for describing multimedia sessions that are advertised and negotiated over the Internet. The "Transport for Initiating and Negotiating Sessions" (TINS) specified herein describes how to use SDP to build a framework for media stream/session initiation and negotiation between entities that natively support XMPP (see &xmppcore;). The approach taken herein is to send pure SDP. While earlier versions of this document used &sdpng; (an XML representation of SDP), SDPng is a more experimental technology; by contrast, SDP is a stable protocol and there is broad support for it by existing gateways and devices. The use of SDP rather than SDPng thus enables the Jabber/XMPP community to implement solutions that are deployable on the Internet today. In particular, TINS provides an XMPP representation of standard session management semantics such as those provided by the Session Initiation Protocol (SIP; see &rfc3261;). As a result, native XMPP clients that support TINS can negotiate out-of-band multimedia sessions (e.g., use of the Real-Time Transport Protocol or RTP; see &rfc3550;) and XMPP services that support TINS can easily interoperate with SIP services through gateways.

             @@ -90,7 +90,7 @@

            TINS exchanges are completed by sending &MESSAGE; stanzas containing a child <tins/> element qualified by the 'http://jabber.org/protocol/tins' namespace. - While it may seem that the semantics of &IQ; stanzas are more appropriate, RFC 3261 allows entities to send multiple results in response to a SIP request, which does not map to the syntax of the &IQ; stanza as defined in RFC 3920. + While it may seem that the semantics of &IQ; stanzas are more appropriate, RFC 3261 allows entities to send multiple results in response to a SIP request, which does not map to the syntax of the &IQ; stanza as defined in RFC 6120. In order to track the structure of the TINS "conversation", the &THREAD; child of &MESSAGE; MAY also be included. The <tins/> element MUST possess a 'method' attribute, whose value SHOULD be either an IANA-registered value for a SIP method or "result", as described below. The following SIP methods will probably be used most frequently in TINS interactions:

            • INVITE -- Used to invite the target user to an out-of-band session. The content inside the <tins/> element MAY be SDP descriptions of the connection types offered. If a session is already established for this transaction, the new INVITE serves as a renegotiation of session parameters.

              • @@ -273,7 +273,7 @@ -

              TINS is subject to the same security considerations as XMPP, particularly with regard to authentication and channel encryption; for details, refer to RFC 3920.

              +

              TINS is subject to the same security considerations as XMPP, particularly with regard to authentication and channel encryption; for details, refer to RFC 6120.

              This document does not describe how the media protocols (e.g. RTP) traverse firewalls and NATs.

              There is no general-purpose way to ensure that media protocol connections are associated with the in-band TINS conversation.

               diff --git a/xep-0124.xml b/xep-0124.xml index 030384b6..849766ba 100644 --- a/xep-0124.xml +++ b/xep-0124.xml @@ -159,7 +159,7 @@

              The Transmission Control Protocol (TCP; &rfc0793;) is often used to establish a stream-oriented connection between two entities. Such connections can often be long-lived to enable an interactive "session" between the entities. However, sometimes the nature of the device or network can prevent an application from maintaining a long-lived TCP connection to a server or peer. In this case, it is desirable to use an alternative connection method that emulates the behavior of a long-lived TCP connection using a sequenced series of requests and responses that are exchanged over short-lived connections. The appropriate request-response semantics are widely available via the Hypertext Transfer Protocol (HTTP) as specified in &rfc1945; and &rfc2616;.

              BOSH, the technology defined in this specification, essentially provides a "drop-in" alternative to a long-lived, bidirectional TCP connection. It is a mature, full-featured technology that has been widely implemented and deployed since 2004. To our knowledge it was the first of many similar technologies, which now include the Comet methodology formalized in the &bayeux; as well as &websocket; and &rhttp;.

              BOSH is designed to transport any data efficiently and with minimal latency in both directions. For applications that require both "push" and "pull" semantics, BOSH is significantly more bandwidth-efficient and responsive than most other bidirectional HTTP-based transport protocols and the techniques now commonly known as "Ajax". BOSH achieves this efficiency and low latency by using so-called "long polling" with multiple synchronous HTTP request/response pairs. Furthermore, BOSH can address the needs of constrained clients by employing fully-compliant HTTP 1.0 without the need for "cookies" (see &rfc2965;) Requiring cookies is sub-optimal because several significant computing platforms provide only limited access to underlying HTTP requests/responses; worse, some platforms hide or remove cookie-related headers. or even access to HTTP headers.

              -

              BOSH was originally developed in the Jabber/XMPP community as a replacement for an even earlier HTTP-based technology called &xep0025;. Although BOSH assumes that the "payload" of HTTP requests and responses will be XML, the payload formats are not limited to XMPP stanzas (see &rfc3920;) and could contain a mixture of elements qualified by namespaces defined by different protocols (e.g., both XMPP and JSON). This mix is necessary because some connection managers might not support Multiple Streams and constrained clients often have no access to HTTP Pipelining (which limits them to one BOSH session at a time). BOSH connection managers are generally not required to understand anything about the XML content that they transport beyond perhaps ensuring that each XML payload is qualified by the correct namespace.

              +

              BOSH was originally developed in the Jabber/XMPP community as a replacement for an even earlier HTTP-based technology called &xep0025;. Although BOSH assumes that the "payload" of HTTP requests and responses will be XML, the payload formats are not limited to XMPP stanzas (see &xmppcore;) and could contain a mixture of elements qualified by namespaces defined by different protocols (e.g., both XMPP and JSON). This mix is necessary because some connection managers might not support Multiple Streams and constrained clients often have no access to HTTP Pipelining (which limits them to one BOSH session at a time). BOSH connection managers are generally not required to understand anything about the XML content that they transport beyond perhaps ensuring that each XML payload is qualified by the correct namespace.

              Note: &xep0206; documents some XMPP-specific extensions of this protocol that were formerly included in this document.

              @@ -229,7 +229,7 @@

            • Internal or external DTD subsets

            • Internal or external entity references (with the exception of predefined entities)

            -

            The <body/> wrapper MUST NOT contain any XML character data, although its child elements MAY contain character data. The <body/> wrapper MUST contain zero or more complete XML immediate child elements (called "payloads" in this document, e.g., XMPP stanzas as defined in RFC 3920 or elements containing XML character data that represents objects using the JSON data interchange format as defined in &rfc4627;). Each <body/> wrapper MAY contain payloads qualified under a wide variety of different namespaces.

            +

            The <body/> wrapper MUST NOT contain any XML character data, although its child elements MAY contain character data. The <body/> wrapper MUST contain zero or more complete XML immediate child elements (called "payloads" in this document, e.g., XMPP stanzas as defined in RFC 6120 or elements containing XML character data that represents objects using the JSON data interchange format as defined in &rfc4627;). Each <body/> wrapper MAY contain payloads qualified under a wide variety of different namespaces.

            The <body/> element of every client request MUST possess a sequential request ID encapsulated via the 'rid' attribute; for details, refer to the Request IDs section of this document.

             @@ -516,7 +516,7 @@ Content-Length: 153 ]]> -

            The connection manager SHOULD return to the client an HTTP 200 OK response with an empty <body/> element.

            +

            The connection manager SHOULD respond to this request with an HTTP 200 OK containing an empty <body/> element.

            In any response it sends to the client, the connection manager MAY return a fatal error by setting a 'type' attribute of the <body/> element to "terminate". These binding errors imply that the HTTP session is terminated (unless a 'stream' attribute is specified -- see Multiple Stream Error Conditions).

            -

            Note: Although many of these conditions are similar to the XMPP stream error conditions specified in RFC 3920, they are not to be confused with XMPP stream errors. In cases where BOSH is being used to transport XMPP, any fatal XMPP stream error conditions experienced between the connection manager and the XMPP server SHOULD only be reported using the "remote-stream-error" condition as described below.

            +

            Note: Although many of these conditions are similar to the XMPP stream error conditions specified in RFC 6120, they are not to be confused with XMPP stream errors. In cases where BOSH is being used to transport XMPP, any fatal XMPP stream error conditions experienced between the connection manager and the XMPP server SHOULD only be reported using the "remote-stream-error" condition as described below.

            -

            An IM user may want to be informed when a contact creates an IM account. If the user knows some information about the contact (e.g., a phone number or email address), the user's service can use that information to place the contact on a "waiting list", then inform the user when the contact creates an IM account. This document defines an extension to &rfc3920; and &rfc3921; that enables such "waiting list" functionality, including the ability to add contacts on other domains if service providers agree to interoperate (e.g., to add a contact who uses a different mobile telephony service provider).

            +

            An IM user may want to be informed when a contact creates an IM account. If the user knows some information about the contact (e.g., a phone number or email address), the user's service can use that information to place the contact on a "waiting list", then inform the user when the contact creates an IM account. This document defines an extension to &xmppcore; and &xmppim; that enables such "waiting list" functionality, including the ability to add contacts on other domains if service providers agree to interoperate (e.g., to add a contact who uses a different mobile telephony service provider).

            Note: The protocol defined herein is currently in use at several large service providers in Europe. Others are welcome to use the protocol.

             @@ -516,7 +516,7 @@ ]]>             -

            As described below, various error conditions may occur. (For information about error syntax, refer to RFC 3920 and &xep0086;.)

            +

            As described below, various error conditions may occur. (For information about error syntax, refer to RFC 6120 and &xep0086;.)

            If the IM User provided a URI whose scheme is not supported, WaitingListService MUST return a &badrequest; error to the IM User and MUST NOT add the Contact to the WaitingList.

            Informational Standards - RFC 3920 + RFC 6120 XEP-0050 @@ -763,7 +763,7 @@ ]]> -

            The data form included in the IQ result will include the user's roster, formatted according to the 'jabber:iq:roster' protocol defined in &rfc3921;.

            +

            The data form included in the IQ result will include the user's roster, formatted according to the 'jabber:iq:roster' protocol defined in &xmppim;.

             -

            The service may enable an administrator to define one or more service-wide blacklists (lists of entities that are blocked from communications to or from the service). For example, a multi-user chat service may forbid a certain user from joining any room on the service, or may block entire domains from accessing the service. An entity specified on the blacklist MAY be a JID of any form as specified in &rfc3920;; the order of JID matching SHOULD be that specified for privacy lists in Section 10 of RFC 3921.

            +

            The service may enable an administrator to define one or more service-wide blacklists (lists of entities that are blocked from communications to or from the service). For example, a multi-user chat service may forbid a certain user from joining any room on the service, or may block entire domains from accessing the service. An entity specified on the blacklist MAY be a JID of any form as specified in &rfc6120;; the order of JID matching SHOULD be that specified for privacy lists in &xep0016;.

            A blacklist may prevent inbound communications, outbound communications, or both; whether to offer only bidirectional blocking or a more granular choice of inbound or outbound blocking is a matter of implementation or deployment policy. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#edit-blacklist" if blocking is bidirectional as shown below; "http://jabber.org/protocol/admin#add-to-blacklist-in" for inbound blocking only; and "http://jabber.org/protocol/admin#add-to-blacklist-out" for outbound blocking only.

            A sample protocol flow for this use case is shown below.

             -

            The service may enable an administrator to define one or more service-wide whitelists (lists of entities that are allowed to communicate the service). For example, a publish-subscribe may allow only a select list of users to publish or subscribe to nodes hosted on the service. An entity added to a whitelist MAY be a JID of any form as specified in RFC 3920; the order of JID matching SHOULD be that specified for privacy lists in Section 10 of RFC 3921.

            +

            The service may enable an administrator to define one or more service-wide whitelists (lists of entities that are allowed to communicate the service). For example, a publish-subscribe may allow only a select list of users to publish or subscribe to nodes hosted on the service. An entity added to a whitelist MAY be a JID of any form as specified in RFC 6120; the order of JID matching SHOULD be that specified for privacy lists in &xep0016;.

            As with blacklists, a whitelist may prevent inbound communications, outbound communications, or both; whether to offer only bidirectional blocking or a more granular choice of inbound or outbound blocking is a matter of implementation or deployment policy. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#add-to-whitelist" if blocking is bidirectional; "http://jabber.org/protocol/admin#add-to-whitelist-in" for inbound blocking only; and "http://jabber.org/protocol/admin#add-to-whitelist-out" for outbound blocking only.

            A sample protocol flow for this use case is shown below.

             -

            It may be helpful to enable an administrator to retrieve the number of registered users who are online at any one moment. By "online user" is meant any user or account that currently has at least one connected or available resource as specified in RFC 3920 and RFC 3921, whether that user is actively sending XML stanzas or is idle. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-online-users-num".

            +

            It may be helpful to enable an administrator to retrieve the number of registered users who are online at any one moment. By "online user" is meant any user or account that currently has at least one connected or available resource as specified in RFC 6120 and RFC 6121, whether that user is actively sending XML stanzas or is idle. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-online-users-num".

            A sample protocol flow for this use case is shown below.

            ]]> -

            Note: The <not-modified/> error condition is not specified as a stanza error condition in &rfc3920; and an error code of 304 was not included in the older Jabber error codes (see &xep0086;). However, the <not-modified/> error condition is included in &rfc6120;.

            +

            Note: The <not-modified/> error condition is not specified as a stanza error condition in &rfc3920; and an error code of 304 was not included in the older Jabber error codes (see &xep0086;). However, the <not-modified/> error condition is included in &xmppcore;.

            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 &xep0072; and in certain applications that use &xep0004;.

             -

            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.

            +

            As specified in &xmppim;, 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 6121 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:

            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 &xep0054;); 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).

              • -

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

              • +

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

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

             @@ -82,7 +82,7 @@ ]]>

            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 &rfc4646; (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 the personal eventing protocol.

            +

            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 &rfc4646; (although the default language MAY be specified at the stanza level; see &rfc6120;). 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 the personal eventing protocol.

            @@ -201,7 +201,7 @@ -

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

            +

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

             diff --git a/xep-0153.xml b/xep-0153.xml index 78ef8669..f014c553 100644 --- a/xep-0153.xml +++ b/xep-0153.xml @@ -240,7 +240,7 @@

            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 &xep0054;.

            +

            This document introduces no security considerations above and beyond those described in &xmppcore;, &xmppim;, and &xep0054;.

            This document requires no interaction with &IANA;.

            diff --git a/xep-0156.xml b/xep-0156.xml index c87f7664..1be41796 100644 --- a/xep-0156.xml +++ b/xep-0156.xml @@ -92,9 +92,9 @@ -

            Although &rfc3920; specifies the use of TCP as the method of connecting to an XMPP server, alternative connection methods exist, including the &xep0124; method for which &xep0206; is the XMPP profile, the &xep0025; method (now deprecated), 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 alternative connection methods before connecting to an XMPP service, the relevant information needs to 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:

            +

            Although &xmppcore; specifies the use of TCP as the method of connecting to an XMPP server, alternative connection methods exist, including the &xep0124; method for which &xep0206; is the XMPP profile, the &xep0025; method (now deprecated), 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 alternative connection methods before connecting to an XMPP service, the relevant information needs to 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. Define 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 can 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. Define 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 can 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 6120.

            3. Define a way to specify alternative connection methods 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).

            4. Define a way to specify alternative connection methods 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 not meet the requirements for discovery of alternative connection methods.

            5. Define a way to specify alternative connection methods using the "URI-enabled NAPTR" (U-NAPTR) profile of the Dynamic Delegation Discovery System (see &rfc4848;). While this is a valid approach that is worth pursuing, the authors are concerned about the deployability of such an approach given the rarity of support for DDDS and U-NAPTR, especially in client-side applications (the main focus of this specification).

              6. @@ -120,8 +120,8 @@

              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. The point of this rule is to prevent someone from defining a new XEP-0156 connection method like "_xmpp-client-tcp" to override the SRV records defined in the core XMPP specification.
                2. -
              2. A domain SHOULD NOT present information in DNS TXT records that is available via the DNS SRV records defined in RFC 3920.
                3. +
              3. TXT lookups MUST be used only as a fallback after the methods specified in RFC 6120 have been exhausted. The point of this rule is to prevent someone from defining a new XEP-0156 connection method like "_xmpp-client-tcp" to override the SRV records defined in the core XMPP specification.
                4. +
              4. A domain SHOULD NOT present information in DNS TXT records that is available via the DNS SRV records defined in RFC 6120.
              5. The order of DNS TXT records SHOULD NOT be interpreted as significant by the presenting domain or the receiving entity.
               diff --git a/xep-0157.xml b/xep-0157.xml index bc7f8194..1001b4bd 100644 --- a/xep-0157.xml +++ b/xep-0157.xml @@ -83,7 +83,7 @@ -

              &rfc2142; specifies conventional electronic mailbox names for common services, roles, and functions related to SMTP, NNTP, and HTTP (such as hostmaster@domain.tld, usenet@domain.tld, and abuse@domain.tld). However, no such conventional email address or XMPP address has been specified for XMPP services (e.g., in &rfc3920;). This document remedies that oversight.

              +

              &rfc2142; specifies conventional electronic mailbox names for common services, roles, and functions related to SMTP, NNTP, and HTTP (such as hostmaster@domain.tld, usenet@domain.tld, and abuse@domain.tld). However, no such conventional email address or XMPP address has been specified for XMPP services (e.g., in &rfc3920;). This document remedies that oversight, and the email recommendation specified here has been incorporated into &rfc6120;.

              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.

              diff --git a/xep-0158.xml b/xep-0158.xml index aa1faed5..9cd70074 100644 --- a/xep-0158.xml +++ b/xep-0158.xml @@ -109,7 +109,7 @@ -

              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 instant messaging spam (a.k.a. "spim") or, in general, abusive traffic. Abusive stanzas could be generated by XMPP clients connected to legitimate servers or by XMPP servers with virtual clients, where the malicious entities are hosted on networks of "zombie" machines. Such abusive stanas could take many forms; a full taxonomy is outside the scope of this document.

              +

              The appearance of large public IM services based on &xmppcore; and &xmppim; makes it desirable to implement protocols that discourage the sending of large quantities of instant messaging spam (a.k.a. "spim") or, in general, abusive traffic. Abusive stanzas could be generated by XMPP clients connected to legitimate servers or by XMPP servers with virtual clients, where the malicious entities are hosted on networks of "zombie" machines. Such abusive stanas could take many forms; a full taxonomy is outside the scope of this document.

              One technique developed to combat abusive messages and behavior via non-XMPP technologies requires 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 XMPP abuse. The very occasional inconvenience of responding to a CAPTCHA (e.g., 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 abusive traffic.

              Both CAPTCHAs and hashcash have been criticized regarding their effectiveness (or lack thereof). Therefore, the challenge protocol specified herein provides a great deal of flexibility, so that challenges can include CAPTCHAs, hashcash, word puzzles, so-called kitten authentication, and any other mechanism that may be developed in the future.

              diff --git a/xep-0159.xml b/xep-0159.xml index 975fddcd..9a4289d4 100644 --- a/xep-0159.xml +++ b/xep-0159.xml @@ -52,7 +52,7 @@ -

              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 instant messaging spam (a.k.a. "spim"). Spim could be generated by XMPP clients connected to legitimate servers or by XMPP servers with virtual clients, where the malicious entities are 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).

              +

              The appearance of large public IM services based on &xmppcore; and &xmppim; makes it desirable to implement protocols that discourage the sending of large quantities of instant messaging spam (a.k.a. "spim"). Spim could be generated by XMPP clients connected to legitimate servers or by XMPP servers with virtual clients, where the malicious entities are 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 spimmer.
                • diff --git a/xep-0160.xml b/xep-0160.xml index ea7f7a73..38ea4be7 100644 --- a/xep-0160.xml +++ b/xep-0160.xml @@ -49,13 +49,13 @@ -

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

                +

                &xmppcore; and &xmppim; 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 RFC 6121). 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 document 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. Sender generates XMPP message stanza This document does not discuss IQ or presence stanzas, handling of which is described in RFC 6120 and RFC 6121. 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 6121 for rules regarding server handling of such XMPP message stanzas).
                  4. +
                4. Recipient's server determines that the intended recipient has no available resources that have specified non-negative presence priority. As specified in RFC 6120, available resources that have specified a negative presence priority shall never receive message stanzas addressed to <node@domain>.
                5. Recipient's server determines that if the server can store offline messages on behalf of the intended recipient; if not (e.g., because the recipient's offline message queue is full), the server returns a &unavailable; error to the sender.
                6. Recipient's server does not return a &unavailable; error but instead stores the message stanza for later delivery.
                7. 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 &xep0013;, although that functionality is not described herein.)
                  8. @@ -94,7 +94,7 @@ ]]> -

                  Message stanzas SHOULD be handled by a server as follows (based on the values of the 'type' attribute specified in RFC 3921):

                  +

                  Message stanzas SHOULD be handled by a server as follows (based on the values of the 'type' attribute specified in RFC 6121):

                  • 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 &xep0085; content (such messages SHOULD NOT be stored offline).

                    • diff --git a/xep-0165.xml b/xep-0165.xml index 622e5e42..279b4c91 100644 --- a/xep-0165.xml +++ b/xep-0165.xml @@ -75,7 +75,7 @@

                    There are two forms of address spoofing: forging and mimicking.

                    In the context of Jabber/XMPP 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 that authenticated as "stpeter@jabber.org" is able to send XML stanzas from "MaineBoy@jabber.org" or "peter@saint-andre.com".

                    -

                    Address forging is difficult in Jabber/XMPP systems given the requirement for sending servers to stamp 'from' addresses and for receiving servers to verify sending domains via server dialback or server-to-server authentication (see &rfc3920;). Difficult, but not impossible: a rogue server could forge JIDs at the sending domain by ignoring the stamping requirement and could even forge JIDs at other domains by means of a DNS poisoning attack. However, discussion of ways to deal with such rogue servers is out of scope for this document.

                    +

                    Address forging is difficult in Jabber/XMPP systems given the requirement for sending servers to stamp 'from' addresses and for receiving servers to verify sending domains via server dialback or server-to-server authentication (see &xmppcore;). Difficult, but not impossible: a rogue server could forge JIDs at the sending domain by ignoring the stamping requirement and could even forge JIDs at other domains by means of a DNS poisoning attack. However, discussion of ways to deal with such rogue servers is out of scope for this document.

                    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 @@ -96,7 +96,7 @@

                    1. The JID "stpeter@jabber.org" is globally unique on the Jabber/XMPP network, but it is not necessarily memorable.

                    2. The nickname "psa" (asserted by the user associated with the address "stpeter@jabber.org") is globally memorable but not necessarily unique; see &xep0172; for more information about user-asserted nicknames.

                      3. -

                    3. The handle or petname "that protocol 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 XEP-0172 and &rfc6121; we refer to this as a "handle". In RFC 3921 this was referred to as an "alias".

                      4. +

                    4. The handle or petname "that protocol 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 XEP-0172 and &xmppim; we refer to this as a "handle". In RFC 6121 this was referred to as an "alias".

                    A client SHOULD require an end user to assign a handle for every contact added to the person's roster, which SHOULD be stored in the roster as the value of the <item/> element's 'name' attribute (see the Security Considerations section of this document for further discussion). 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 discourage mimicked addresses from being presented as equivalent to the address that is being mimicked.

                    diff --git a/xep-0168.xml b/xep-0168.xml index 41ef56ce..b12285c3 100644 --- a/xep-0168.xml +++ b/xep-0168.xml @@ -117,7 +117,7 @@ -

                    Within the Extensible Messaging and Presence Protocol (XMPP; see &rfc3920;), presence indicates availability for communication. Specifically, in systems that bundle presence and instant messaging (see &rfc3921;), the <priority/> child of the XMPP &PRESENCE; stanza indicates availability for communications qualified by the "jabber:client" namespace, especially instant messaging. 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.

                    +

                    Within the Extensible Messaging and Presence Protocol (&xmppcore;), presence indicates availability for communication. Specifically, in systems that bundle presence and instant messaging (see &xmppim;), the <priority/> child of the XMPP &PRESENCE; stanza indicates availability for communications qualified by the "jabber:client" namespace, especially instant messaging. 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 (see &xep0167;) with a user who has the following three XMPP resources:

            diff --git a/xep-0171.xml b/xep-0171.xml index c564217e..2004d990 100644 --- a/xep-0171.xml +++ b/xep-0171.xml @@ -107,7 +107,7 @@ -

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

            +

            There currently exists no standard for describing language translations over a text chat protocol. While numerous products and services exist to provide translation of text, there exists no standardized protocol extension for requesting a translation and expressing the details of the translation over XMPP (see &xmppcore;). 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.

             @@ -380,7 +380,7 @@

            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.

            +

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

            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.

            diff --git a/xep-0198.xml b/xep-0198.xml index 4ab1e56a..e1ea87ce 100644 --- a/xep-0198.xml +++ b/xep-0198.xml @@ -161,7 +161,7 @@
          6. Stream Resumption -- the ability to quickly resume a stream that has been terminated.

            7. Stream management implements these features using short XML elements at the root stream level. These elements are not "stanzas" in the XMPP sense (i.e., not &IQ;, &MESSAGE;, or &PRESENCE; stanzas as defined in &xmppcore;) and are not counted or acked in stream management, since they exist for the purpose of managing stanzas themselves.

            -

            Stream management is used at the level of an XML stream. To check TCP connectivity underneath a given stream, it is RECOMMENDED to use whitespace keepalives (see Section 4.6.1 of &rfc6120;), &xep0199;, or TCP keepalives. By constrast with stream management, &xep0079; and &xep0184; define acks that are sent end-to-end over multiple streams; these facilities are useful in special scenarios but are unnecessary for checking of a direct stream between two XMPP entities.

            +

            Stream management is used at the level of an XML stream. To check TCP connectivity underneath a given stream, it is RECOMMENDED to use whitespace keepalives (see &xmppcore;), &xep0199;, or TCP keepalives. By constrast with stream management, &xep0079; and &xep0184; define acks that are sent end-to-end over multiple streams; these facilities are useful in special scenarios but are unnecessary for checking of a direct stream between two XMPP entities.

            (Examples prepended by "C:" are sent by a client and examples prepended by "S:" are sent by a server. Stream management can be used server-to-server but most of the examples in this specification show its use between a client and a server.)

             diff --git a/xep-0199.xml b/xep-0199.xml index 1a424a13..d08f2db5 100644 --- a/xep-0199.xml +++ b/xep-0199.xml @@ -70,7 +70,7 @@ -

            As specified in &rfc3920;, the XML streams used in XMPP are bound to TCP. Unfortunately, TCP connections can go down without the application (XMPP) layer knowing about it. The traditional approach to solving this issue has been to periodically send so-called "whitespace pings" over the XML stream. This document recommends a more XML-friendly approach, which can be used over more than one hop in the communication path (e.g., from one client to another) and can also be used with other bindings such as the &xep0124; method for which &xep0206; is the XMPP profile.

            +

            As specified in &xmppcore;, the XML streams used in XMPP are bound to TCP. Unfortunately, TCP connections can go down without the application (XMPP) layer knowing about it. The traditional approach to solving this issue has been to periodically send so-called "whitespace pings" over the XML stream. This document recommends a more XML-friendly approach, which can be used over more than one hop in the communication path (e.g., from one client to another) and can also be used with other bindings such as the &xep0124; method for which &xep0206; is the XMPP profile.

             @@ -110,7 +110,7 @@ ]]> -

            The other error conditions defined in RFC 3920 could also be returned if appropriate.

            +

            The other error conditions defined in RFC 6120 could also be returned if appropriate.

            A client may also ping its server by sending an IQ-get over the stream between the two entities.

            @@ -133,7 +133,7 @@ ]]> -

            The other error conditions defined in RFC 3920 could also be returned if appropriate.

            +

            The other error conditions defined in RFC 6120 could also be returned if appropriate.

            Pings can also be used to test a server-to-server connection. This is done by sending an IQ-get over the stream from one server to another.

            @@ -155,7 +155,7 @@ ]]> -

            The other error conditions defined in RFC 3920 could also be returned if appropriate.

            +

            The other error conditions defined in RFC 6120 could also be returned if appropriate.

            Pings can also be used for client-to-client (i.e., end-to-end) pings.

            @@ -187,7 +187,7 @@ ]]> -

            The other error conditions defined in RFC 3920 could also be returned if appropriate.

            +

            The other error conditions defined in RFC 6120 could also be returned if appropriate.

            Pings can also be used for component-to-client pings, for example from a &xep0045; component to a client.

            @@ -207,7 +207,7 @@ id='comp1' type='result'/> ]]> -

            If the pinged entity does not support the ping namespace, RFC 3920 requires it to return a &unavailable; error:

            +

            If the pinged entity does not support the ping namespace, RFC 6120 requires it to return a &unavailable; error:

            ]]> -

            The other error conditions defined in RFC 3920 could also be returned if appropriate.

            +

            The other error conditions defined in RFC 6120 could also be returned if appropriate.

                         @@ -253,7 +253,7 @@ -

            If a server receives a ping request directed to a full JID &LOCALFULL; associated with a registered account but there is no connected resource matching the 'to' address, RFC 3920 requires it to reply with a &unavailable; error and set the 'from' address of the IQ-error to the full JID provided in the 'to' address of the ping request. If a connected resource receives a ping request but it does not want to reveal its network availability to the sender for any reason (e.g., because the sender is not authorized to know the connected resource's availability), then it too MUST reply with a &unavailable; error. This consistency between the server response and the client response helps to prevent presence leaks.

            +

            If a server receives a ping request directed to a full JID &LOCALFULL; associated with a registered account but there is no connected resource matching the 'to' address, RFC 6120 requires it to reply with a &unavailable; error and set the 'from' address of the IQ-error to the full JID provided in the 'to' address of the ping request. If a connected resource receives a ping request but it does not want to reveal its network availability to the sender for any reason (e.g., because the sender is not authorized to know the connected resource's availability), then it too MUST reply with a &unavailable; error. This consistency between the server response and the client response helps to prevent presence leaks.

             diff --git a/xep-0200.xml b/xep-0200.xml index 452e0bcb..71d6b6f5 100644 --- a/xep-0200.xml +++ b/xep-0200.xml @@ -129,8 +129,8 @@

            Alice MAY use this protocol to encrypt only that part of the content of one-to-one &MESSAGE;, &PRESENCE; and &IQ; stanzas that would normally be ignored by the intermediate servers. She MUST NOT encrypt:

            • Stanza wrapper element tags (only stanza content)

              • -

            • <error/> elements RFC 3920 requires that stanzas of type 'error' contain an <error/> child element.

              • -

            • <defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> child elements of <error/> elements. RFC 3920 requires that <error/> elements contain a <defined-condition/> child element.

              • +

            • <error/> elements RFC 6120 requires that stanzas of type 'error' contain an <error/> child element.

              • +

            • <defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> child elements of <error/> elements. RFC 6120 requires that <error/> elements contain a <defined-condition/> child element.

            • &THREAD; elements Applications typically use &THREAD; elements internally to route stanzas to the process handling a session. The content of thread elements MUST be opaque with no semantic meaning and only exact comparisons MAY be made against it.

            • <amp/> elements (see &xep0079;)

            diff --git a/xep-0205.xml b/xep-0205.xml index 1343c71b..225cf4bf 100644 --- a/xep-0205.xml +++ b/xep-0205.xml @@ -59,7 +59,7 @@ -

            A key factor in the reliability and security of network infrastructure is its resilience in the face of denial of service attacks (see &rfc4732;). Although the existing network of servers and clients that communicate via the Extensible Messaging and Presence Protocol (XMPP; see &rfc3920;) has not yet been subject to such attacks, that is no cause for complacency. Therefore this document specifies a set of best practices that server implementations and deployments can follow in order to reduce the likelihood of denial of service attacks on the Jabber network.

            +

            A key factor in the reliability and security of network infrastructure is its resilience in the face of denial of service attacks (see &rfc4732;). Although the existing network of servers and clients that communicate via the Extensible Messaging and Presence Protocol (&xmppcore;) has not yet been subject to such attacks, that is no cause for complacency. Therefore this document specifies a set of best practices that server implementations and deployments can follow in order to reduce the likelihood of denial of service attacks on the Jabber network.

            RFC 4732 defines denial of service as follows:

            @@ -79,9 +79,9 @@

            Numerous potential solutions have been suggested to deal with the threat of denial of service attacks against XMPP servers, including the following:

            1. Limiting the number of connections that a server will accept from a given IP address at any one time. Such a limit may help to prevent automated processes from exhausting the server's resources (such as available ports or XML parser processing resources).

              2. -

            2. Limiting the number of connection attempts (via the TCP binding specified in RFC 3920 or via the &xep0124;) that a server will accept from a given IP address in a given time period. Such a limit may help to prevent automated processes from exhausting the server's resources (such as available ports or XML parser processing capacity).

              3. +

            3. Limiting the number of connection attempts (via the TCP binding specified in RFC 6120 or via the &xep0124;) that a server will accept from a given IP address in a given time period. Such a limit may help to prevent automated processes from exhausting the server's resources (such as available ports or XML parser processing capacity).

            4. Limiting the number of authentication attempts for a given Jabber ID in a given time period. While such a limit may seem beneficial, in fact it might result in locking out the legitimate owner of a Jabber ID if a malicious entity attempts a large number of illegitimate authentication attempts for the Jabber ID; therefore such a limit is not recommended except as described in Section 6.4.5 of &rfc6120;, and it is instead recommended to limit the number of connections and connection attempts on a per-IP basis.

              5. -

            5. Disallowing unauthenticated connections from clients and from peer servers; as mentioned below, this is required by RFC 3920.

              6. +

            6. Disallowing unauthenticated connections from clients and from peer servers; as mentioned below, this is required by RFC 6120.

            7. Limiting the number of XMPP resource identifiers allowed to an account at any one time. This may help to prevent a rogue account from creating an unlimited number of sessions and therefore exhausting the resources of the server's session manager.

            8. Limiting the absolute size in bytes of XML stanzas accepted by the server, or of particular aspects of an XML stanza (e.g., attribute values, element names, XML character data). Limits on particular aspects of an XML stanza are probably not needed, as long as it is possible to limit the absolute size of each XML stanza, since such a limit may help to prevent exhaustion of server resources (e.g., XML parser processing capacity).

            9. Limiting the number of bytes or XML stanzas that a server will accept over a given TCP connection or for a given JabberID in a given time period. Such a limit, which helps to prevent rogue accounts or hijacked clients from flooding the server, is common in existing XMPP server implementations and often goes by the name "karma".

              10. @@ -102,7 +102,7 @@

              If an entity attempts to connect but the maximum number of connection attempts has been reached, the receiving server MUST NOT allow the new connection to proceed. There are no XMPP errors associated with this behavior, since it occurs at the binding (TCP or HTTP) level before an XML stream is initiated.

              -

              In accordance with RFC 3920, a server MUST NOT process XML stanzas (i.e., &MESSAGE;, &PRESENCE;, or &IQ;) from clients that have not yet provided appropriate authentication credentials, and MUST NOT process XML stanzas from peer servers whose identity it has not either authenticated via SASL (see &rfc4422;) or verified via server dialback.

              +

              In accordance with RFC 6120, a server MUST NOT process XML stanzas (i.e., &MESSAGE;, &PRESENCE;, or &IQ;) from clients that have not yet provided appropriate authentication credentials, and MUST NOT process XML stanzas from peer servers whose identity it has not either authenticated via SASL (see &rfc4422;) or verified via server dialback.

              A server implementation SHOULD enable a server administrator to limit the number of resources it will allow an account to bind at any one time.

              diff --git a/xep-0211.xml b/xep-0211.xml index ecc1a2f4..ba8137c7 100644 --- a/xep-0211.xml +++ b/xep-0211.xml @@ -87,12 +87,12 @@
            - - + + - - + + @@ -111,7 +111,6 @@
            Requirement Level
            &rfc3920;REQUIRED *&rfc6120;REQUIRED
            &rfc3921;REQUIRED *&rfc6121;REQUIRED
            &xep0030;RECOMMENDED
            -

            * Note: RFC 3920 and RFC 3921 are currently being revised to correct errors, clarify matters that were underspecified, and incorporate feedback based on implementation and deployment experience gained since RFC 3920 and RFC 3921 were published in 2004. Although the compliance level specified herein refers to RFC 3920 and RFC 3921, developers are also advised to consult &rfc3920bis; and &rfc3921bis;, which provide the most up-to-date and accurate description the core XMPP protocols.

            Some of the protocol specifications referenced herein have their own dependencies; developers must refer to the relevant specifications for further information.

            diff --git a/xep-0212.xml b/xep-0212.xml index f37fcf83..452bfe34 100644 --- a/xep-0212.xml +++ b/xep-0212.xml @@ -81,12 +81,12 @@ Requirement Level - &rfc3920; - REQUIRED * + &rfc6120; + REQUIRED - &rfc3921; - REQUIRED * + &rfc6121; + REQUIRED &xep0030; @@ -94,19 +94,18 @@ &xep0078; - RECOMMENDED ** + RECOMMENDED * &xep0086; - RECOMMENDED ** + RECOMMENDED * &xep0138; RECOMMENDED -

            * Note: RFC 3920 and RFC 3921 are currently being revised to correct errors, clarify matters that were underspecified, and incorporate feedback based on implementation and deployment experience gained since RFC 3920 and RFC 3921 were published in 2004. Although the compliance level specified herein refers to RFC 3920 and RFC 3921, developers are also advised to consult &rfc3920bis; and &rfc3921bis;, which provide the most up-to-date and accurate description the core XMPP protocols.

            -

            ** Note: Support for XEP-0078 and XEP-0086 is recommended for backward compatibility only. It is likely that compliance definitions for future years will remove these recommendations.

            +

            * Note: Support for XEP-0078 and XEP-0086 is recommended for backward compatibility only. It is likely that compliance definitions for future years will remove these recommendations.

            Some of the protocol specifications referenced herein have their own dependencies; developers must refer to the relevant specifications for further information.

            diff --git a/xep-0219.xml b/xep-0219.xml index 96b19ad0..d5c99580 100644 --- a/xep-0219.xml +++ b/xep-0219.xml @@ -67,7 +67,7 @@

            Note: This specification has been retracted by the author because the problem is not compelling and a real solution would be too complicated.

            -

            When two XMPP users communicate, one or both of them may want to know the status of the XMPP communications path (i.e., of all the hops) between them. While the primary motivation is to determine if all the hops are secured via Transport Layer Security (see &rfc5246;) as specified for XMPP in &rfc3920;, more general information about the communications path may also be of interest.

            +

            When two XMPP users communicate, one or both of them may want to know the status of the XMPP communications path (i.e., of all the hops) between them. While the primary motivation is to determine if all the hops are secured via Transport Layer Security (see &rfc5246;) as specified for XMPP in &xmppcore;, more general information about the communications path may also be of interest.

            This document describes a protocol for discovering such information, similar in spirit to the traceroute protocol specified in &rfc1393; but specific to XMPP.

             @@ -183,9 +183,9 @@
          7. If the respondent does not support the hopcheck namespace, it MUST return a &unavailable; error.
          8. If the <hopcheck/> element does not include a 'to' attribute, the respondent MUST return a &badrequest; error.
          9. If the 'to' or 'for' attribute of the <hopcheck/> element contains a JID that is malformed, the respondent MUST return a &badjid; error.
            10. -
          10. If the respondent is a server and the sender is a full JID &LOCALFULL;, the server MUST verify that the JID is a connected resource of the server (per RFC 3920); if it is not, then the respondent MUST return a &forbidden; error.
            11. +
          11. If the respondent is a server and the sender is a full JID &LOCALFULL;, the server MUST verify that the JID is a connected resource of the server (per RFC 6120); if it is not, then the respondent MUST return a &forbidden; error.
          12. If both the sender and the respondent are servers and the domain identifier of the <hopcheck/> element's 'to' attribute does not match a validated domain of the respondent, the respondent MUST return a ¬found; error.
            13. -
          13. If both the sender and the respondent are servers, the JID of the <hopcheck/> element's 'to' is a connected resource of the respondent server, and the JID of the <hopcheck/> element's 'for' is not authorized to know the presence of the target (either via presence subscription or temporary presence sharing via directed presence as defined in &rfc3921;), then the respondent MUST return a &forbidden; error.
            14. +
          14. If both the sender and the respondent are servers, the JID of the <hopcheck/> element's 'to' is a connected resource of the respondent server, and the JID of the <hopcheck/> element's 'for' is not authorized to know the presence of the target (either via presence subscription or temporary presence sharing via directed presence as defined in &xmppim;), then the respondent MUST return a &forbidden; error.
            15.  @@ -214,7 +214,7 @@
            • A Simple Authentication and Security Layer mechanism (see &rfc4422; for the specification and &ianasasl; for a list of registered SASL mechanisms; the names for standardized, non-obsolete mechanisms are used as values of the 'auth' attribute).
            • The obsolete &xep0078; protocol using the "plaintext" or "digest" method.
              • -
            • The server dialback protocol ("dialback") as specified in RFC 3920.
              • +
            • The server dialback protocol ("dialback") as specified in &xep0220;.
                         diff --git a/xep-0233.xml b/xep-0233.xml index 3ac4759b..e1f81722 100644 --- a/xep-0233.xml +++ b/xep-0233.xml @@ -54,7 +54,7 @@

            In certain kinds of XMPP deployments, multiple connection managers associated with the XMPP server can be used to handle requests from connecting clients. In such an architecture, the connection manager might need to communicate the hostname to which the client has connected, or information about alternative connection manager.

            This is especially true in environments that make use of Kerberos V and negotiation of Simple Authentication and Security Layer (SASL) over XMPP, because the client might need additional information about the Kerberos principal so that it can obtain a proper ticket for authentication.

            -

            This scenario was not addressed in &rfc3920;. However, the problem can now be solved using the concept of domain-based service names as described in &rfc5178;. In particular, because XMPP servers typically use the Kerberos V5 ("GSSAPI") SASL mechanism as described in &rfc4752;, they can communicate domain-based names as Kerberos V service principal names as described in &rfc5179;.

            +

            This scenario was not addressed in &rfc3920; or &rfc6120;. However, the problem can now be solved using the concept of domain-based service names as described in &rfc5178;. In particular, because XMPP servers typically use the Kerberos V5 ("GSSAPI") SASL mechanism as described in &rfc4752;, they can communicate domain-based names as Kerberos V service principal names as described in &rfc5179;.

            Therefore this document defines a method for communication of authentication hostnames (especially Kerberos V domain-based service names) in the context of SASL negotiation by XMPP entities.

             @@ -94,7 +94,7 @@             -

            The communication of hostnames during SASL negotiation is not known to introduce new security vulnerabilities. Communication of hostnames SHOULD NOT occur until after the underlying channel has been secured using Transport Layer Security (TLS; &rfc5246;) as described for XMPP in RFC 3920 and RFC 6120. For additional security considerations, refer to RFC5178 and RFC 5179.

            +

            The communication of hostnames during SASL negotiation is not known to introduce new security vulnerabilities. Communication of hostnames SHOULD NOT occur until after the underlying channel has been secured using Transport Layer Security (TLS; &rfc5246;) as described for XMPP in RFC 6120 and RFC 6120. For additional security considerations, refer to RFC5178 and RFC 5179.

             diff --git a/xep-0238.xml b/xep-0238.xml index bc1f79df..33d1b3aa 100755 --- a/xep-0238.xml +++ b/xep-0238.xml @@ -41,7 +41,7 @@

            1. Permissive Federation -- a server accepts a connection from any other peer on the network, even without verifiying the identity of the peer based on DNS lookups. The lack of peer verification or authentication means that domains can be spoofed. Permissive federation was effectively outlawed on the Jabber network in October 2000 with the release of the jabberd 1.2 server, which included support for the newly-developed &xep0220; protocol.

            2. Verified Federation -- a server accepts a connection from a peer only after the identity of the peer has been weakly verified via Server Dialback, based on information obtained via the Domain Name System (DNS) and verification keys exchanged in-band over XMPP. However, the connection is not encrypted. The use of identity verification effectively prevents domain spoofing, but federation requires proper DNS setup and is still subject to DNS poisoning attacks. Verified federation has been the default service policy followed by servers on the open XMPP network from October 2000 until now.

              3. -

            3. Encrypted Federation -- a server accepts a connection from a peer only if the peer supports Transport Layer Security (TLS) as defined for XMPP in &rfc3920; and the peer presents a digital certificate. However, the certificate may be self-signed, in which case mutual authentication is typically not possible. Therefore, after STARTTLS negotiation the parties proceed to weakly verify identity using Server Dialback. This combination results in an encrypted connection with weak identity verification.

              4. +

            4. Encrypted Federation -- a server accepts a connection from a peer only if the peer supports Transport Layer Security (TLS) as defined for XMPP in &xmppcore; and the peer presents a digital certificate. However, the certificate may be self-signed, in which case mutual authentication is typically not possible. Therefore, after STARTTLS negotiation the parties proceed to weakly verify identity using Server Dialback. This combination results in an encrypted connection with weak identity verification.

            5. Trusted Federation -- a server accepts a connection from a peer only if the peer supports Transport Layer Security (TLS) and the peer presents a digital certificate issued by a trusted root certification authority (CA). The list of trusted root CAs is determined by local service policy, as is the level of trust accorded to various types of certificates (i.e., Class 1, Class 2, or Class 3). The use of trusted domain certificates effectively prevents DNS poisoning attacks but makes federation more difficult since typically such certificates are not easy to obtain.

            The remainder of this document describes in more detail the protocol flows that make it possible to deploy verified federation, encrypted federation, and trusted federation. Protocol flows are shown for federation attempts between various combinations to illustrate the interaction between different federation policies.

            @@ -62,7 +62,7 @@ Type 1 Verified Only None - XMPP 0.9 "XMPP 0.9" is the core XML streaming protocol used in the Jabber community before the formalization of XMPP 1.0 by the IETF in RFC 3920, including STARTTLS and SASL. and Server Dialback + XMPP 0.9 "XMPP 0.9" is the core XML streaming protocol used in the Jabber community before the formalization of XMPP 1.0 by the IETF in &rfc3920;, including STARTTLS and SASL. and Server Dialback type1.lit citizen@type1.lit diff --git a/xep-0242.xml b/xep-0242.xml index 1927c45b..3df4d93c 100644 --- a/xep-0242.xml +++ b/xep-0242.xml @@ -59,12 +59,11 @@

            The XMPP Core Client 2009 certification level is defined as follows:

              -
            • &rfc3920; *
              • -
            • &rfc3921; *
              • +
            • &rfc6120;
              • +
            • &rfc6121;
            • &xep0030;
            • &xep0115;
            -

            * Note: RFC 3920 and RFC 3921 are currently being revised to correct errors, clarify matters that were underspecified, and incorporate feedback based on implementation and deployment experience gained since RFC 3920 and RFC 3921 were published in 2004. Although the compliance level specified herein refers to RFC 3920 and RFC 3921, developers are also advised to consult &rfc3920bis; and &rfc3921bis;, which provide the most up-to-date and accurate description the core XMPP protocols.

            The XMPP Advanced Client 2009 certification level is defined as follows:

            diff --git a/xep-0243.xml b/xep-0243.xml index 0e5745c7..4bab01af 100644 --- a/xep-0243.xml +++ b/xep-0243.xml @@ -67,11 +67,10 @@

            The XMPP Core Server 2009 certification level is defined below. Support for these specifications is REQUIRED for compliance purposes.

              -
            • &rfc3920; *
              • -
            • &rfc3921; *
              • +
            • &rfc6120;
              • +
            • &rfc6121;
            • &xep0030;
            -

            * Note: RFC 3920 and RFC 3921 are currently being revised to correct errors, clarify matters that were underspecified, and incorporate feedback based on implementation and deployment experience gained since RFC 3920 and RFC 3921 were published in 2004. Although the compliance level specified herein refers to RFC 3920 and RFC 3921, developers are also advised to consult &rfc3920bis; and &rfc3921bis;, which provide the most up-to-date and accurate description the core XMPP protocols.

            The XMPP Advanced Server 2009 certification level is defined as follows:

            diff --git a/xep-0246.xml b/xep-0246.xml index f819afc2..d97b864f 100644 --- a/xep-0246.xml +++ b/xep-0246.xml @@ -36,7 +36,7 @@ -

            XMPP as defined in &rfc3920; does not support direct interaction between endpoints, since it requires a client to authenticate an XML stream with a "home" server and send of all of its outbound XML stanzas through that server (which potentially can route those stanzas through a peer server for delivery to the intended recipient). However, in some scenarios it is desirable to establish end-to-end XML streams between two endpoints instead of relying on the standard client-server architecture. These scenarios include:

            +

            XMPP as defined in &xmppcore; does not support direct interaction between endpoints, since it requires a client to authenticate an XML stream with a "home" server and send of all of its outbound XML stanzas through that server (which potentially can route those stanzas through a peer server for delivery to the intended recipient). However, in some scenarios it is desirable to establish end-to-end XML streams between two endpoints instead of relying on the standard client-server architecture. These scenarios include:

            • Two endpoints cannot access an XMPP server
            • Two endpoints want to enforce end-to-end encryption
              • @@ -47,7 +47,7 @@ -

              The initiator and recipient essentially follow the process defined in RFC 3920 to establish XML streams between themselves.

              +

              The initiator and recipient essentially follow the process defined in RFC 6120 to establish XML streams between themselves.

              First, the initiator opens an XML stream to the recipient over the negotiated transport.

              ]]> -

              In accordance with &rfc3921bis;, the initial stream header SHOULD include the 'to' and 'from' attributes. In the case of XEP-0174, these SHOULD be the username@machine-name advertised in the PTR record. In the case of Jingle XML Streams, these SHOULD be the bare JIDs &BAREJID; of the entities as communicated via XMPP.

              -

              If the initiator supports stream features and the other stream-related aspects of XMPP 1.0 as specified in RFC 3920, then it SHOULD include the version='1.0' flag as shown in the previous example.

              +

              In accordance with RFC 6120, the initial stream header SHOULD include the 'to' and 'from' attributes. In the case of XEP-0174, these SHOULD be the username@machine-name advertised in the PTR record. In the case of Jingle XML Streams, these SHOULD be the bare JIDs &BAREJID; of the entities as communicated via XMPP.

              +

              If the initiator supports stream features and the other stream-related aspects of XMPP 1.0 as specified in RFC 6120, then it SHOULD include the version='1.0' flag as shown in the previous example.

              The recipient then responds with a stream header as well:

              ]]> -

              If both the initiator and recipient included the version='1.0' flag, the recipient SHOULD also send stream features as specified in RFC 3920:

              +

              If both the initiator and recipient included the version='1.0' flag, the recipient SHOULD also send stream features as specified in RFC 6120:

              diff --git a/xep-0261.xml b/xep-0261.xml index 0dedf89e..ba13750e 100644 --- a/xep-0261.xml +++ b/xep-0261.xml @@ -186,7 +186,7 @@ Initiator Responder -

              Now the initiator can begin sending IBB packets using an IQ-set for each chunk as described in XEP-0047, where the responder will acknowledge each IQ-set in accordance with &rfc3920;.

              +

              Now the initiator can begin sending IBB packets using an IQ-set for each chunk as described in XEP-0047, where the responder will acknowledge each IQ-set in accordance with &xmppcore;.

              Advanced Client - &rfc3920; * + &rfc6120; ✓ ✓ ✓ ✓ - &rfc3921; * + &rfc6121; ✓ ✓ ✓ @@ -111,14 +111,14 @@ &xep0124; ✕ ✕ - ✓ ** + ✓ * ✕ &xep0206; ✕ ✕ - ✓ ** + ✓ * ✕ @@ -139,8 +139,8 @@ &xep0045; ✕ ✕ + ✓ * ✓ ** - ✓ *** &xep0085; @@ -150,9 +150,8 @@ ✓ -

              * RFC 3920 and RFC 3921 are currently being revised to correct errors, clarify matters that were underspecified, and incorporate feedback based on implementation and deployment experience gained since RFC 3920 and RFC 3921 were published in 2004. Although the compliance level specified herein refers to RFC 3920 and RFC 3921, developers are also advised to consult &rfc3920bis; and &rfc3921bis;, which provide the most up-to-date and accurate description the core XMPP protocols.

              -

              ** Support can be enabled via an external component or an internal server module/plugin.

              -

              *** Support for the Entity Use Cases and Occupant Use Cases is REQUIRED; support for the remaining use cases is RECOMMENDED.

              +

              * Support can be enabled via an external component or an internal server module/plugin.

              +

              ** Support for the Entity Use Cases and Occupant Use Cases is REQUIRED; support for the remaining use cases is RECOMMENDED.

              Some of the protocol specifications referenced herein have their own dependencies; developers need to consult the relevant specifications for further information.

              diff --git a/xep-0271.xml b/xep-0271.xml index c598e4af..028cb5b0 100755 --- a/xep-0271.xml +++ b/xep-0271.xml @@ -44,7 +44,7 @@ -

              Both &xep0030; and &xep0060; refer to "nodes" in relation to XMPP entities. However, the concept of an XMPP node has never been clearly specified (e.g., in &rfc3920;). This document attempts to remedy that oversight.

              +

              Both &xep0030; and &xep0060; refer to "nodes" in relation to XMPP entities. However, the concept of an XMPP node has never been clearly specified (e.g., in &rfc3920; or &rfc6120;). This document attempts to remedy that oversight.

              To clarify the nature of a node, it is first helpful to describe the architecture of XMPP systems.

              @@ -114,7 +114,7 @@ xmpp:romeo@example.org?;node=foo

              An XMPP node can include any UTF-8 character.

               -

              This specification introduces no security considerations above and beyond those discussed in RFC 3920, XEP-0030, XEP-0060.

              +

              This specification introduces no security considerations above and beyond those discussed in RFC 6120, XEP-0030, XEP-0060.

              This document requires no interaction with &IANA;.

              diff --git a/xep-0274.xml b/xep-0274.xml index 7d133e85..a596f99f 100644 --- a/xep-0274.xml +++ b/xep-0274.xml @@ -437,7 +437,7 @@ ]]> -

              The example.com server is required, per &rfc3920;, to add a 'from' attribute to the +

              The example.com server is required, per &xmppcore;, to add a 'from' attribute to the &MESSAGE; element before forwarding it to the example.net server. The example.net server is required to replace the 'to' attribute with the full JID of the romeo@example.net client it intends to forward the message to. These alternatations will "break" the signature.

              diff --git a/xep-0279.xml b/xep-0279.xml index 4e76e8f6..64c35c4e 100755 --- a/xep-0279.xml +++ b/xep-0279.xml @@ -97,7 +97,7 @@               -

              &rfc3920; specifies that client IP addresses shall not be made public. If a client requests its own IP address, that policy is not violated. However, a server MUST NOT return the IP address of another client (e.g., if a connected client sends a SIC request to the bare JID of another user); instead, it MUST return a &forbidden; error.

              +

              &xmppcore; specifies that client IP addresses shall not be made public. If a client requests its own IP address, that policy is not violated. However, a server MUST NOT return the IP address of another client (e.g., if a connected client sends a SIC request to the bare JID of another user); instead, it MUST return a &forbidden; error.

               diff --git a/xep-0283.xml b/xep-0283.xml index 3d411261..a3c69fdf 100644 --- a/xep-0283.xml +++ b/xep-0283.xml @@ -97,15 +97,14 @@

              This XEP defines an approach for communicating that your JID has moved to a new JID, extending the existing subscription protocol documented - in &rfc3921;. The steps outlined here may be done either through a client + in &xmppim;. The steps outlined here may be done either through a client or automated by a server.

                -
              • The methods described here maintain compatibility with &rfc3920; and - &rfc3921;
                • +
              • The methods described here maintain compatibility with &xmppcore; and RFC 6121.
               diff --git a/xep-0288.xml b/xep-0288.xml index f5eee4f8..f44e1a23 100644 --- a/xep-0288.xml +++ b/xep-0288.xml @@ -56,7 +56,7 @@ -

              &rfc3920; restricts server-to-server communication in such a way that a server has to use on TCP connection for XML stanzas sent from the server to the peer and another TCP connection (initiated by the peer) for stanzas from the peer to the server, for a total of two TCP connections. &rfc6120; allows two servers to send stanzas in a bidirectional way, but does not define methods for explicitly signalling the usage thereof. This is accomplished in this specification.

              +

              &xmppcore; restricts server-to-server communication in such a way that a server has to use on TCP connection for XML stanzas sent from the server to the peer and another TCP connection (initiated by the peer) for stanzas from the peer to the server, for a total of two TCP connections. &rfc6120; allows two servers to send stanzas in a bidirectional way, but does not define methods for explicitly signalling the usage thereof. This is accomplished in this specification.

               -rfc3920bis rfc3920bis: proposed revisions to Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/draft-ietf-xmpp-3920bis>. (work in progress)" > -rfc3921bis rfc3921bis: proposed revisions to Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/draft-ietf-xmpp-3921bis>. (work in progress)" > - XMPP Extensible Messaging and Presence Protocol (XMPP) <http://xmpp.org/>." > XMPP Core RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>." > XMPP IM RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc6121>." >