From 6d0d7deebaa27a64f086589f59ce2aadd492669c Mon Sep 17 00:00:00 2001
From: Guus der Kinderen The &XSF; adheres to an open standards process that enables interested parties to document existing protocols used within the Jabber/XMPP developer community and to submit proposals that define new protocols; with a few exceptions, The &XSF; adheres to an open standards process that enables interested parties to document existing protocols used within the Jabber/XMPP developer community and to submit proposals that define new protocols; with a few exceptions, Advancement of a XEP through the XSF's standards process is contingent on three factors: The ®ISTRAR; performs a function similar to the IANA, although limited to the XMPP developer community. It does so by reserving protocol namespaces and by uniquely assigning parameters for use in the context of XMPP protocols (for example, the categories and types used in &xep0030;). Whether or not a XEP requires registration of protocol namespaces or parameters with the XMPP Registrar, that fact must be noted and explained in a distinct section of the XEP entitled "XMPP Registrar Considerations". Such registration should not occur until a XEP advances to a status of Stable (Standards Track XEPs) or Active (Informational and Historical XEPs). Registration of protocol namespaces is initiated by the XMPP Extensions Editor when a XEP advances to Stable or Active. Registration of particular parameters used within a specification may be initiated by a XEP author within the text of the XEP, or by an implementor of the XEP after it has advanced to Stable or Active. For details regarding the XMPP Registrar and its processes, refer to XEP-0053. Whether or not a XEP requires registration of protocol namespaces or parameters with the XMPP Registrar, that fact must be noted and explained in a distinct section of the XEP entitled "XMPP Registrar Considerations". Such registration should not occur until a XEP advances to a status of Stable (Standards Track XEPs) or Active (Informational and Historical XEPs). Registration of protocol namespaces is initiated by the XMPP Extensions Editor when a XEP advances to Stable or Active. Registration of particular parameters used within a specification may be initiated by a XEP author within the text of the XEP, or by an implementor of the XEP after it has advanced to Stable or Active. For details regarding the XMPP Registrar and its processes, refer to &xep0053;. A XEP may also request that a new registry is to be created by the XMPP Registrar. The XEP author must clearly define the nature of the new registry as well as the process for submitting data to the registry, and should do so in collaboration with the Registrar. The information contained in an IQ reply for this namespace is inherently ambiguous. Specifically, for a bare JID &LOCALBARE; the information is the time since the JID was last connected to its server; for a full JID &LOCALFULL; the information is the time since the resource was last active in the context of an existing session; and for a bare domain the information is the uptime for the server or component. An application MUST take these differences into account when presenting the information to a human user (if any). A server MUST NOT allow an unauthorized entity to learn a user's network availability by sending a Last Activity request to a JID of the form &LOCALBARE; or &LOCALFULL;, since doing so would constitute a "presence leak" as described in RFC 6120. That is, Last Activity information MAY be divulged only to those entities that have permission to view the user's presence via a presence subscription (potentially as restricted by &xep0016; or &xep0191;). A server MUST NOT allow an unauthorized entity to learn a user's network availability by sending a Last Activity request to a JID of the form &LOCALBARE; or &LOCALFULL;, since doing so would constitute a "presence leak" as described in &rfc6120;. That is, Last Activity information MAY be divulged only to those entities that have permission to view the user's presence via a presence subscription (potentially as restricted by &xep0016; or &xep0191;). A client MUST provide a way for a human user to disable sending of Last Activity responses from the client's full JID &LOCALFULL;. If the server supports this protocol, it MUST return a <feature/> element in the disco result with the 'var' attribute set to the namespace name for this protocol: 'http://jabber.org/protocol/offline'. RFC 1939 includes a feature (the "STAT" command) that enables a user to determine how many messages are waiting to be retrieved (without retrieving all of the headers). Such a feature would be helpful in Jabber/XMPP as well, especially if the client is constrained with regard to storage capacity or available bandwidth. &rfc1939; includes a feature (the "STAT" command) that enables a user to determine how many messages are waiting to be retrieved (without retrieving all of the headers). Such a feature would be helpful in Jabber/XMPP as well, especially if the client is constrained with regard to storage capacity or available bandwidth. In order to determine the number of messages in the offline message queue, the user sends a disco#info request without a 'to' address (i.e., implicitly to the user himself) and with the disco node specified as 'http://jabber.org/protocol/offline': Almost all types of Instant Messaging (IM) applications have found it necessary to develop some method for a user to block the receipt of messages and packets from other users (the rationale for such blockage depends on the needs of the individual user). This document defines a flexible method for communications blocking. Note: The protocol specified herein MAY be used in conjunction with &xep0191;; see XEP-0191 for details. Note: The protocol specified herein MAY be used in conjunction with &xep0191;; see &xep0191; for details. 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 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 the type is "subscription", then the 'value' attribute MUST be one of "both", "to", "from", or "none" as defined &rfc6121;, 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". 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.) 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). 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. 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. 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. 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 &rfc6121;. 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 &rfc6121; and (2) the handling of subscription-related presence stanzas (and corresponding generation of roster pushes) specified in RFC 6121. 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/>. 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. If no fall-through item is provided in a list, the fall-through action is assumed to be "allow". 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 6121). 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 &rfc6121;). 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. 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: If the foregoing suggestions are followed, the user will appear offline to the contact. 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 6120 and RFC 6121. If properly implemented, this protocol extension does not introduce any new security concerns above and beyond those defined in &rfc6120; and RFC 6121. No interaction with &IANA; is required as a result of this specification.
- Jabber based services that wish to comply to this document have to make sure that all information they send to clients is tagged with an xml:lang attribute corresponding to the language used in the outgoing data, if appropriate, even if the component supports no other localizations. An example for this is a search form based on XEP-0004.
+ Jabber based services that wish to comply to this document have to make sure that all information they send to clients is tagged with an xml:lang attribute corresponding to the language used in the outgoing data, if appropriate, even if the component supports no other localizations. An example for this is a search form based on &xep0004;.
This feature has been removed in favor of the XMPP publish-subscribe technology defined in XEP-0060. This feature has been removed in favor of the XMPP publish-subscribe technology defined in &xep0060;. In response to a disco#items request, the server MUST return an empty result set if: TLS allows clients to be authenticated by verifying the certificate that they present during the TLS negotiation. This can be done in conjunction with the Jabber SASL profile (see &xep0034;) and the EXTERNAL mechanism. If a client authenticates with a certificate using the TLS authentication, and the client requests the use of SASL in the second XML stream negotiation (over the secure channel), servers supporting certificate-based authentication should add the EXTERNAL mechanism to the list of supported authentication mechanisms. If the client then requests this mechanism, the server should automatically inform the user that authentication was successful. See &rfc2222; and XEP-0034 for more information. If a client authenticates with a certificate using the TLS authentication, and the client requests the use of SASL in the second XML stream negotiation (over the secure channel), servers supporting certificate-based authentication should add the EXTERNAL mechanism to the list of supported authentication mechanisms. If the client then requests this mechanism, the server should automatically inform the user that authentication was successful. See &rfc2222; and &xep0034; for more information. Servers implementing STARTTLS functionality are not required to implement certificate-based authentication. If the full list of rooms is large (see XEP-0030 for details), the service MAY return only a partial list of rooms. If it does so, it SHOULD include a <set/> element qualified by the 'http://jabber.org/protocol/rsm' namespace (as defined in &xep0059;) to indicate that the list is not the full result set. If the full list of rooms is large (see &xep0030; for details), the service MAY return only a partial list of rooms. If it does so, it SHOULD include a <set/> element qualified by the 'http://jabber.org/protocol/rsm' namespace (as defined in &xep0059;) to indicate that the list is not the full result set. Note: These <item/> elements are qualified by the disco#items namespace, not the muc namespace; this means that they cannot possess 'affiliation' or 'role' attributes, for example. If the list of occupants is private, the room MUST return an empty &QUERY; element, in accordance with XEP-0030. If the list of occupants is private, the room MUST return an empty &QUERY; element, in accordance with &xep0030;. If this information is private, the user MUST return an empty &QUERY; element, in accordance with XEP-0030. If this information is private, the user MUST return an empty &QUERY; element, in accordance with &xep0030;. 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. The 'from' attribute MUST be set to the JID of the room itself. (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.) (Note: The 'urn:xmpp:delay' namespace defined in &xep0203; supersedes the older 'jabber:x:delay' namespace defined in &xep0091;; some implementations include both formats for backward compatibility.) The service MUST send all discussion history messages before delivering the room subject and any "live" messages sent after the user enters the room. Note well that this means the room subject (and changes to the room subject prior to the current subject) are not part of the discussion history. If the room is non-anonymous, the service MAY include an &xep0033; element that notes the original full JID of the sender by means of the "ofrom" address type: If the user is already registered, as described in XEP-0077 the room MUST reply with an IQ stanza of type "result", which MUST contain an empty <registered/> element and SHOULD contain at least a <username/> element that specifies the user's registered nickname in the room. If the user is already registered, as described in &xep0077; the room MUST reply with an IQ stanza of type "result", which MUST contain an empty <registered/> element and SHOULD contain at least a <username/> element that specifies the user's registered nickname in the room. If the user does not have a registered nickname, the room MUST return a service discovery &QUERY; element that is empty (in accordance with XEP-0030). If the user does not have a registered nickname, the room MUST return a service discovery &QUERY; element that is empty (in accordance with &xep0030;). 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. 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 &OCCUPANTJID;; as a result, there is no need for the leaving client to send directed unavailable presence to its occupant 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). 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 &OCCUPANTJID;; as a result, there is no need for the leaving client to send directed unavailable presence to its occupant 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 &rfc6121;). Note: See Ghost Users for suggestions regarding room occupants that appear to be present in the room but that are actually offline. Note: If the room is not persistent and this occupant is the last to exit, the service is responsible for destroying the room. Some administrators might 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; see XEP-0133. Some administrators might 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; see &xep0133;. As specified in Banning a User, users cannot be banned under certain conditions. For example: admins and owners cannot ban themselves, and a user cannot be banned by an admin with a lower affiliation. When a request to modify the ban list includes one or more modifications that is prohibited by the definitions in Banning a User, then the service SHOULD NOT apply any of the requested changes and MUST deny the request using an error which SHOULD be either &conflict; or ¬allowed;. 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. Room owners can 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, an owner can also specify the JIDs of other owners, if supported by the implementation. In order to provide the necessary flexibility for a wide range of configuration options, Data Forms (XEP-0004) are used for room configuration. 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 (&xep0004;) are used for room configuration. 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 (clearance levels, profanity filters, supported languages, message logging, etc.), which is why the use of the 'jabber:x:data' protocol is valuable here. 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 6120. 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 &rfc6120;. 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 (see &xep0171;). As specified in &rfc6120;, 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 (see &xep0171;). 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. Nicknames can contain virtually any Unicode character. This introduces the possibility of nick spoofing; see &rfc6122; for a description of related security considerations. No room entrance authentication or authorization method more secure than cleartext passwords is defined or required by this document. Although the risks involved can mitigated somewhat by the use of channel encryption and strong authentication via TLS and SASL as described in RFC 6120, an entity that joins a room has no way of knowing if its complete communication channel to the room is encrypted (thereby protecting the plaintext password). A future specification might define an XMPP profile of SASL for use with MUC, but currently there is no such specification. No room entrance authentication or authorization method more secure than cleartext passwords is defined or required by this document. Although the risks involved can mitigated somewhat by the use of channel encryption and strong authentication via TLS and SASL as described in &rfc6120;, an entity that joins a room has no way of knowing if its complete communication channel to the room is encrypted (thereby protecting the plaintext password). A future specification might define an XMPP profile of SASL for use with MUC, but currently there is no such specification. See XEP-0203 for security considerations regarding the inclusion and processing of delayed delivery notations. See &xep0203; for security considerations regarding the inclusion and processing of delayed delivery notations. In order to provide consistency regarding the addresses captured in room JIDs and occupant 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 6122). As explicitly stated in RFC 6122, both the Room ID (node) and Room Nickname (resource) portions of an Occupant 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 and occupant 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 &rfc6122;). As explicitly stated in RFC 6122, both the Room ID (node) and Room Nickname (resource) portions of an Occupant 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). The following guidelines are intended to assist client and service developers in creating MUC implementations. In handling messages sent by visitors in a moderated room, a MUC service MAY queue each message for approval by a moderator and MAY inform the sender that the message is being held for approval; however, such behavior is OPTIONAL, and definition of a message approval protocol (e.g., using Data Forms as defined in XEP-0004) is out of scope for this document. In handling messages sent by visitors in a moderated room, a MUC service MAY queue each message for approval by a moderator and MAY inform the sender that the message is being held for approval; however, such behavior is OPTIONAL, and definition of a message approval protocol (e.g., using Data Forms as defined in &xep0004;) is out of scope for this document. 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. 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. Room types MAY be configured in any combination. A MUC service MAY support or allow any desired room types or combinations thereof. There is no guarantee that any such combination is sensible. As noted, a service (more precisely, a properly-configured room) MAY discard some or all extended namespaces attached to &MESSAGE; and &PRESENCE; stanzas that are intended for reflection from the sender through the room to all of the room occupants. If the room does so, it SHOULD enable senders to discover the list of allowable extensions by sending a disco#info query to the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic', returning one <feature/> element for each namespace supported in the result. If the room does not allow any extended namespaces, it MUST return an empty query as specified in XEP-0030. If the room does not support the "#traffic" node, it MUST return a &feature; error in response to queries sent to the 'http://jabber.org/protocol/muc#traffic' node. As noted, a service (more precisely, a properly-configured room) MAY discard some or all extended namespaces attached to &MESSAGE; and &PRESENCE; stanzas that are intended for reflection from the sender through the room to all of the room occupants. If the room does so, it SHOULD enable senders to discover the list of allowable extensions by sending a disco#info query to the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic', returning one <feature/> element for each namespace supported in the result. If the room does not allow any extended namespaces, it MUST return an empty query as specified in &xep0030;. If the room does not support the "#traffic" node, it MUST return a &feature; error in response to queries sent to the 'http://jabber.org/protocol/muc#traffic' node. The following example shows a room that allows the 'http://jabber.org/protocol/xhtml-im' and 'http://jabber.org/protocol/rosterx' namespaces only, but no other extended namespaces. Upon receiving an error related to the data packet, the sender MUST close the bytestream as described under Closing the Bytestream. Data packets MUST be processed in the order they are received. If an out-of-sequence packet is received for a particular direction within a bytestream (determined by checking the 'seq' attribute), then this indicates that a packet has been lost. The recipient MUST NOT process the data of such an out-of-sequence packet, nor any that follow it within the same bytestream; instead, the recipient MUST close the bytestream as described in the next section. In order to retrieve stored data without receiving notifications (e.g., upon initial login), the user's client sends a retrieve-items request as specified in XEP-0060. In order to retrieve stored data without receiving notifications (e.g., upon initial login), the user's client sends a retrieve-items request as specified in &xep0060;. Security considerations related to object persistent via publish-subscribe are described in XEP-0060 and XEP-0223. Security considerations related to object persistent via publish-subscribe are described in XEP-0060 and &xep0223;. Use of the <password/> child of the <conference/> element is NOT RECOMMENDED, since the password could be discovered by a third party, e.g. an eavesdropper (if channel encryption is not used) or a server administrator. However, the element MAY be used in suitably secure environments (e.g., where it is known that communications will not be sent over unencrypted channels and the server administrators are trusted). Clients SHOULD NOT default to storing passwords and MUST enable users to disable any password storage. The XMPP Registrar shall maintain registries of assigned namespaces and parameters at <http://www.xmpp.org/registrar/> and shall update those registries in a timely fashion. Changes to the registries shall be announced on the <standards@xmpp.org> mailing list. The XMPP Registrar shall be responsible for issuing namespaces to be used in XMPP Extension Protocols (XEPs) developed through the XMPP Standards Foundation's standards process as specified in XEP-0001. The policies and procedures for namespace issuance shall be as follows: The XMPP Registrar shall be responsible for issuing namespaces to be used in XMPP Extension Protocols (XEPs) developed through the XMPP Standards Foundation's standards process as specified in &xep0001;. The policies and procedures for namespace issuance shall be as follows: When a XEP is first published in the Experimental state, the XMPP Registrar shall work with the author(s) to mint an appropriate namespace name, which shall be of the form "urn:xmpp:ShortName:0" or, where appropriate, "urn:xmpp:ShortName:SubName:0". The newly minted name shall be added by the XMPP Registrar as 'Provisional' to the registry. The following considerations apply: If there are no items whatsoever in the full result set, the responding entity MUST return a response that adheres to the definition of the wrapper protocol (e.g., "jabber:iq:search", "http://jabber.org/protocol/disco#items", or "http://jabber.org/protocol/pubsub"). For both XEP-0055 and XEP-0030, that means the responding entity shall return an empty &QUERY; element; for XEP-0060, that means the responding entity shall return an empty <pubsub/> element; for XEP-0136, that means the responding entity shall return an empty <list/> or <store/> element. If there are no items whatsoever in the full result set, the responding entity MUST return a response that adheres to the definition of the wrapper protocol (e.g., "jabber:iq:search", "http://jabber.org/protocol/disco#items", or "http://jabber.org/protocol/pubsub"). For both &xep0055; and XEP-0030, that means the responding entity shall return an empty &QUERY; element; for XEP-0060, that means the responding entity shall return an empty <pubsub/> element; for XEP-0136, that means the responding entity shall return an empty <list/> or <store/> element. The requesting entity MAY ask for the previous page in a result set by including in its request the UID of the first item from the page that has already been received (encapsulated in a <before/> element), along with the maximum number of items to return. The foregoing examples show the use of result set management in the context of Jabber Search. In the following examples we show the use of this protocol in the context of Service Discovery. XEP-0136 ("Message Archiving") includes more examples. A future version of this document may also include examples from Publish-Subscribe and other XMPP protocol extensions. The foregoing examples show the use of result set management in the context of Jabber Search. In the following examples we show the use of this protocol in the context of Service Discovery. &xep0136; ("Message Archiving") includes more examples. A future version of this document may also include examples from Publish-Subscribe and other XMPP protocol extensions. Note: Even if a responding entity understands the result set management protocol, its support for result set management in the context of any given "using protocol" is OPTIONAL (e.g., an implementation could support it in the context of the 'jabber:iq:search' namespace but not in the context of the 'http://jabber.org/protocol/disco#items' namespace). Currently the only way for a requesting entity to determine if a responding entity supports result set management in the context of a given "using protocol" is to include result set management extensions in its request. If the responding entity does not include result set management extensions in its response, then the requesting entity SHOULD NOT include such extensions in future requests wrapped by the "using protocol" namespace. Security considerations are the responsibility of the using ("wrapper") protocol, such as XEP-0030 for the 'http://jabber.org/protocol/disco#items' namespace, XEP-0055 for the 'jabber:iq:search' namespace, and XEP-0136 for the 'http://jabber.org/protocol/archive' namespace. Security considerations are the responsibility of the using ("wrapper") protocol, such as &xep0030; for the 'http://jabber.org/protocol/disco#items' namespace, XEP-0055 for the 'jabber:iq:search' namespace, and XEP-0136 for the 'http://jabber.org/protocol/archive' namespace. This document requires no interaction with &IANA;. If a pubsub node is addressable, it MUST be addressable either (1) as a JID or (2) as the combination of a JID and a node. If a pubsub node is addressable as a JID, the NodeID MUST be the resource identifier, and MUST NOT be specified by the "user" portion (node identifier) of the JID (e.g. "domain.tld/NodeID" and "user@domain.tld/NodeID" are allowed; "NodeID@domain.tld" is not allowed If a pubsub node is addressable as a JID, the NodeID MUST be the resource identifier, and MUST NOT be specified by the "user" portion (node identifier) of the JID (e.g. "domain.tld/NodeID" and "user@domain.tld/NodeID" are allowed; "NodeID@domain.tld" is not allowed Consider the following example, in which the pubsub service is located at the hostname pubsub.shakespeare.lit. If a pubsub node is addressable as a JID plus node, the NodeID MUST be the value of both the Service Discovery 'node' attribute and the pubsub 'node' attribute; i.e., for discovery purposes, a pubsub node is equivalent to a Service Discovery node. If a pubsub node is addressable as a JID plus node, the pubsub service SHOULD ensure that the NodeID conforms to the Resourceprep profile of Stringprep as described in RFC 3920. If a pubsub node is addressable as a JID plus node, the NodeID MUST be the value of both the Service Discovery 'node' attribute and the pubsub 'node' attribute; i.e., for discovery purposes, a pubsub node is equivalent to a Service Discovery node. If a pubsub node is addressable as a JID plus node, the pubsub service SHOULD ensure that the NodeID conforms to the Resourceprep profile of Stringprep as described in &rfc3920;. Consider the following example, in which the (virtual) pubsub service is located at hamlet@denmark.lit. If a service implements a hierarchy of nodes (by means of Collection Nodes), it MUST also enable entities to discover the nodes in that hierarchy by means of the Service Discovery protocol, subject to the recommendations in XEP-0030 regarding large result sets (for which &xep0055; or some other protocol SHOULD be used). The following examples show the use of service discovery in discovering the nodes available at a hierarchical pubsub service. If a service implements a hierarchy of nodes (by means of Collection Nodes), it MUST also enable entities to discover the nodes in that hierarchy by means of the Service Discovery protocol, subject to the recommendations in &xep0030; regarding large result sets (for which &xep0055; or some other protocol SHOULD be used). The following examples show the use of service discovery in discovering the nodes available at a hierarchical pubsub service. Note: Node hierarchies and collection nodes are OPTIONAL. For details, refer to the NodeID Semantics and Collection Nodes sections of this document. In the first example, an entity sends a service discovery items ("disco#items") request to the root node (i.e., the service itself), which is a Collection Node: These error cases are described more fully in the following sections. When requesting subscription options, the subscriber MUST specify the JID that is subscribed to the node and SHOULD specify a node (if no node is specified, i.e. via node="", the service MUST assume that the requesting entity wishes to request subscription options for its subscription to the root collection node; refer to XEP-0248 for details). When requesting subscription options, the subscriber MUST specify the JID that is subscribed to the node and SHOULD specify a node (if no node is specified, i.e. via node="", the service MUST assume that the requesting entity wishes to request subscription options for its subscription to the root collection node; refer to &xep0248; for details). The service MUST validate that the entity making the request is authorized to set the subscription options for the subscribed entity. If the subscriber's JID is of the form &FULLJID;, a service MUST perform this check by comparing the &BAREJID; part of the two JIDs to ensure that they match. If the bare JID portions of the JIDs do not match and the requesting entity is not authorized to modify subscription options for the JID (e.g., because it is not a service-wide admin or authorized proxy), the service MUST return a &forbidden; error. The process for retrieving the default subscription configuration options for collection nodes is described in XEP-0248. The process for retrieving the default subscription configuration options for collection nodes is described in &xep0248;. If no error occurs, the node MUST return the default subscription configuration options. A service MAY allow entities to request the most recent N items by using the 'max_items' attribute. When max_items is used, implementations SHOULD return the N most recent (as opposed to the N oldest) items. (Note: A future version of this specification may recommend the use of XEP-0059 instead of the 'max_items' attribute.) A service MAY allow entities to request the most recent N items by using the 'max_items' attribute. When max_items is used, implementations SHOULD return the N most recent (as opposed to the N oldest) items. (Note: A future version of this specification may recommend the use of &xep0059; instead of the 'max_items' attribute.) If the service or node does not support item retrieval (e.g., because the node is a collection node as described in XEP-0248), the service MUST return a &feature; error to the subscriber, specifying a pubsub-specific error condition of <unsupported/> and a feature of "retrieve-items". If the service or node does not support item retrieval (e.g., because the node is a collection node as described in &xep0248;), the service MUST return a &feature; error to the subscriber, specifying a pubsub-specific error condition of <unsupported/> and a feature of "retrieve-items". If the node does not support item publication (e.g., because it is a collection node as described in XEP-0248), the service MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "publish". If the node does not support item publication (e.g., because it is a collection node as described in &xep0248;), the service MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "publish". The <publish-options/> element MUST contain a data form (see XEP-0004), whose FORM_TYPE MUST be "http://jabber.org/protocol/pubsub#publish-options" (see XEP-0068). The <publish-options/> element MUST contain a data form (see &xep0004;), whose FORM_TYPE MUST be "http://jabber.org/protocol/pubsub#publish-options" (see XEP-0068). Each form field denotes a precondition to publishing the request. A pub-sub service advertising support for publishing options MUST check each precondition field against the node configuration of the same name, and it MUST reject the publication upon encountering unknown fields. Preconditions MUST be processed as follows: (For error handling if the service does not support the specified node type, refer to XEP-0248.) (For error handling if the service does not support the specified node type, refer to &xep0248;.) If an implementation allows node configuration (see the Configure a Node section of this document), it SHOULD allow node creation requests to contain the desired node configuration in the node creation request. If the "pubsub#notify_config" option is set to true, the service MUST notify subscribers of the configuration change. (A service SHOULD support this option for leaf nodes and MUST support it for collection nodes as described in XEP-0248.) If the node configuration is set to notification-only, the notification MUST consist of an empty <configuration/> element whose 'node' attribute is set to the NodeID of the node; if the node configuration is set to full payloads, the <configuration/> element MUST in addition contain the node configuration as represented via the Data Forms protocol. If the "pubsub#notify_config" option is set to true, the service MUST notify subscribers of the configuration change. (A service SHOULD support this option for leaf nodes and MUST support it for collection nodes as described in &xep0248;.) If the node configuration is set to notification-only, the notification MUST consist of an empty <configuration/> element whose 'node' attribute is set to the NodeID of the node; if the node configuration is set to full payloads, the <configuration/> element MUST in addition contain the node configuration as represented via the Data Forms protocol. There are several reasons why the node deletion request might fail: These error cases are described more fully in the following sections. If the service or node does not persist items (e.g., because the node is a collection node as described in XEP-0248), it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "persistent-items". If the service or node does not persist items (e.g., because the node is a collection node as described in &xep0248;), it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "persistent-items". Publish-subscribe functionality can be integrated into existing instant messaging and presence services (see RFC 3921), such that each registered account functions as a virtual pubsub service (sometimes called "pubsub-on-a-JID"). In such deployments, the root pubsub node for each virtual pubsub service has the same address as the bare JID &BAREJID; of the account, which is typically associated with an IM user (e.g., <hamlet@denmark.lit>). Since an IM user typically has a roster of "buddies" and shares presence information with those buddies, the virtual pubsub service can use roster and presence information to provide some helpful shortcuts for subscribers, in particular the auto-subscribe and filtered-notifications features described in this section. Publish-subscribe functionality can be integrated into existing instant messaging and presence services (see &rfc3921;), such that each registered account functions as a virtual pubsub service (sometimes called "pubsub-on-a-JID"). In such deployments, the root pubsub node for each virtual pubsub service has the same address as the bare JID &BAREJID; of the account, which is typically associated with an IM user (e.g., <hamlet@denmark.lit>). Since an IM user typically has a roster of "buddies" and shares presence information with those buddies, the virtual pubsub service can use roster and presence information to provide some helpful shortcuts for subscribers, in particular the auto-subscribe and filtered-notifications features described in this section. Note: PEP ties the receipt of PEP notifications to the subscriber's presence, but does not tie the generation of PEP notifications to the publisher's presence. If the publisher wishes to stop generating PEP events (or to generate an "empty" event as can be done for some PEP payloads) before ending its presence session, the publisher MUST direct its client to do so and MUST NOT depend on the PEP service to automatically "zero out" its PEP information when the PEP service receives unavailable presence from the publisher. If an instant messaging and presence account is also a virtual pubsub service, service discovery information ("disco#info") responses from the bare JID of the account MUST include a feature of "http:/jabber.org/protocol/pubsub#pubsub-on-a-jid": Note: Because the account owner's bare JID is the default destination address for any stanzas a client generates, clients often omit the "to" attribute on such stanzas; on this point, see RFC 6120 and (with regard to rosters) RFC 6121. Note: Because the account owner's bare JID is the default destination address for any stanzas a client generates, clients often omit the "to" attribute on such stanzas; on this point, see &rfc6120; and (with regard to rosters) RFC 6121. When a contact is affiliated with the account owner through sharing of XMPP presence, the "auto-subscribe" feature greatly simplifies the subscription process. In particular, support for the "auto-subscribe" has the following implications: A contact might not want to receive notifications for all the nodes hosted at a user's virtual pubsub service. A contact SHOULD signal its preferences to the account owner's server by including XEP-0115 information that specifies the NodeIDs for which the contact wishes to receive notifications (if any). This information is used by a pubsub service that supports the "filtered-notifications" feature to send notifications only from those NodeIDs that match the subscriber's preferences. In order to make this possible, all possible NodeIDs can be appended with the string "+notify" to indicate that the contact wishes to receive notifications for the specified NodeID. Thus if Romeo wants to receive notifications for location data (&xep0080;) and tune data (&xep0118;) but not activity data (&xep0108;), his client would advertise support for the following strings in the disco#info results it sends: A contact might not want to receive notifications for all the nodes hosted at a user's virtual pubsub service. A contact SHOULD signal its preferences to the account owner's server by including &xep0115; information that specifies the NodeIDs for which the contact wishes to receive notifications (if any). This information is used by a pubsub service that supports the "filtered-notifications" feature to send notifications only from those NodeIDs that match the subscriber's preferences. In order to make this possible, all possible NodeIDs can be appended with the string "+notify" to indicate that the contact wishes to receive notifications for the specified NodeID. Thus if Romeo wants to receive notifications for location data (&xep0080;) and tune data (&xep0118;) but not activity data (&xep0108;), his client would advertise support for the following strings in the disco#info results it sends: This set of strings would then be advertised by including them in the identity+features hash encapsulated via the 'ver' attribute as described in XEP-0115. This set of strings would then be advertised by including them in the identity+features hash encapsulated via the 'ver' attribute as described in &xep0115;. It is the responsibility of the account owner's server to cache XEP-0115 information. When the server receives presence from a contact, it MUST check that presence information for entity capabilities data and correlate that data with the desired NodeIDs for the contact's client. The server MUST NOT send notifications related to any NodeIDs that the contact's client has not asked for via the relevant "NodeID+notify" disco#info feature. This enables a client to turn off all notifications (e.g., because of bandwidth restrictions) and to easily receive all desired data formats simply by adding support for the appropriate "NodeID+notify" combination in its disco#info results and client capabililies. However, it also implies that a client can request notifications only on a global basis and cannot request, say, mood information only from certain contacts in the user's roster. Community consensus is that this is an acceptable tradeoff. Also, note that this works only if the account owner has a presence subscription to the contact and the contact has a presence subscription to the account owner. It is the responsibility of the account owner's server to cache &xep0115; information. When the server receives presence from a contact, it MUST check that presence information for entity capabilities data and correlate that data with the desired NodeIDs for the contact's client. The server MUST NOT send notifications related to any NodeIDs that the contact's client has not asked for via the relevant "NodeID+notify" disco#info feature. This enables a client to turn off all notifications (e.g., because of bandwidth restrictions) and to easily receive all desired data formats simply by adding support for the appropriate "NodeID+notify" combination in its disco#info results and client capabililies. However, it also implies that a client can request notifications only on a global basis and cannot request, say, mood information only from certain contacts in the user's roster. Community consensus is that this is an acceptable tradeoff. Also, note that this works only if the account owner has a presence subscription to the contact and the contact has a presence subscription to the account owner. Some examples may help to illustrate the concept of notification filtering. Here we show presence generated by two of the contacts listed above (benvolio@montague.lit does not have any presence subscriptions to or from juliet@capulet.lit and therefore is not involved in these protocol flows). (As noted in XEP-0115, the server MUST check the hash provided in the 'ver' attribute against the generation method to ensure that no poisoning has occurred.) (As noted in &xep0115;, the server MUST check the hash provided in the 'ver' attribute against the generation method to ensure that no poisoning has occurred.) Now we revisit account owner publication and server generation of notifications, with filtering enabled because the server has caps information: If Juliet publishes a tune item to the presence-access "http://jabber.org/protocol/tune" node, her server will send notifications to <nurse@capulet.lit/chamber> and <romeo@montague.lit/orchard> (full JIDs). As noted above, a pubsub service SHOULD ensure that the &MESSAGE; stanza for each event notification it generates possesses an 'id' attribute with a value. (This notification ID is not to be confused with either the node ID or the item ID.) This ID MUST be unique within the context of the pubsub service in order to ensure proper tracking of any delivery-related errors. Exactly how a service shall handle delivery-related errors is a matter of implementation. In general, such handling is effectively similar to the bounce processing performed by other message delivery systems, such as mail transfer agents and mailing list software. The following are some suggested guidelines regarding the handling of XMPP-specific error conditions in relation to pubsub event notifications (see RFC 3920 and XEP-0086 regarding XMPP error condition semantics): Exactly how a service shall handle delivery-related errors is a matter of implementation. In general, such handling is effectively similar to the bounce processing performed by other message delivery systems, such as mail transfer agents and mailing list software. The following are some suggested guidelines regarding the handling of XMPP-specific error conditions in relation to pubsub event notifications (see &rfc3920; and &xep0086; regarding XMPP error condition semantics): Implementations of pubsub MAY deliver event notifications only when the subscriber is online. In these cases, the option may be a node configuration option as shown in the examples above. To facilitate this, the pubsub service needs to subscribe to the subscriber's presence and check the subscriber's current presence information before sending any event notifications (as described in RFC 3921). Presence subscriptions MUST be based on the subscribed JID. Implementations of pubsub MAY deliver event notifications only when the subscriber is online. In these cases, the option may be a node configuration option as shown in the examples above. To facilitate this, the pubsub service needs to subscribe to the subscriber's presence and check the subscriber's current presence information before sending any event notifications (as described in &rfc3921;). Presence subscriptions MUST be based on the subscribed JID. If a service understands the semantics for a particular payload type and an entity's subscription is so configured (by the "pubsub#include_body" subscription option to true), the service SHOULD include an appropriate XMPP &BODY; child element along with the payloads it sends in event notifications for a given node, where the body's XML character data summarizes or represents the information contained in the payload (this enables clients that do not understand the payload format to present the appropriate information to an end user). For example, the Atom <summary/> element (see RFC 4287) could be mapped to the XMPP &BODY; element. A service MUST NOT provide the "pubsub#include_body" subscription option for a node if it does not have a defined way to transform part or all of the payload format into a sensible message body. A node owner MAY define an XSLT for transforming the payload format into a message body, via the "pubsub#body_xslt" node configuration option. This XSLT is applied by the pubsub service after receiving a publish request and before sending the appropriate notifications, not by the client before sending a publish request. If a service understands the semantics for a particular payload type and an entity's subscription is so configured (by the "pubsub#include_body" subscription option to true), the service SHOULD include an appropriate XMPP &BODY; child element along with the payloads it sends in event notifications for a given node, where the body's XML character data summarizes or represents the information contained in the payload (this enables clients that do not understand the payload format to present the appropriate information to an end user). For example, the Atom <summary/> element (see &rfc4287;) could be mapped to the XMPP &BODY; element. A service MUST NOT provide the "pubsub#include_body" subscription option for a node if it does not have a defined way to transform part or all of the payload format into a sensible message body. A node owner MAY define an XSLT for transforming the payload format into a message body, via the "pubsub#body_xslt" node configuration option. This XSLT is applied by the pubsub service after receiving a publish request and before sending the appropriate notifications, not by the client before sending a publish request. If the service does not understand the semantics for a particular payload type and therefore cannot transform the payload into a human-readable message body, it SHOULD NOT include a <body/> child. If a subscriber has multiple subscriptions to the same node, where some of the SubIDs have include_body set to true and others have include_body set to false, the service SHOULD include a body with all notifications. How subscription requests are sent to node owners is a matter of implementation. Possibilities include: NodeIDs MAY have semantic meaning in particular profiles, implementations, or deployments of pubsub. However, it is STRONGLY RECOMMENDED that such semantic meaning not be used to encapsulate the hierarchical structure of nodes; instead, node hierarchy SHOULD be encapsulated using collections and their associated child nodes as described in XEP-0248. NodeIDs MAY have semantic meaning in particular profiles, implementations, or deployments of pubsub. However, it is STRONGLY RECOMMENDED that such semantic meaning not be used to encapsulate the hierarchical structure of nodes; instead, node hierarchy SHOULD be encapsulated using collections and their associated child nodes as described in &xep0248;. The SHIM headers are generated by the node to which the subscriber has a subscription, which may be either a leaf node or a collection node (refer to XEP-0248). The SHIM headers are generated by the node to which the subscriber has a subscription, which may be either a leaf node or a collection node (refer to &xep0248;). SHIM headers are not to be included when the content does not differ based on subscription ID, e.g., when a node sends notification of a configuration change to the node itself, notification that the node has been purged, or notification that the node has been deleted. Alternatively, if a service implements the personal eventing subset of this protocol, the virtual pubsub service is the account owner's bare JID and notifications are sent from that JID; for details, refer to XEP-0163. Alternatively, if a service implements the personal eventing subset of this protocol, the virtual pubsub service is the account owner's bare JID and notifications are sent from that JID; for details, refer to &xep0163;. The registry submissions associated with these namespaces are defined below. Note: There is no requirement that configuration fields need to be registered with the XMPP Registrar. However, as specified in Section 3.4 of XEP-0068, names of custom (unregistered) fields MUST begin with the characters "x-" if the form itself is scoped by a registered FORM_TYPE. Note: There is no requirement that configuration fields need to be registered with the XMPP Registrar. However, as specified in Section 3.4 of &xep0068;, names of custom (unregistered) fields MUST begin with the characters "x-" if the form itself is scoped by a registered FORM_TYPE. Next the Target attempts to open a standard TCP socket on the network address of the StreamHost/Requester (for information about UDP usage, see the Optional UDP Support section of this document). Note: If the Requester provides more than one StreamHost, the Target SHOULD try to connect to them in the order of the <streamhost/> children within the &QUERY; element. &xep0260; modifies this rule by providing explicit priorities for each streamhost candidate. If the Target is able to open a TCP socket on a StreamHost/Requester, it MUST use the SOCKS5 protocol to establish a SOCKS5 connection. In accordance with RFC 1928, the Target might need to authenticate in order to use the proxy. However, any authentication required is beyond the scope of this document. If the Target is able to open a TCP socket on a StreamHost/Requester, it MUST use the SOCKS5 protocol to establish a SOCKS5 connection. In accordance with &rfc1928;, the Target might need to authenticate in order to use the proxy. However, any authentication required is beyond the scope of this document. Once the Target has successfully authenticated with the StreamHost/Requester, it sends a CONNECT request (CMD = X'01') in order to continue the negotiation. The following rules apply: When replying to the Target in accordance with Section 6 of RFC 1928, the StreamHost MUST set the BND.ADDR and BND.PORT to the DST.ADDR and DST.PORT values provided by the client in the connection request. When replying to the Target in accordance with Section 6 of &rfc1928;, the StreamHost MUST set the BND.ADDR and BND.PORT to the DST.ADDR and DST.PORT values provided by the client in the connection request. If the Target tries but is unable to connect to any of the StreamHosts and it does not wish to attempt a connection from its side, it MUST return an ¬found; error to the Requester. Next the Target attempts to open a standard TCP socket on the network address of the Proxy. If the Target is able to open a TCP socket on the Proxy, it uses the SOCKS5 protocol to establish a SOCKS5 connection. In accordance with RFC 1928, the Target might need to authenticate in order to use the proxy. However, any authentication required is beyond the scope of this document. If the Target is able to open a TCP socket on the Proxy, it uses the SOCKS5 protocol to establish a SOCKS5 connection. In accordance with &rfc1928;, the Target might need to authenticate in order to use the proxy. However, any authentication required is beyond the scope of this document. Once the Target has successfully authenticated with the Proxy, it sends a CONNECT request (CMD = X'01') in order to continue the negotiation. The following rules apply: When replying to the Target in accordance with Section 6 of RFC 1928, the Proxy MUST set the BND.ADDR and BND.PORT to the DST.ADDR and DST.PORT values provided by the client in the connection request. When replying to the Target in accordance with Section 6 of &rfc1928;, the Proxy MUST set the BND.ADDR and BND.PORT to the DST.ADDR and DST.PORT values provided by the client in the connection request. After the Target has established a SOCKS5 connection with the Proxy, it replies to the initiate request with an IQ-result whose &QUERY; element contains a <streamhost-used/> child that specifies which StreamHost was used (in this case, the Proxy). The <streamhost/> element contains the bytestream connection information. This element has attributes for the StreamHost's JID, network host/address, and network port. This element MUST NOT contain any XML character data or child elements. The "jid" attribute specifies the StreamHost's JID. This attribute MUST be present, and MUST be a valid JID for communication over XMPP. The "host" attribute specifies the host to connect to. This attribute MUST be present. The value MUST be either an IPv4 or IPv6 address, or a resolvable DNS domain name. The "port" attribute specifies the port to connect to. This attribute MAY be present. The value MUST be a valid port number in decimal form. If not specified, the port value is "1080" (in accordance with RFC 1928). The "port" attribute specifies the port to connect to. This attribute MAY be present. The value MUST be a valid port number in decimal form. If not specified, the port value is "1080" (in accordance with &rfc1928;). When communicating the available hosts, the Requester MUST include the host and port. The intent of the 'jabber:iq:oob' was to provide a "least common denominator" mechanism for basic file transfers. Although &xep0096; defines a more generic method for communicating file exchange options, the 'jabber:iq:oob' namespace can be included as one option therein since it provides a fallback mechanism when clients do not support file transfer options such as those defined in &xep0065; and &xep0047;. To initiate an out-of-band file transfer with an intended recipient using the 'jabber:iq:oob' namespace (whether or not negotiated via XEP-0096), the sending application sends an &IQ; of type 'set' to the recipient containing a &QUERY; child element qualified by the 'jabber:iq:oob' namespace; the &QUERY; MUST in turn contain a <url/> child specifying the URL of the file to be transferred, and MAY contain an optional <desc/> child describing the file. This usage is shown in the following example. To initiate an out-of-band file transfer with an intended recipient using the 'jabber:iq:oob' namespace (whether or not negotiated via &xep0096;), the sending application sends an &IQ; of type 'set' to the recipient containing a &QUERY; child element qualified by the 'jabber:iq:oob' namespace; the &QUERY; MUST in turn contain a <url/> child specifying the URL of the file to be transferred, and MAY contain an optional <desc/> child describing the file. This usage is shown in the following example. This document inherits terminology about the HyperText Transfer Protocol from RFC 2616 and RFC 2617. This document inherits terminology about the HyperText Transfer Protocol from &rfc2616; and RFC 2617. This process flow is described in more detail in the following sections. Let us stipulate that an XMPP user (say, <juliet@capulet.com>) learns of an HTTP URL (e.g., <https://files.shakespeare.lit:9345/missive.html>). The user then attempts to retrieve the URL using her HTTP Client, which opens a TCP connection to the appropriate port of the host and sends an HTTP request as defined in RFC 2616. The request method MAY be any valid HTTP request method, including user-defined methods. Let us stipulate that an XMPP user (say, <juliet@capulet.com>) learns of an HTTP URL (e.g., <https://files.shakespeare.lit:9345/missive.html>). The user then attempts to retrieve the URL using her HTTP Client, which opens a TCP connection to the appropriate port of the host and sends an HTTP request as defined in &rfc2616;. The request method MAY be any valid HTTP request method, including user-defined methods. An example is provided below: If the user did not provide authorization credentials in the initial request, the HTTP Server then MUST respond with a (401) Authenticate response as defined in RFC 2616. The response MUST contain an HTTP 401 error and one WWW-Authenticate header for each authentication scheme recognized by the HTTP Server. In order to provide verification via XMPP, at least one of these headers MUST specify a realm of "xmpp" (case-sensitive). If the user did not provide authorization credentials in the initial request, the HTTP Server then MUST respond with a (401) Authenticate response as defined in &rfc2616;. The response MUST contain an HTTP 401 error and one WWW-Authenticate header for each authentication scheme recognized by the HTTP Server. In order to provide verification via XMPP, at least one of these headers MUST specify a realm of "xmpp" (case-sensitive). The HTTP Client responds with an Authorization Request as defined in RFC 2616. The following rules apply: The HTTP Client responds with an Authorization Request as defined in &rfc2616;. The following rules apply: The Authorization Request process is described in the following subsections. The Basic Access Authentication scheme is defined in RFC 2617. This scheme specifies that the authorization information shall consist of a userid and password, separated by a ':' character and then encoded using Base64. When the realm is "xmpp", the profile defined herein further specifies that the userid MUST be a valid JID as described above, that the password entity MUST be a transaction identifier as described above, that any character in the JID or transaction identifier that is outside the range of the US-ASCII coded character set MUST be transformed into a percent-encoded octet as specified in Section 2.1 of &rfc3986; prior to Base64 encoding, and that Base64 encoding MUST adhere to Section 4 of &rfc4648;. (Refer to RFC 2617 for specification of the syntax of the Basic Access Authentication scheme; that information is not duplicated here.) The Basic Access Authentication scheme is defined in &rfc2617;. This scheme specifies that the authorization information shall consist of a userid and password, separated by a ':' character and then encoded using Base64. When the realm is "xmpp", the profile defined herein further specifies that the userid MUST be a valid JID as described above, that the password entity MUST be a transaction identifier as described above, that any character in the JID or transaction identifier that is outside the range of the US-ASCII coded character set MUST be transformed into a percent-encoded octet as specified in Section 2.1 of &rfc3986; prior to Base64 encoding, and that Base64 encoding MUST adhere to Section 4 of &rfc4648;. (Refer to &rfc2617; for specification of the syntax of the Basic Access Authentication scheme; that information is not duplicated here.) The Digest Access Authentication scheme is defined in RFC 2617. This scheme specifies that the authorization information shall consist of the MD5 checksum of the username, a cnonce generated by the client, a nonce value provided in the challenge, the HTTP method, and the requested URL. When the realm is "xmpp", the profile defined herein further specifies that prior to creating the MD5 checksum the username MUST be a valid JID as described above, that the cnonce MUST be a transaction identifier as described above, and that any character in the JID or transaction identifier that is outside the range of the US-ASCII coded character set MUST be transformed into a percent-encoded octet as specified in Section 2.1 of RFC 3986. (Refer to RFC 2617 for specification of the syntax of the Digest Access Authentication scheme; that information is not duplicated here.) The Digest Access Authentication scheme is defined in &rfc2617;. This scheme specifies that the authorization information shall consist of the MD5 checksum of the username, a cnonce generated by the client, a nonce value provided in the challenge, the HTTP method, and the requested URL. When the realm is "xmpp", the profile defined herein further specifies that prior to creating the MD5 checksum the username MUST be a valid JID as described above, that the cnonce MUST be a transaction identifier as described above, and that any character in the JID or transaction identifier that is outside the range of the US-ASCII coded character set MUST be transformed into a percent-encoded octet as specified in Section 2.1 of RFC 3986. (Refer to &rfc2617; for specification of the syntax of the Digest Access Authentication scheme; that information is not duplicated here.) 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 usual architecture of XMPP is described in &rfc6120;. 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 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. 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 &rfc6120;), 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 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: The recommended method for sending associated data is to use the file transfer protocol described in &xep0096;. 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 &xep0137; by including the SI-pub data extension along with the XMPP &MESSAGE; stanza with which the data is associated: For details regarding file transfer and advertising of file transfer stream initiation requests, refer to XEP-0096 and XEP-0137. For details regarding file transfer and advertising of file transfer stream initiation requests, refer to &xep0096; 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: 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: Section 4 of &w3soap1; defines a SOAP Protocol Binding Framework; two instantiations of that framework are the SOAP HTTP Binding (specified in Section 7 of &w3soap2;) and the &w3soapemail;. (Additionally, a binding to BEEP is described in RFC 4227.) As an alternative to the HTTP and Email bindings, this section formally defines the SOAP XMPP Binding in accordance with the SOAP Protocol Binding Framework. Section 4 of &w3soap1; defines a SOAP Protocol Binding Framework; two instantiations of that framework are the SOAP HTTP Binding (specified in Section 7 of &w3soap2;) and the &w3soapemail;. (Additionally, a binding to BEEP is described in &rfc4227;.) As an alternative to the HTTP and Email bindings, this section formally defines the SOAP XMPP Binding in accordance with the SOAP Protocol Binding Framework. Note: The SOAP XMPP Binding is optional, and SOAP nodes are not required to implement it. A SOAP node that correctly and completely implements the SOAP XMPP Binding as described herein may be said to "conform to the SOAP 1.2 XMPP Binding". The SOAP XMPP Binding is identified by the following URI: 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. XMPP is a pure XML streaming protocol used to exchange snippets of structured data called "XML stanzas" (see &rfc6120;) 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.) 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 remainder of this section describes the message exchange pattern (MEP) state machine and its relation to XMPP as described in &rfc6120;. 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. For a listing of relevant XMPP error conditions, refer to RFC 6120. For a listing of relevant XMPP error conditions, refer to &rfc6120;. The following table formally describes the "Sending+Receiving" state of the Requesting SOAP Node in the SOAP XMPP Binding: For a listing of relevant XMPP error conditions, refer to RFC 6120. For a listing of relevant XMPP error conditions, refer to &rfc6120;. 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. For a listing of relevant XMPP error conditions, refer to RFC 6120. For a listing of relevant XMPP error conditions, refer to &rfc6120;. The following table formally describes the "Receiving" state of the Responding SOAP Node in the SOAP XMPP Binding: 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 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. Per &rfc6120;, 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 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. 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 &rfc6120;, 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. 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). 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 &rfc6120;. 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. 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. Generic XMPP routers that conform to &rfc6120; 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. The software developed in the Jabber community is built on the foundation of XML streams, a consistent addressing scheme (JIDs), channel encryption, authentication of an entity (client or server) with a server, three core data elements (&MESSAGE;, &PRESENCE;, and &IQ;), and proper handling of XML namespaces. These foundational building blocks have been formalized within RFC 3920, support for which is REQUIRED by this protocol suite. However, XMPP Core is not fully congruent with the core of what has traditionally been known as "Jabber", and this divergence needs to be captured in the Basic IM Protocol Suite. For the sake of backward compatibility, support for &xep0078; is RECOMMENDED for servers (but not clients) as a fallback method of authentication by older deployed clients. RFC 3920 does not define everything that is normally expected of even a minimal instant messaging and presence application (in effect, it defines the transport layer rather than the IM and presence application layer). Much of this IM and presence functionality is defined in RFC 3921 in order to meet the requirements of RFC 2779. In particular, RFC 3921 defines roster management, presence subscriptions, and routing and delivery guidelines for clients and servers. Therefore, support for RFC 3921 is REQUIRED. RFC 3920 does not define everything that is normally expected of even a minimal instant messaging and presence application (in effect, it defines the transport layer rather than the IM and presence application layer). Much of this IM and presence functionality is defined in RFC 3921 in order to meet the requirements of RFC 2779. In particular, RFC 3921 defines roster management, presence subscriptions, and routing and delivery guidelines for clients and servers. Therefore, support for &rfc3921; is REQUIRED. Furthermore, Jabber instant messaging and presence applications typically include the ability to discover information about other entities on the network, and to reply to queries for information. This behavior is extremely helpful because it ensures that entities on the network can determine each other's capabilities and thus understand how to communicate together. Therefore, support for &xep0030; is REQUIRED by this protocol suite, as is (for clients) the dynamic profile of service discovery specified in &xep0115;. Traditionally, Jabber servers (and some services) have also offered the ability for clients to register accounts "in-band" (see &xep0077;) in order to bootstrap participation on the network; support for that protocol is RECOMMENDED but any given server deployment MAY disable in-band registration as a matter of service provisioning. Thus we define the Basic IM Protocol Suite as follows: RFC 3920 requires support for SASL and TLS as must-implement protocols, and that support is not modified herein. The older authentication method specified in XEP-0078: Non-SASL Authentication is now deprecated; however, support for it is still recommended in server implementations for the sake of backward compatibility (see XEP-0078 regarding the proper order of precedence between SASL authentication and non-SASL authentication). RFC 3920 requires support for SASL and TLS as must-implement protocols, and that support is not modified herein. The older authentication method specified in XEP-0078: Non-SASL Authentication is now deprecated; however, support for it is still recommended in server implementations for the sake of backward compatibility (see &xep0078; regarding the proper order of precedence between SASL authentication and non-SASL authentication). This document requires no interaction with &IANA;. The <key/> element was also used during registration removal. 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: &rfc6120; 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: 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. 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 &rfc6120;), 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 &rfc6120; (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 6120, i.e., UTF-8 as defined in &rfc3629;). 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 &rfc6120;, i.e., UTF-8 as defined in &rfc3629;). The value of the <digest/> element MUST be computed according to the following algorithm: 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. Although &rfc6120; 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. 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). &rfc6120; 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). 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 6120. 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 &rfc6120;. 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. The browser passes this file to the helper application, which shall send an IQ stanza of type='get' to the service associated with the JID defined in the file in order to determine the registration requirements (first authenticating with the user's Jabber/XMPP server if necessary), as described in &xep0077;. The helper application shall then instantiate an appropriate interface for registering with the service. If the user completes the interface, the helper application shall then send an IQ stanza of type='set' to the JID as described in XEP-0077. The browser passes this file to the helper application, which shall send an IQ stanza of type='get' to the service associated with the JID defined in the file in order to determine the registration requirements (first authenticating with the user's Jabber/XMPP server if necessary), as described in &xep0077;. The helper application shall then instantiate an appropriate interface for registering with the service. If the user completes the interface, the helper application shall then send an IQ stanza of type='set' to the JID as described in &xep0077;. Detailed security considerations for instant messaging and presence protocols are given in &rfc2779; (Sections 5.1 through 5.4), and for XMPP in particular are given in RFC 3920 (Sections 12.1 through 12.6). In addition, all of the security considerations specified in RFC 3023 apply to the "application/jabber+xml" media type. Detailed security considerations for instant messaging and presence protocols are given in &rfc2779; (Sections 5.1 through 5.4), and for XMPP in particular are given in &rfc3920; (Sections 12.1 through 12.6). In addition, all of the security considerations specified in RFC 3023 apply to the "application/jabber+xml" media type. When a helper application has finished processing a file of type "application/jabber+xml", it SHOULD discard the file; this helps to prevent security-related problems that may result from HTTP caching. This process flow is described more fully in the following sections. Note: Before publishing avatar data and metadata, the user MUST determine if his or her server supports the PEP subset of pubsub by following the procedures specified in XEP-0163, since such support simplifies avatar publication. The following examples assume the availability of a PEP service. Note: Before publishing avatar data and metadata, the user MUST determine if his or her server supports the PEP subset of pubsub by following the procedures specified in &xep0163;, since such support simplifies avatar publication. The following examples assume the availability of a PEP service. Before updating the avatar metadata node, the publisher MUST make sure that the avatar data is available at the data node or URL. When publishing the avatar data to the data node, the publisher MUST ensure that the value of the pubsub ItemID is a SHA-1 hash of the data for the "image/png" content-type (this is used by the subscriber to determine if a locally cached copy can be displayed). The following example illustrates the XML structure to be sent when publishing avatar data to the data node. If the avatar will be made available via HTTP instead of a pubsub data node, the publisher MUST either verify that the avatar exists at the HTTP URL or publish it via standard HTTP methods (such methods are out of scope for this specification; refer to RFC 2616). If the avatar will be made available via HTTP instead of a pubsub data node, the publisher MUST either verify that the avatar exists at the HTTP URL or publish it via standard HTTP methods (such methods are out of scope for this specification; refer to &rfc2616;). Whenever the publisher wishes to change its current avatar, it MUST update the metadata node. As with the data node, the publisher MUST ensure that the value of the pubsub ItemID is a SHA-1 hash of the data for the "image/png" content-type (the match between the ItemID of the data node and metadata node is used by the subscriber to determine if a locally cached copy can be displayed). As shown, depending on node configuration, the item may include &xep0033; information about the publishing resource (see XEP-0060 for details). As shown, depending on node configuration, the item may include &xep0033; information about the publishing resource (see &xep0060; for details). Upon receiving the notification, each subscriber SHOULD determine if it has a locally cached copy of that avatar (which it can do by searching for an image identified by the ItemID). If the subscriber already has a locally cached copy of the avatar image, it MUST NOT retrieve the image data. If the <info/> element sent to the metadata node possesses a 'url' attribute, the avatar data is hosted at a URL. Therefore, in order to retrieve the avatar image data for that content-type, the requesting entity MUST send an HTTP request to the specified URL. Methods for doing so are out of scope for this specification (see RFC 2616). If the <info/> element sent to the metadata node possesses a 'url' attribute, the avatar data is hosted at a URL. Therefore, in order to retrieve the avatar image data for that content-type, the requesting entity MUST send an HTTP request to the specified URL. Methods for doing so are out of scope for this specification (see &rfc2616;). In order to temporarily disable avatar publishing, the user publishes an empty <metadata/> element to the metadata node. The contact then MAY subscribe to the metadata node following the protocol specified in XEP-0060. However, the contact SHOULD NOT subscribe to the data node (instead, it SHOULD simply retrieve items from that node when needed, as described above). The contact then MAY subscribe to the metadata node following the protocol specified in &xep0060;. However, the contact SHOULD NOT subscribe to the data node (instead, it SHOULD simply retrieve items from that node when needed, as described above). If a user has multiple online resources at the same time, each resource MAY publish a different avatar. The PEP service SHOULD include the "replyto" address of the publishing resource as shown above in order to facilitate differentiation between per-resource avatars. When a user logs in with a new resource and before publishing an avatar, its client SHOULD retrieve its last published avatar, either automatically by sending presence with the appropriate entity capabilities information (see XEP-0115) or using the "retrieve-items" method described in XEP-0060. When a user logs in with a new resource and before publishing an avatar, its client SHOULD retrieve its last published avatar, either automatically by sending presence with the appropriate entity capabilities information (see &xep0115;) or using the "retrieve-items" method described in XEP-0060. It is the responsibility of the receiving application to determine which avatar format to retrieve (e.g., "image/gif" rather than "image/png") and to determine the appropriate method for retrieval (e.g., HTTP rather than pubsub). See XEP-0060 and XEP-0163 regarding security considerations related to the underlying transport protocol. See &xep0060; and XEP-0163 regarding security considerations related to the underlying transport protocol. It is possible that output of the SHA-1 hashing algorithm can result in collisions; however, the use of SHA-1 in producing a hash of the avatar data is not security-critical. Many instant messaging systems include notifications about the state of one's conversation partner in a one-to-one chat (or, sometimes, in a many-to-many chat). Usually these are limited to notification that one's partner is currently typing -- e.g., the Composing event in the older (deprecated) &xep0022; protocol. However, a composing event is essentially information about a person's participation in or involvement with the chat "session" and therefore is really a session-level state rather than a per-message event (in contrast to the Delivered and Displayed events in XEP-0022). While the composing event is interesting, the concept of a session-level state can be extended to answer a variety of questions about the participation of a person in a real-time chat conversation, such as: Many instant messaging systems include notifications about the state of one's conversation partner in a one-to-one chat (or, sometimes, in a many-to-many chat). Usually these are limited to notification that one's partner is currently typing -- e.g., the Composing event in the older (deprecated) &xep0022; protocol. However, a composing event is essentially information about a person's participation in or involvement with the chat "session" and therefore is really a session-level state rather than a per-message event (in contrast to the Delivered and Displayed events in &xep0022;). While the composing event is interesting, the concept of a session-level state can be extended to answer a variety of questions about the participation of a person in a real-time chat conversation, such as: A client MUST allow users to configure whether they want to send chat state notifications. Note: Support for only <active/> and <composing/> is functionally equivalent to supporting the Composing event from XEP-0022. Note: Support for only <active/> and <composing/> is functionally equivalent to supporting the Composing event from &xep0022;. Even if the user types continuously for a long time (e.g., while composing a lengthy reply), the client MUST NOT send more than one standalone <composing/> notification in a row. More generally, a client MUST NOT send a second instance of any given standalone notification (i.e., a standalone notification MUST be followed by a different state, not repetition of the same state). However, every content message SHOULD contain an <active/> notification. Servers in constrained network environments (e.g., serving small-footprint clients via &xep0025; or &xep0124;) and services that rebroadcast message stanzas (e.g., Multi-User Chat services) MAY process standalone notifications differently from other messages. In particular, a server or service MAY refuse to deliver standalone notifications to its users, and SHOULD NOT store them offline. In contrast to XEP-0022, chat state notifications are completely the responsibility of the client, and MUST NOT be generated by a server or service. Servers in constrained network environments (e.g., serving small-footprint clients via &xep0025; or &xep0124;) and services that rebroadcast message stanzas (e.g., Multi-User Chat services) MAY process standalone notifications differently from other messages. In particular, a server or service MAY refuse to deliver standalone notifications to its users, and SHOULD NOT store them offline. In contrast to &xep0022;, chat state notifications are completely the responsibility of the client, and MUST NOT be generated by a server or service. Note: This specification has been deprecated in favor of &xep0202;. This document provides canonical documentation of the 'jabber:iq:time' namespace, which was long used by Jabber applications to discover the time at another entity's location. This document is of historical importance only, since it has been deprecated in favor of XEP-0202. This document provides canonical documentation of the 'jabber:iq:time' namespace, which was long used by Jabber applications to discover the time at another entity's location. This document is of historical importance only, since it has been deprecated in favor of &xep0202;. The 'jabber:iq:time' namespace provides a standard way for Jabber entities to exchange information about the local time (e.g., to "ping" another entity or check network latency). The information is communicated in a request/response pair using an &IQ; element that contains a &QUERY; scoped by the 'jabber:iq:time' namespace. The following children of the &QUERY; element are allowed in an IQ result: Note: This specification has been deprecated in favor of &xep0203;. This document provides canonical documentation of the 'jabber:x:delay' namespace, which was long used by Jabber applications to mark message or presence stanzas as delivered with a delay. This document is of historical importance only, since it has been deprecated in favor of XEP-0203. This document provides canonical documentation of the 'jabber:x:delay' namespace, which was long used by Jabber applications to mark message or presence stanzas as delivered with a delay. This document is of historical importance only, since it has been deprecated in favor of &xep0203;. The 'jabber:x:delay' namespace is used to provide timestamp information about data stored for later delivery. The most common uses of this namespace are to stamp: In accordance with XEP-0137, the application SHOULD then initiate a file transfer exchange with by sending a stanza of the following form: In accordance with &xep0137;, the application SHOULD then initiate a file transfer exchange with by sending a stanza of the following form: 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). Note: As specified in &rfc6121;, 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). Jabber User sends subscription request to Gateway (i.e., by sending a presence stanza of type "subscribe" to Gateway). 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. Note: As specified in &rfc6121;, sending this packet will result in a "roster push" from the Server to all of the Jabber User's available resources. Gateway transforms subscription request and routes it 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. Server sends normal "roster push" to Jabber User (see &rfc6121;) and sends presence stanzas of type "unsubscribe", "unsubscribed", and "unavailable" to Legacy User. Jabber User's server performs defined functionality for handling presence stanzas of type "unsubscribe" and "unsubscribed" (see RFC 6121). Jabber User's server performs defined functionality for handling presence stanzas of type "unsubscribe" and "unsubscribed" (see &rfc6121;). Use Case Ends. The Jabber Identifier corresponding to a Legacy User's address is typically of the form <LegacyUserAddress@gateway.example.com>, where LegacyUserAddress is the Legacy User's address on the Legacy Service and where gateway.example.com is the Jabber address of the gateway. Unfortunately, usernames on some Legacy Services may allow characters that are disallowed in Jabber usernames as specified by the Nodeprep profile of stringprep defined in RFC 3920. For example, the usernames for a Legacy Service may be of the form <user@domain>, which would result in an illegal JID such as <user@domain@gateway.example.com>. Unfortunately, usernames on some Legacy Services may allow characters that are disallowed in Jabber usernames as specified by the Nodeprep profile of stringprep defined in &rfc3920;. For example, the usernames for a Legacy Service may be of the form <user@domain>, which would result in an illegal JID such as <user@domain@gateway.example.com>. There are two possible ways to solve this problem: 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. 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 &rfc6121;. Therefore, a gateway SHOULD instead send the legacy contact list items to the Jabber User via the &xep0144; protocol. The following business rules apply: This document addresses the following requirements: The escaping mechanism shall apply to the localpart of a JID only, and MUST NOT be applied to domainparts or resourceparts. Escaped JIDs MUST conform to the definition of a Jabber ID as specified in RFC 7622, including the UsernameCaseMapped profile of PRECIS. In particular this means that even after passing through the enforcement step of the UsernameCaseMapped profile, the JID MUST be valid, with the result that Unicode look-alikes like U+02BC (Modifier Letter Apostrophe) MUST NOT be used. Escaped JIDs MUST conform to the definition of a Jabber ID as specified in &rfc7622;, including the UsernameCaseMapped profile of PRECIS. In particular this means that even after passing through the enforcement step of the UsernameCaseMapped profile, the JID MUST be valid, with the result that Unicode look-alikes like U+02BC (Modifier Letter Apostrophe) MUST NOT be used. It MUST NOT be possible for clients to use this escaping mechanism to avoid the goal of PRECIS; namely, that JIDs that look alike should have same character representation after being processed by PRECIS. Therefore, this mechanism MUST NOT be applied to any characters other than the disallowed characters (with the exception that, in certain circumstances, the escaping character itself ("\") might also be escaped). Existing JIDs that include portions of the escaping mechanism MUST continue to be valid. The escaping mechanism MUST NOT break commonly deployed Jabber/XMPP software implementations such as servers, components, gateways, and clients. * Note: The character sequence \20 MUST NOT be the first or last character of an escaped localpart. * Note: The character sequence \20 MUST NOT be the first or last character of an escaped localpart. In the following example, Porthos starts a chat with D'Artagnan, typing into his client the string "d'artagnan@musketeers.lit" (which is escaped by his client to "d\27artagnan@musketeers.lit"). When transforming a non-XMPP ("source") address into an escaped JID, an implementation MUST adhere to the following process: If the source address is a URI, it MUST first be properly decoded according to the rules in RFC 3986 before it is transformed into a JID. If the source address is a URI, it MUST first be properly decoded according to the rules in &rfc3986; before it is transformed into a JID. If the source address is a URI, the URI scheme component MUST be removed. If there are any instances of character sequences that correspond to escapings of the disallowed characters (e.g., the character sequence "\27") or the escaping character (i.e., the character sequence "\5c") in the source address, the leading backslash character MUST be escaped to the character sequence "\5c" (e.g., resulting in the character sequences "\5c27" or "\5c5c"). All disallowed characters in the source address MUST be properly escaped in the resulting JID (as described above). The address format for an Internet mailbox is specified in RFC 5322. The identifier of interest in this context is the "addr-spec" address and more particularly the "dot-atom-text" rule specified in Section 3.2.3, i.e., the email address shorn of angle brackets, display names, comments, quoted strings, and the like. Because some deployments of XMPP messaging systems may want to re-use existing email addresses as JIDs, it is helpful to define how to transform an email address into a JID. In general, it is straightforward to transform an email address (i.e., a "dot-atom-text") into a JID, since traditional email addresses allow US-ASCII characters only rather than the nearly full range of Unicode code points allowed in a JID. The address format for an Internet mailbox is specified in &rfc5322;. The identifier of interest in this context is the "addr-spec" address and more particularly the "dot-atom-text" rule specified in Section 3.2.3, i.e., the email address shorn of angle brackets, display names, comments, quoted strings, and the like. Because some deployments of XMPP messaging systems may want to re-use existing email addresses as JIDs, it is helpful to define how to transform an email address into a JID. In general, it is straightforward to transform an email address (i.e., a "dot-atom-text") into a JID, since traditional email addresses allow US-ASCII characters only rather than the nearly full range of Unicode code points allowed in a JID. The im: and pres: URI schemes are specified in &rfc3860; and &rfc3859; respectively. With the exception of headers, an im: or pres: URI is simply a mailbox (as specified in RFC 5322) prepended with the im: or pres: scheme. Thus a basic IM or PRES address (not including optional headers) is essentially similar to an email address (e.g., the same characters & ' / allowed in an email address but disallowed in an XMPP localpart are also allowed in a basic IM or PRES address). The im: and pres: URI schemes are specified in &rfc3860; and &rfc3859; respectively. With the exception of headers, an im: or pres: URI is simply a mailbox (as specified in &rfc5322;) prepended with the im: or pres: scheme. Thus a basic IM or PRES address (not including optional headers) is essentially similar to an email address (e.g., the same characters & ' / allowed in an email address but disallowed in an XMPP localpart are also allowed in a basic IM or PRES address). Within the Lightweight Directory Access Protocol (see &rfc2251;), a "distinguished name" (DN) is a hierarchically-organized string representation that uniquely identifies a user, system, or organization. It is possible that some messaging systems use LDAP distinguished names to identify entities that can communicate using the system (e.g., this is reputed to be the case for certain releases of the Lotus Sametime system sold by IBM), and in any case it may be helpful to transform an LDAP distinguished name into an XMPP address for identification or addressing purposes. As previously mentioned, a UTF-8 string representation of LDAP distinguished names is specified in RFC 2253. This representation specifies that the characters , + " \ < > ; are to be escaped with the backslash character (e.g., the character sequence "\," would be used to escape the , character) and that any other non-US-ASCII characters are to be escaped using a character sequence of the form "\xx". As previously mentioned, a UTF-8 string representation of LDAP distinguished names is specified in &rfc2253;. This representation specifies that the characters , + " \ < > ; are to be escaped with the backslash character (e.g., the character sequence "\," would be used to escape the , character) and that any other non-US-ASCII characters are to be escaped using a character sequence of the form "\xx". The following example shows a distinguished name (and transformations thereof) for a person whose common name is "D'Artagnan Saint-André" and who is associated with an organization called "Example & Company, Inc." whose domain name is "example.com": TINS exchanges are completed by sending &MESSAGE; stanzas containing a child <tins/> element qualified by the 'http://jabber.org/protocol/tins' namespace.
- 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.
diff --git a/xep-0035.xml b/xep-0035.xml
index 96d1ae2d0..9af3a6b22 100644
--- a/xep-0035.xml
+++ b/xep-0035.xml
@@ -122,7 +122,7 @@ S: <stream:stream xmlns='jabber:client'
-
@@ -951,11 +951,11 @@ And by opposing end them?
Collection
- A node that contains nodes and/or other collections but no published items. Collections make it possible to represent more sophisticated relationships among nodes. For details, refer to XEP-0248.
+ A node that contains nodes and/or other collections but no published items. Collections make it possible to represent more sophisticated relationships among nodes. For details, refer to &xep0248;.
Presence
- Any entity with a subscription of type "from" or "both" may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems (see RFC 3921).
+ Any entity with a subscription of type "from" or "both" may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems (see &rfc3921;).
Roster
- Any entity in the specified roster group(s) may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems (see RFC 3921).
+ Any entity in the specified roster group(s) may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems (see &rfc3921;).
Authorize
@@ -973,7 +973,7 @@ And by opposing end them?
@@ -3567,7 +3567,7 @@ And by opposing end them?
]]>
-
-
collections
Collection nodes are supported.
OPTIONAL
- Refer to XEP-0248
+ Refer to &xep0248;
config-node
@@ -5360,7 +5360,7 @@ And by opposing end them?
multi-collection
A single leaf node can be associated with multiple collections.
OPTIONAL
- Refer to XEP-0248
+ Refer to &xep0248;
- multi-items
@@ -5560,7 +5560,7 @@ And by opposing end them?
-
@@ -164,7 +164,7 @@
fail:ReceptionFailure
fail:BadRequestMessage
- fail:BadRequestMessage
-
@@ -1090,7 +1090,7 @@
-
@ \40
- \ \5c
-
The request stanza MAY also include either or both of the following:
In reply to a request, the receiver MUST send zero or more replies, with the value of the 'method' attribute set to a value of "result" and the value of the 'code' attribute set to one of the valid SIP response codes as specified in Section 21 of RFC 3261.
+In reply to a request, the receiver MUST send zero or more replies, with the value of the 'method' attribute set to a value of "result" and the value of the 'code' attribute set to one of the valid SIP response codes as specified in Section 21 of &rfc3261;.
Before initiating a TINS negotiation, an XMPP entity SHOULD determine that the target entity supports the 'http://jabber.org/protocol/tins' namespace. Such discovery SHOULD occur by means of &xep0030;, either directly by querying the target entity or indirectly by means of &xep0115;. If the target entity is a non-XMPP entity that is contacted through a gateway, the gateway itself SHOULD reply to service discovery queries on behalf of the non-XMPP entity and SHOULD insert a client capabilities extension into the presence stanzas it generates on behalf of the non-XMPP entity.
@@ -274,7 +274,7 @@TINS is subject to the same security considerations as XMPP, particularly with regard to authentication and channel encryption; for details, refer to RFC 6120.
+TINS is subject to the same security considerations as XMPP, particularly with regard to authentication and channel encryption; for details, refer to &rfc6120;.
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.
NOTE WELL: The protocol defined herein has been folded into &xep0080;.
-This document defines an extension mechanism for capturing "extended presence" information about a user's current physical location. The information structures defined herein are intended to provide a format for describing a location or address that may change fairly frequently (e.g., one's location on a campus or in a large building) in situations where the user or application does not possess, or does not wish to communicate, detailed latitude/longitude data of the type defined in XEP-0080.
+This document defines an extension mechanism for capturing "extended presence" information about a user's current physical location. The information structures defined herein are intended to provide a format for describing a location or address that may change fairly frequently (e.g., one's location on a campus or in a large building) in situations where the user or application does not possess, or does not wish to communicate, detailed latitude/longitude data of the type defined in &xep0080;.
Information about the user's location is provided by the user and propagated on the network by the user's client. The information is structured by means of an <physloc/> element that is qualified by the 'http://jabber.org/protocol/physloc' namespace. The location information itself is provided as the XML character data of the following children of the <physloc/> element:
diff --git a/xep-0114.xml b/xep-0114.xml index 155cb3593..759c25eb9 100644 --- a/xep-0114.xml +++ b/xep-0114.xml @@ -100,7 +100,7 @@ from='plays.shakespeare.lit' id='3BF96D32'> ]]> -If the server will not service the component name specified in the 'to' attribute of the stream header, it MUST return a stream error (e.g., <conflict/> or <host-unknown/>). If the server does not recognize or support the namespace specified in the stream header (e.g., it does not support streams qualified by the 'jabber:component:accept' namespace), it MUST return an <invalid-namespace/> stream error. For all errors related to the stream header, the server MUST follow the rules in Section 4.7.1 of XMPP Core by returning an opening stream tag, stream error element, and closing stream tag rather than merely a stream error element (refer to RFC 3920 for details).
+If the server will not service the component name specified in the 'to' attribute of the stream header, it MUST return a stream error (e.g., <conflict/> or <host-unknown/>). If the server does not recognize or support the namespace specified in the stream header (e.g., it does not support streams qualified by the 'jabber:component:accept' namespace), it MUST return an <invalid-namespace/> stream error. For all errors related to the stream header, the server MUST follow the rules in Section 4.7.1 of XMPP Core by returning an opening stream tag, stream error element, and closing stream tag rather than merely a stream error element (refer to &rfc3920; for details).
After receiving the stream header reply from the server, the component MUST send a <handshake/> element with appropriate contents.
The protocol defined herein addresses the following requirements:
Note: All sorting operations MUST be performed using "i;octet" collation as specified in Section 9.3 of &rfc4790;.
Consider a more complex example, where the entity includes several identities (with the service discovery name in different languages) as well as extended information formatted according to XEP-0128.
+Consider a more complex example, where the entity includes several identities (with the service discovery name in different languages) as well as extended information formatted according to &xep0128;.
<iq from='benvolio@capulet.lit/230193'
id='disco1'
@@ -470,7 +470,7 @@
An application (the "requesting entity") can learn what features another entity supports by sending a disco#info request (see XEP-0030) to the entity that generated the caps information (the "generating entity").
+An application (the "requesting entity") can learn what features another entity supports by sending a disco#info request (see &xep0030;) to the entity that generated the caps information (the "generating entity").
When a connected client or peer server sends a service discovery information request to determine the entity capabilities of a server that advertises capabilities via the stream feature, the requesting entity MUST send the disco#info request to the server's JID as provided in the 'from' attribute of the response stream header (the 'from' attribute was recommended by &rfc3920; and is required by &rfc6120;). To enable this functionality, a server that advertises support for entity capabilities MUST provide a 'from' address in its response stream headers, in accordance with RFC 6120.
+When a connected client or peer server sends a service discovery information request to determine the entity capabilities of a server that advertises capabilities via the stream feature, the requesting entity MUST send the disco#info request to the server's JID as provided in the 'from' attribute of the response stream header (the 'from' attribute was recommended by &rfc3920; and is required by &rfc6120;). To enable this functionality, a server that advertises support for entity capabilities MUST provide a 'from' address in its response stream headers, in accordance with &rfc6120;.
Before attempting to engage in an ESession with Bob, Alice MAY discover whether he supports this protocol, using either &xep0030; or the presence-based profile of XEP-0030 specified in &xep0115;.
-The normal course of events is for Alice to authenticate with her server, retrieve her roster (see RFC 3921), send initial presence to her server, and then receive presence information from all the contacts in her roster. If the presence information she receives from some contacts does not include capabilities data (per XEP-0115), Alice SHOULD then send a service discovery information ("disco#info") request to each of those contacts (in accordance with XEP-0030). Such initial service discovery stanzas MUST NOT be considered part of encrypted communication sessions for the purposes of this document, since they perform a "bootstrapping" function that is a prerequisite to encrypted communications. The disco#info request sent from Alice to Bob might look as follows:
+Before attempting to engage in an ESession with Bob, Alice MAY discover whether he supports this protocol, using either &xep0030; or the presence-based profile of &xep0030; specified in &xep0115;.
+The normal course of events is for Alice to authenticate with her server, retrieve her roster (see &rfc3921;), send initial presence to her server, and then receive presence information from all the contacts in her roster. If the presence information she receives from some contacts does not include capabilities data (per &xep0115;), Alice SHOULD then send a service discovery information ("disco#info") request to each of those contacts (in accordance with XEP-0030). Such initial service discovery stanzas MUST NOT be considered part of encrypted communication sessions for the purposes of this document, since they perform a "bootstrapping" function that is a prerequisite to encrypted communications. The disco#info request sent from Alice to Bob might look as follows:
If Bob supports one or more of each of Alice's ESession options and is willing to start an ESession with Alice, then he MUST select one of the options from each of the ESession fields he received from Alice including one hash algorithm ("HASH"), and one of the MODP groups (see &rfc3766; or RFC 3526 for recommendations regarding balancing the sizes of symmetric cipher blocks and Diffie-Hellman moduli) and Alice's corresponding value of 'He' (for 4-message negotiations) or 'e' (for 3-message negotiations).
+If Bob supports one or more of each of Alice's ESession options and is willing to start an ESession with Alice, then he MUST select one of the options from each of the ESession fields he received from Alice including one hash algorithm ("HASH"), and one of the MODP groups (see &rfc3766; or &rfc3526; for recommendations regarding balancing the sizes of symmetric cipher blocks and Diffie-Hellman moduli) and Alice's corresponding value of 'He' (for 4-message negotiations) or 'e' (for 3-message negotiations).
Note: Each MODP group has at least two well known constants: a large prime number p, and a generator g for a subgroup of GF(p).
For 3-message negotiations, Bob SHOULD return a &feature; error unless: 1 < e < p - 1
Bob MUST then perform the following computations (where n is the number of bits per cipher block for the selected block cipher algorithm):
diff --git a/xep-0117.xml b/xep-0117.xml index 276ecb3b9..ace8b922a 100644 --- a/xep-0117.xml +++ b/xep-0117.xml @@ -87,10 +87,10 @@Note: This protocol suite is obsolete. For updated protocol suites, refer to &xep0213; and &xep0216;.
-The &xep0073; introduced the concept of a "protocol suite". This document extends the basic support specified in XEP-0073 by specifying an Intermediate IM Protocol Suite.
+The &xep0073; introduced the concept of a "protocol suite". This document extends the basic support specified in &xep0073; by specifying an Intermediate IM Protocol Suite.
This document follows the same approach as XEP-0073. By design, the Basic IM Protocol Suite does not include more advanced instant messaging functionality; the present document fills the need for a protocol suite that addresses such functionality.
+This document follows the same approach as &xep0073;. By design, the Basic IM Protocol Suite does not include more advanced instant messaging functionality; the present document fills the need for a protocol suite that addresses such functionality.
A protocol is deemed worthy of inclusion in this protocol suite if:
In addition, because the intermediate suite builds on the basic suite, by definition all protocols required by XEP-0073 are also required by the intermediate suite (refer to XEP-0073 for details).
+In addition, because the intermediate suite builds on the basic suite, by definition all protocols required by &xep0073; are also required by the intermediate suite (refer to XEP-0073 for details).
This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.
diff --git a/xep-0119.xml b/xep-0119.xml index ed5bb17f3..dc7247ea2 100644 --- a/xep-0119.xml +++ b/xep-0119.xml @@ -88,7 +88,7 @@XMPP began life as a dedicated instant messaging and presence protocol within the Jabber community. The needs of this community were not advanced (simple IM and presence), and the presence model designed by that community mainly takes account of basic presence only (i.e., on/off availability on an IM network). Within this model (and using the terminology of &rfc2778;), the only watchers are those in the principal's contact list (in XMPP called a "roster"). In addition, authorization to receive basic presence broadcasts is handled by the principal through a combination of roster management and basic presence subscriptions as defined in &xmppim;. The presence service is tied to the principal's session with a server, and the server's internal session manager handles both presence and instant messaging functionality (although IM and presence can be separated in system configuration or "on the fly" via negative presence priorities).
-This basic presence model was not designed for the more advanced world of extended presence. While some existing IM clients publish extended presence information as XML extensions to the XMPP &PRESENCE; stanza, that model does not scale well, does not respect the bandwidth restrictions of many clients on the network, and does not provide for more granular control over information access (anyone who receives presence will also receive geolocation data and the like). However, there is a more advanced protocol that is specially designed to fully implement the publish-subscribe design pattern on top of XMPP, specified in XEP-0060: &xep0060;. The publish-subscribe protocol can be used to create a service that provides full control over each type of extended presence data, sending that data only to those specifically authorized to receive it and those who have an active interest in each extension. In particular, for extended presence related to IM users, we specify the use of the personal eventing subset of XEP-0060, as defined in XEP-0163.
+This basic presence model was not designed for the more advanced world of extended presence. While some existing IM clients publish extended presence information as XML extensions to the XMPP &PRESENCE; stanza, that model does not scale well, does not respect the bandwidth restrictions of many clients on the network, and does not provide for more granular control over information access (anyone who receives presence will also receive geolocation data and the like). However, there is a more advanced protocol that is specially designed to fully implement the publish-subscribe design pattern on top of XMPP, specified in XEP-0060: &xep0060;. The publish-subscribe protocol can be used to create a service that provides full control over each type of extended presence data, sending that data only to those specifically authorized to receive it and those who have an active interest in each extension. In particular, for extended presence related to IM users, we specify the use of the personal eventing subset of &xep0060;, as defined in XEP-0163.
The provision and communication of extended presence information follows the classic publish-subscribe design pattern: an individual publishes information such as geographical location data, and the data is broadcasted to all subscribers who are authorized to receive that data. (Alternatively, the data can be published on behalf of the individual, such as by a mobile telephony service that has knowledge of the individual's geographical location and authorization to act as a publisher of that data.) In general, the relationship between the publisher and subscriber is mediated by a service that receives publication requests, broadcasts data to subscribers, and enables the individual to manage lists of entities that are authorized to publish or subscribe to the data. This model makes it possible to deploy highly flexible extended presence services within the context of XMPP.
The following diagram provides a schematic representation of such a service.
@@ -156,7 +156,7 @@ Service | Manager
REQUIRED *
- * Note: The User Avatar specification (XEP-0084) has not yet advanced to a status of Draft within the XSF's standards process, and the Extended Presence Protocol Suite will not be submitted for approval until it does so.
+ * Note: The User Avatar specification (&xep0084;) has not yet advanced to a status of Draft within the XSF's standards process, and the Extended Presence Protocol Suite will not be submitted for approval until it does so.
Discovery of extended presence pubsub nodes is expedited through the use of Personal Eventing via Pubsub (PEP), since in PEP services there is a one-to-one relationship between payload types and NodeIDs. The NodeIDs MUST be as follows:
diff --git a/xep-0124.xml b/xep-0124.xml index a169b5488..71b608f3d 100644 --- a/xep-0124.xml +++ b/xep-0124.xml @@ -310,9 +310,9 @@ first socket second socket ]]>The requirements of RFC 2616 MUST be met for both requests and responses. Additional HTTP headers not specified herein MAY be included, but receivers SHOULD ignore any such headers. Clients and connection managers MAY omit headers that are not mandated by RFC 2616 and would otherwise be ignored (e.g. if the client has constrained bandwidth), but clients are advised that network and proxy policies could block such requests.
+The requirements of &rfc2616; MUST be met for both requests and responses. Additional HTTP headers not specified herein MAY be included, but receivers SHOULD ignore any such headers. Clients and connection managers MAY omit headers that are not mandated by RFC 2616 and would otherwise be ignored (e.g. if the client has constrained bandwidth), but clients are advised that network and proxy policies could block such requests.
All information is encoded in the body of standard HTTP POST requests and responses. Each HTTP body contains a single <body/> wrapper which encapsulates the XML elements being transferred (see <body/> Wrapper Element).
-Clients MUST send all HTTP requests as POST requests in any way permitted by RFC 1945 or RFC 2616. For example, clients can be expected to open more than one persistent connection, or in some cases to open a new HTTP/1.0 connection to send each request. However, clients and connection managers SHOULD NOT use Chunked Transfer Coding, since intermediaries might buffer each partial HTTP request or response and only forward the full request or response once it is available.
+Clients MUST send all HTTP requests as POST requests in any way permitted by &rfc1945; or RFC 2616. For example, clients can be expected to open more than one persistent connection, or in some cases to open a new HTTP/1.0 connection to send each request. However, clients and connection managers SHOULD NOT use Chunked Transfer Coding, since intermediaries might buffer each partial HTTP request or response and only forward the full request or response once it is available.
Clients MAY include an HTTP Accept-Encoding header in any request. If the connection manager receives a request with an Accept-Encoding header, it MAY include an HTTP Content-Encoding header in the response (indicating one of the encodings specified in the request) and compress the response body accordingly.
The HTTP Content-Type header of all client requests SHOULD be "text/xml; charset=utf-8". However, clients MAY specify another value if they are constrained to do so (e.g., "application/x-www-form-urlencoded" or "text/plain"). The client and connection manager SHOULD ignore all HTTP Content-Type headers they receive.
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 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/> 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 &rfc6120; 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.
Note: Clients that only support Polling Sessions MAY prevent the connection manager from waiting by setting 'wait' or 'hold' to "0". However, polling is NOT RECOMMENDED since the associated increase in bandwidth consumption and the decrease in responsiveness are both typically one or two orders of magnitude!
-A connection manager MAY be configured to enable sessions with more than one server in different domains. When requesting a session with such a "proxy" connection manager, a client SHOULD include a 'route' attribute that specifies the protocol, hostname, and port of the server with which it wants to communicate, formatted as "proto:host:port" (e.g., "xmpp:example.com:9999").
The <body/> element of the first request MAY also possess a 'from' attribute, which specifies the originator of the first stream and which enables the connection manager to forward the originating entity's identity to the application server (e.g., the JabberID of an entity that is connecting to an XMPP server; see XEP-0206).
+A connection manager MAY be configured to enable sessions with more than one server in different domains. When requesting a session with such a "proxy" connection manager, a client SHOULD include a 'route' attribute that specifies the protocol, hostname, and port of the server with which it wants to communicate, formatted as "proto:host:port" (e.g., "xmpp:example.com:9999").
The <body/> element of the first request MAY also possess a 'from' attribute, which specifies the originator of the first stream and which enables the connection manager to forward the originating entity's identity to the application server (e.g., the JabberID of an entity that is connecting to an XMPP server; see &xep0206;).
A client MAY include an 'ack' attribute (set to "1") to indicate that it will be using acknowledgements throughout the session and that the absence of an 'ack' attribute in any request is meaningful (see Acknowledgements).
Some clients are constrained to only accept HTTP responses with specific Content-Types (e.g., "text/html"). The <body/> element of the first request MAY possess a 'content' attribute. This specifies the value of the HTTP Content-Type header that MUST appear in all the connection manager's responses during the session. If the client request does not possess a 'content' attribute, then the HTTP Content-Type header of responses MUST be "text/xml; charset=utf-8".
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 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.
+Note: Although many of these conditions are similar to the XMPP stream error conditions specified in &rfc6120;, 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.
HTTP pipelining allows a client to send multiple requests over the same HTTP socket connection without waiting for the corresponding responses. However, RFC 2616 notes that only idempotent methods should be allowed to use HTTP pipelining, which does not include the POST method used extensively by BOSH. Furthermore, there is no guarantee that pipelining will succeed because intermediate proxies might not support it. Therefore, clients and connection managers SHOULD NOT use HTTP Pipelining.
+HTTP pipelining allows a client to send multiple requests over the same HTTP socket connection without waiting for the corresponding responses. However, &rfc2616; notes that only idempotent methods should be allowed to use HTTP pipelining, which does not include the POST method used extensively by BOSH. Furthermore, there is no guarantee that pipelining will succeed because intermediate proxies might not support it. Therefore, clients and connection managers SHOULD NOT use HTTP Pipelining.
Several popular instant messaging services implement a feature known as invisibility: the ability to remain online yet appear offline to some or all of one's contacts. A number of Jabber servers and clients have also implemented such a feature, using special values of the &PRESENCE; element's 'type' attribute (e.g., <presence type='invisible'/>). Unfortunately, such implementations are not compliant with &xmppcore; and &xmppim;, which specify that only the 'type' attribute values defined in the XML schema for the 'jabber:client' and 'jabber:server' namespaces are allowed in XMPP (and those values do not include "invisible"). However, RFC 3921 also defines a privacy lists protocol (i.e., the 'jabber:iq:privacy' namespace) that can be used to implement invisibility in an XMPP-compliant manner. This specification documents how to do just that.
+Several popular instant messaging services implement a feature known as invisibility: the ability to remain online yet appear offline to some or all of one's contacts. A number of Jabber servers and clients have also implemented such a feature, using special values of the &PRESENCE; element's 'type' attribute (e.g., <presence type='invisible'/>). Unfortunately, such implementations are not compliant with &xmppcore; and &xmppim;, which specify that only the 'type' attribute values defined in the XML schema for the 'jabber:client' and 'jabber:server' namespaces are allowed in XMPP (and those values do not include "invisible"). However, &rfc3921; also defines a privacy lists protocol (i.e., the 'jabber:iq:privacy' namespace) that can be used to implement invisibility in an XMPP-compliant manner. This specification documents how to do just that.
This document addresses the following requirements:
@@ -409,7 +409,7 @@Privacy lists can become complex and must be carefully managed by clients. For example, let us imagine that the user is currently applying another active list unrelated to visibility (e.g., a list that blocks communications with a stalker); if the user then clicks "Go Invisible" and the client is not smart, it could overwrite the stalker blocking. Therefore, if the user has an active list that incorporates rules other than those related to visibility/invisibility, the client SHOULD either assume that visibility/invisibility is an overlay on the list currently in use (generating an appropriate privacy list that takes both into account) or prompt the user regarding their intentions. In the absence of privacy lists unrelated to visibility/invisibility, the client may proceed in a less cautious fashion.
For security concerns related to privacy lists, refer to RFC 3921. Care must be taken regarding privacy lists, especially so that visibility/invisibility rules do not overwrite existing rules the user has set for the sake of security and privacy; for details, see the Implementation Notes section of this document.
+For security concerns related to privacy lists, refer to &rfc3921;. Care must be taken regarding privacy lists, especially so that visibility/invisibility rules do not overwrite existing rules the user has set for the sake of security and privacy; for details, see the Implementation Notes section of this document.
It is important to recognize that invisibility can be defeated without more advanced privacy lists than those defined above and an awareness of context on the part of a client. For example, if a user usually logs in as the same resource (e.g., "Home"), a contact can send an IQ request to that resource's full JID using &xep0012;, &xep0030;, &xep0090;, or &xep0092; and receive a reply, thus providing information that reveals the user's availability. In addition, Last Activity requests sent by a subscribed contact to the user's bare JID will normally reveal the user's availability as well. To help ensure that the user's invisibility cannot be defeated in this way, the user's client SHOULD add IQ blocking to the relevant privacy list. Finally, the user's client SHOULD NOT return "is-composing" events as defined in &xep0022; or &xep0085;.
No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this specification.
The XML schema for the 'jabber:iq:privacy' namespace is defined in RFC 3921.
+The XML schema for the 'jabber:iq:privacy' namespace is defined in &rfc3921;.
This document inherits terms from RFC 2518, &rfc2616;, and &rfc2617;.
+This document inherits terms from &rfc2518;, &rfc2616;, and &rfc2617;.
The client SHOULD attempt to PUT the file on the server.
If the XEP-0070 verification is successful, the server then allows the file to be retrieved:
+If the &xep0070; verification is successful, the server then allows the file to be retrieved:
See RFC 2518, XMPP Core, and XEP-0070 for security considerations related to those protocols, which are used by the profile defined herein. The initiating client MUST ensure that appropriate access controls are specified, normally by performing a PROPPATCH request to set the list of Jabber IDs authorized to retrieve the file. The server MUST NOT allow access to the file until access controls have been specified. In addition, the server MUST NOT allow access to the file by any unauthorized entity.
+See &rfc2518;, XMPP Core, and &xep0070; for security considerations related to those protocols, which are used by the profile defined herein. The initiating client MUST ensure that appropriate access controls are specified, normally by performing a PROPPATCH request to set the list of Jabber IDs authorized to retrieve the file. The server MUST NOT allow access to the file until access controls have been specified. In addition, the server MUST NOT allow access to the file by any unauthorized entity.
This document requires no interaction with &IANA;.
diff --git a/xep-0130.xml b/xep-0130.xml index 59e7b2408..b2a19eedc 100644 --- a/xep-0130.xml +++ b/xep-0130.xml @@ -529,7 +529,7 @@ ]]> -As described below, various error conditions may occur. (For information about error syntax, refer to RFC 6120 and &xep0086;.)
+As described below, various error conditions may occur. (For information about error syntax, refer to &rfc6120; 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.
Date formats differ widely. &xep0082; defines the Date, DateTime, and Time profiles of &iso8601;, which correspond to the Date, DateTime, and Time headers registered herein. The SHIM Date header also corresponds to the Date metadata element used in &DUBLINCORE; as specified in &rfc2413;.
-However, many Internet standards use a different datetime format that ultimately derives from &rfc0822; as updated by &rfc1123;; specifically, that format is used by email (RFC 2822), the World Wide Web (RFC 2616), and the Session Initiation Protocol (RFC 3261). To map dates to and from these protocols, we define the SHIM RFC2822Date header.
+However, many Internet standards use a different datetime format that ultimately derives from &rfc0822; as updated by &rfc1123;; specifically, that format is used by email (&rfc2822;), the World Wide Web (RFC 2616), and the Session Initiation Protocol (RFC 3261). To map dates to and from these protocols, we define the SHIM RFC2822Date header.
In general, security considerations are the responsibility of the "using protocol".
diff --git a/xep-0133.xml b/xep-0133.xml index 1051ce69f..36db0915a 100644 --- a/xep-0133.xml +++ b/xep-0133.xml @@ -994,7 +994,7 @@ ]]>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;.
+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 &rfc6120;; 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 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".
+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 &rfc6120; 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.
The <note/> element specifies a private note about the conversation. The absolute time the note was created SHOULD be specified with a 'utc' attribute (which MUST be UTC and adhere to the DateTime format specified in XEP-0082). Inclusion of the <note/> element is OPTIONAL.
+The <note/> element specifies a private note about the conversation. The absolute time the note was created SHOULD be specified with a 'utc' attribute (which MUST be UTC and adhere to the DateTime format specified in &xep0082;). Inclusion of the <note/> element is OPTIONAL.
Therefore, often a client will want to send or receive a sequence of messages, optionally add private notes to the sequence, optionally encrypt the sequence (see XEP-0241), and then ask the server to archive it. Such messages and notes SHOULD be stored on the server in the form of a "collection".
+Therefore, often a client will want to send or receive a sequence of messages, optionally add private notes to the sequence, optionally encrypt the sequence (see &xep0241;), and then ask the server to archive it. Such messages and notes SHOULD be stored on the server in the form of a "collection".
A collection of messages and notes is uploaded to the server encapsulated in a <save/> element.
@@ -779,7 +779,7 @@ ]]>The client MAY specify an absolute time for any message by providing a 'utc' attribute (which MUST be UTC and adhere to the DateTime format specified in XEP-0082) instead of a 'secs' attribute. The absolute time MAY be earlier than the start time of the collection:
+The client MAY specify an absolute time for any message by providing a 'utc' attribute (which MUST be UTC and adhere to the DateTime format specified in &xep0082;) instead of a 'secs' attribute. The absolute time MAY be earlier than the start time of the collection:
As described in XEP-0241, the content of the uploaded x:data form MAY be encrypted.
+As described in &xep0241;, the content of the uploaded x:data form MAY be encrypted.
Requirements and protocol flows for each of these use cases are defined below. The protocols to retrieve a list of collections and an indivdual collection both make extensive use of &xep0059;. Clients and servers SHOULD support all the features defined in that protocol.
To request a list of collections, the client sends a <list/> element. The 'start' and 'end' attributes MAY be specified to indicate a date range (the values of these attributes MUST be UTC and adhere to the DateTime format specified in XEP-0082). The 'with' attribute MAY specify the JIDs of XMPP entities (see the JID Matching section of this document).
+To request a list of collections, the client sends a <list/> element. The 'start' and 'end' attributes MAY be specified to indicate a date range (the values of these attributes MUST be UTC and adhere to the DateTime format specified in &xep0082;). The 'with' attribute MAY specify the JIDs of XMPP entities (see the JID Matching section of this document).
If the 'with' attribute is omitted then collections with any JID are returned. If only 'start' is specified then all collections on or after that date should be returned. If only 'end' is specified then all collections prior to that date should be returned.
The client SHOULD use Result Set Management to limit the number of collections returned by the server in a single stanza, taking care not to request a page of collections that is so big it might exceed rate limiting restrictions.
To request a page of messages from a collection the client sends a <retrieve/> element. The 'with' and 'start' attributes specify the participating JID and the start time (see XEP-0082). Both attributes MUST be included to uniquely identify a collection.
+To request a page of messages from a collection the client sends a <retrieve/> element. The 'with' and 'start' attributes specify the participating JID and the start time (see &xep0082;). Both attributes MUST be included to uniquely identify a collection.
Note: the <retrieve/> SHALL NOT possess the 'exactmatch' attribute, because exact JID matching is always implied for this command (see the JID Matching section of this document). This is done to prevent the return of multiple collections in response to the <retrieve/> command.
The client SHOULD use Result Set Management to limit the number of messages returned by the server in a single stanza, taking care not to request a page of messages that is so big it might exceed rate limiting restrictions.
The client can "synchronize" its local copy of the archive with the "primary" archive on the server at any time. The first step is to request the list of collections that the server has modified (created, changed, or removed) in its primary archive since the last update to the client's copy of the archive.
Replication uses the <modified/> element. The list of collections that have been modified since a given time is requested by sending a <modified/> element to the server. The server then returns the list of collections that have been created, changed, or removed. A collection that has been created or changed is specified with a <changed/> element (with version zero for created collections), and a collection that has been removed is specified with a <removed/> element.
-When requesting the list of modified collections, the client MUST embed appropriate Result Set Management data in the <modified/> element. The <modified/> element MUST include a 'start' attribute that specifies a UTC datetime (see XEP-0082) that it has previously received from the server or that it has determined locally (e.g., when synchronizing for the first time the client SHOULD choose a suitable time for the first page request, such as 1970-01-01T00:00:00Z).
+When requesting the list of modified collections, the client MUST embed appropriate Result Set Management data in the <modified/> element. The <modified/> element MUST include a 'start' attribute that specifies a UTC datetime (see &xep0082;) that it has previously received from the server or that it has determined locally (e.g., when synchronizing for the first time the client SHOULD choose a suitable time for the first page request, such as 1970-01-01T00:00:00Z).
If automatic archiving defaults to enabled then that creates serious privacy issues for users of legacy clients that do not support this protocol, and (more seriously) for those contacts who they unwittingly mislead by agreeing to disable logging (via the 'logging' field defined in XEP-0155).
+If automatic archiving defaults to enabled then that creates serious privacy issues for users of legacy clients that do not support this protocol, and (more seriously) for those contacts who they unwittingly mislead by agreeing to disable logging (via the 'logging' field defined in &xep0155;).
If a server deployment enables automatic archiving by default, then it MUST return a stream feature containing an empty <default/> element (see the Stream Feature section of this document).
This format is nearly identical to that for the stream initiation <si/> element (see XEP-0095). The major difference is the lack of the feature negotiation for the stream methods, and the addition of a 'from' attribute.
+This format is nearly identical to that for the stream initiation <si/> element (see &xep0095;). The major difference is the lack of the feature negotiation for the stream methods, and the addition of a 'from' attribute.
The 'from' attribute SHOULD be present, and MUST be present if the stanza containing the <sipub/> is not from the stream owner (e.g., if the stream is advertised at a publish-subscribe node). If present, this attribute MUST be the valid JID for the stream owner.
The 'id' attribute is an opaque identifier. This attribute MUST be present, and MUST be a valid non-empty string. It uniquely identifies the published request at the potential sender.
As with stream initiation, the 'profile' attribute MUST be present, and MUST be the namespace URI governing the profile information. It identifies the format for the SI profile.
@@ -152,7 +152,7 @@One of the goals of sipub is to integrate Stream Initiation with Data Forms to provide a "file upload" capability. This is accomplished via the datatypes specified in &xep0122;. Each datatype is specific to the profile desired.
-For example the datatype "sipub:file-transfer" is used to identify the file upload field(s) corresponding to XEP-0096:
+For example the datatype "sipub:file-transfer" is used to identify the file upload field(s) corresponding to &xep0096;:
This document introduces no security concerns beyond those specified in XEP-0060 and the relevant Stream Initiation profile in use.
+This document introduces no security concerns beyond those specified in &xep0060; and the relevant Stream Initiation profile in use.
This document requires no interaction with &IANA;.
diff --git a/xep-0138.xml b/xep-0138.xml index 1cdedd485..88f493314 100644 --- a/xep-0138.xml +++ b/xep-0138.xml @@ -139,7 +139,7 @@Both entities MUST now consider the previous (uncompressed) stream to be null and void, just as with TLS negotiation and SASL negotiation (as specified in RFC 3920) and MUST begin compressed communications with a new (compressed) stream. Therefore the initiating entity MUST initiate a new stream to the receiving entity:
+Both entities MUST now consider the previous (uncompressed) stream to be null and void, just as with TLS negotiation and SASL negotiation (as specified in &rfc3920;) and MUST begin compressed communications with a new (compressed) stream. Therefore the initiating entity MUST initiate a new stream to the receiving entity:
Finally an example of a required form submission before a user is allowed to the workgroup queue for support@workgroup.example.com. The data form in this example is trivial; please see XEP-0004 for a complete data form example. The example begins as normal, but the workgroup returns a &e406; error.
+Finally an example of a required form submission before a user is allowed to the workgroup queue for support@workgroup.example.com. The data form in this example is trivial; please see &xep0004; for a complete data form example. The example begins as normal, but the workgroup returns a &e406; error.
The server sends an invitation to the user to begin their conversation with an agent, structured according to the format defined in XEP-0045. The 'from' attribute of the <invite/> element MUST be set to the JID of the workgroup. The invitation indicates that the user is no longer in the workgroup queue. The user MUST NOT receive any more user queue status updates once they receive an invitation.
+The server sends an invitation to the user to begin their conversation with an agent, structured according to the format defined in &xep0045;. The 'from' attribute of the <invite/> element MUST be set to the JID of the workgroup. The invitation indicates that the user is no longer in the workgroup queue. The user MUST NOT receive any more user queue status updates once they receive an invitation.
There are no defined error conditions for user invitations.
There are no defined error conditions for workgroup queue status updates.
@@ -899,7 +899,7 @@ Agent Service |<-----------------------------| | | ]]>The server sends an invitation to the agent to begin their conversation with the user, structured according to the format defined in XEP-0045. The 'from' attribute of the <invite/> element MUST be set to the JID of the workgroup.
+The server sends an invitation to the agent to begin their conversation with the user, structured according to the format defined in &xep0045;. The 'from' attribute of the <invite/> element MUST be set to the JID of the workgroup.
In order to match invitations to offers, all invitations SHOULD include metadata in the <offer/> element, with the JID of the user specified via the 'jid' attribute. The typical metadata fragment would appear as:
After completing this research, the prospective author might conclude that a new protocol extension is needed. If so, the author is strongly advised to do the following:
The XMPP Extensions Editor team will then process your pull request, seek Council approval if necessary, and publish an updated version of your XEP.
-NOTE: As explained in XEP-0001, updated versions of XEPs in the Experimental state are published without the need for approval by the XMPP Council. However, updated versions of XEPs in the Active, Draft, or Final state must be approved by the XMPP Council to ensure proper change control regarding approved protocols.
+NOTE: As explained in &xep0001;, updated versions of XEPs in the Experimental state are published without the need for approval by the XMPP Council. However, updated versions of XEPs in the Active, Draft, or Final state must be approved by the XMPP Council to ensure proper change control regarding approved protocols.
The XML character data of the <type/> element SHOULD be either "Standards Track" or "Informational" (there are also Historical, Humorous, and Procedural XEPs, but these are uncommon and usually written by the XMPP Extensions Editor team). A Standards Track XEP defines an XMPP extension intended to be used as a common part of XMPP technologies. An Informational XEP defines best practices or a usage profile related to XMPP or an XMPP Extension Protocol (e.g., &xep0175;).
The XML character data of the <approver/> element SHOULD be "Council".
The <dependencies/> element is used to specify RFCs, XMPP Extension Protocols, and other specifications on which your proposal depends in a normative fashion (i.e., specifications that MUST or SHOULD be understood in order to implement your proposed protocol). Each specification MUST be identified by a distinct <spec/> child element (see existing XEP specifications for clues regarding document identifiers, or consult with the XMPP Extensions Editor team).
-The <supersedes/>, <supersededby/>, <shortname/>, and <schemaloc/> elements are for use by the XMPP Extensions Editor team; however, if your document supersedes an existing XMPP Extension Protocol, feel free to include a <spec/> child element specifying the document identifier (e.g., XEP-0093) for the protocol that is being superseded.
-Include one <author/> element for each co-author. Note well that the <firstname/> and <surname/> elements are REQUIRED per XEP-0001, as is some combination of the <email/>, <jid/>, and <uri/> elements so that appropriate contact information is available.
+The <supersedes/>, <supersededby/>, <shortname/>, and <schemaloc/> elements are for use by the XMPP Extensions Editor team; however, if your document supersedes an existing XMPP Extension Protocol, feel free to include a <spec/> child element specifying the document identifier (e.g., &xep0093;) for the protocol that is being superseded.
+Include one <author/> element for each co-author. Note well that the <firstname/> and <surname/> elements are REQUIRED per &xep0001;, as is some combination of the <email/>, <jid/>, and <uri/> elements so that appropriate contact information is available.
Include one <revision/> element for each revision of your document. The XML character data of the <version/> element SHOULD be "0.0.1" for your initial submission to the XMPP Extensions Editor team, and the <remark/> SHOULD be "First draft."; for each revision, you will include another <revision/> element (place it before the existing <revision/> elements) and iterate the <version/> element (e.g., "0.0.2" after "0.0.1" or "0.10" after "0.9"). The format for the <date/> element is yyyy-mm-dd.
If your proposal defines a number of error and status codes (as is done in XEP-0045), it is a good idea to include a table of all the codes defined in your document.
+If your proposal defines a number of error and status codes (as is done in &xep0045;), it is a good idea to include a table of all the codes defined in your document.
You may want to include a section describing various business rules (essentially, a variety of MUSTs, SHOULDs, and MAYs regarding application behavior). This is not required but can be helpful to implementers.
@@ -201,7 +201,7 @@If there are any internationalization or localization issues related to your proposal (e.g., whether to include the 'xml:lang' attribute), define them in this optional section.
Your proposal MUST include a section entitled "Security Considerations". Even if there are no security features or concerns related to your proposal, you MUST note that fact. For helpful guidelines, refer to &rfc3552;; the core XMPP specification (RFC 6120) also includes a very thorough security considerations section that can be used as an examplar.
+Your proposal MUST include a section entitled "Security Considerations". Even if there are no security features or concerns related to your proposal, you MUST note that fact. For helpful guidelines, refer to &rfc3552;; the core XMPP specification (&rfc6120;) also includes a very thorough security considerations section that can be used as an examplar.
This section is REQUIRED. The IANA is &IANA;, the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. Most proposals do not require interaction with the IANA, in which case the text of this section SHOULD read "This document requires no interaction with the Internet Assigned Numbers Authority (IANA)." If your proposal requires interaction with the IANA, discuss the matter with the XMPP Extensions Editor team in their role as the XMPP Registrar. Do not contact the IANA on your own!
@@ -266,14 +266,14 @@ echo -n 'bard@shakespeare.lit' | openssl enc -nopad -base64When talking about an element by name, refer to it as an empty XML element. Example: the <query/> element.
-The top-level &MESSAGE;, &PRESENCE;, and &IQ; elements are actually XML stanzas (see RFC 6120); please refer to them as stanzas, not elements.
+The top-level &MESSAGE;, &PRESENCE;, and &IQ; elements are actually XML stanzas (see &rfc6120;); please refer to them as stanzas, not elements.
Elements possess attributes and contain character data and/or child elements; do not confuse these terms.
Do not use the term "tag" when you mean "element".
Do not add a possessive to the element itself. Negative example: the <body/>'s character data. Positive example: the <body/> element's character data.
Note: There are shortcuts for stanza names and some common element names in the xep.ent file.
When talking about an error condition, use the XML element names defined in RFC 6120 rather than the old HTTP-style code numbers. Example: the <feature-not-implemented/> error.
+When talking about an error condition, use the XML element names defined in &rfc6120; rather than the old HTTP-style code numbers. Example: the <feature-not-implemented/> error.
Note: There are shortcuts for the stanza errors in the xep.ent file.
This document deliberately speaks of rosters and roster items, not presence subscriptions. Although rosters and subscriptions are closely connected (as explained in RFC 3921), they are not identical. The protocol defined herein enables an entity to suggest that another entity might want to add, delete, or modify roster items only, and does not dictate the suggested presence subscription state associated with those roster items. This is intentional.
+This document deliberately speaks of rosters and roster items, not presence subscriptions. Although rosters and subscriptions are closely connected (as explained in &rfc3921;), they are not identical. The protocol defined herein enables an entity to suggest that another entity might want to add, delete, or modify roster items only, and does not dictate the suggested presence subscription state associated with those roster items. This is intentional.
If the roster item addition stanza will result in adding the item to the roster, the receiving application MUST (either with approval by a human user or automatically subject to configuration) send a roster set to the user's server containing the new item as described in RFC 3921. After completing the roster set, the receiving application SHOULD also send a &PRESENCE; stanza of type "subscribe" to the JID of the new item.
+If the roster item addition stanza will result in adding the item to the roster, the receiving application MUST (either with approval by a human user or automatically subject to configuration) send a roster set to the user's server containing the new item as described in &rfc3921;. After completing the roster set, the receiving application SHOULD also send a &PRESENCE; stanza of type "subscribe" to the JID of the new item.
For a description of the recommended application behavior when a roster item addition stanza actually results in editing of an existing roster item, refer to the Suggesting Roster Item Modification section of this document.
If the item is to be deleted, the receiving application SHOULD remove the item from the roster by sending a roster set to the user's server with the 'subscription' attribute set to a value of "remove" as described in RFC 3921, since this results in generation of the appropriate &PRESENCE; stanzas by the user's server.
+If the item is to be deleted, the receiving application SHOULD remove the item from the roster by sending a roster set to the user's server with the 'subscription' attribute set to a value of "remove" as described in &rfc3921;, since this results in generation of the appropriate &PRESENCE; stanzas by the user's server.
In order to programatically suggest that the receiving entity should modify one or more items from its roster, the sending entity MUST send a &MESSAGE; or &IQ; stanza containing an &X; element qualified by the 'http://jabber.org/protocol/rosterx' namespace; the &X; element in turn MUST contain one or more <item/> child elements, each of which MUST possess an 'action' attribute whose value is "modify", MUST possess a 'jid' attribute that specifies the JabberID of the item to be modified, MAY possess a 'name' attribute that specifies a natural-language name or nickname for the item, and MAY contain one or more <group/> elements specifying roster groups into which to place the item. If a &MESSAGE; stanza is sent, it MAY contain a &BODY; element but SHOULD NOT contain any other child elements. Here is an example:
@@ -188,7 +188,7 @@If a roster item addition, deletion, or modification stanza will result in editing of an existing item in the roster, the receiving application MUST (either with approval by a human user or automatically subject to configuration) send a roster set to the user's server with no changes to the 'subscription' attribute but rather with appropriate changes to the value of 'name' attribute or the <group/> child element or elements, as described in RFC 3921.
+If a roster item addition, deletion, or modification stanza will result in editing of an existing item in the roster, the receiving application MUST (either with approval by a human user or automatically subject to configuration) send a roster set to the user's server with no changes to the 'subscription' attribute but rather with appropriate changes to the value of 'name' attribute or the <group/> child element or elements, as described in &rfc3921;.
Note: All notes are stored as a "bundle" within the same <storage/> element.
-Retrieving notes uses the protocol described in XEP-0049.
+Retrieving notes uses the protocol described in &xep0049;.
For error conditions please refer to XEP-0049.
+For error conditions please refer to &xep0049;.
Security considerations related to private XML storage are described in XEP-0049.
+Security considerations related to private XML storage are described in &xep0049;.
&rfc5122; defines a Uniform Resource Identifier (URI) scheme for use in forming URIs and Internationalized Resource Identifiers (IRIs)
However, RFC 5122 intentionally leaves the potential values of the query component open-ended, does not provide a list of common "actions" for queries (e.g., send message or join chatroom), and does not specify recommended "key-value" pairs to be used in the context of such actions. Therefore, this document defines a registry of such actions and key-value pairs (to be maintained by the ®ISTRAR;) and specifies a set of initial values for that registry.
+&rfc5122; defines a Uniform Resource Identifier (URI) scheme for use in forming URIs and Internationalized Resource Identifiers (IRIs)
However, &rfc5122; intentionally leaves the potential values of the query component open-ended, does not provide a list of common "actions" for queries (e.g., send message or join chatroom), and does not specify recommended "key-value" pairs to be used in the context of such actions. Therefore, this document defines a registry of such actions and key-value pairs (to be maintained by the ®ISTRAR;) and specifies a set of initial values for that registry.
This document is organized as follows:
Note: The format of the XMPP URI scheme, including the format of the query component, is fully specified and formally defined in RFC 5122; this document does not modify the xmpp URI scheme in any way and assumes that the reader is familiar with all aspects of RFC 5122.
+Note: The format of the XMPP URI scheme, including the format of the query component, is fully specified and formally defined in &rfc5122;; this document does not modify the xmpp URI scheme in any way and assumes that the reader is familiar with all aspects of RFC 5122.
This document inherits terminology from &rfc3986;, &rfc3987;, and RFC 5122.
+This document inherits terminology from &rfc3986;, &rfc3987;, and &rfc5122;.
The range of actions that might be triggered by interaction with an XMPP entity by means of an XMPP IRI/URI is potentially as wide as the range of extensions to XMPP. This document does not seek to exhaustively define all such potential actions. However, the following actions might be of general interest:
@@ -114,8 +114,8 @@For each such action, the XMPP Registrar maintains a RECOMMENDED "querytype" (this can be thought of as an action name or "verb"; see RFC 5122 for syntax and semantics) as well as an OPTIONAL list of keys to be used in key-value pairs if appropriate.
-The querytypes and key-value pairs related to RFC 3920 and RFC 3921 are defined herein; the querytypes and key-value pairs related to protocols defined in the XMPP Standards Foundation's XEP series are defined in the relevant XMPP Extension Protocol specifications.
+For each such action, the XMPP Registrar maintains a RECOMMENDED "querytype" (this can be thought of as an action name or "verb"; see &rfc5122; for syntax and semantics) as well as an OPTIONAL list of keys to be used in key-value pairs if appropriate.
+The querytypes and key-value pairs related to &rfc3920; and RFC 3921 are defined herein; the querytypes and key-value pairs related to protocols defined in the XMPP Standards Foundation's XEP series are defined in the relevant XMPP Extension Protocol specifications.
It may desirable for an XMPP IRI/URI to trigger a specialized interface for sending an XMPP message stanza. The RECOMMENDED querytype for this action is "message". If no key-value pair is provided, interacting with an XMPP IRI/URI that contains a querytype of "message" SHOULD trigger an interface that enables the user to input the text of an XMPP message and other relevant parameters (e.g., a message subject or &xep0071; markup).
The 'jabber:iq:roster' namespace provides a mechanism for managing an XMPP roster (also called a "contact list"). This namespace is defined in RFC 3921. The following actions are defined.
+The 'jabber:iq:roster' namespace provides a mechanism for managing an XMPP roster (also called a "contact list"). This namespace is defined in &rfc3921;. The following actions are defined.
The registered querytype for adding items to the roster or editing items in the roster is "roster" (effectively there is no difference between adding and editing). An XMPP IRI/URI containing a "roster" querytype MAY also include at most one "name" key whose value maps to the 'name' attribute of the <item/> element within the 'jabber:iq:roster' namespace, and MAY contain one "group" key whose value maps to the character data of the <group/> child element of <item/>.
Closely coupled with roster management is presence subscription management. In XMPP, subscription management is handled via special values of the &PRESENCE; stanza, as described in RFC 3921. The following actions are defined
+Closely coupled with roster management is presence subscription management. In XMPP, subscription management is handled via special values of the &PRESENCE; stanza, as described in &rfc3921;. The following actions are defined
When an entity subscribes to another entity's presence by means of an XMPP IRI/URI, the invoked XMPP application SHOULD first send a roster add stanza as shown below (this is consistent with the recommendations in RFC 3921).
+When an entity subscribes to another entity's presence by means of an XMPP IRI/URI, the invoked XMPP application SHOULD first send a roster add stanza as shown below (this is consistent with the recommendations in &rfc3921;).
Internationalization considerations for XMPP IRIs/URIs are specified in RFC 5122; the reader is referred to that document for a complete discussion of the relevant issues.
+Internationalization considerations for XMPP IRIs/URIs are specified in &rfc5122;; the reader is referred to that document for a complete discussion of the relevant issues.
Localization of application-specific data presented to a human user (e.g., as encapsulated in key-value pairs) is the responsibility of the "using protocol".
Security considerations for XMPP IRIs/URIs are specified in RFC 5122.
+Security considerations for XMPP IRIs/URIs are specified in &rfc5122;.
Completion of some of the actions defined herein will cause changes to an entity's account, subscriptions to information, registration with services, communication with other entities, completion of ad-hoc commands, and the like. Naturally, such changes, information, services, and communications are potentially undesirable (e.g., joining a chatroom whose discussion topic is not of interest to, or even patently offensive to, the joining user). The invoked application SHOULD appropriately warn a human user regarding the potential consequences of the action about to be completed.
In order to specify the time period for a state, event, or activity, the generating entity SHOULD include both "Start" and "Stop" SHIM headers that specify the dateTimes at which the time period starts and stops. The following rules apply:
An XMPP extension for user activity is specified in XEP-0108. It may be desirable to include time period information when publishing one's activity.
+An XMPP extension for user activity is specified in &xep0108;. It may be desirable to include time period information when publishing one's activity.
An XMPP extension for user mood is specified in XEP-0107. It may be desirable to include time period information when publishing one's mood.
+An XMPP extension for user mood is specified in &xep0107;. It may be desirable to include time period information when publishing one's mood.
In HTTP, an "entity" is the information transferred as the payload of a request or response, and an "Entity Tag" is an opaque string that uniquely identifies that payload. For example, when an HTTP server sends an entity in an HTTP response, it can include an ETag header that identifies the payload as cacheable, and the client can cache that entity; in future requests, the client can include the same value in an If-None-Match header and the server will either return an HTTP 304 ("Not Modified") error if the entity has not changed or return the entity in the HTTP response if it has changed. (Note: For information about the semantics of Entity Tags, the ETag header, and the If-None-Match header, refer to Sections 3.11, 14.19, and 14.26 respectively of RFC 2616.)
-The basic concept behind XMPP Entity Tag use is semantically equivalent to the use in HTTP (although we use the term "data object" to refer to the payload); this is made possible by a straightforward application of SHIM headers as specified in XEP-0131. In the context of an IQ request-response interaction, the responding entity will include an ETag SHIM header in its IQ response (indicating that the data object can be cached), the requesting entity will include that identical value in an If-None-Match SHIM header when it queries the server for the same data object, and the responding entity will return either an IQ result with the changed data object or an IQ error indicating that the data object has not changed.
+In HTTP, an "entity" is the information transferred as the payload of a request or response, and an "Entity Tag" is an opaque string that uniquely identifies that payload. For example, when an HTTP server sends an entity in an HTTP response, it can include an ETag header that identifies the payload as cacheable, and the client can cache that entity; in future requests, the client can include the same value in an If-None-Match header and the server will either return an HTTP 304 ("Not Modified") error if the entity has not changed or return the entity in the HTTP response if it has changed. (Note: For information about the semantics of Entity Tags, the ETag header, and the If-None-Match header, refer to Sections 3.11, 14.19, and 14.26 respectively of &rfc2616;.)
+The basic concept behind XMPP Entity Tag use is semantically equivalent to the use in HTTP (although we use the term "data object" to refer to the payload); this is made possible by a straightforward application of SHIM headers as specified in &xep0131;. In the context of an IQ request-response interaction, the responding entity will include an ETag SHIM header in its IQ response (indicating that the data object can be cached), the requesting entity will include that identical value in an If-None-Match SHIM header when it queries the server for the same data object, and the responding entity will return either an IQ result with the changed data object or an IQ error indicating that the data object has not changed.
Here is an example of such a request-response flow (the example is that of roster retrieval):
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: In HTTP, an Entity Tag may be either "strong" or "weak" (see Section 13.3.3 of &rfc2616;); 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 &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.
+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 &rfc6121; 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:
XEP-0131 specifies how support for a particular SHIM header can be explicitly determined using &xep0030;. To review, the protocol flow between a client and a server is as follows:
+&xep0131; specifies how support for a particular SHIM header can be explicitly determined using &xep0030;. To review, the protocol flow between a client and a server is as follows:
To publish reachability addresses via the personal eventing protocol (XEP-0163), the entity publishes data to the "urn:xmpp:reach:0" node.
+To publish reachability addresses via the personal eventing protocol (&xep0163;), the entity publishes data to the "urn:xmpp:reach:0" node.
When the recipient's client receives the hash of the avatar image, it SHOULD check the hash to determine if it already has a cached copy of that avatar image. If not, it retrieves the sender's full vCard in accordance with the protocol flow described in XEP-0054 (note that this request is sent to the user's bare JID, not full JID):
+When the recipient's client receives the hash of the avatar image, it SHOULD check the hash to determine if it already has a cached copy of that avatar image. If not, it retrieves the sender's full vCard in accordance with the protocol flow described in &xep0054; (note that this request is sent to the user's bare JID, not full JID):
It is widely acknowledged within the Jabber/XMPP community that the &xep0054; specification (XEP-0054) has outlived its usefulness. There are several reasons for this conclusion:
+It is widely acknowledged within the Jabber/XMPP community that the &xep0054; specification (&xep0054;) has outlived its usefulness. There are several reasons for this conclusion:
Pubsub (publish-and-subscribe) semantics.
-A more complex model is for an entity to publish its profile data to a publish-subscribe node or nodes and allow other entities to subscribe to that node or nodes, thus receiving notifications whenever the profiled entity updates its data. This model is more appropriate for entities that modify their profile data on a regular basis or when other entities wish to be informed when the profile data changes. Because this model will most likely be used most often by IM users and other intermittently-connected network endpoints, we use the simplified subset of the XMPP publish-subscribe extension defined in XEP-0163 to implement this model.
+A more complex model is for an entity to publish its profile data to a publish-subscribe node or nodes and allow other entities to subscribe to that node or nodes, thus receiving notifications whenever the profiled entity updates its data. This model is more appropriate for entities that modify their profile data on a regular basis or when other entities wish to be informed when the profile data changes. Because this model will most likely be used most often by IM users and other intermittently-connected network endpoints, we use the simplified subset of the XMPP publish-subscribe extension defined in &xep0163; to implement this model.
Therefore, this proposal specifies that profile data shall be represented in data forms scoped by a FORM_TYPE of 'urn:xmpp:tmp:profile' &NSNOTE;, in accordance with the field standardization methods defined in XEP-0068. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the ®ISTRAR; (although they may or may not be defined in a XMPP Extension Protocol specification). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of XEP-0068.
Therefore, this proposal specifies that profile data shall be represented in data forms scoped by a FORM_TYPE of 'urn:xmpp:tmp:profile' &NSNOTE;, in accordance with the field standardization methods defined in &xep0068;. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the ®ISTRAR; (although they may or may not be defined in a XMPP Extension Protocol specification). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of XEP-0068.
The following is a simple and incomplete example of profile data represented via the Data Forms protocol, containing two registered data fields and one unregistered field:
By specifying that all fields are scoped by a FORM_TYPE of 'urn:xmpp:tmp:profile', this proposal does not mean to imply that all profile data will or should be gathered in one data form. In reality, most such data will probably be gathered at the time of registration either at a website or via a "wizard" interface that breaks the process into smaller bundles (such as "Basic Personal Data", "Physical Location", "Internet Addresses", "Hobbies and Interests", and "Favorite Things"). The use of one FORM_TYPE is simply meant to scope the data fields so that each field is unique within the context of profile data. Any form that uses these fields along with a FORM_TYPE of 'urn:xmpp:tmp:profile' is of the "profile type" (i.e., is a specific instance of that type), which does not limit the number of forms that can be of that type.
-However, scoping all data fields with a single FORM_TYPE implies it is necessary to define separate data fields for similar kinds of information. For example, the vCard specification (RFC 2426) defines "types" for certains kinds of data, such as email addresses, telephone numbers, and physical addresses, making it possible to specify that a telephone number corresponds to a fax machine or mobile phone or that a physical address corresponds to one's home or work location. In the Data Forms representation, any desired piece of information (e.g., work phone) must be represented with a separate data field.
+However, scoping all data fields with a single FORM_TYPE implies it is necessary to define separate data fields for similar kinds of information. For example, the vCard specification (&rfc2426;) defines "types" for certains kinds of data, such as email addresses, telephone numbers, and physical addresses, making it possible to specify that a telephone number corresponds to a fax machine or mobile phone or that a physical address corresponds to one's home or work location. In the Data Forms representation, any desired piece of information (e.g., work phone) must be represented with a separate data field.
In order to address most (if not all) of the pieces of information described in existing profile specifications, this document defines a great number of data fields. Even so, the data fields specified herein are not exhaustive, and it is expected that additional fields will be registered in the future through the mechanisms specified in the XMPP Registrar Considerations section of this document.
Otherwise it MUST return an error. If the server does not support the profile data functionality, the error MUST be &unavailable;.
In order to update selected fields in a public profile, an entity simply publishes the modified fields (not the entire profile) to a pubsub node of "urn:xmpp:tmp:profile" at its server using the PEP subset of the publish-subscribe extension, as specified in XEP-0163.
+In order to update selected fields in a public profile, an entity simply publishes the modified fields (not the entire profile) to a pubsub node of "urn:xmpp:tmp:profile" at its server using the PEP subset of the publish-subscribe extension, as specified in &xep0163;.
In order to receive updated fields for a contact's profile, an entity shall encapsulate a feature of "urn:xmpp:tmp:profile+notify" in its &xep0115; data. If the contact's server supports the personal eventing profile of XMPP Publish-Subscribe as described in XEP-0163, the entity will receive notifications whenever the contact sends updated profile fields to the profile node:
+In order to receive updated fields for a contact's profile, an entity shall encapsulate a feature of "urn:xmpp:tmp:profile+notify" in its &xep0115; data. If the contact's server supports the personal eventing profile of XMPP Publish-Subscribe as described in &xep0163;, the entity will receive notifications whenever the contact sends updated profile fields to the profile node:
Everyone knows at least one language well (e.g., they are able to speak or write the language with a fair degree of fluency). Determination of whether someone knows a language "well" or "fluently" is left to the user.
-The value of this field MUST be an abbreviation for a language as specified in RFC 4646.
+The value of this field MUST be an abbreviation for a language as specified in &rfc4646;.
The Data Forms field that represents a language known well is "languages_well".
This field maps to:
This proposal defines best practices for such a negotiation, re-using the protocol defined in &xep0020;.
@@ -669,7 +669,7 @@ PENDING o---------------+If a party receives an XMPP presence stanza of type "unavailable" from the full JID &LOCALFULL; of the other party (i.e., the resource with which it has had an active session) during a session, the receiving party SHOULD assume that the other client will still be able to continue the session (perhaps it simply became "invisible", or it is persisting the state of the negotiated session until it reconnects and receives "offline" messages).
-However, the receiving party MAY assume that the other client will not be able to continue the session.
However, the receiving party MAY assume that the other client will not be able to continue the session.
When mapping instant messaging flows to SIP, implementations SHOULD adhere to &rfc7572;.
@@ -684,7 +684,7 @@ PENDING o---------------+If a contact does not share its presence information with a user through a presence subscription (see RFC 3921) or if it blocks outbound presence notifications to the user (see &xep0016;), then it will effectively expose its presence if it accepts the user's stanza session negotiation request or returns an error to the user. Therefore, due care must be exercised in determining whether to accept the request or return an error. The contact's client SHOULD NOT automatically (i.e. without first asking the contact) either accept the user's request or return an error to the user unless the user is subscribed to the contact's presence and the contact is not blocking outbound presence notifications to the user. Note: There should be no need for the contact's client to consult the contact's block list (see &xep0191;), since if the user is on the block list then the contact would not receive the request from the user in the first place.
+If a contact does not share its presence information with a user through a presence subscription (see &rfc3921;) or if it blocks outbound presence notifications to the user (see &xep0016;), then it will effectively expose its presence if it accepts the user's stanza session negotiation request or returns an error to the user. Therefore, due care must be exercised in determining whether to accept the request or return an error. The contact's client SHOULD NOT automatically (i.e. without first asking the contact) either accept the user's request or return an error to the user unless the user is subscribed to the contact's presence and the contact is not blocking outbound presence notifications to the user. Note: There should be no need for the contact's client to consult the contact's block list (see &xep0191;), since if the user is on the block list then the contact would not receive the request from the user in the first place.
If a client is configured to show a request <form/> to a human user instead of responding automatically, it SHOULD replace the content of the <title/> element and of all label attributes of the known and registered <field/> and <option/> elements with its own localised versions before showing the form to the user -- even if the form already appears to be in the correct language.
diff --git a/xep-0156.xml b/xep-0156.xml index 7c533fc8c..d887c5e14 100644 --- a/xep-0156.xml +++ b/xep-0156.xml @@ -181,14 +181,14 @@The following examples show two host-meta link records: the first indicates support for the XMPP Over BOSH connection method defined in XEP-0124 and XEP-0206 and the second indicates support for the XMPP Over WebSocket connection method defined in &rfc7395;.
+The following examples show two host-meta link records: the first indicates support for the XMPP Over BOSH connection method defined in &xep0124; and XEP-0206 and the second indicates support for the XMPP Over WebSocket connection method defined in &rfc7395;.
&rfc2142; specifies conventional electronic mailbox names for common services, roles, and functions related to SMTP, NNTP, and HTTP (such as security@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.
+Consistent with &rfc2142;, a domain that offers a Jabber/XMPP service SHOULD provide an Internet mailbox of "XMPP" for inquiries related to that service.
The administrators of an XMPP service may desire to advertise contact information related to that service.
Values of 'status-addresses' form field MUST be valid URIs, i.e. comply with the
'xs:anyURI' datatype of &w3xmlschema2;. Values of the 'abuse-addresses',
@@ -184,7 +184,7 @@
The ®ISTRAR; includes the following information in its registries. &xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and XEP-0128 describes how to use field standardization in the context of service discovery. This section registers fields for server information scoped by the "http://jabber.org/network/serverinfo" FORM_TYPE. &xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and &xep0128; describes how to use field standardization in the context of service discovery. This section registers fields for server information scoped by the "http://jabber.org/network/serverinfo" FORM_TYPE. This section shows how challenges SHOULD be combined with the existing In-Band Registration protocol according to the rules defined in the Extensibility section of XEP-0077. Note: The <challenge/> wrapper element is not included, because XEP-0077 specifies that data forms shall be contained as the direct children of the &QUERY; element. This section shows how challenges SHOULD be combined with the existing In-Band Registration protocol according to the rules defined in the Extensibility section of &xep0077;. Note: The <challenge/> wrapper element is not included, because &xep0077; specifies that data forms shall be contained as the direct children of the &QUERY; element. A service that hosts multi-user chat rooms in accordance with XEP-0045 MAY challenge unknown entities that seek to join such rooms or that send messages in such rooms. A service that hosts multi-user chat rooms in accordance with &xep0045; MAY challenge unknown entities that seek to join such rooms or that send messages in such rooms. It is RECOMMENDED that entities employ other techniques to combat abusive stanzas in addition to those described in this document (e.g., see XEP-0161 and &xep0205;). It is RECOMMENDED that entities employ other techniques to combat abusive stanzas in addition to those described in this document (e.g., see &xep0161; and &xep0205;). It is expected that this protocol will be an important and successful tool for discouraging abusive traffic. However, much of its success is dependent on the quality of the CAPTCHAs and other puzzles employed by a particular implementation. The administrator of an application that functions as a challenger SHOULD discontinue the use of CAPTCHA forms under the following circumstances: The use of CAPTCHAs is not a panacea, and should be combined with other anti-abuse mechanisms, such as those described in XEP-0161 and XEP-0205. For example, the task of finding solutions to CAPTCHAs and other computational puzzles is becoming easier for computer programs, and in any case can be farmed out to third parties. Therefore challengers should limit the number of triggering stanzas (e.g., registration attempts, subscription requests, or chatroom joins) allowed per JabberID or IP address during any given time period, and may simply refuse repeated stanzas by terminating an XML stream with a &policy; stream error or returning a ¬acceptable; stanza error as appropriate. In addition, a challenger should feel free to deploy additional anti-abuse mechanisms as needed. The use of CAPTCHAs is not a panacea, and should be combined with other anti-abuse mechanisms, such as those described in &xep0161; and XEP-0205. For example, the task of finding solutions to CAPTCHAs and other computational puzzles is becoming easier for computer programs, and in any case can be farmed out to third parties. Therefore challengers should limit the number of triggering stanzas (e.g., registration attempts, subscription requests, or chatroom joins) allowed per JabberID or IP address during any given time period, and may simply refuse repeated stanzas by terminating an XML stream with a &policy; stream error or returning a ¬acceptable; stanza error as appropriate. In addition, a challenger should feel free to deploy additional anti-abuse mechanisms as needed.
@@ -703,7 +703,7 @@
The stanza blocking protocol defined in XEP-0016 enables a client to control explicitly which senders its server must block stanzas from. Such explicit blocking is suitable for privacy control, but not for filtering spim.
-This document contradicts an assumption expressed in the standard blocking protocol in order to extend client control to spim blocking. More specifically, it simply defines a spim recognition privacy-list fall-through action that is different from the 'allow' default assumed in XEP-0016.
The stanza blocking protocol defined in &xep0016; enables a client to control explicitly which senders its server must block stanzas from. Such explicit blocking is suitable for privacy control, but not for filtering spim.
+This document contradicts an assumption expressed in the standard blocking protocol in order to extend client control to spim blocking. More specifically, it simply defines a spim recognition privacy-list fall-through action that is different from the 'allow' default assumed in &xep0016;.
The various spim recognition procedures that may be employed by the server are beyond the scope of this document. No single measure can differentiate all spim perfectly. It is RECOMMENDED that servers implement a combination of complementary spim recognition techniques (and other anti-spim techniques
This section specifies server functionality not defined in XEP-0016. This document will not reach Draft status until Server-Based Privacy Rules has been modified to permit this functionality.
+This section specifies server functionality not defined in &xep0016;. This document will not reach Draft status until Server-Based Privacy Rules has been modified to permit this functionality.
A server that supports this protocol MAY maintain a separate
Note: When it blocks a stanza, the server MUST NOT add the 'from' attribute of the stanza to the correspondents list.
@@ -143,7 +143,7 @@This informative section requires no client or server functionality beyond that defined in XEP-0016.
+This informative section requires no client or server functionality beyond that defined in &xep0016;.
The client SHOULD use the 'subscription' type to exclude all JIDs on the user's roster from spim blocking (see the items with order 20, 30 and 40 in the example below).
@@ -194,12 +194,12 @@If stanzas from a spim robot running on a zombie domain somehow manage to get past the server's spim recognition then the client MAY use the 'jid' type to block one or all JIDs from the domain. (XEP-0016 already enables this functionality.)
+If stanzas from a spim robot running on a zombie domain somehow manage to get past the server's spim recognition then the client MAY use the 'jid' type to block one or all JIDs from the domain. (&xep0016; already enables this functionality.)
&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".
+&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 &rfc6121;). 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:
Message stanzas SHOULD be handled by a server as follows (based on the values of the 'type' attribute specified in RFC 6121):
+Message stanzas SHOULD be handled by a server as follows (based on the values of the 'type' attribute specified in &rfc6121;):
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).
A message stored offline may not be readable by the recipient if the message was encrypted using a session-based encryption method such as &xep0116; or if the key used in object encryption is revoked after the message was sent but before it is read.
In certain countries, offline storage of message stanzas may introduce legal requirements or privacy vulnerabilities that do not apply to messages that are delivered immediately and never stored on an intermediate server.
-See XEP-0203 for security considerations regarding the inclusion and processing of delayed delivery notations.
+See &xep0203; for security considerations regarding the inclusion and processing of delayed delivery notations.
This document requires no interaction with &IANA;.
diff --git a/xep-0163.xml b/xep-0163.xml index a4afddf4b..b722ee1f3 100644 --- a/xep-0163.xml +++ b/xep-0163.xml @@ -164,7 +164,7 @@Personal eventing provides a way for a Jabber/XMPP user to send updates or "events" to other users, who are typically contacts in the user's roster. An event can be anything that a user wants to make known to other people, such as those described in &xep0080;, &xep0107;, &xep0108;, and &xep0118;. While the XMPP &xep0060; extension ("pubsub") can be used to broadcast such events associated, the full pubsub protocol is often thought of as complicated and therefore has not been widely implemented.
Note: Any use cases not described herein are described in XEP-0060. Also, this document does not show error flows related to the generic publish-subscribe use cases referenced herein, since they are exhaustively defined in XEP-0060. The reader is referred to XEP-0060 for all relevant protocol details related to the XMPP publish-subscribe extension. This document merely defines a "subset" or "profile" of XMPP publish-subscribe.
+Note: Any use cases not described herein are described in &xep0060;. Also, this document does not show error flows related to the generic publish-subscribe use cases referenced herein, since they are exhaustively defined in XEP-0060. The reader is referred to XEP-0060 for all relevant protocol details related to the XMPP publish-subscribe extension. This document merely defines a "subset" or "profile" of XMPP publish-subscribe.
This section provides a friendly introduction to personal eventing via pubsub (PEP).
@@ -292,7 +292,7 @@ ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/> ]]> -Your server knows to send tune information to Romeo because when the server unpacks the value of the 'ver' attribute ("054H4A7280JuT6+IroVYxgCAjZo=") in accordance with XEP-0115, it discovers that Romeo's client advertises a service discovery feature of "http://jabber.org/protocol/tune+notify", where the "+notify" suffix indicates interest in receiving notifications of the node whose NodeID precedes the suffix (see XEP-0060 § 9.2). The server can verify this support if needed by sending a service discovery request to Romeo's full JID, where the response would be as follows:
+Your server knows to send tune information to Romeo because when the server unpacks the value of the 'ver' attribute ("054H4A7280JuT6+IroVYxgCAjZo=") in accordance with &xep0115;, it discovers that Romeo's client advertises a service discovery feature of "http://jabber.org/protocol/tune+notify", where the "+notify" suffix indicates interest in receiving notifications of the node whose NodeID precedes the suffix (see XEP-0060 § 9.2). The server can verify this support if needed by sending a service discovery request to Romeo's full JID, where the response would be as follows:
These uses of presence simplify the task of developing compliant clients (cf. &xep0134;).
@@ -351,7 +351,7 @@An account owner publishes an item to a node by following the protocol specified in XEP-0060:
+An account owner publishes an item to a node by following the protocol specified in &xep0060;:
If the node does not already exist, the PEP service MUST create the node. This "auto-create" feature (defined in XEP-0060) MUST be supported by a PEP service. (Naturally, the account owner's client MAY follow the node creation use case specified in XEP-0060 before attempting to publish an item.)
-A PEP service SHOULD also support the "publish-options" feature defined in XEP-0060.
+If the node does not already exist, the PEP service MUST create the node. This "auto-create" feature (defined in &xep0060;) MUST be supported by a PEP service. (Naturally, the account owner's client MAY follow the node creation use case specified in XEP-0060 before attempting to publish an item.)
+A PEP service SHOULD also support the "publish-options" feature defined in &xep0060;.
If the publication logic dictates that event notifications shall be sent, the account owner's server generates notifications and sends them to all appropriate entities as described in the Receiving Event Notifications section of this document, as well as to any of the account owner's available resources.
Note: PEP ties the receipt of PEP notifications to the subscriber's presence, but does not tie the generation of PEP notifications to the publisher's presence. If the publisher wishes to stop generating PEP events (or to generate an "empty" event as can be done for some PEP payloads) before ending its presence session, the publisher MUST direct its client to do so and MUST NOT depend on the PEP service to automatically "zero out" its PEP information when the PEP service receives unavailable presence from the publisher.
An entity shall receive event notifications if:
A PEP service MUST support the "auto-subscribe" feature defined in Section 9.1 of XEP-0060. This implies that when a user has an XMPP presence subscription to the account owner's presence, the user automatically also has the right to subscribe to any of the account owner's PEP nodes (if the access model is the default of "presence") and to retrieve items from such PEP nodes.
+A PEP service MUST support the "auto-subscribe" feature defined in Section 9.1 of &xep0060;. This implies that when a user has an XMPP presence subscription to the account owner's presence, the user automatically also has the right to subscribe to any of the account owner's PEP nodes (if the access model is the default of "presence") and to retrieve items from such PEP nodes.
A PEP service MUST support the "filtered-notifications" feature defined in Section 9.2 of XEP-0060. This implies that when an automatic subscriber can specify which event payloads it wants to receive by including appropriate feature bundles in the XEP-0115 information it broadcasts.
+A PEP service MUST support the "filtered-notifications" feature defined in Section 9.2 of &xep0060;. This implies that when an automatic subscriber can specify which event payloads it wants to receive by including appropriate feature bundles in the XEP-0115 information it broadcasts.
If an entity subscribed using a full JID &FULLJID; or a bare domain identifier &DOMAINBARE;, a PEP service MUST send one notification only, addressed to the subscribed JID.
If a subscriber subscribed using a bare JID &LOCALBARE; and a PEP service does not have appropriate presence information about the subscriber, a PEP service MUST send at most one notification, addressed to the bare JID &LOCALBARE; of the subscriber, and MAY choose not to send any notification. (By "appropriate presence information" is meant an available presence stanza with XEP-0115 data that indicates interest in the relevant data format.)
If a subscriber subscribed using a bare JID &LOCALBARE; and a PEP service has appropriate presence information about the subscriber, the PEP service MUST send one notification to the full JID &FULLJID; of each of the subscriber's available resources that have included XEP-0115 information indicating an interest in the data format.
If a subscriber subscribed using a bare JID &LOCALBARE; and a PEP service does not have appropriate presence information about the subscriber, a PEP service MUST send at most one notification, addressed to the bare JID &LOCALBARE; of the subscriber, and MAY choose not to send any notification. (By "appropriate presence information" is meant an available presence stanza with &xep0115; data that indicates interest in the relevant data format.)
If a subscriber subscribed using a bare JID &LOCALBARE; and a PEP service has appropriate presence information about the subscriber, the PEP service MUST send one notification to the full JID &FULLJID; of each of the subscriber's available resources that have included &xep0115; information indicating an interest in the data format.
When an account owner publishes an item to a node, a PEP service MUST generate a notification and send it to all appropriate subscribers (where the number of notifications is determined by the foregoing rules).
When a PEP service receives initial presence
When a PEP service receives initial presence
As an exception to the foregoing MUST rules, a PEP service MUST NOT send notifications to a subscriber if the user has blocked the subscriber from receiving the kind of stanza used for notifications (typically message stanzas) by means of communications blocking as specified in &xep0016; or &xep0191;.
As mentioned, a PEP service MUST send the last published item to all new subscribers and to all newly-available resources for each subscriber, including the account owner itself. (That is, the default value of the "pubsub#send_last_published_item" node configuration field must be "on_sub_and_presence"; this behavior essentially mimics the functionality of presence as defined in XMPP IM.) When processing a new subscription, the service MAY send not only the last published item but instead all items that are currently associated with the node (i.e., up to the maximum number of items at the node, which might be one if the node is a "singleton node" as described in XEP-0060). If the service has knowledge about the datetime that a subscriber's newly-available resource last received updated information from the node (e.g., as described in &xep0256;), then it MAY also send more items than only the last published item to the newly-available resource.
+As mentioned, a PEP service MUST send the last published item to all new subscribers and to all newly-available resources for each subscriber, including the account owner itself. (That is, the default value of the "pubsub#send_last_published_item" node configuration field must be "on_sub_and_presence"; this behavior essentially mimics the functionality of presence as defined in XMPP IM.) When processing a new subscription, the service MAY send not only the last published item but instead all items that are currently associated with the node (i.e., up to the maximum number of items at the node, which might be one if the node is a "singleton node" as described in &xep0060;). If the service has knowledge about the datetime that a subscriber's newly-available resource last received updated information from the node (e.g., as described in &xep0256;), then it MAY also send more items than only the last published item to the newly-available resource.
Note: The "on_sub_and_presence" setting relates to the subscriber's presence, not the publisher's presence.
A PEP service MUST:
If the account owner's server supports PEP and the account is provisioned for PEP, the server MUST return an identity of "pubsub/pep" on behalf of the account (as well as a list of the namespaces and other features it supports, including all supported XEP-0060 features):
+If the account owner's server supports PEP and the account is provisioned for PEP, the server MUST return an identity of "pubsub/pep" on behalf of the account (as well as a list of the namespaces and other features it supports, including all supported &xep0060; features):
A contact MAY send service discovery requests to the account owner's bare JID &BAREJID;. If the contact already has a subscription to the account owner's presence, this is not necessary in order to receive notifications from the account owner via personal eventing. However, a user without a presence subscription needs to do so in order to discover if the account owner is a virtual pubsub service and to discover the account owner's eventing nodes. The relevant protocol flows are demonstrated in XEP-0060.
+A contact MAY send service discovery requests to the account owner's bare JID &BAREJID;. If the contact already has a subscription to the account owner's presence, this is not necessary in order to receive notifications from the account owner via personal eventing. However, a user without a presence subscription needs to do so in order to discover if the account owner is a virtual pubsub service and to discover the account owner's eventing nodes. The relevant protocol flows are demonstrated in &xep0060;.
Note: When returning disco#items results, the account owner's server MUST check the access model for each of the account owner's PEP nodes and MUST return as service discovery items only those nodes to which the contact is allowed to subscribe or from which the contact is allowed to retrieve items without first subscribing.
If the modification results in a loss of access, the service MUST cancel the entity's subscription. In addition, the service MAY send a message to the (former) subscriber informing it of the cancellation (for information about the format of messages sent to notify subscribers of subscription cancellation, see the "Notification of Subscription Denial or Cancellation" section of XEP-0060).
+If the modification results in a loss of access, the service MUST cancel the entity's subscription. In addition, the service MAY send a message to the (former) subscriber informing it of the cancellation (for information about the format of messages sent to notify subscribers of subscription cancellation, see the "Notification of Subscription Denial or Cancellation" section of &xep0060;).
An earlier version of this document specified that there could be only one publish-subscribe node associated with any given payload type (XML namespace) for the account owner (e.g., there could be only one pubsub node for geolocation events, one node for tune events, and one node for mood events, etc.). However, this rule is now considered overly restrictive because some data formats can be used to encapsulate many different kinds of information; the usual example is Atom as defined in &rfc4287;, for which many extensions exist. Therefore, this document now does not specify that there is a one-to-one relationship between NodeIDs and payload namespaces.
@@ -556,7 +556,7 @@Because PEP simply reuses the protocol specified in XEP-0060, a separate schema is not needed.
+Because PEP simply reuses the protocol specified in &xep0060;, a separate schema is not needed.
To illustrate the functionality of this protocol, we will first request a standard vCard. As shown in XEP-0054, a user may view another user's vCard by sending an IQ of type "get" to the other user's bare JID. A compliant server MUST return the vCard to the requestor and not forward the IQ to the requestee's connected resource.
+To illustrate the functionality of this protocol, we will first request a standard vCard. As shown in &xep0054;, a user may view another user's vCard by sending an IQ of type "get" to the other user's bare JID. A compliant server MUST return the vCard to the requestor and not forward the IQ to the requestee's connected resource.
The schema for the 'vcard-temp-filter' namespace re-uses the element names from the DTD described in XEP-0054.
+The schema for the 'vcard-temp-filter' namespace re-uses the element names from the DTD described in &xep0054;.
diff --git a/xep-0165.xml b/xep-0165.xml
index d8c229fc2..040bd59f7 100644
--- a/xep-0165.xml
+++ b/xep-0165.xml
@@ -96,7 +96,7 @@
The JID "stpeter@jabber.org" is globally unique on the Jabber/XMPP network, but it is not necessarily memorable.
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.
- 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".
+ 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 &xep0172; and &xmppim; we refer to this as a "handle". In &rfc6121; 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.
Naturally, based on the JID, it is possible to pull information about the sender from a persistent data store such as an LDAP database, &xep0054; node, or future profile system (see &xep0154;). However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender (encapsulated via the format specified in XEP-0172) and the sender's key or keys.
+Naturally, based on the JID, it is possible to pull information about the sender from a persistent data store such as an LDAP database, &xep0054; node, or future profile system (see &xep0154;). However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender (encapsulated via the format specified in &xep0172;) and the sender's key or keys.
Implementation experience indicates that a dual-stack approach might not be feasible on all the computing platforms for which Jabber clients have been written, or even desirable on platforms where it is feasible.
As a result of feedback received on XEP-0111, the original authors of this document (Joe Hildebrand and Peter Saint-Andre) began to define such a signalling protocol, code-named Jingle. Upon communication with members of the Google Talk team,
As a result of feedback received on &xep0111;, the original authors of this document (Joe Hildebrand and Peter Saint-Andre) began to define such a signalling protocol, code-named Jingle. Upon communication with members of the Google Talk team,
The authors would like to thank Rohan Mahy for his valuable input on early versions of the Jingle specifications. Thiago Camargo, Diana Cionoiu, Olivier Crête, Dafydd Harries, Antti Ijäs, Tim Julien, Lauri Kaila, Justin Karneges, Jussi Laako, Steffen Larsen, Marcus Lundblad, Dirk Meyer, Anthony Minessale, Akito Nozaki, Matt O'Gorman, Mike Ruprecht, Rob Taylor, Will Thompson, Matt Tucker, Justin Uberti, Saku Vainio, Unnikrishnan Vikrama Panicker, Brian West, Jeff Williams, and others have also provided helpful input. Thanks also to those who have commented on the &SSIG; and Jingle
In accordance with Section 10 of XEP-0166, this document specifies the following information related to the Jingle RTP application type:
+In accordance with Section 10 of &xep0166;, this document specifies the following information related to the Jingle RTP application type:
The application format negotiation process is defined in the Negotiating a Jingle RTP Session section of this document.
The semantics of the &DESCRIPTION; element are defined in the Application Format section of this document.
A Jingle RTP session is described by a content type that contains one application format and one transport method. Each <content/> element defines a single RTP session. A Jingle negotiation MAY result in the establishment of multiple RTP sessions (e.g., one for audio and one for video). An application SHOULD consider all of the RTP sessions that are established via the same Jingle negotiation to be synchronized for purposes of streaming, playback, recording, etc.
-RTP as defined in RFC 3550 is used in the context of various "profiles" that are defined by other specifications. Jingle RTP treats RTP profiles as follows:
+RTP as defined in &rfc3550; is used in the context of various "profiles" that are defined by other specifications. Jingle RTP treats RTP profiles as follows:
The application format consists of one or more encodings contained within a wrapper <description/> element qualified by the 'urn:xmpp:jingle:apps:rtp:1' namespace &VNOTE;. In the language of RFC 4566 each encoding is a payload-type; therefore, each <payload-type/> element specifies an encoding that can be used for the RTP stream, as illustrated in the following example.
+The application format consists of one or more encodings contained within a wrapper <description/> element qualified by the 'urn:xmpp:jingle:apps:rtp:1' namespace &VNOTE;. In the language of &rfc4566; each encoding is a payload-type; therefore, each <payload-type/> element specifies an encoding that can be used for the RTP stream, as illustrated in the following example.
@@ -362,10 +362,10 @@
]]>
- The &DESCRIPTION; element is intended to be a child of a Jingle &CONTENT; element as specified in XEP-0166.
+The &DESCRIPTION; element is intended to be a child of a Jingle &CONTENT; element as specified in &xep0166;.
The &DESCRIPTION; element MUST possess a 'media' attribute that specifies the media type, such as "audio" or "video", where the media type SHOULD be as registered at &ianamedia;.
-The &DESCRIPTION; element MAY possess a 'ssrc' attribute that specifies the 32-bit synchronization source for this media stream, as defined in RFC 3550.
-After inclusion of one or more &PAYLOADTYPE; child elements, the &DESCRIPTION; element MAY also contain a <bandwidth/> element that specifies the allowable or preferred bandwidth for use by this application type. The 'type' attribute of the <bandwidth/> element SHOULD be a value for the SDP "bwtype" parameter as listed in the &ianasdp;. For RTP sessions, often the <bandwidth/> element will specify the "session bandwidth" as described in Section 6.2 of RFC 3550, measured in kilobits per second as described in Section 5.2 of RFC 4566.
+The &DESCRIPTION; element MAY possess a 'ssrc' attribute that specifies the 32-bit synchronization source for this media stream, as defined in &rfc3550;.
+After inclusion of one or more &PAYLOADTYPE; child elements, the &DESCRIPTION; element MAY also contain a <bandwidth/> element that specifies the allowable or preferred bandwidth for use by this application type. The 'type' attribute of the <bandwidth/> element SHOULD be a value for the SDP "bwtype" parameter as listed in the &ianasdp;. For RTP sessions, often the <bandwidth/> element will specify the "session bandwidth" as described in Section 6.2 of &rfc3550;, measured in kilobits per second as described in Section 5.2 of RFC 4566.
Also, the &DESCRIPTION; element MAY contain a <rtcp-mux/> element that specifies the ability to multiplex RTP Data and Control Packets on a single port as described in &rfc5761;.
The encodings SHOULD be provided in order of preference by placing the most-preferred payload type as the first &PAYLOADTYPE; child of the &DESCRIPTION; element and the least-preferred payload type as the last child.
The attributes of the &PAYLOADTYPE; element are as follows:
@@ -413,7 +413,7 @@In Jingle RTP, the encodings are used in the context of RTP. The most common encodings for the Audio/Video Profile (AVP) of RTP are listed in RFC 3551 (these "static" types are reserved from payload ID 0 through payload ID 95), although other encodings are allowed (these "dynamic" types use payload IDs 96 to 127) in accordance with the dynamic assignment rules described in Section 3 of RFC 3551. The payload IDs are represented in the 'id' attribute.
+In Jingle RTP, the encodings are used in the context of RTP. The most common encodings for the Audio/Video Profile (AVP) of RTP are listed in &rfc3551; (these "static" types are reserved from payload ID 0 through payload ID 95), although other encodings are allowed (these "dynamic" types use payload IDs 96 to 127) in accordance with the dynamic assignment rules described in Section 3 of RFC 3551. The payload IDs are represented in the 'id' attribute.
Each <payload-type/> element MAY contain one or more child elements that specify particular parameters related to the payload. For example, as described in &rfc5574;, the "cng", "mode", and "vbr" parameters can be specified in relation to usage of the Speex
@@ -492,7 +492,7 @@ Initiator Responder
]]>
Upon receiving the session-initiate stanza, the responder determines whether it can proceed with the negotiation. The general Jingle error cases are specified in XEP-0166 and illustrated in the Scenarios section of this document.
+Upon receiving the session-initiate stanza, the responder determines whether it can proceed with the negotiation. The general Jingle error cases are specified in &xep0166; and illustrated in the Scenarios section of this document.
If there is no immediate error, the responder acknowledges the session initiation request.
The SDP media type for Jingle RTP is "audio" (see Section 8.2.1 of RFC 4566) for audio media, "video" (see Section 8.2.1 of RFC 4566) for video media, etc. The media type is reflected in the Jingle 'media' attribute.
+The SDP media type for Jingle RTP is "audio" (see Section 8.2.1 of &rfc4566;) for audio media, "video" (see Section 8.2.1 of RFC 4566) for video media, etc. The media type is reflected in the Jingle 'media' attribute.
The Jingle <bandwidth/> element SHALL be mapped to an SDP b= line; in particular, the value of the 'type' attribute SHALL be mapped to the SDP <bwtype> parameter and the XML character data of the Jingle <bandwidth/> element SHALL be mapped to the SDP <bandwidth> parameter.
-If the payload type is static (payload-type IDs 0 through 95 inclusive), it MUST be mapped to an m= line as defined in RFC 4566. The generic format for this line is as follows:
+If the payload type is static (payload-type IDs 0 through 95 inclusive), it MUST be mapped to an m= line as defined in &rfc4566;. The generic format for this line is as follows:
]]>
diff --git a/xep-0169.xml b/xep-0169.xml
index 5d4683b10..65fe54a10 100644
--- a/xep-0169.xml
+++ b/xep-0169.xml
@@ -569,7 +569,7 @@
| |-- blitzen
|-- santa et al.
]]>
- In addition, we assume that the twas-the-night.lit server is running a virtual pubsub service for each account it hosts (in accordance with XEP-0163) and that the users "narrator", "mama", and "child" publish information to personal pubsub nodes related to mood (XEP-0107), activity (XEP-0108), and physical location (XEP-0112).
+In addition, we assume that the twas-the-night.lit server is running a virtual pubsub service for each account it hosts (in accordance with &xep0163;) and that the users "narrator", "mama", and "child" publish information to personal pubsub nodes related to mood (XEP-0107), activity (XEP-0108), and physical location (XEP-0112).
* Because millions of people track the movements and activities of Santa, northpole.lit runs a highly scalable, standalone pubsub service instead of PEP at Santa's bare JID.
** The U.S. Military divides its operations geographically among NORTHCOM, SOUTHCOM, EUCOM, and PACOM. Given the scale of operations implemented by Santa's workshop, it comes as no surprise that the command center at the North Pole is known as POLECOM. Naturally POLECOM subscribes to the pubsub feeds for Santa's geolocation and activity, as well as the sleigh's geolocation, just in case a search and rescue mission needs to be initiated.
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 6120.
+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 &rfc6120;.
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-0172.xml b/xep-0172.xml index dbf7f6476..43ca98fc6 100644 --- a/xep-0172.xml +++ b/xep-0172.xml @@ -164,11 +164,11 @@As defined in RFC 6121, a presence subscription request contains only the JID of the sender:
+As defined in &rfc6121;, a presence subscription request contains only the JID of the sender:
Naturally, based on the JID of the sender, it is possible for the client to pull information about the sender from a persistent data store such as an LDAP database, &xep0054; node, or XEP-0154 store. However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender:
+Naturally, based on the JID of the sender, it is possible for the client to pull information about the sender from a persistent data store such as an LDAP database, &xep0054; node, or &xep0154; store. However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender:
If a client does not support XEP-0060 or the subset thereof specified in XEP-0163, it MAY send one &MESSAGE; stanza to each of its contacts, containing the updated nickname (note: the client SHOULD send the messages in a staggered fashion in order to avoid server-enforced rate limiting, commonly known as "karma").
+If a client does not support &xep0060; or the subset thereof specified in XEP-0163, it MAY send one &MESSAGE; stanza to each of its contacts, containing the updated nickname (note: the client SHOULD send the messages in a staggered fashion in order to avoid server-enforced rate limiting, commonly known as "karma").
An IM client MAY use the user's own nickname as all or part of the "display name" shown to the user of that client (e.g., as the sending name in one-to-one chats and groupchats). For example, if the user whose JID is narrator@moby-dick.lit asserts that his nickname is "Ishmael", that user's client may show "Ishmael" as all or part of the user's display name. How the client shall store the display name is out of scope for this document; possible mechanisms include the user's local vCard, an organizational LDAP directory, &xep0049;, or XEP-0154.
+An IM client MAY use the user's own nickname as all or part of the "display name" shown to the user of that client (e.g., as the sending name in one-to-one chats and groupchats). For example, if the user whose JID is narrator@moby-dick.lit asserts that his nickname is "Ishmael", that user's client may show "Ishmael" as all or part of the user's display name. How the client shall store the display name is out of scope for this document; possible mechanisms include the user's local vCard, an organizational LDAP directory, &xep0049;, or &xep0154;.
Earlier versions of this document described how to include the User Nickname extension in presence stanzas and invitations sent in relation to &xep0045; rooms. Based on deployment experience, that usage is now discouraged, since it is confusing to display multiple nicknames to an end user and inclusion of user-generated nicknames can override or work around local service policies for "nick lockdown" in chatrooms.
Earlier versions also described usage in relation to the &xep0130; protocol. Because that protocol is now obsolete, documentation of such usage has been removed from this specification.
A nickname is a memorable, friendly name asserted by a user. There is no guarantee that any given nickname will be unique even within a particular community (such as an enterprise or university), let alone across the Internet through federation of communities. Clients SHOULD warn users that nicknames asserted by contacts are not unique and that nickname collisions are possible. Clients also MUST NOT depend on nicknames to validate the identity of contacts; instead, nicknames SHOULD be used in conjunction with JIDs (which are globally unique) and user-assigned handles (which are private and unique) as described in XEP-0165 in order to provide a three-pronged approach to identity validation, preferably in combination with X.509 certificates.
+A nickname is a memorable, friendly name asserted by a user. There is no guarantee that any given nickname will be unique even within a particular community (such as an enterprise or university), let alone across the Internet through federation of communities. Clients SHOULD warn users that nicknames asserted by contacts are not unique and that nickname collisions are possible. Clients also MUST NOT depend on nicknames to validate the identity of contacts; instead, nicknames SHOULD be used in conjunction with JIDs (which are globally unique) and user-assigned handles (which are private and unique) as described in &xep0165; in order to provide a three-pronged approach to identity validation, preferably in combination with X.509 certificates.
This document requires no interaction with &IANA;.
diff --git a/xep-0174.xml b/xep-0174.xml index 83cb494b2..8dc82cd28 100644 --- a/xep-0174.xml +++ b/xep-0174.xml @@ -340,7 +340,7 @@ juliet@pronto._presence._tcp.local. IN TXT "vc=CA!" "ver=QgayPKawpkPSDYmwT/WM94uAlu0="" ]]> -The IPv4 and IPv6 addresses associated with a machine might vary depending on the local network to which the machine is connected. For example, on an Ethernet connection the physical address might be "192.168.0.100" but when the machine is connected to a wireless network the physical address might change to "10.10.1.187". See RFC 3927 for details.
+The IPv4 and IPv6 addresses associated with a machine might vary depending on the local network to which the machine is connected. For example, on an Ethernet connection the physical address might be "192.168.0.100" but when the machine is connected to a wireless network the physical address might change to "10.10.1.187". See &rfc3927; for details.
If the machine name asserted by a client is already taken by another machine on the network, the client MUST assert a different machine name, which SHOULD be formed by adding the character "-" and digit "1" to the end of the machine name string (e.g., "pronto-1"), adding the character "-" and digit "2" if the resulting machine name is already taken (e.g., "pronto-2"), and similarly incrementing the digit until a unique machine name is constructed.
If the username asserted by a client is already taken by another application on the machine, the client MUST assert a different username, which SHOULD be formed by adding the character "-" and digit "1" to the end of the username string (e.g., "juliet-1"), adding the character "-" and digit "2" if the resulting username is already taken (e.g., "juliet-2"), and similarly incrementing the digit until a unique username is constructed.
In order to exchange serverless messages, the initiator and recipient MUST first establish XML streams between themselves, as is familiar from RFC 6120.
+In order to exchange serverless messages, the initiator and recipient MUST first establish XML streams between themselves, as is familiar from &rfc6120;.
First, the initiator opens a TCP connection at the IP address and port discovered via the DNS lookup for an entity and opens an XML stream to the recipient, which SHOULD include 'to' and 'from' address:
Note: 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.
+Note: If the initiator supports stream features and the other stream-related aspects of XMPP 1.0 as specified in &rfc6120;, 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 6120:
+If both the initiator and recipient included the version='1.0' flag, the recipient SHOULD also send stream features as specified in &rfc6120;:
Because serverless communication does not involve the exchange of XMPP presence, it is not possible to use &xep0115; for capabilities discovery. Therefore, it is RECOMMENDED to instead include the node, hash, and ver TXT record parameters (and OPTIONAL to include the ext parameter). The values of these parameters MUST be the same as the values for the 'node', 'hash', 'ver', and 'ext' attributes that are advertised for the application in normal XMPP presence (if any) via the Entity Capabilities protocol as described in XEP-0115.
+Because serverless communication does not involve the exchange of XMPP presence, it is not possible to use &xep0115; for capabilities discovery. Therefore, it is RECOMMENDED to instead include the node, hash, and ver TXT record parameters (and OPTIONAL to include the ext parameter). The values of these parameters MUST be the same as the values for the 'node', 'hash', 'ver', and 'ext' attributes that are advertised for the application in normal XMPP presence (if any) via the Entity Capabilities protocol as described in &xep0115;.
As with Entity Capabilities over native XMPP networks, a client might not know the &xep0030; features associated with the 'ver' value advertised by another entity. However, in the case of serverless messaging there is no way for the client to discover the entity's supported features without initiating an XML stream to that entity and then sending a Service Discovery information ("disco#info") request over the negotiated stream.
Unfortunately, full stream negotiation (including TLS and SASL if appropriate) can require a large number of packets. Therefore, as an optimization, it is RECOMMENDED for the receiving entity in a serverless XML stream negotiation to include its disco#info data (including node) as a stream feature, as shown in the following examples.
RFC 1035 does not allow characters outside the &ascii; character range in DNS A records. Therefore the "machine" portion of an A record as used for serverless messaging MUST NOT contain characters outside the US-ASCII character range.
-Although RFC 2317 and RFC 2782 do not allow characters outside the US-ASCII character range in PTR and SRV records respectively, Section 4.1 of DNS-Based Service Discovery recommends support for UTF-8-encoded Unicode characters in the <Instance> portion of Service Instance Names, which in serverless messaging is the "user@machine" portion of the PTR or SRV record. This document adheres to the recommendation in DNS-Based Service Discovery. However, as mentioned above, the "machine" portion of the <Instance> portion MUST NOT contain characters outside the US-ASCII range.
-Although RFC 1464 does not allow characters outside the US-ASCII character range in TXT records, Section 6.5 of DNS-Based Service Discovery mentions support for UTF-8-encoded Unicode characters in text record values (e.g., values of the TXT "msg" name). This document adheres to the recommendation in DNS-Based Service Discovery.
+&rfc1035; does not allow characters outside the &ascii; character range in DNS A records. Therefore the "machine" portion of an A record as used for serverless messaging MUST NOT contain characters outside the US-ASCII character range.
+Although &rfc2317; and RFC 2782 do not allow characters outside the US-ASCII character range in PTR and SRV records respectively, Section 4.1 of DNS-Based Service Discovery recommends support for UTF-8-encoded Unicode characters in the <Instance> portion of Service Instance Names, which in serverless messaging is the "user@machine" portion of the PTR or SRV record. This document adheres to the recommendation in DNS-Based Service Discovery. However, as mentioned above, the "machine" portion of the <Instance> portion MUST NOT contain characters outside the US-ASCII range.
+Although &rfc1464; does not allow characters outside the US-ASCII character range in TXT records, Section 6.5 of DNS-Based Service Discovery mentions support for UTF-8-encoded Unicode characters in text record values (e.g., values of the TXT "msg" name). This document adheres to the recommendation in DNS-Based Service Discovery.
XMPP networks use TLS (&rfc5246;) for channel encryption, SASL (&rfc4422;) for authentication, and the Domain Name System (&rfc1034;) for weak validation of server hostnames; these technologies help to ensure the identity of sending entities and to encrypt XML streams. By contrast, zero-configuration networking uses dynamic discovery and asserted machine names as the basis of sender identity. Therefore, serverless messaging does not result in authenticated identities in the same way that XMPP itself does, nor does it provide for an encrypted channel between entities.
-To secure communications between serverless entities, it is RECOMMENDED to negotiate the use of TLS and SASL for the XML stream as described in RFC 6120. However, subject to client configuration and local service policies, an entity MAY accept an unauthenticated and unencrypted channel, in which case the client SHOULD warn the human user that the channel is unauthenticated and unencrypted.
+To secure communications between serverless entities, it is RECOMMENDED to negotiate the use of TLS and SASL for the XML stream as described in &rfc6120;. However, subject to client configuration and local service policies, an entity MAY accept an unauthenticated and unencrypted channel, in which case the client SHOULD warn the human user that the channel is unauthenticated and unencrypted.
Because of fundamental differences between a true XMPP network and a serverless client "mesh", entities communicating via serverless messaging MUST NOT attempt to inject serverless traffic onto an XMPP network and an XMPP server MUST reject communications until an entity is properly authenticated in accordance with the rules defined in RFC 6120. However, a client on a serverless mesh MAY forward traffic to an XMPP network after having properly authenticated on such a network (e.g., to forward a message received on a serverless client mesh to a contact on an XMPP network).
+Because of fundamental differences between a true XMPP network and a serverless client "mesh", entities communicating via serverless messaging MUST NOT attempt to inject serverless traffic onto an XMPP network and an XMPP server MUST reject communications until an entity is properly authenticated in accordance with the rules defined in &rfc6120;. However, a client on a serverless mesh MAY forward traffic to an XMPP network after having properly authenticated on such a network (e.g., to forward a message received on a serverless client mesh to a contact on an XMPP network).
Because there is no mechanism for validating the information that is published in DNS TXT records, it is possible for clients to "poison" this information (e.g., by publishing email addresses or Jabber IDs that are controlled by or associated with other users).
diff --git a/xep-0175.xml b/xep-0175.xml index f78d8529b..a5c26112f 100644 --- a/xep-0175.xml +++ b/xep-0175.xml @@ -66,7 +66,7 @@An XMPP server implementation SHOULD NOT enable the SASL ANONYMOUS mechanism by default, but instead SHOULD force the administrator of a given service to explicitly enable support in the context of that deployment.
When a client authenticates using SASL ANONYMOUS, an XMPP server SHOULD assign a temporary, unique bare JID &LOCALBARE; to the client. Although the method for ensuring the uniqueness of the localpart is a matter of implementation, it is RECOMMENDED for the localpart to be a UUID as specified in &rfc4122;.
-Although RFC 4505 allows the client to provide so-called "trace data" when authenticating via SASL ANONYMOUS, it is NOT RECOMMENDED for the client to include trace data as the XML character data of the <auth/> element (instead, the <auth/> element SHOULD be empty). However, if trace data is included, the server MUST NOT use it for any purpose other than tracing (e.g., not use it as the resource identifier of the anonymous user's full JID).
+Although &rfc4505; allows the client to provide so-called "trace data" when authenticating via SASL ANONYMOUS, it is NOT RECOMMENDED for the client to include trace data as the XML character data of the <auth/> element (instead, the <auth/> element SHOULD be empty). However, if trace data is included, the server MUST NOT use it for any purpose other than tracing (e.g., not use it as the resource identifier of the anonymous user's full JID).
Because an anonymous user is unknown to the server, the server SHOULD appropriately restrict the user's access in order to limit the possibility of malicious behavior (such as denial of service attacks as described in &xep0205;), especially on public deployments. The following restrictions are encouraged on public deployments. Administrators of private deployments and specialized deployments are advised to take these restrictions into account when configuring their services, but can reasonably relax these restrictions if they have appropriate access controls in place or their deployment requirements cannot be met using the more restrictive profile applied in public deployments.
During resource binding, the server MAY ignore the resource identifier provided by the client (if any) and instead assign a resource identifier that it generates on behalf of the client.
The RECOMMENDED protocol flow following TLS negotiation (refer to RFC 3920) is as follows:
+The RECOMMENDED protocol flow following TLS negotiation (refer to &rfc3920;) is as follows:
Client initiates stream to server.
@@ -183,7 +183,7 @@ ]]>The security considerations discussed in RFC 3920 and RFC 4505 apply to the use of SASL ANONYMOUS in XMPP; specific suggestions regarding usage restrictions for anonymous users are provided under the Recommendations section of this document.
+The security considerations discussed in &rfc3920; and RFC 4505 apply to the use of SASL ANONYMOUS in XMPP; specific suggestions regarding usage restrictions for anonymous users are provided under the Recommendations section of this document.
This document requires no interaction with &IANA;.
diff --git a/xep-0176.xml b/xep-0176.xml index e764c5f7e..d070e4046 100644 --- a/xep-0176.xml +++ b/xep-0176.xml @@ -250,7 +250,7 @@In accordance with Section 10 of XEP-0166, this document specifies the following information related to the Jingle ice-udp transport method:
+In accordance with Section 10 of &xep0166;, this document specifies the following information related to the Jingle ice-udp transport method:
The transport negotiation process is defined in the Protocol Description section of this document.
The semantics of the &TRANSPORT; element are defined in the ICE Negotiation section of this document.
Note: The examples in this document follow the scenario described in Section 17 of &icecore;, except that we substitute the Shakespearean characters "Romeo" and "Juliet" for the generic entities "L" and "R".
In order for the initiator in a Jingle exchange to start the negotiation, it sends a Jingle "session-initiate" stanza that includes at least one content type, as described in XEP-0166. If the initiator wishes to negotiate the ice-udp transport method for an application format, it MUST include a &TRANSPORT; child element qualified by the 'urn:xmpp:jingle:transports:ice-udp:1' namespace &VNOTE;. This element SHOULD in turn contain one &CANDIDATE; element for each of the initiator's higher-priority transport candidates as determined in accordance with the ICE methodology, but MAY instead be empty (with each candidate to be sent as the payload of a transport-info message).
+In order for the initiator in a Jingle exchange to start the negotiation, it sends a Jingle "session-initiate" stanza that includes at least one content type, as described in &xep0166;. If the initiator wishes to negotiate the ice-udp transport method for an application format, it MUST include a &TRANSPORT; child element qualified by the 'urn:xmpp:jingle:transports:ice-udp:1' namespace &VNOTE;. This element SHOULD in turn contain one &CANDIDATE; element for each of the initiator's higher-priority transport candidates as determined in accordance with the ICE methodology, but MAY instead be empty (with each candidate to be sent as the payload of a transport-info message).
As described in XEP-0166, to acknowledge receipt of the session initiation request, the responder immediately returns an IQ-result.
+As described in &xep0166;, to acknowledge receipt of the session initiation request, the responder immediately returns an IQ-result.
The first step in negotiating connectivity is for each party to send transport candidates to the other party.
Each candidate shall be sent as a <candidate/> child of a &TRANSPORT; element qualified by the 'urn:xmpp:jingle:transports:ice-udp:1' namespace. The &TRANSPORT; element is sent via a Jingle message of type session-initiate, session-accept, or transport-info.
-Either party MAY include multiple <candidate/> elements in one &TRANSPORT; element, especially in the session-initiate and session-accept messages sent at the beginning of the session negotiation. Including multiple candidates in the session-initiate and session-accept messages can help to ensure interoperability with entities that implement the SDP offer/answer model described in RFC 3264; in particular, an entity SHOULD include multiple candidates in its session-initiate or session-accept message if the other party advertises support for the "urn:ietf:rfc:3264" service discovery feature as described in the SDP Offer / Answer Support section of this document. However, including one candidate per subsequent transport-info message typically results in a faster negotiation because the candidates most likely to succeed are sent first (in the session-info and session-accept messages) and it is not necessary to gather all candidates before beginning to send any candidates; furthermore, because certain candidates can be more "expensive" in terms of bandwidth or processing power, either party might not want to advertise the existence of such candidates unless it is necessary to do so after other candidates have failed.
+Either party MAY include multiple <candidate/> elements in one &TRANSPORT; element, especially in the session-initiate and session-accept messages sent at the beginning of the session negotiation. Including multiple candidates in the session-initiate and session-accept messages can help to ensure interoperability with entities that implement the SDP offer/answer model described in &rfc3264;; in particular, an entity SHOULD include multiple candidates in its session-initiate or session-accept message if the other party advertises support for the "urn:ietf:rfc:3264" service discovery feature as described in the SDP Offer / Answer Support section of this document. However, including one candidate per subsequent transport-info message typically results in a faster negotiation because the candidates most likely to succeed are sent first (in the session-info and session-accept messages) and it is not necessary to gather all candidates before beginning to send any candidates; furthermore, because certain candidates can be more "expensive" in terms of bandwidth or processing power, either party might not want to advertise the existence of such candidates unless it is necessary to do so after other candidates have failed.
If the party that receives a candidate in a Jingle message can successfully process a given candidate or set of candidates, it returns an IQ-result (if not, for example because the candidate data is improperly formatted, it returns an IQ-error). At this point, the receiving entity is only indicating receipt of the candidate or set of candidates, not telling the other party that the candidate will be used.
The initiator can keep sending candidates (without stopping to receive an acknowledgement of receipt from the responder for each candidate) until it has exhausted its supply of possible or desirable transport candidates. The responder can also keep sending potential candidates, which the initiator will acknowledge.
(In accordance with Jingle core, the responder will also acknowledge the transport-info message.)
-In the unlikely event that one of the parties determines that it cannot establish connectivity even after sending and checking lower-priority candidates, it SHOULD terminate the session as described in XEP-0166.
+In the unlikely event that one of the parties determines that it cannot establish connectivity even after sending and checking lower-priority candidates, it SHOULD terminate the session as described in &xep0166;.
Even after media has begun to flow, either party MAY continue to send additional candidates to the other party (e.g., because the user agent has become aware of a new media proxy or network interface card). Such candidates are shared by sending a transport-info message.
@@ -888,7 +888,7 @@ Romeo Gateway JulietIn order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.
If an entity supports the SDP offer / answer model described in RFC 3264 and therefore prefers to receive multiple candidates in a single transport-info message, it MUST advertise support for the "urn:ietf:rfc:3264" service discovery feature. Typically this feature will be advertised only by gateways between Jingle and SIP.
+If an entity supports the SDP offer / answer model described in &rfc3264; and therefore prefers to receive multiple candidates in a single transport-info message, it MUST advertise support for the "urn:ietf:rfc:3264" service discovery feature. Typically this feature will be advertised only by gateways between Jingle and SIP.
If an entity supports the SDP offer / answer model described in RFC 3264 and therefore prefers to receive one transport-info message with multiple candidates, it MUST advertise support for the "urn:ietf:rfc:3264" feature.
+If an entity supports the SDP offer / answer model described in &rfc3264; and therefore prefers to receive one transport-info message with multiple candidates, it MUST advertise support for the "urn:ietf:rfc:3264" feature.
The registry submission is as follows.
diff --git a/xep-0177.xml b/xep-0177.xml
index 121962759..860a3a329 100644
--- a/xep-0177.xml
+++ b/xep-0177.xml
@@ -181,7 +181,7 @@
- In accordance with Section 10 of XEP-0166, this document specifies the following information related to the Jingle Raw UDP transport type:
+ In accordance with Section 10 of &xep0166;, this document specifies the following information related to the Jingle Raw UDP transport type:
The transport negotiation process is defined in the Protocol Description section of this document.
The semantics of the &TRANSPORT; element are defined in the Transport Initiation section of this document.
@@ -211,7 +211,7 @@ INITIATOR RESPONDER
In order for the initiator in a Jingle exchange to start the negotiation, it sends a Jingle "session-initiate" stanza that includes at least one content type, as described in XEP-0166. If the initiator wishes to negotiate the Raw UDP transport for a given content type, it MUST include a &TRANSPORT; child element qualified by the 'urn:xmpp:jingle:transports:raw-udp:1' namespace &VNOTE;, which MUST
In order for the initiator in a Jingle exchange to start the negotiation, it sends a Jingle "session-initiate" stanza that includes at least one content type, as described in &xep0166;. If the initiator wishes to negotiate the Raw UDP transport for a given content type, it MUST include a &TRANSPORT; child element qualified by the 'urn:xmpp:jingle:transports:raw-udp:1' namespace &VNOTE;, which MUST
If the client is aware of which type of candidate it is sending, the candidate element MAY contain a 'type' attribute. Although this information is merely a hint about the candidate type, this information can help the recipient be aware of how permissive the peer's NAT or firewall is. The values of the 'type' attribute are "host", "prflx", "relay", and "srflx" (as in the ICE specification and XEP-0176).
+If the client is aware of which type of candidate it is sending, the candidate element MAY contain a 'type' attribute. Although this information is merely a hint about the candidate type, this information can help the recipient be aware of how permissive the peer's NAT or firewall is. The values of the 'type' attribute are "host", "prflx", "relay", and "srflx" (as in the ICE specification and &xep0176;).
As described in XEP-0166, to acknowledge the session initiation request, the responder returns an IQ-result:
+As described in &xep0166;, to acknowledge the session initiation request, the responder returns an IQ-result:
As specified in RFC 3920 and updated in RFC 6120, during the stream negotiation process an XMPP client can present a certificate (a "client certificate"). If a JabberID is included in a client certificate, it is encapsulated as an id-on-xmppAddr Object Identifier ("xmppAddr"), i.e., a subjectAltName entry of type otherName with an ASN.1 Object Identifier of "id-on-xmppAddr" as specified in Section 13.7.1.4 of RFC 6120.
+As specified in &rfc3920; and updated in RFC 6120, during the stream negotiation process an XMPP client can present a certificate (a "client certificate"). If a JabberID is included in a client certificate, it is encapsulated as an id-on-xmppAddr Object Identifier ("xmppAddr"), i.e., a subjectAltName entry of type otherName with an ASN.1 Object Identifier of "id-on-xmppAddr" as specified in Section 13.7.1.4 of RFC 6120.
There are three possible cases:
Server advertises SASL mechanisms. Because the client presented a client certificate, here the server offers the SASL EXTERNAL mechanism (see Section 6.3.4 of RFC 6120 for recommendations regarding the conditions under which to offer the SASL EXTERNAL mechanism).
+Server advertises SASL mechanisms. Because the client presented a client certificate, here the server offers the SASL EXTERNAL mechanism (see Section 6.3.4 of &rfc6120; for recommendations regarding the conditions under which to offer the SASL EXTERNAL mechanism).
Client considers EXTERNAL to be its preferred SASL mechanism so it attempts to complete SASL negotiation using that mechanism. The following paragraphs illustrate several possible paths, depending on whether the client includes an authorization identity (for the official rules regarding when to include the authorization identity, see Section 6.3.8 of RFC 6120).
+Client considers EXTERNAL to be its preferred SASL mechanism so it attempts to complete SASL negotiation using that mechanism. The following paragraphs illustrate several possible paths, depending on whether the client includes an authorization identity (for the official rules regarding when to include the authorization identity, see Section 6.3.8 of &rfc6120;).
If the client certificate contains only one JID, then the client MAY include an authorization identity, but only if it desires to be authorized as a JID other than the address in the client certificate; else it MUST NOT include an authorization identity (this is shown in the following example by setting the XML character data of the <auth/> element to "=").
@@ -269,12 +269,12 @@If SASL authentication succeeded, the client opens a new stream, then client and server proceed with resource binding as described in RFC 6120.
+If SASL authentication succeeded, the client opens a new stream, then client and server proceed with resource binding as described in &rfc6120;.
RFC 3920 specified that if a JabberID is included in a certificate intended for use by an XMPP server (a "server certificate"), it shall be encapsulated as an xmppAddr. That recommendation is updated in RFC 6120 through a reference to &rfc6125;, which prefers use of a dNSName and/or SRVName entry in the Subject Alternative Name. The DNS domain name contained in the certificate can be a fully-qualified domain name ("FQDN") or a so-called "wildcard" with the '*' character as the complete left-most label (see RFC 6125 for complete details).
+&rfc3920; specified that if a JabberID is included in a certificate intended for use by an XMPP server (a "server certificate"), it shall be encapsulated as an xmppAddr. That recommendation is updated in RFC 6120 through a reference to &rfc6125;, which prefers use of a dNSName and/or SRVName entry in the Subject Alternative Name. The DNS domain name contained in the certificate can be a fully-qualified domain name ("FQDN") or a so-called "wildcard" with the '*' character as the complete left-most label (see RFC 6125 for complete details).
The RECOMMENDED protocol flow for server-to-server use of SASL EXTERNAL with server (domain) certificates is as follows:
Server2 requests, and Server1 presents, Server1's certificate during TLS negotiation.
Server2 validates certificate in accordance with the rules from RFC 6120 and RFC 6125.
+Server2 validates certificate in accordance with the rules from &rfc6120; and RFC 6125.
If certificate is unacceptable for the reasons explained in RFC 6120 and RFC 6125, Server2 closes Server1's TCP connection.
+If certificate is unacceptable for the reasons explained in &rfc6120; and RFC 6125, Server2 closes Server1's TCP connection.
Else Server2 completes successful TLS negotiation and Server1 sends a new initial stream header to Server2 over the encrypted TCP connection.
@@ -357,7 +357,7 @@ ]]>Server2 advertises SASL mechanisms. If the 'from' attribute of the stream header sent by Server1 can be matched against one of the identifiers provided in the certificate following the matching rules from RFC 6125, Server2 SHOULD advertise the SASL EXTERNAL mechanism. If no match is found, Server2 MAY either close Server1's TCP connection or continue with a &xep0220; negotiation.
+Server2 advertises SASL mechanisms. If the 'from' attribute of the stream header sent by Server1 can be matched against one of the identifiers provided in the certificate following the matching rules from &rfc6125;, Server2 SHOULD advertise the SASL EXTERNAL mechanism. If no match is found, Server2 MAY either close Server1's TCP connection or continue with a &xep0220; negotiation.
Server1 considers EXTERNAL to be its preferred SASL mechanism. For server-to-server authentication, the <auth/> element MAY include an authorization identity, however a future version of this specification might disallow use of the authorization identity in server-to-server authentication (in the following example, Server1 includes an empty response of "=" as shown in RFC 6120).
+Server1 considers EXTERNAL to be its preferred SASL mechanism. For server-to-server authentication, the <auth/> element MAY include an authorization identity, however a future version of this specification might disallow use of the authorization identity in server-to-server authentication (in the following example, Server1 includes an empty response of "=" as shown in &rfc6120;).
Server2 determines if hostname is valid.
If the 'from' attribute of stream header sent by Server1 can be matched against one of the identifiers provided in the certificate following the matching rules from RFC 6125, Server2 returns success.
+If the 'from' attribute of stream header sent by Server1 can be matched against one of the identifiers provided in the certificate following the matching rules from &rfc6125;, Server2 returns success.
This document introduces no security considerations or concerns above and beyond those discussed in RFC 6120 and RFC 6125.
+This document introduces no security considerations or concerns above and beyond those discussed in &rfc6120; and RFC 6125.
This document requires no interaction with &IANA;.
diff --git a/xep-0179.xml b/xep-0179.xml index 14aa5cfb0..c648e8278 100644 --- a/xep-0179.xml +++ b/xep-0179.xml @@ -79,7 +79,7 @@In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in XEP-0166. This stanza MUST include at least one transport method. If the initiating entity wishes to negotiate the IAX transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/iax' namespace.
+In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in &xep0166;. This stanza MUST include at least one transport method. If the initiating entity wishes to negotiate the IAX transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/iax' namespace.
As described in XEP-0166, to provisionally accept the session initiation request, the target entity returns an IQ-result:
+As described in &xep0166;, to provisionally accept the session initiation request, the target entity returns an IQ-result:
In accordance with Section 8 of XEP-0166, this document specifies the following information related to the Jingle Video via RTP application type:
+In accordance with Section 8 of &xep0166;, this document specifies the following information related to the Jingle Video via RTP application type:
The application format negotiation process is defined in the Negotiating a Jingle Video Session section of this document.
The semantics of the &DESCRIPTION; element are defined in the Application Format section of this document.
A Jingle video session is described by a content type that contains one application format and one transport method. The application format consists of one or more encodings contained within a wrapper <description/> element qualified by the 'urn:xmpp:tmp:jingle:apps:video-rtp' namespace &NSNOTE;. In the language of RFC 4566 each encoding is a payload-type; therefore, each <payload-type/> element specifies an encoding that can be used for the audio stream, as illustrated in the following example.
+A Jingle video session is described by a content type that contains one application format and one transport method. The application format consists of one or more encodings contained within a wrapper <description/> element qualified by the 'urn:xmpp:tmp:jingle:apps:video-rtp' namespace &NSNOTE;. In the language of &rfc4566; each encoding is a payload-type; therefore, each <payload-type/> element specifies an encoding that can be used for the audio stream, as illustrated in the following example.
The &DESCRIPTION; element is intended to be a child of a &CONTENT; element as specified in XEP-0166.
+The &DESCRIPTION; element is intended to be a child of a &CONTENT; element as specified in &xep0166;.
The &DESCRIPTION; element SHOULD possess a 'profile' attribute that specifies the profile of RTP in use as would be encapsulated in SDP (e.g., "RTP/AVP" or "UDP/TLS/RTP/SAVP"). If not included, the default value of "RTP/AVP" MUST be assumed.
The encodings SHOULD be provided in order of preference by placing the most-preferred &PAYLOADTYPE; element as the first child of the &DESCRIPTION; element (etc.).
The allowable attributes of the &PAYLOADTYPE; element are as follows:
@@ -207,7 +207,7 @@In Jingle Video, the encodings are used in the context of RTP. The most common encodings for the Audio/Video Profile (AVP) of RTP are listed in &rfc3551; (these "static" types are reserved from payload ID 0 through payload ID 95), although other encodings are allowed (these "dynamic" types use payload IDs 96 to 127) in accordance with the dynamic assignment rules described in Section 3 of RFC 3551. The payload IDs are represented in the 'id' attribute.
+In Jingle Video, the encodings are used in the context of RTP. The most common encodings for the Audio/Video Profile (AVP) of RTP are listed in &rfc3551; (these "static" types are reserved from payload ID 0 through payload ID 95), although other encodings are allowed (these "dynamic" types use payload IDs 96 to 127) in accordance with the dynamic assignment rules described in Section 3 of &rfc3551;. The payload IDs are represented in the 'id' attribute.
Each <payload-type/> element MAY contain one or more child elements that specify particular parameters related to the payload. For example, as described in &rtptheora;, the "configuration", "configuration-uri", "delivery-method", "height", "sampling", and "width" parameters may be specified in relation to usage of the Theora
@@ -244,7 +244,7 @@
]]>
- Upon receiving the session-initiate stanza, the responder determines whether it can proceed with the negotiation. The general Jingle error cases are specified in XEP-0166 and illustrated &xep0167;. In addition, the responder must determine if it supports any of the payload types advertised by the initiator; if it supports none of the offered payload types, it must reject the session by returning a ¬acceptable; error with a Jingle-Video-specific condition of <unsupported-codecs/>:
+ Upon receiving the session-initiate stanza, the responder determines whether it can proceed with the negotiation. The general Jingle error cases are specified in &xep0166; and illustrated &xep0167;. In addition, the responder must determine if it supports any of the payload types advertised by the initiator; if it supports none of the offered payload types, it must reject the session by returning a ¬acceptable; error with a Jingle-Video-specific condition of <unsupported-codecs/>:
]]>
- After successful transport negotiation (for the ICE-UDP method, see XEP-0176), the responder then accepts the session:
+ After successful transport negotiation (for the ICE-UDP method, see &xep0176;), the responder then accepts the session:
]]>
- Note: For more examples, see XEP-0167.
+ Note: For more examples, see &xep0167;.
The SDP media type for Jingle Video via RTP is "video" (see Section 8.2.1 of RFC 4566).
-If the payload type is static (payload-type IDs 0 through 95 inclusive), it MUST be mapped to a media field defined in RFC 4566. The generic format for the media field is as follows:
+The SDP media type for Jingle Video via RTP is "video" (see Section 8.2.1 of &rfc4566;).
+If the payload type is static (payload-type IDs 0 through 95 inclusive), it MUST be mapped to a media field defined in &rfc4566;. The generic format for the media field is as follows:
]]>
diff --git a/xep-0181.xml b/xep-0181.xml
index ee6f5c5b1..d04a0d8ee 100644
--- a/xep-0181.xml
+++ b/xep-0181.xml
@@ -283,6 +283,6 @@
]]>
Thanks to Diana Cionoiu, Olivier Crête, Robert McQueen, and Paul Witty for their feedback. Several sentences were borrowed from RFC 4733.
+Thanks to Diana Cionoiu, Olivier Crête, Robert McQueen, and Paul Witty for their feedback. Several sentences were borrowed from &rfc4733;.
In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in XEP-0166. This stanza MUST include at least one transport method. If the initiating entity wishes to negotiate the telepathy transport, it MUST include a &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/telepathy' namespace.
+In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in &xep0166;. This stanza MUST include at least one transport method. If the initiating entity wishes to negotiate the telepathy transport, it MUST include a &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/telepathy' namespace.
This &TRANSPORT; element MUST include one and only one &CANDIDATE; element per channel specifying the parameters that the initiator believes will be most likely to succeed for that channel. (Note: You have to believe.) This is not necessarily the initiator's preferred address for spiritual communication, but instead is the "address most likely to succeed", i.e., the address that is assumed to be reachable by the vast majority of target entities. (Establishing direct spiritual communication is hard enough as it is.) Here is an example:
As described in XEP-0166, to provisionally accept the session initiation request, the receiver returns an IQ-result:
+As described in &xep0166;, to provisionally accept the session initiation request, the receiver returns an IQ-result:
Now the initiating entity and receiver can begin sending appropriate psychical media over the negotiated ESP stream.
-In the event that the receiver cannot establish a channel, it SHOULD terminate the session (see XEP-0176 or XEP-0177 for examples).
+In the event that the receiver cannot establish a channel, it SHOULD terminate the session (see &xep0176; or XEP-0177 for examples).
Because the informational message payloads specific to the telepathy transport method cannot be tied down to the arbitrary conventions of XML syntax, a <message/> element qualified by the 'http://jabber.org/protocol/info/telepathy' namespace may include any character data that either party feels like communicating.
diff --git a/xep-0185.xml b/xep-0185.xml index 3d017c5bc..6d96d7da2 100644 --- a/xep-0185.xml +++ b/xep-0185.xml @@ -69,7 +69,7 @@&rfc3920; does not specify in detail a recommended algorithm for generating the keys used in the server dialback protocol. This document provides such a recommendation as an aid to implementors of XMPP servers. This document is not meant to supersede any text in RFC 3920; however, the recommendations in this document have been incorporated into &xep0220;.
+&rfc3920; does not specify in detail a recommended algorithm for generating the keys used in the server dialback protocol. This document provides such a recommendation as an aid to implementors of XMPP servers. This document is not meant to supersede any text in &rfc3920;; however, the recommendations in this document have been incorporated into &xep0220;.
The process for generating and validating a dialback key SHOULD take into account the following four inputs:
@@ -101,7 +101,7 @@ key = HMAC-SHA256This document closely follows the description of the dialback protocol in RFC 3920 and XEP-0220, but omits steps that are not important for the generation and validation of the dialback keys. For ease of comparison the numbering of the steps is the same as in section 8.3 of RFC 3920 and Appendix C.3 of XEP-0220. Any line breaks in the examples are included for the purpose of readability only.
+This document closely follows the description of the dialback protocol in &rfc3920; and &xep0220;, but omits steps that are not important for the generation and validation of the dialback keys. For ease of comparison the numbering of the steps is the same as in section 8.3 of RFC 3920 and Appendix C.3 of XEP-0220. Any line breaks in the examples are included for the purpose of readability only.
The following data values are used in the examples:
<end/> | -The UTC DateTime after which the key shall not be considered valid, formatted according to XEP-0082. | +The UTC DateTime after which the key shall not be considered valid, formatted according to &xep0082;. |
<jid/> | @@ -226,7 +226,7 @@||
<revocationtime/> | -The UTC DateTime at which the key was revoked, formatted according to XEP-0082. | +The UTC DateTime at which the key was revoked, formatted according to &xep0082;. |
The data that is signed MUST be the revoked public key (i.e., the XML character data of the <key/> element), the fingerprint of the revoked public key (i.e., the XML character data of the <keyprint/> element), the fingerprint of the key used to sign the revocation (i.e., the XML character data of the <revocationprint/> element), and the time of the revocation (i.e., the XML character data of the <revocationtime/> element), concatenated together with no spaces or other additional characters.
@@ -292,7 +292,7 @@The data that is signed MUST be the user's public key (i.e., the XML character data of the <key/> element), the fingerprint of the user's public key (i.e., the XML character data of the <keyprint/> element), the signer's JID (i.e., the XML character data of the <signerjid/> element), the fingerprint of the signer's key (i.e., the XML character data of the <signerprint/> element), and the time of the attestation (i.e., the XML character data of the <signtime/> element), concatenated together with no spaces or other additional characters.
diff --git a/xep-0190.xml b/xep-0190.xml index c766418bd..21c5e19d4 100644 --- a/xep-0190.xml +++ b/xep-0190.xml @@ -60,7 +60,7 @@RFC 3920 describes several ways to terminate an XML stream, but does not always make a clear statement about which to use. This can lead to faulty implementations. In particular, closing a stream that has not been in use for a while is very often achieved using a connection-timeout error, then closing the socket. This can lead to loss of data. Therefore this document proposes a practice that will avoid such data loss.
+&rfc3920; describes several ways to terminate an XML stream, but does not always make a clear statement about which to use. This can lead to faulty implementations. In particular, closing a stream that has not been in use for a while is very often achieved using a connection-timeout error, then closing the socket. This can lead to loss of data. Therefore this document proposes a practice that will avoid such data loss.
Note: The recommendation described herein has been incorporated into &rfc6120;.
&rfc3921; includes an XMPP protocol extension for communications blocking, which has since been moved to &xep0016;. Unfortunately, because the privacy lists extension is quite complex, it has not been widely implemented in servers and has been implemented virtually not at all in clients. This is problematic, since the ability to block communications with selected users is an important feature for an instant messaging system (and is required by &rfc2779;). However, the full power of privacy lists is not needed in order to block communications, so this document proposes a simpler blocking protocol that meets the requirement specified in RFC 2779 and can be implemented more easily in XMPP clients and servers.
+&rfc3921; includes an XMPP protocol extension for communications blocking, which has since been moved to &xep0016;. Unfortunately, because the privacy lists extension is quite complex, it has not been widely implemented in servers and has been implemented virtually not at all in clients. This is problematic, since the ability to block communications with selected users is an important feature for an instant messaging system (and is required by &rfc2779;). However, the full power of privacy lists is not needed in order to block communications, so this document proposes a simpler blocking protocol that meets the requirement specified in &rfc2779; and can be implemented more easily in XMPP clients and servers.
If the <block/> element does not contain at least one <item/> child element, the server MUST return a &badrequest; error. The <block/> element MAY contain more than one <item/> child. Other standard XMPP stanza errors also apply; see &xmppcore; and &xep0086;.
-When the user blocks communications with a JID, the user's server MUST send unavailable presence information to the JID (but only if the JID is allowed to receive presence notifications from the user in accordance with the rules defined in RFC 3921).
+When the user blocks communications with a JID, the user's server MUST send unavailable presence information to the JID (but only if the JID is allowed to receive presence notifications from the user in accordance with the rules defined in &rfc3921;).
Once the user has blocked communications with a JID, the user's server MUST NOT deliver any XML stanzas from the JID to the user. The block remains in force until the user subsequently unblocks commmunications with the JID (i.e., the duration of the block is potentially unlimited and applies across sessions).
If a blocked JID 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:
When the user unblocks communications with a JID, the user's server MUST send the user's current presence information to the JID (but only if the JID is allowed to receive presence notifications from the user in accordance with the rules defined in RFC 3921).
+When the user unblocks communications with a JID, the user's server MUST send the user's current presence information to the JID (but only if the JID is allowed to receive presence notifications from the user in accordance with the rules defined in &rfc3921;).
After the user has unblocked communications with a JID, the user's server MUST deliver any subsequent XML stanzas from the JID to the user.
The communications blocking protocol specified herein is intended to be a user-friendly "front end" to a subset of the functionality defined by the privacy lists protocol (XEP-0016). If a service deploys both privacy lists and the blocking command, the service MUST use the same back-end data store for both protocols. (Note: Wherever possible, this document attempts to define a protocol that is fully consistent with XEP-0016; if a particular aspect of functionality is not specified herein, the relevant text in XEP-0016 shall be taken to apply.)
+The communications blocking protocol specified herein is intended to be a user-friendly "front end" to a subset of the functionality defined by the privacy lists protocol (&xep0016;). If a service deploys both privacy lists and the blocking command, the service MUST use the same back-end data store for both protocols. (Note: Wherever possible, this document attempts to define a protocol that is fully consistent with XEP-0016; if a particular aspect of functionality is not specified herein, the relevant text in XEP-0016 shall be taken to apply.)
When implementing both XEP-0191 and XEP-0016, a service SHOULD map the blocklist to the default privacy list, where each blocked JID is represented as a privacy list item of type "jid" and action "deny".
If all of a user's clients always use the blocking command, then the default privacy list will be equivalent to the blocklist and the default privacy list will be a kind of "virtual list" (in the sense that it is never modified directly by any of the clients).
Matching of JIDs as specified in the 'jid' attribute of the <item/> element SHOULD proceed in the following order (this is consistent with XEP-0016):
+Matching of JIDs as specified in the 'jid' attribute of the <item/> element SHOULD proceed in the following order (this is consistent with &xep0016;):
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 &rfc3920; and RFC 3921.
RFC 3920 introduced the concept of stream features. Implementation experience has revealed several shortcomings in the current definition and usage of stream features:
+&rfc3920; introduced the concept of stream features. Implementation experience has revealed several shortcomings in the current definition and usage of stream features:
Note: The recommendations from this document were NOT incorporated into &rfc6120; and this document is Obsolete.
The XMPP stream feature for Transport Layer Security (TLS) includes a <required/> child element that can be used to indicate that negotiation of TLS must be completed before proceeding with the rest of the stream negotiation. However, as defined in RFC 3920 the remaining stream features do not include the ability to flag that negotiation of the feature is required in order to (1) proceed with the negotiation or (2) begin sending XML stanzas. Because the non-TLS features lack a required flag, it is not possible for the initiating entity to know definitively how to proceed at any given stage in the stream negotiation, and the only way for the initiating entity to know whether it may begin sending XML stanzas is to attempt to send them (the receiving entity will return a ¬authorized; stream error if not all required features have been negotiated). This state of affairs is suboptimal. Therefore, every stream feature must include the ability to flag the feature as required or not required. When the initiating entity receives a stream features element with no features containing a <required/> element, it knows thatt the receiving party will accept XML stanzas over the stream.
+The XMPP stream feature for Transport Layer Security (TLS) includes a <required/> child element that can be used to indicate that negotiation of TLS must be completed before proceeding with the rest of the stream negotiation. However, as defined in &rfc3920; the remaining stream features do not include the ability to flag that negotiation of the feature is required in order to (1) proceed with the negotiation or (2) begin sending XML stanzas. Because the non-TLS features lack a required flag, it is not possible for the initiating entity to know definitively how to proceed at any given stage in the stream negotiation, and the only way for the initiating entity to know whether it may begin sending XML stanzas is to attempt to send them (the receiving entity will return a ¬authorized; stream error if not all required features have been negotiated). This state of affairs is suboptimal. Therefore, every stream feature must include the ability to flag the feature as required or not required. When the initiating entity receives a stream features element with no features containing a <required/> element, it knows thatt the receiving party will accept XML stanzas over the stream.
The following examples show a possible flow of stream negotiation between a client and a server, using the required flag for all but one of the features and following the order specified in &xep0170;. (This example is more verbose than a typical stream negotiation flow, but is provided here for the sake of completeness.)
As specified in RFC 3920, support for the server dialback protocol is currently adverised through inclusion of a dialback namespace prefix in the stream header:
+As specified in &rfc3920;, support for the server dialback protocol is currently adverised through inclusion of a dialback namespace prefix in the stream header:
The improvements described herein do not introduce any new security concerns above and beyond those defined in RFC 3920.
+The improvements described herein do not introduce any new security concerns above and beyond those defined in &rfc3920;.
No interaction with &IANA; is required as a result of this document.
diff --git a/xep-0193.xml b/xep-0193.xml index ff065ad91..1588d8701 100644 --- a/xep-0193.xml +++ b/xep-0193.xml @@ -71,7 +71,7 @@RFC 3920 introduced the concept of binding a resource to an XML stream (this concept superseded part of the obsolete jabber:iq:auth protocol described in &xep0078;). As defined in RFC 3920, resource binding enables a client to bind one resource to a stream but does not enable a client to unbind a resource and leaves underspecified what a server and client should do if a client binds more than one resource to a stream. Because the ability to bind multiple resources to a stream is desirable in certain environments (e.g., for devices that are unable to open more than one TCP connection or when a machine runs a daemon process that is used by multiple applications), this document proposes improvements to resource binding in order to address these shortcomings.
+&rfc3920; introduced the concept of binding a resource to an XML stream (this concept superseded part of the obsolete jabber:iq:auth protocol described in &xep0078;). As defined in RFC 3920, resource binding enables a client to bind one resource to a stream but does not enable a client to unbind a resource and leaves underspecified what a server and client should do if a client binds more than one resource to a stream. Because the ability to bind multiple resources to a stream is desirable in certain environments (e.g., for devices that are unable to open more than one TCP connection or when a machine runs a daemon process that is used by multiple applications), this document proposes improvements to resource binding in order to address these shortcomings.
Note: The recommendations from this document were NOT incorporated into &rfc6120; and this document is Obsolete.
When a client binds multiple resources to the same stream, proper management of 'from' addresses is imperative. In particular, a client MUST specify a 'from' address on every stanza it sends over a stream to which it has bound multiple resources, where the 'from' address is the full JID &LOCALFULL; associated with the relevant resource. If a client does not specify a 'from' address on a stanza it sends over a stream to which it has bound multiple resources (or if it specifies as the 'from' address a full JID other than one of the bound resources), the server MUST return the stanza to the client with an <unknown-sender/> stanza error.
Naturally, the existing rules from RFC 3920 regarding validation of asserted 'from' addresses still apply.
+When a client binds multiple resources to the same stream, proper management of 'from' addresses is imperative. In particular, a client MUST specify a 'from' address on every stanza it sends over a stream to which it has bound multiple resources, where the 'from' address is the full JID &LOCALFULL; associated with the relevant resource. If a client does not specify a 'from' address on a stanza it sends over a stream to which it has bound multiple resources (or if it specifies as the 'from' address a full JID other than one of the bound resources), the server MUST return the stanza to the client with an <unknown-sender/> stanza error.
Naturally, the existing rules from &rfc3920; regarding validation of asserted 'from' addresses still apply.
In instant messaging and presence applications, an XMPP server manages a session on behalf of a connected client. A server MUST create and manage a separate session for each distinct resource, even if there are multiple resources associated with a given XML stream. In particular:
If the server does not allow entities to bind multiple resources to the stream, it MUST return a ¬allowed; error as described in RFC 3920.
+If the server does not allow entities to bind multiple resources to the stream, it MUST return a ¬allowed; error as described in &rfc3920;.
Now the client sends more stanzas.
If properly implemented, the modifications described herein do not introduce any new security concerns above and beyond those defined in RFC 3920. However, care must be taken to properly manage 'from' addresses in order to avoid the delivery of stanzas from an unintended resource (which may, for example, leak presence information).
+If properly implemented, the modifications described herein do not introduce any new security concerns above and beyond those defined in &rfc3920;. However, care must be taken to properly manage 'from' addresses in order to avoid the delivery of stanzas from an unintended resource (which may, for example, leak presence information).
No interaction with &IANA; is required as a result of this document.
diff --git a/xep-0198.xml b/xep-0198.xml index d2a3342a4..c4544f301 100644 --- a/xep-0198.xml +++ b/xep-0198.xml @@ -235,8 +235,8 @@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 RFC 6120) 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 RFC 6120), &xep0199;, or TCP keepalives. By contrast 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 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 &rfc6120;) 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 &rfc6120;), &xep0199;, or TCP keepalives. By contrast 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.
Note: Stream Management can be used for server-to-server streams as well as for client-to-server streams. However, for convenience this specification discusses client-to-server streams only. The same principles apply to server-to-server streams.
The <enabled/> element MAY include a 'max' attribute to specify the server's preferred maximum resumption time.
-The <enabled/> element MAY include a 'location' attribute to specify the server's preferred IP address or hostname (optionally with a port) for reconnection, in the form specified in Section 4.9.3.19 of RFC 6120 (i.e., "domainpart:port", where IPv6 addresses are enclosed in square brackets "[...]" as described in &rfc5952;); if reconnection to that location fails, the standard XMPP connection algorithm specified in RFC 6120 applies.
+The <enabled/> element MAY include a 'location' attribute to specify the server's preferred IP address or hostname (optionally with a port) for reconnection, in the form specified in Section 4.9.3.19 of &rfc6120; (i.e., "domainpart:port", where IPv6 addresses are enclosed in square brackets "[...]" as described in &rfc5952;); if reconnection to that location fails, the standard XMPP connection algorithm specified in RFC 6120 applies.
The client MUST NOT attempt to negotiate stream management until it is authenticated; i.e., it MUST NOT send an <enable/> element until after authentication (such as SASL, &xep0078; or &xep0220;) has been completed successfully.
For client-to-server connections, the client MUST NOT attempt to enable stream management until after it has completed Resource Binding unless it is resuming a previous session (see Resumption).
The server SHALL enforce this order and return a <failed/> element in response if the order is violated (see Error Handling).
@@ -392,7 +392,7 @@Note: The order of events might differ from those shown above, depending on when the server offers the SM feature, whether the client chooses STARTTLS, etc. Furthermore, in practice server-to-server streams often do not complete SASL negotiation or even TLS negotiation. The foregoing text does not modify any rules about the stream negotiation process specified in RFC 6120. However, since stream management applies to the exchange of stanzas (not any other XML elements), it makes sense for the server to offer the SM feature when it will be possible for the other party to start sending stanzas, not before. See also &xep0170;.
+Note: The order of events might differ from those shown above, depending on when the server offers the SM feature, whether the client chooses STARTTLS, etc. Furthermore, in practice server-to-server streams often do not complete SASL negotiation or even TLS negotiation. The foregoing text does not modify any rules about the stream negotiation process specified in &rfc6120;. However, since stream management applies to the exchange of stanzas (not any other XML elements), it makes sense for the server to offer the SM feature when it will be possible for the other party to start sending stanzas, not before. See also &xep0170;.
To request resumption of the former stream, the client sends a <resume/> element qualified by the 'urn:xmpp:sm:3' namespace. The <resume/> element MUST include a 'previd' attribute whose value is the SM-ID of the former stream and MUST include an 'h' attribute that identifies the sequence number of the last handled stanza sent over the former stream from the server to the client (in the unlikely case that the client never received any stanzas, it would set 'h' to zero).
If an error occurs with regard to an <enable/> or <resume/> element, the server MUST return a <failed/> element. This element SHOULD contain an error condition, which MUST be one of the stanza error conditions defined in RFC 6120.
+If an error occurs with regard to an <enable/> or <resume/> element, the server MUST return a <failed/> element. This element SHOULD contain an error condition, which MUST be one of the stanza error conditions defined in &rfc6120;.
An example follows.
The other error conditions defined in RFC 6120 could also be returned if appropriate.
+The other error conditions defined in &rfc6120; 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.
@@ -139,7 +139,7 @@ ]]> -The other error conditions defined in RFC 6120 could also be returned if appropriate.
+The other error conditions defined in &rfc6120; 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.
@@ -161,7 +161,7 @@ ]]> -The other error conditions defined in RFC 6120 could also be returned if appropriate.
+The other error conditions defined in &rfc6120; could also be returned if appropriate.
Pings can also be used for client-to-client (i.e., end-to-end) pings.
@@ -193,7 +193,7 @@ ]]> -The other error conditions defined in RFC 6120 could also be returned if appropriate.
+The other error conditions defined in &rfc6120; 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.
@@ -213,7 +213,7 @@ id='comp1' type='result'/> ]]> -If the pinged entity does not support the ping namespace, RFC 6120 requires it to return a &unavailable; error:
+If the pinged entity does not support the ping namespace, &rfc6120; requires it to return a &unavailable; error:
The other error conditions defined in RFC 6120 could also be returned if appropriate.
+The other error conditions defined in &rfc6120; could also be returned if appropriate.
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.
+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, &rfc6120; 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.
Several security considerations related to XMPP threads are described in RFC 6121.
+Several security considerations related to XMPP threads are described in &rfc6121;.
This document requires no interaction with &IANA;.
diff --git a/xep-0202.xml b/xep-0202.xml index d9f85b557..0f0483cd8 100644 --- a/xep-0202.xml +++ b/xep-0202.xml @@ -73,12 +73,12 @@Although the XMPP protocol extension defined in &xep0090; provides a way to discover the time at another entity, it has several limitations:
The 'jabber:iq:time' namespace specified in XEP-0090 requires communication of time only in UTC. While this is useful for UTC synchronization (e.g., if a client wants to synchronize with its server), it does not enable one entity to know the other entity's offset from UTC.
The 'jabber:iq:time' namespace specified in &xep0090; requires communication of time only in UTC. While this is useful for UTC synchronization (e.g., if a client wants to synchronize with its server), it does not enable one entity to know the other entity's offset from UTC.
The timezone may be specified in a natural language (English) name via the <tz/> element, but not in a numeric offest. The name may be not understood by the requesting entity since there is no reliable and canonical list of timezone names
The responding entity may provide a user-friendly datetime format via the <display/> element, but this too is effectively useless since datetime formats vary widely by culture and nation.
The 'jabber:iq:time' namespace specified in XEP-0090 (first developed in 1999 or 2000) is not consistent with the recommended date and time profiles for XMPP protocols defined in &xep0082; (written in 2003).
The 'jabber:iq:time' namespace specified in &xep0090; (first developed in 1999 or 2000) is not consistent with the recommended date and time profiles for XMPP protocols defined in &xep0082; (written in 2003).
To overcome these limitations, this document defines a replacement for XEP-0090 which enables communication of an entity's UTC time and numeric time zone offset while adhering to XEP-0082.
+To overcome these limitations, this document defines a replacement for &xep0090; which enables communication of an entity's UTC time and numeric time zone offset while adhering to XEP-0082.
The protocol defined herein provides a standard way for XMPP entities to exchange information about the local time. The information is communicated in a request/response pair using an &IQ; element that contains a <time/> element qualified by the 'urn:xmpp:time' namespace. The following children of the <time/> element are defined for use in IQ stanzas of type 'result':
@@ -90,12 +90,12 @@This protocol was designed in a way that makes migration from XEP-0090 straightforward. This document specifies a different format for the XML character data of the <utc> element (compliant with XEP-0082) and specifies a new <tzo> element for the numeric offset from UTC, while removing the formerly optional and effectively useless <display/> and <tz/> elements.
-Implementations that support XEP-0090 should support the protocol defined herein as soon as possible, but should continue to support the protocol defined in XEP-0090 for backwards compatibility until the status of that specification is changed to Obsolete.
+This protocol was designed in a way that makes migration from &xep0090; straightforward. This document specifies a different format for the XML character data of the <utc> element (compliant with XEP-0082) and specifies a new <tzo> element for the numeric offset from UTC, while removing the formerly optional and effectively useless <display/> and <tz/> elements.
+Implementations that support &xep0090; should support the protocol defined herein as soon as possible, but should continue to support the protocol defined in XEP-0090 for backwards compatibility until the status of that specification is changed to Obsolete.
Revealing an entity's numeric time zone offset may leak limited information about the entity's current location. If the entity's understanding of UTC is far off from actual UTC, revealing that discrepancy may make it possible for an attacker to send XML stanzas that appear to be in the past or future even though they are not; therefore an entity should use the Network Time Protocol (&rfc0958;) or a similar technology to stay synchronized with actual UTC.
diff --git a/xep-0203.xml b/xep-0203.xml index 6b706cd71..2b29bb74d 100644 --- a/xep-0203.xml +++ b/xep-0203.xml @@ -65,7 +65,7 @@Although the XMPP protocol extension defined in &xep0091; provides a way to communicate that an XML stanza (typically a &MESSAGE; or &PRESENCE; stanza) has been delivered with a delay, the timestamp format defined in that document does not adhere to the recommended date and time profiles for XMPP protocols defined in &xep0082;. Therefore, this document defines a replacement for XEP-0091 which enables communication of delayed delivery information while adhering to XEP-0082.
+Although the XMPP protocol extension defined in &xep0091; provides a way to communicate that an XML stanza (typically a &MESSAGE; or &PRESENCE; stanza) has been delivered with a delay, the timestamp format defined in that document does not adhere to the recommended date and time profiles for XMPP protocols defined in &xep0082;. Therefore, this document defines a replacement for &xep0091; which enables communication of delayed delivery information while adhering to XEP-0082.
The XML namespace defined herein is used to provide timestamp information about data stored for later delivery. The most common uses of this namespace are to stamp:
@@ -88,7 +88,7 @@This protocol was designed in a way that makes migration from XEP-0091 straightforward. All attributes present in the 'jabber:x:delay' namespace are present in the namespace defined herein. However, this document specifies a different format for the value of the <stamp> attribute (compliant with XEP-0082).
-Implementations that support XEP-0091 should support the protocol defined herein as soon as possible, but should continue to support the protocol defined in XEP-0091 for backwards compatibility until the status of that specification is changed to Obsolete.
+This protocol was designed in a way that makes migration from &xep0091; straightforward. All attributes present in the 'jabber:x:delay' namespace are present in the namespace defined herein. However, this document specifies a different format for the value of the <stamp> attribute (compliant with XEP-0082).
+Implementations that support &xep0091; should support the protocol defined herein as soon as possible, but should continue to support the protocol defined in XEP-0091 for backwards compatibility until the status of that specification is changed to Obsolete.
Delayed delivery data can expose information about the sender's presence on the network at some time in the past. However, this introduces no new vulnerabilities, since the same information would have been available in real time.
diff --git a/xep-0205.xml b/xep-0205.xml index 2d298c9c7..d37cd538e 100644 --- a/xep-0205.xml +++ b/xep-0205.xml @@ -74,7 +74,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 (&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:
+&rfc4732; defines denial of service as follows:
A Denial-of-Service (DoS) attack is an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work. The victim can be a network server, client or router, a network link or an entire network, an individual Internet user or a company doing business using the Internet, an Internet Service Provider (ISP), country, or any combination of or variant on these.
The authors list a number of attacks, of which the following seem most likely against XMPP systems:
Numerous potential solutions have been suggested to deal with the threat of denial of service attacks against XMPP servers, including the following:
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).
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).
Limiting the number of connection attempts (via the TCP binding specified in &rfc6120; 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).
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.
Disallowing unauthenticated connections from clients and from peer servers; as mentioned below, this is required by RFC 6120.
Disallowing unauthenticated connections from clients and from peer servers; as mentioned below, this is required by &rfc6120;.
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.
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).
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".
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 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.
+In accordance with &rfc6120;, 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.
@@ -180,7 +180,7 @@An implementation of a service that enables traffic amplification (e.g., multi-user chat or publish-subscribe) SHOULD enable an administrator of that service to limit (based on JabberID or other characteristics) what entities may send information through the service. (See XEP-0045 regarding methods of banning users from multi-user chat rooms and XEP-0060 regarding methods for prohibiting users from interacting with publish-subscribe nodes.)
+An implementation of a service that enables traffic amplification (e.g., multi-user chat or publish-subscribe) SHOULD enable an administrator of that service to limit (based on JabberID or other characteristics) what entities may send information through the service. (See &xep0045; regarding methods of banning users from multi-user chat rooms and XEP-0060 regarding methods for prohibiting users from interacting with publish-subscribe nodes.)
In fact, the "session manager" of an XMPP presence server also acts as just such an amplifier, since presence information is broadcast to all subscribers. Any such service SHOULD enable an administrator to limit the number of stanzas sent through the service in any given period of time (presence changes in a session manager, presence changes or messages in a chatroom, published items in a pubsub service).
Jabber technologies as invented by Jeremie Miller started out as a relatively lightweight XML messaging transport, but they have become unnecessarily -- even ridiculously -- bloated over the years. Formalization of the core Jabber protocols as the Extensible Messaging and Presence Protocol (XMPP) within the IETF seemed like a good idea at the time, but the extensible nature of the core protocols has tempted the developer community to extend XMPP six ways from Sunday. The result has been a plethora of different conceptual models for various extensions, such as &xep0045; for multi-user communication and &xep0050; for structured entity-to-entity request/response semantics. These different models are inelegant and unnecessary. Indeed, even the inclusion of three different basic packet types (presence, message, and IQ) in the core protocol is overkill.
-We can do better. In fact, we can reduce all the communication types and styles that are currently defined within the XMPP ecosystem to one model: publish-subscribe as specified in XEP-0060.
+We can do better. In fact, we can reduce all the communication types and styles that are currently defined within the XMPP ecosystem to one model: publish-subscribe as specified in &xep0060;.
Consider:
Because XMPP Eventing via Pubsub simply reuses the protocol specified in XEP-0060, a separate schema is not needed.
+Because XMPP Eventing via Pubsub simply reuses the protocol specified in &xep0060;, a separate schema is not needed.
In order to initiate a Jingle session, the initiator must determine which of the responder's XMPP resources is best for the desired application format. The following approach may be helpful to implementors:
If the intended responder shares presence with the initiator (see &xmppim;) and has only one available resource, the initiator SHOULD attempt to negotiate a Jingle session with that resource unless the initiator knows via &xep0030; or &xep0115; that the resource does not support Jingle and the desired application format.
If the intended responder shares presence with the initiator (see &xmppim;) and has only one available resource, the initiator SHOULD attempt to negotiate a Jingle session with that resource unless the initiator knows via &xep0030; or &xep0115; that the resource does not support Jingle and the desired application format.
If the intended responder shares presence with the initiator and has more than one available resource but only one of the resources supports Jingle and the desired application format, the initiator SHOULD initiate the Jingle session with that resource.
If the intended responder shares presence with the initiator and has more than one available resource but more than one of the resources supports Jingle and the desired application format, the initiator SHOULD use &xep0168; in order to determine which is the best resource with which to initiate the desired Jingle session.
If the intended responder does not share presence with the initiator, the initiator SHOULD first send a &xep0155; request to the responder in order to initiate the exchange of XMPP stanzas. The request SHOULD include a RAP routing hint as specified in XEP-0168 and the &MESSAGE; stanza containing the request SHOULD be of type "headline" so that (typically) it is not stored offline for later delivery. The stanza session negotiation SHOULD result in temporary sharing of presence between the parties via the "presence" field as described in XEP-0155.
If the intended responder does not share presence with the initiator, the initiator SHOULD first send a &xep0155; request to the responder in order to initiate the exchange of XMPP stanzas. The request SHOULD include a RAP routing hint as specified in &xep0168; and the &MESSAGE; stanza containing the request SHOULD be of type "headline" so that (typically) it is not stored offline for later delivery. The stanza session negotiation SHOULD result in temporary sharing of presence between the parties via the "presence" field as described in XEP-0155.
If none of the errors specified in XEP-0166 occurs, the responder acknowledges the session initiation request.
+If none of the errors specified in &xep0166; occurs, the responder acknowledges the session initiation request.
If no negotiation is required (e.g., to modify the port number or transport method), the responder simply accepts the session. (Alternatively, if the responder wants to use a port other 17777, it SHOULD negotiate the port using a Jingle content-modify action; see XEP-0166 for details and examples.)
+If no negotiation is required (e.g., to modify the port number or transport method), the responder simply accepts the session. (Alternatively, if the responder wants to use a port other 17777, it SHOULD negotiate the port using a Jingle content-modify action; see &xep0166; for details and examples.)
Existing approaches to encryption of XMPP communications have generally assumed that each stanza to be encrypted is a standalone storeable object; the term "object encryption" well captures this assumption. Both &xep0027; and &rfc3923; assume that no interactive session exists, and that XMPP communications are similar to the exchange of files or email messages - where the receiver is typically not connected to its server at the time the message is sent. Although Current Jabber OpenPGP Usage uses "old-style" PGP object encryption and RFC 3923 uses "new-style" S/MIME object encryption, both specify the use of object encryption. Any new protocol based on &w3xmlenc; and &w3xmlsig;, would also be an "object encryption" protocol.
+Existing approaches to encryption of XMPP communications have generally assumed that each stanza to be encrypted is a standalone storeable object; the term "object encryption" well captures this assumption. Both &xep0027; and &rfc3923; assume that no interactive session exists, and that XMPP communications are similar to the exchange of files or email messages - where the receiver is typically not connected to its server at the time the message is sent. Although Current Jabber OpenPGP Usage uses "old-style" PGP object encryption and &rfc3923; uses "new-style" S/MIME object encryption, both specify the use of object encryption. Any new protocol based on &w3xmlenc; and &w3xmlsig;, would also be an "object encryption" protocol.
However, encryption schemes that are appropriate for less dynamic Internet technologies are not appropriate for session-oriented communication technologies like XMPP. With XMPP the receiver is typically connected to its server at the time the message is sent, so XMPP can take advantage of much more secure session-oriented approaches to encryption - approaches that are not feasible for less dynamic technologies like email. Most importantly, XMPP can benefit from Perfect Forward Secrecy and Identity Protection.
Therefore, for XMPP, the focus should be on "session encryption" rather than "object encryption". The paradigm should be something closer to the widely-deployed Secure Shell technology (see &rfc4253;) or &rfc6189; (an acclaimed SRTP - &rfc3711; - key agreement protocol) or TLS (see &rfc5246;) or IPsec (see &rfc4301;) than to the traditional encryption of files and email messages.
The session metaphor applies to communication between any two XMPP endpoints. For instance, in IM applications, most instant messaging exchanges occur in bursts within limited time periods (e.g., two people may send a fairly large number of messages during a five-minute chat and then not exchange messages again for hours or even days). The XML stanzas exchanged during such a session may not be limited to &MESSAGE; stanzas; for instance, the session may be triggered by a change in one of the parties' presence status (e.g., changing from away to available) and the session may involve the exchange of &IQ; stanzas (e.g., to transfer a file as specified in &xep0096;).
diff --git a/xep-0217.xml b/xep-0217.xml index e25207bb7..7035bc769 100644 --- a/xep-0217.xml +++ b/xep-0217.xml @@ -68,7 +68,7 @@Before attempting to engage in an ESession with Bob, Alice MAY discover whether he supports this protocol, using either &xep0030; or the presence-based profile of XEP-0030 specified in &xep0115;.
+Before attempting to engage in an ESession with Bob, Alice MAY discover whether he supports this protocol, using either &xep0030; or the presence-based profile of &xep0030; specified in &xep0115;.
The disco#info request sent from Alice to Bob might look as follows:
&xep0188;
-Strictly speaking, a developer does not implement this specification, since it describes the theory behind the process of upgrading from cleartext to encryption that is defined in XEP-0116. However it is useful background knowledge for developers who implement XEP-0116.
+Strictly speaking, a developer does not implement this specification, since it describes the theory behind the process of upgrading from cleartext to encryption that is defined in &xep0116;. However it is useful background knowledge for developers who implement XEP-0116.
Naturally, when developing from the library/API level up to the client/interface level, the order should be (roughly) reversed.
diff --git a/xep-0219.xml b/xep-0219.xml index b1832a2b0..ebdfaea28 100644 --- a/xep-0219.xml +++ b/xep-0219.xml @@ -184,7 +184,7 @@Since October 2000, the use of Server Dialback (even absent DNSSEC) has made it more difficult to spoof the hostnames of servers (and therefore the addresses of sent messages) on the XMPP network.
Server Dialback is unidirectional, and results in verification for one XML stream in one direction. Because traditionally Server-to-Server connections are used unidirectionally, Server Dialback needs to be completed in each direction in order to enable bidirectional communication between two domains (unless &xep0288; is used).
Furthermore, because a separate TCP connection is mandated for each domain pair, the use of server dialback results in significant scalability challenges for large XMPP service providers that host many domains (see &rfc7712; for a possible solution).
-Finally, dialback signalling can be used without basing the identity verification on checking of the dialback key provided by the Initiating Server. As one example, if Transport Layer Security (TLS) is used then the Receiving Server can attempt to verify the certificate presented by the Initiating Server, either according to the PKIX-based rules specified in &xep0178;, RFC 6120, and &rfc6125; or by checking that the public key or certificate of the Initiating Server matches a public key or certificate obtained via &posh;. However, this technique of using dialback signalling without verifying the dialback key (sometimes called "dialback without dialing back" since the Receiving Server does not contact the Authoritative Server) is not described in this document.
+Finally, dialback signalling can be used without basing the identity verification on checking of the dialback key provided by the Initiating Server. As one example, if Transport Layer Security (TLS) is used then the Receiving Server can attempt to verify the certificate presented by the Initiating Server, either according to the PKIX-based rules specified in &xep0178;, &rfc6120;, and &rfc6125; or by checking that the public key or certificate of the Initiating Server matches a public key or certificate obtained via &posh;. However, this technique of using dialback signalling without verifying the dialback key (sometimes called "dialback without dialing back" since the Receiving Server does not contact the Authoritative Server) is not described in this document.
Note that, unless XEP-0288 is used, the 'type' should not be set on either <db:result/> or <db:verify/> elements received on an inbound connection.
+Note that, unless &xep0288; is used, the 'type' should not be set on either <db:result/> or <db:verify/> elements received on an inbound connection.
This subsection describes the interaction between the server hosting capulet.example (acting as an Initiating Server) and the server hosting montague.net (acting as a Receiving Server), from the inbound perspective of the Receiving Server (i.e., this section is the mirror image of Section 2.1.1).
@@ -505,7 +505,7 @@ recv:Before the Receiving Server allows the Initiating Server to send stanzas from the Sender Domain (here "capulet.example") to the Target Domain (here "montague.example"), it MUST verify the identity of the Initiating Server. Depending on how the server dialback protocol is used, this can be done by verifying the dialback key or by using some out-of-band method as in the POSH prooftype for XMPP domain name associations. Note that the verification process might fail prematurely, for example, if the Receiving Server's policy states that connections from the Initiating Server or the Sender Domain are not allowed.
Note: The Receiving Server MUST continue to accept and process stanzas for already verified domain pairs, and MUST continue to process both <db:result/> and <db:verify/> elements.
-If the Target Domain as given in the 'to' attribute of the element is not a configured domain of the Receiving Server, this results in a dialback error. This error, which is explained further under Section 2.4.2, is not a stream error and therefore MUST NOT result in closing of the stream as described in Section 4.4 of RFC 6120, since the stream might already be used to exchange XML stanzas for other domain pairs.
+If the Target Domain as given in the 'to' attribute of the element is not a configured domain of the Receiving Server, this results in a dialback error. This error, which is explained further under Section 2.4.2, is not a stream error and therefore MUST NOT result in closing of the stream as described in Section 4.4 of &rfc6120;, since the stream might already be used to exchange XML stanzas for other domain pairs.
If the Target Domain as given in the 'to' attribute of the element does not match a configured local domain according to the Authoritative Server, this results in a dialback error. This error, which is explained further under Section 2.4, is not a stream error and therefore MUST NOT result in closing of the stream (as described in Section 4.4 of RFC 6120), since the stream might already be used for sending XML stanzas for other domain pairs. (The following example is the same as Example 8.)
+If the Target Domain as given in the 'to' attribute of the element does not match a configured local domain according to the Authoritative Server, this results in a dialback error. This error, which is explained further under Section 2.4, is not a stream error and therefore MUST NOT result in closing of the stream (as described in Section 4.4 of &rfc6120;), since the stream might already be used for sending XML stanzas for other domain pairs. (The following example is the same as Example 8.)
The result of the protocol exchanges shown in the foregoing two sections is that the server hosting montague.example has verified the identity of the server hosting capulet.example. Since XMPP Server-to-Server connections are unidirectional (unless XEP-0288 is used), dialback needs to be completed in each direction before XML stanzas can be exchanged over the two TCP connections between the servers.
+The result of the protocol exchanges shown in the foregoing two sections is that the server hosting montague.example has verified the identity of the server hosting capulet.example. Since XMPP Server-to-Server connections are unidirectional (unless &xep0288; is used), dialback needs to be completed in each direction before XML stanzas can be exchanged over the two TCP connections between the servers.
Support for the traditional server dialback protocol (originally specified in RFC 3920) is indicated by inclusion of the dialback namespace declaration in the stream header.
+Support for the traditional server dialback protocol (originally specified in &rfc3920;) is indicated by inclusion of the dialback namespace declaration in the stream header.
Note: Although in general advertising protocol support by means of an XML namespace declaration has been superseded by the use of stream features as originally defined in RFC 3920 and updated in RFC 6120, the server dialback protocol predates the existence of stream features and therefore the namespace declaration method is still used in this instance.
+Note: Although in general advertising protocol support by means of an XML namespace declaration has been superseded by the use of stream features as originally defined in &rfc3920; and updated in RFC 6120, the server dialback protocol predates the existence of stream features and therefore the namespace declaration method is still used in this instance.
Note: It is conventional to use a namespace prefix of "db" for Server Dialback elements. Although the prefix is allowed to be other than "db" according to the XML namespaces specification (&w3xmlnamespaces;), some existing implementations and deployments might accept only the "db" prefix.
RFC 3920 introduced stream errors for any errors related to dialback. However, this turned out to be overly aggressive, particularly if the XML stream was used to multiplex stanzas for more than one domain pair (since closing the stream would result in throwing away accumulated dialback state for a potentially large number of domain pairs). Therefore this specification defines a third value for the 'type' attribute: "error".
-This usage of the 'error' value for the 'type' attribute is not fully backward compatible with RFC 3920. However, the server that generates the error SHOULD still attempt to send the dialback error instead of terminating the stream, as the worst thing that can happen is that the remote server terminates the stream if it does not understand the error or if it eventually times out the connection. Dialback errors are to be considered non-fatal for the XML stream, but the Initiating Server MUST return queued stanzas to the respective senders with a &timeout; stanza error. If an error is encountered in Step 3 of the dialback negotiation, the Receiving Server MUST send a <remote-server-not-found/> dialback error to the Initiating Server.
+&rfc3920; introduced stream errors for any errors related to dialback. However, this turned out to be overly aggressive, particularly if the XML stream was used to multiplex stanzas for more than one domain pair (since closing the stream would result in throwing away accumulated dialback state for a potentially large number of domain pairs). Therefore this specification defines a third value for the 'type' attribute: "error".
+This usage of the 'error' value for the 'type' attribute is not fully backward compatible with &rfc3920;. However, the server that generates the error SHOULD still attempt to send the dialback error instead of terminating the stream, as the worst thing that can happen is that the remote server terminates the stream if it does not understand the error or if it eventually times out the connection. Dialback errors are to be considered non-fatal for the XML stream, but the Initiating Server MUST return queued stanzas to the respective senders with a &timeout; stanza error. If an error is encountered in Step 3 of the dialback negotiation, the Receiving Server MUST send a <remote-server-not-found/> dialback error to the Initiating Server.
When the <db:verify/> or <db:result/> element is of type "error", the element MUST contain an <error/> element (implicitly qualified by the 'jabber:server' namespace), which MUST in turn contain an XML element qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace (i.e., a stanza error condition) as those errors are defined in RFC 6120. The following table provides additional guidance regarding the most relevant stanza error conditions:
&constraint; | -The Receiving Server lacks the resources to add the requested domain pair to the list of connections authorized for this connection. The initiating server should attempt to establish a new TCP connection to the target domain using the process described in RFC 6120 and give up when receiving the same error on the new connection. | +The Receiving Server lacks the resources to add the requested domain pair to the list of connections authorized for this connection. The initiating server should attempt to establish a new TCP connection to the target domain using the process described in &rfc6120; and give up when receiving the same error on the new connection. | Step 4 |
Server Dialback helps protect against domain spoofing, thus making it difficult to spoof the origin of XML stanzas. Absent the use of DNS security (DNSSEC, RFC 4033), Server Dialback does not provide a mechanism for authenticating a stream, as is done via TLS and SASL, and results in weak verification of server identities only. Furthermore, if DNSSEC is not used then it is susceptible to DNS poisoning attacks.
+Server Dialback helps protect against domain spoofing, thus making it difficult to spoof the origin of XML stanzas. Absent the use of DNS security (DNSSEC, &rfc4033;), Server Dialback does not provide a mechanism for authenticating a stream, as is done via TLS and SASL, and results in weak verification of server identities only. Furthermore, if DNSSEC is not used then it is susceptible to DNS poisoning attacks.
If DNSSEC is used, Server Dialback provides stream authentication only (i.e., a strong association between a domain name and an XML stream). However, Server Dialback by itself does not provide confidentiality, data integrity, or stream encryption. Some existing implementations are known to support dialback over TLS. In this case, Server Dialback is typically carried out the same way as without TLS, but gains from the use of channel encryption.
In mid-2012, several implementations turned out to be vulnerable to a number of attacks against the protocol described in this document. These attacks were based on sending verify (STEP 3) or result (STEP 4) responses without an associated request, in an unexpected direction and/or on an unexpected XML stream. Failure to reject those 'unsolicited' responses lets an attacker either spoof stanzas with an arbitrary sender domain or enables him to impersonate any target domain.
diff --git a/xep-0221.xml b/xep-0221.xml index 8f4d4d912..45a8255d5 100644 --- a/xep-0221.xml +++ b/xep-0221.xml @@ -93,7 +93,7 @@ ]]>The cid: URI points to data that can be retrieved using the protocol described in &xep0231; and the data element would be included along with the XMPP stanza containing the data form.
-The following example is provided only for the purpose of illustration; consult the specifications for using protocols (e.g., XEP-0158) to see canonical examples.
+The following example is provided only for the purpose of illustration; consult the specifications for using protocols (e.g., &xep0158;) to see canonical examples.
The best practices described herein re-use the concepts already defined in XEP-0060 and XEP-0163. In order to optimize for object persistence instead of transient event notifications, a node MUST be configured as follows:
+The best practices described herein re-use the concepts already defined in &xep0060; and XEP-0163. In order to optimize for object persistence instead of transient event notifications, a node MUST be configured as follows:
The access model MAY be any model defined in XEP-0060.
+The access model MAY be any model defined in &xep0060;.
An account owner publishes an item to a node by following the protocol specified in XEP-0060:
+An account owner publishes an item to a node by following the protocol specified in &xep0060;:
If the node does not already exist, the virtual pubsub service MUST create the node. As described in XEP-0163, this "auto-create" feature (defined in XEP-0060) MUST be supported by a PEP service. (Naturally, the account owner's client MAY follow the node creation use case specified in XEP-0060 before attempting to publish an item.)
-In order for the client to reliably persist objects, the virtual pubsub service must also support the "publish-options" feature defined in XEP-0060. Typically, a client will publish with options so that the object is properly persisted.
+If the node does not already exist, the virtual pubsub service MUST create the node. As described in &xep0163;, this "auto-create" feature (defined in XEP-0060) MUST be supported by a PEP service. (Naturally, the account owner's client MAY follow the node creation use case specified in XEP-0060 before attempting to publish an item.)
+In order for the client to reliably persist objects, the virtual pubsub service must also support the "publish-options" feature defined in &xep0060;. Typically, a client will publish with options so that the object is properly persisted.
If the publication logic dictates that event notifications shall be sent, the account owner's server generates notifications and sends them to all appropriate entities as described in the Receiving Event Notifications section of XEP-0163.
+If the publication logic dictates that event notifications shall be sent, the account owner's server generates notifications and sends them to all appropriate entities as described in the Receiving Event Notifications section of &xep0163;.
This document introduces no security considerations above and beyond those specified in XEP-0060 and XEP-0163.
+This document introduces no security considerations above and beyond those specified in &xep0060; and XEP-0163.
The best practices defined herein re-use the concepts already defined in XEP-0060 and XEP-0163. In order to optimize for object persistence of private information instead of transient event notifications related to semi-public data, a node MUST be configured as follows:
+The best practices defined herein re-use the concepts already defined in &xep0060; and XEP-0163. In order to optimize for object persistence of private information instead of transient event notifications related to semi-public data, a node MUST be configured as follows:
An account owner publishes an item to a node by following the protocol specified in XEP-0060:
+An account owner publishes an item to a node by following the protocol specified in &xep0060;:
If the node does not already exist, the virtual pubsub service MUST create the node. As described in XEP-0163, this "auto-create" feature (defined in XEP-0060) MUST be supported by a PEP service. (Naturally, the account owner's client MAY follow the node creation use case specified in XEP-0060 before attempting to publish an item.)
-In order for the client to reliably persist private information, the virtual pubsub service must also support the "publish-options" feature defined in XEP-0060. Typically, a client will publish with options so that the object is privately stored.
+If the node does not already exist, the virtual pubsub service MUST create the node. As described in &xep0163;, this "auto-create" feature (defined in XEP-0060) MUST be supported by a PEP service. (Naturally, the account owner's client MAY follow the node creation use case specified in XEP-0060 before attempting to publish an item.)
+In order for the client to reliably persist private information, the virtual pubsub service must also support the "publish-options" feature defined in &xep0060;. Typically, a client will publish with options so that the object is privately stored.
If the publication logic dictates that event notifications shall be sent, the account owner's server generates notifications and sends them to all appropriate entities as described in the Receiving Event Notifications section of XEP-0163.
+If the publication logic dictates that event notifications shall be sent, the account owner's server generates notifications and sends them to all appropriate entities as described in the Receiving Event Notifications section of &xep0163;.
Since private data is to be stored in a mechanism originally intended to publish data, it is REQUIRED for entities to ensure that the restrictive <publish-options/> will actually be honored by the server by performing the feature discovery procedure as specified in Determining Support. If an entity using that procedure finds that the server does not support <publish-options/>, it MUST NOT store private data in PubSub, unless it can ensure privacy of the data with other means.
The configuration of a local pubsub node does not prevent an attacker or a contact with a misconfigured node from sending pubsub events with the same payload. Therefore clients MUST verify that the ‘from’ attribute on incoming event messages is either absent or equal to their own account JID.
-The Security Considerations specified in XEP-0060 and XEP-0163 need to be taken into account.
+The Security Considerations specified in &xep0060; and XEP-0163 need to be taken into account.
The protocol defined in XEP-0114 depended on use of the 'to' address in the stream header to specify the hostname of the component. By contrast, client-to-server connections use stream establishment is followed by binding of a resource to the stream (in fact multiple resources can be bound to the stream). This protocol emulates client-to-server connections by using a hostname binding process that is similar to the resource binding process specified in XMPP Core.
+The protocol defined in &xep0114; depended on use of the 'to' address in the stream header to specify the hostname of the component. By contrast, client-to-server connections use stream establishment is followed by binding of a resource to the stream (in fact multiple resources can be bound to the stream). This protocol emulates client-to-server connections by using a hostname binding process that is similar to the resource binding process specified in XMPP Core.
If a server offers component binding over a stream, it MUST advertise a feature of "urn:xmpp:component:0".
If the hostname cannot be bound, the server MUST return an IQ-error, which SHOULD be &badrequest;, &conflict;, ¬allowed;, or &constraint;, just as with client resource binding as specified in RFC 3920.
+If the hostname cannot be bound, the server MUST return an IQ-error, which SHOULD be &badrequest;, &conflict;, ¬allowed;, or &constraint;, just as with client resource binding as specified in &rfc3920;.
Note: Although the JID asserted during STARTTLS and SASL negotiation MUST be of the form <domain> (i.e., an XMPP domain identifier), the <hostname/> element MAY be of the form <domain/resource>. This form can be used for application-specific functionality (e.g., load balancing), but such functionality is out of scope for this specification.
A component can send a subsequent bind request to bind another hostname (a server MUST support binding of multiple hostnames).
This protocol improves upon the earlier component protocol defined in XEP-0114 by specifying the use of Transport Layer Security (TLS) for channel encryption and the Simple Authentication and Security Layer (SASL) for authentication. Because this protocol re-uses the XML stream establishment processes defined in XMPP Core, the security considerations from RFC 3920 and RFC 6120 apply to this protocol as well.
+This protocol improves upon the earlier component protocol defined in &xep0114; by specifying the use of Transport Layer Security (TLS) for channel encryption and the Simple Authentication and Security Layer (SASL) for authentication. Because this protocol re-uses the XML stream establishment processes defined in XMPP Core, the security considerations from RFC 3920 and RFC 6120 apply to this protocol as well.
This document requires no interaction with &IANA;.
diff --git a/xep-0229.xml b/xep-0229.xml index 5b304152c..eb92dc58b 100644 --- a/xep-0229.xml +++ b/xep-0229.xml @@ -43,7 +43,7 @@&xep0138; specifies an extensible framework for XML stream compression and defines a registry for compression methods (see &COMPRESSMETHODS;). However, XEP-0138 registers only the ZLIB method (see &rfc1950;). This document specifies usage of the LZW compression method.
+&xep0138; specifies an extensible framework for XML stream compression and defines a registry for compression methods (see &COMPRESSMETHODS;). However, &xep0138; registers only the ZLIB method (see &rfc1950;). This document specifies usage of the LZW compression method.
The initiating entity and receiving entity then MUST attempt to negotiate use of the LZW algorithm in accordance with XEP-0138.
+The initiating entity and receiving entity then MUST attempt to negotiate use of the LZW algorithm in accordance with &xep0138;.
If the use of the LZW algorithm is negotiated, the usage SHOULD follow the definition in ECMA-151.
The LZW algorithm is OPTIONAL to implement for XEP-0138 implementations and this specification does not define a mandatory-to-implement technology.
+The LZW algorithm is OPTIONAL to implement for &xep0138; implementations and this specification does not define a mandatory-to-implement technology.
It is RECOMMENDED for the recipient to cache data; however, the recipient MAY opt not to cache data, for example because it runs on a device that does not have sufficient space for data storage.
The default behavior is for the recipient to cache the data only for the life of the entity's application session (not a client's presence session with the server or the controlling user's communication session with the contact from whom the user received the data); that is, the recipient would clear the cache when the application is terminated or restarted.
-As a hint regarding the suggested period for caching the data, the sender MAY include a 'max-age' attribute whenever it sends a <data/> element. The meaning of the 'max-age' attribute exactly matches that of the Max-Age attribute from RFC 2965.
+As a hint regarding the suggested period for caching the data, the sender MAY include a 'max-age' attribute whenever it sends a <data/> element. The meaning of the 'max-age' attribute exactly matches that of the Max-Age attribute from &rfc2965;.
If it is not suggested to cache the data (e.g., because it is ephemeral), the value of the 'max-age' attribute MUST be "0" (the number zero).
A recipient SHOULD cache data based on the hash of the data as encapsulated in the cid. However, if a hash cannot be extracted from the cid, if the recipient does not support the hashing algorithm used, or the recipient does not support hashes, then the recipient SHOULD cache based on the JID of the sender.
&xep0128; defines a way for an XMPP entity to include extended information in its responses to &xep0030; information requests. This document specifies a usage of XEP-0128 whereby an XMPP entity can provide detailed data about itself in such responses. This protocol is intended to replace &xep0092; for software information discovery (thus reducing or eliminating the need for distinct software version requests) and also provides a format that can be encapsulated into &xep0115; notifications.
+&xep0128; defines a way for an XMPP entity to include extended information in its responses to &xep0030; information requests. This document specifies a usage of &xep0128; whereby an XMPP entity can provide detailed data about itself in such responses. This protocol is intended to replace &xep0092; for software information discovery (thus reducing or eliminating the need for distinct software version requests) and also provides a format that can be encapsulated into &xep0115; notifications.
The ®ISTRAR; shall include the following information in its registries.
&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and XEP-0128 describes how to use field standardization in the context of service discovery. This section registers fields for software information scoped by the "urn:xmpp:dataforms:softwareinfo" FORM_TYPE.
+&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and &xep0128; describes how to use field standardization in the context of service discovery. This section registers fields for software information scoped by the "urn:xmpp:dataforms:softwareinfo" FORM_TYPE.
urn:xmpp:dataforms:softwareinfo
diff --git a/xep-0233.xml b/xep-0233.xml
index 0931cd05b..9e86c4640 100644
--- a/xep-0233.xml
+++ b/xep-0233.xml
@@ -91,21 +91,21 @@
The Kerberos Network Authentication Service (V5) is described in &rfc4120;. An application can call the Kerberos library through the Generic Security Services Application Programming Interface (GSS-API) described in &rfc4121; or the proprietary Microsoft Windows Security Service Provider Interface (SSPI).
- The Simple Authentication and Security Layer or SASL (&rfc4422;) is a framework for adding authentication support to connection-based protocols. The SASL mechanism used in environments that make use of Kerberos V5 is called "GSSAPI" and is described in &rfc4752;. Note that the RFC 4121 API has a hyphen and the SASL mechanism does not.
+ The Simple Authentication and Security Layer or SASL (&rfc4422;) is a framework for adding authentication support to connection-based protocols. The SASL mechanism used in environments that make use of Kerberos V5 is called "GSSAPI" and is described in &rfc4752;. Note that the &rfc4121; API has a hyphen and the SASL mechanism does not.
Before using the "GSSAPI" SASL mechanism to authenticate to an XMPP server (which is referred to as the "acceptor" in Kerberos terminology), a connecting client needs to obtain a Kerberos ticket from the Key Distribution Centre (KDC). For this the client needs to determine the Kerberos principal name of the XMPP server. This scenario was not addressed in &rfc3920; or &rfc6120;.
This specification sets out the rules that must be followed when registering the Kerberos principal name of an XMPP server. It also details how a client can determine the hostname of the XMPP server which can then be used to construct the Kerberos principal name.
An XMPP client will initiate a connection to the XMPP server.
- The XMPP server will communicate its hostname in a child element of the <mechanisms/> element during SASL negotation, as allowed by RFC 6120 (see Section 6.3.5 and the schema for the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace in Appendix A.4).
+ The XMPP server will communicate its hostname in a child element of the <mechanisms/> element during SASL negotation, as allowed by &rfc6120; (see Section 6.3.5 and the schema for the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace in Appendix A.4).
This child element is <hostname/> qualified by the 'urn:xmpp:domain-based-name:1' namespace. &NSNOTE;.
The XML character data of the <hostname/> element specifies the fully-qualified name of the XMPP server. This should be used for constructing the Kerberos principal name and is independent of the usual rules that an XMPP client uses for establishing a network connection to the XMPP server which may use insecure DNS queries (also see &rfc4120;).
When the XMPP server is implemented using GSS-API, the domain-based service name (&rfc5178;, &rfc5179;) is used as the Kerberos principal name. Domain-based service names contain a domain name in addition to a hostname. This allows naming clustered servers after the domain which they service.
- The domain-based service name is mapped to the Kerberos principal name following the format specified in RFC 5179 (i.e., "service/hostname/domain@REALM") and setting the values as follows:
+ The domain-based service name is mapped to the Kerberos principal name following the format specified in &rfc5179; (i.e., "service/hostname/domain@REALM") and setting the values as follows:
- The service string MUST be "xmpp".
- The hostname string MUST be the hostname of the XMPP server, as provided by the server in the XML character data of the <hostname/> element during SASL negotiation.
@@ -116,7 +116,7 @@
Microsoft Windows provides the proprietary SSPI to support the "GSSAPI" SASL mechanism. This section describes the Windows equivalent of the domain-based service name for an XMPP server.
- In the Microsoft Windows environment, the concept of Service Principal Name (SPN) is used, which is specified in https://msdn.microsoft.com/en-us/library/ms677601%28v=vs.85%29.aspx. This format ("service class/host:port/service name") is similar to the one specified in RFC 5179. The SPN can be generated by setting the values as follows:
+ In the Microsoft Windows environment, the concept of Service Principal Name (SPN) is used, which is specified in https://msdn.microsoft.com/en-us/library/ms677601%28v=vs.85%29.aspx. This format ("service class/host:port/service name") is similar to the one specified in &rfc5179;. The SPN can be generated by setting the values as follows:
- The service class string MUST be "xmpp".
- The host string MUST be the hostname of the XMPP server, as provided by the server in the XML character data of the <hostname/> element during SASL negotiation.
@@ -151,7 +151,7 @@
- The communication of the XMPP server's hostname during SASL negotiation is not known to introduce new security vulnerabilities, as long as it is done after the underlying channel has been secured using Transport Layer Security (TLS; &rfc5246;) as described for XMPP in RFC 6120. For additional security considerations, refer to RFC 5178 and RFC 5179.
+ The communication of the XMPP server's hostname during SASL negotiation is not known to introduce new security vulnerabilities, as long as it is done after the underlying channel has been secured using Transport Layer Security (TLS; &rfc5246;) as described for XMPP in &rfc6120;. For additional security considerations, refer to RFC 5178 and RFC 5179.
diff --git a/xep-0234.xml b/xep-0234.xml
index 6e270a7fb..440d39278 100644
--- a/xep-0234.xml
+++ b/xep-0234.xml
@@ -266,7 +266,7 @@
To overcome these drawbacks, this specification defines a file transfer negotiation method that meets the following requirements:
- Use the session negotiation semantics from XEP-0166.
+ Use the session negotiation semantics from &xep0166;.
-
Use any reliable Jingle transport mechanism, including but not limited to:
@@ -275,7 +275,7 @@
- In-Band Bytestreams &xep0261;
- Define a file description format that, unlike XEP-0096, enables hash agility (via &xep0300;).
+ Define a file description format that, unlike &xep0096;, enables hash agility (via &xep0300;).
Define a clear upgrade path from SI File Transfer to Jingle File Transfer.
Note that Jingle file transfer is only as reliable as the transports on which it depends. In particular, SOCKS5 Bytestreams ("S5B") does not always result in NAT or firewall traversal. To work around that problem, this specification requires all implementations to support as a fallback mechanism In-Band Bytestreams ("IBB"), which usually results in a successful (if slow) file transfer. A more robust and adaptable option is ICE-TCP (RFC 6544); at the time of writing &xep0176; is being updated to include the ability to negotiate ICE-TCP candidates.
@@ -303,7 +303,7 @@
- In accordance with Section 12 of XEP-0166, this document specifies the following information related to the Jingle File Transfer ("Jingle FT") application type:
+ In accordance with Section 12 of &xep0166;, this document specifies the following information related to the Jingle File Transfer ("Jingle FT") application type:
The application format negotiation process is defined in the Negotiating a Jingle File Transfer Session section of this document.
The semantics of the &DESCRIPTION; element are defined in the Application Format section of this document.
@@ -364,7 +364,7 @@
algo='sha-1'>w0mcJylzCn+AfvuGdqkty2+KP48=
]]>
- The &DESCRIPTION; element is intended to be a child of a Jingle &CONTENT; element as specified in XEP-0166.
+The &DESCRIPTION; element is intended to be a child of a Jingle &CONTENT; element as specified in &xep0166;.
The child elements of the <file/> element are as follows:
Type 2 | Verified Acceptable | Self-signed | -XMPP 1.0 |
+ XMPP 1.0 |
type2.lit | juliet@type2.lit | timestamp | xs:datetime | -UTC timestamp specifying the moment when the reading was taken (MUST conform to the DateTime profile of XEP-0082) | +UTC timestamp specifying the moment when the reading was taken (MUST conform to the DateTime profile of &xep0082;) | 2004-02-19T21:12Z | Piped directly through from query timestamp field. | @@ -703,7 +703,7 @@