It is RECOMMENDED for an IM User's client to retrieve the WaitingList immediately after logging in. However, first it must discover its local WaitingListService. An IM User MAY use either &jep0030; or the deprecated &jep0094; protocol.
+It is RECOMMENDED for an IM User's client to retrieve the WaitingList immediately after logging in. However, first it must discover its local WaitingListService. An IM User MAY use either &xep0030; or the deprecated &xep0094; protocol.
Once an IM User's client has discovered the WaitingListService and requested the user's WaitingList, the user can add Contacts to the WaitingList based on the Contact's URI. (Note: This JEP uses the example of phone numbers via the 'tel' URI scheme, but the same rules apply to WaitingList items based on email addresses or other URI schemes.)
+Once an IM User's client has discovered the WaitingListService and requested the user's WaitingList, the user can add Contacts to the WaitingList based on the Contact's URI. (Note: This document uses the example of phone numbers via the 'tel' URI scheme, but the same rules apply to WaitingList items based on email addresses or other URI schemes.)
As described below, various error conditions may occur. (For information about error syntax, refer to RFC 3920 and &jep0086;.)
+As described below, various error conditions may occur. (For information about error syntax, refer to RFC 3920 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.
If InterPartner's WaitingListService knows the Contact JID, it sends it to ServiceProvider's WaitingListService as shown in the ServiceProvider's WaitingListService Adds Contact to WaitingList section of this document.
If WaitingListService knows Contact JID (or learns Contact JID from InteropPartner), it MUST inform IM User through a "JID push" message, which consists of a message stanza that contains a <waitlist/> element qualified by the 'http://jabber.org/protocol/waitinglist' namespace:
-
A ServiceProvider's WaitingListService MUST record which of its IM Users have requested the JID associated with Contact's URI, and an InteropPartner's WaitingListService MUST record that Service Provider's WaitingListService (not User) has requested JID associated with Contact's URI. Therefore when Contact registers, InteropPartner's WaitingListService informs its local users as well as ServiceProvider's WaitingListService, and ServiceProvider's WaitingListService informs its local users.
The InteropPartner's WaitingListService is not required to be hosted by InteropPartner, and could be hosted by a third party (e.g., a neutral phone number translation service). In this case, InteropPartner would simply advertise 'waitlist.third-party.com' as its WaitingListService.
Once an IM User learns a Contact's JID, the IM User MAY send a normal subscription request to the Contact, setting the "to" address to Contact's JID. This interaction is defined in the base XMPP specifications and is out of scope for this document.
For historical reasons, implementations MUST support the older Agent Information protocol (JEP-0094) and SHOULD support Service Discovery (JEP-0030). Note well that the Agent Information protocol will eventually be deprecated in favor of Service Discovery.
For historical reasons, implementations MUST support the older Agent Information protocol (XEP-0094) and SHOULD support Service Discovery (XEP-0030). Note well that the Agent Information protocol will eventually be deprecated in favor of Service Discovery.
An IM User's client receives WaitingList information either through a "JID push" message (received from WaitingListService at any time) or in the IQ result received after requesting the WaitingList (since one or more of the WaitingList items may contain a JID). (The same rule applies to a ServiceProvider's WaitingListService that receives an IQ set from an InteropPartner's WaitingListService.)
When an IM User logs in, the user's client SHOULD request the current WaitingList.
Although the examples in this JEP show the hostname of the WaitingListService as 'waitlist.third-party.com' (etc.), this is for convenience only; the hostname MAY be any valid DNS hostname.
Although the examples in this document show the hostname of the WaitingListService as 'waitlist.third-party.com' (etc.), this is for convenience only; the hostname MAY be any valid DNS hostname.
When sending JID pushes, an implementation MAY specify a message type of 'headline', which in some deployments will prevent such messages from being stored offline for later delivery.
It can happen that WaitingListService does not receive a reply from InteropPartner within a certain amount of time or the connection to InteropPartner times out. Because such behavior is often transient, WaitingListService MAY attempt to reconnect and then resend the request (although any retry logic to handle these cases is a matter of implementation). However, WaitingListService SHOULD NOT return an ¬found; error to IM User unless it knows definitively that the Contact's InteropPartner is permanently unavailable, since returning an ¬found; error in response to temporary connection timeouts is likely to be misleading.
A service MAY require a Contact to approve the disclosure of the Contact's JID, either as a global preference or for each request; however, this is a local policy matter.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; includes 'http://jabber.org/protocol/waitinglist' in its registry of protocol namespaces.
The Jabber Registar includes a type of "waitinglist" in the "directory" category in its registry of service discovery identities.
The Jabber Registrar includes supported URI schemes in its registry of service discovery features. These features shall be of the form 'http://jabber.org/protocol/waitlist/schemes/SCHEME-NAME'.
-This JEP registers the following two namespace names for URI schemes, but others MAY be registered in the future using standard registration procedures:
+The XMPP Registrar includes supported URI schemes in its registry of service discovery features. These features shall be of the form 'http://jabber.org/protocol/waitlist/schemes/SCHEME-NAME'.
+This document registers the following two namespace names for URI schemes, but others MAY be registered in the future using standard registration procedures:
Added Date, DateTime, and Time headers conforming to profiles from JEP-0082; renamed Date header to RFC2822Date; added note about date-related headers; added headers from RFC 2413 (Dublin Core).
Added Date, DateTime, and Time headers conforming to profiles from XEP-0082; renamed Date header to RFC2822Date; added note about date-related headers; added headers from RFC 2413 (Dublin Core).
In order to ensure proper processing by the recipient of an XML stanza, some Jabber protocols and other XMPP extensions may need to enable the sender to communicate non-addressing information about the stanza (this is especially true of protocols that translate from a foreign format to XMPP; a good example is &jep0111;). Such information was formerly included in &jep0033;, but was removed from that specification when it was changed to focus on addressing information only. Therefore, this JEP defines a mechanism for encapsulating non-addressing "header" information about stanzas, including standard Internet metadata such as that defined by &rfc2045;, &rfc2616;, &rfc2617;, &rfc2822;, and &rfc3261;. Such information is encapsulated in a protocol extension qualified by the 'http://jabber.org/protocol/shim' namespace, where "SHIM" stands for "Stanza Headers and Internet Metadata".
+In order to ensure proper processing by the recipient of an XML stanza, some Jabber protocols and other XMPP extensions may need to enable the sender to communicate non-addressing information about the stanza (this is especially true of protocols that translate from a foreign format to XMPP; a good example is &xep0111;). Such information was formerly included in &xep0033;, but was removed from that specification when it was changed to focus on addressing information only. Therefore, this document defines a mechanism for encapsulating non-addressing "header" information about stanzas, including standard Internet metadata such as that defined by &rfc2045;, &rfc2616;, &rfc2617;, &rfc2822;, and &rfc3261;. Such information is encapsulated in a protocol extension qualified by the 'http://jabber.org/protocol/shim' namespace, where "SHIM" stands for "Stanza Headers and Internet Metadata".
This protocol addresses the following requirements:
@@ -106,7 +106,7 @@In order to discover whether another entity supports this protocol, an entity MUST use &jep0030;.
+In order to discover whether another entity supports this protocol, an entity MUST use &xep0030;.
All public headers SHOULD be registered with the Jabber Registrar following the process specified in the Jabber Registrar Considerations section of this document. Many such headers are defined by other protocol specifications, such as RFCs 2045, 2616, 2617, 2822, and 3261; implementors MUST refer to those specifications for definition of the relevant headers.
-This JEP defines several additional headers that may prove useful within Jabber protocols and other XMPP extensions, as specified in the following sections; further headers may be registered with the Jabber Registrar, either directly or via definition in Jabber Enhancement Proposals.
+All public headers SHOULD be registered with the XMPP Registrar following the process specified in the XMPP Registrar Considerations section of this document. Many such headers are defined by other protocol specifications, such as RFCs 2045, 2616, 2617, 2822, and 3261; implementors MUST refer to those specifications for definition of the relevant headers.
+This document defines several additional headers that may prove useful within Jabber protocols and other XMPP extensions, as specified in the following sections; further headers may be registered with the XMPP Registrar, either directly or via definition in Jabber Enhancement Proposals.
The Classification header enables a sender or other entity to classify a stanza according to some classification scheme. The values of the XML character data contained within this header are out of scope for this document, since they are determined by the using application. Note: This header may be security-sensitive (see the Security Considerations for details).
The Date header is defined by RFC 2822 and therefore follows the date and time format defined by RFC 2822; while this header is thus useful for translating email messages into XMPP stanzas, it is not consistent with &jep0082;. Therefore we define the "Created" header, which specifies the date and time when a stanza was created by the originating entity, where the value conforms to the DateTime profile specified in JEP-0082.
+The Date header is defined by RFC 2822 and therefore follows the date and time format defined by RFC 2822; while this header is thus useful for translating email messages into XMPP stanzas, it is not consistent with &xep0082;. Therefore we define the "Created" header, which specifies the date and time when a stanza was created by the originating entity, where the value conforms to the DateTime profile specified in XEP-0082.
The Distribute header enables a sender to specify whether the stanza may be further distributed by the recipient to other entities on the network. The allowable values for this header are "true" and "false". If the sender specifies a value of "false", the recipient MUST NOT further distribute the stanza or any information contained therein; if the sender specifies a value of "true", the recipient MAY further distribute the stanza or any information contained therein; if the value is anything other than "true" or "false" and the recipient does not understand the value, the recipient MUST assume the default value of "false". This header is semantically equivalent to the "Distribute" flag defined in &geoprivpol;. (The HTTP "Max-Forwards" header is not appropriate for this usage, since it defines proxy and gateway behavior rather than recipient behavior.) Note: This header may be security-sensitive (see the Security Considerations for details).
@@ -192,7 +192,7 @@The Store header enables a sender to specify whether the stanza may be stored or archived by the recipient. The allowable values for this header are "true" and "false". If the sender specifies a value of "false", the recipient MUST NOT store the stanza or any information contained therein; if the sender specifies a value of "true", the recipient MAY store the stanza or any information contained therein; if the value is anything other than "true" or "false" and the recipient does not understand the value, the recipient MUST assume the default value of "false". Note: This header may be security-sensitive (see the Security Considerations for details).
It may be useful to specify that the information contained in a stanza is valid only for a limited period of time. Such is the function of the "TTL" header, the value of which is some number of seconds since the creation of the stanza. Note well that this header is purely informational and MUST NOT be used for routing or delivery of XML stanzas, since that function is already served by &jep0079;. A stanza that includes the "TTL" header SHOULD also include a "Created" header so that the recipient can properly process the stanza.
+It may be useful to specify that the information contained in a stanza is valid only for a limited period of time. Such is the function of the "TTL" header, the value of which is some number of seconds since the creation of the stanza. Note well that this header is purely informational and MUST NOT be used for routing or delivery of XML stanzas, since that function is already served by &xep0079;. A stanza that includes the "TTL" header SHOULD also include a "Created" header so that the recipient can properly process the stanza.
One situation in which both the "Created" and "TTL" headers might prove valuable is the broadcasting of structured presence information, such as a calendar-generated notification that a user will be in a meeting for the next hour:
Date formats differ widely. &jep0082; 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;.
+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.
Certain SHIM headers MAY be security-sensitive (e.g., the "Classification", "Distribute", and "Store" headers specified herein). If an entity plans to use such headers, it MUST determine whether the intended recipient supports both the SHIM protocol and the particular security-sensitive headers of interst, as described under Service Discovery; furthermore, an implementation MUST warn a human user (if any) before use if the security-sensitive headers of interest are not supported.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The Jabber Registrar includes 'http://jabber.org/protocol/shim' in its registry of protocol namespaces (see &SHIMHEADERS;).
+The XMPP Registrar includes 'http://jabber.org/protocol/shim' in its registry of protocol namespaces (see &SHIMHEADERS;).
The Jabber Registrar includes 'http://jabber.org/protocol/shim' in its registry of well-known Service Discovery nodes.
+The XMPP Registrar includes 'http://jabber.org/protocol/shim' in its registry of well-known Service Discovery nodes.
The Jabber Registrar maintains a registry of SHIM headers.
+The XMPP Registrar maintains a registry of SHIM headers.
Classification
a level within a classification scheme
- JEP-0131
+ XEP-0131
@@ -447,7 +447,7 @@
Created
date and time of stanza creation in ISO 8601 format
- JEP-0131
+ XEP-0131
@@ -464,14 +464,14 @@
Date
- a string that conforms to the Date profile specified in JEP-0082
- JEP-0131
+ a string that conforms to the Date profile specified in XEP-0082
+ XEP-0131
DateTime
- a string that conforms to the DateTime profile specified in JEP-0082
- JEP-0131
+ a string that conforms to the DateTime profile specified in XEP-0082
+ XEP-0131
@@ -483,7 +483,7 @@
Distribute
whether or not the stanza may be further distributed
- JEP-0131
+ XEP-0131
@@ -783,7 +783,7 @@
Store
whether or not the stanza may be stored or archived
- JEP-0131
+ XEP-0131
@@ -806,8 +806,8 @@
Time
- a string that conforms to the Time profile specified in JEP-0082
- JEP-0131
+ a string that conforms to the Time profile specified in XEP-0082
+ XEP-0131
@@ -837,7 +837,7 @@
TTL
a time to live for the stanza, in seconds
- JEP-0131
+ XEP-0131
@@ -861,7 +861,7 @@
Urgency
the time sensitivity of a stanza ("high", "medium", or "low")
- JEP-0131
+ XEP-0131
@@ -911,7 +911,7 @@
The protocol documented by this schema is defined in
- JEP-0131: http://www.jabber.org/jeps/jep-0131.html
+ XEP-0131: http://www.xmpp.org/extensions/xep-0131.html
@@ -936,4 +936,4 @@
]]>
&xmppcore; and &xmppim; define methods for exchanging information about a person's network availability via the XML <presence/> stanza. In general, such presence information is generated only when a person initiates interaction with a client, although it can be generated programmatically through features such as auto-away. However, sometimes a user is present in the vicinity of a client but is not actively engaged with the client interface. In such circumstances, it would be helpful to have a mechanism that is sometimes referred to as <presence type='probe-irl'/>: the ability to invoke a real-life means of determining the physical presence of the user. This JEP defines just such a mechanism.
+&xmppcore; and &xmppim; define methods for exchanging information about a person's network availability via the XML <presence/> stanza. In general, such presence information is generated only when a person initiates interaction with a client, although it can be generated programmatically through features such as auto-away. However, sometimes a user is present in the vicinity of a client but is not actively engaged with the client interface. In such circumstances, it would be helpful to have a mechanism that is sometimes referred to as <presence type='probe-irl'/>: the ability to invoke a real-life means of determining the physical presence of the user. This document defines just such a mechanism.
Physical presence is best determined through direct interaction with an object. In this JEP, our approach is labelled "kinesthetic excitation": some form of physical contact is initiated with the object (in most cases a user), resulting in hard evidence of presence obtained by a sense modality such as sight, touch, or hearing. To ensure reliability, the physical contact MUST impinge upon the object or user to such an extent that it measurably reacts in the form of motion through space (e.g., moving in relation to a visual observation device), generation of an auditory event (e.g., vocalization), and the like. The exact means of excitation and perception are implementation-specific and therefore not specified fully in this JEP, although suggestions are provided in the Methods section below.
+Physical presence is best determined through direct interaction with an object. In this document, our approach is labelled "kinesthetic excitation": some form of physical contact is initiated with the object (in most cases a user), resulting in hard evidence of presence obtained by a sense modality such as sight, touch, or hearing. To ensure reliability, the physical contact MUST impinge upon the object or user to such an extent that it measurably reacts in the form of motion through space (e.g., moving in relation to a visual observation device), generation of an auditory event (e.g., vocalization), and the like. The exact means of excitation and perception are implementation-specific and therefore not specified fully in this document, although suggestions are provided in the Methods section below.
In the past, some members of the Jabber community have suggested the addition of a new presence type: "probe-irl". However, this has several drawbacks. First, the XMPP specifications (XMPP Core and XMPP IM) approved by the IETF do not allow any values for the 'type' attribute other than those defined in the XML schemas for the 'jabber:client' and 'jabber:server' namespaces. Second, presence probes are handled by a server on behalf of a user and therefore are not routed to clients (which presumably often have the best opportunity for discovering evidence of physical presence); an &IQ; stanza is more appropriate for client-to-client information exchange. Therefore, this JEP defines a general extension mechanism that can be used in both &PRESENCE; and &IQ; stanzas.
+In the past, some members of the Jabber community have suggested the addition of a new presence type: "probe-irl". However, this has several drawbacks. First, the XMPP specifications (XMPP Core and XMPP IM) approved by the IETF do not allow any values for the 'type' attribute other than those defined in the XML schemas for the 'jabber:client' and 'jabber:server' namespaces. Second, presence probes are handled by a server on behalf of a user and therefore are not routed to clients (which presumably often have the best opportunity for discovering evidence of physical presence); an &IQ; stanza is more appropriate for client-to-client information exchange. Therefore, this document defines a general extension mechanism that can be used in both &PRESENCE; and &IQ; stanzas.
The extension mechanism is encapsulated in a <poke/> element qualified by the 'http://jabber.org/protocol/poke' namespace; this element MAY be included as a direct child of a &PRESENCE; stanza of type "probe" or an &IQ; stanza of type "get" (for a request), "result" (for a successful response), or "error" (for an unsuccessful response).
The requesting entity MAY specify a preferred method of excitation and observation; in general, these methods correspond to particular sense modalities such as sight, touch, and hearing (see the Methods section below).
As defined in XMPP IM, presence stanzas of type "probe" are handled on behalf of the target entity by the entity's server. While normally these presence stanzas are generated by the requesting entity's server (e.g., when the requesting entity sends initial presence), the requesting entity itself (or, more precisely, its client) is allowed to generate presence stanzas of type "probe". In this JEP we make use of this ability to query the target entity's server regarding the entity's physical presence.
+As defined in XMPP IM, presence stanzas of type "probe" are handled on behalf of the target entity by the entity's server. While normally these presence stanzas are generated by the requesting entity's server (e.g., when the requesting entity sends initial presence), the requesting entity itself (or, more precisely, its client) is allowed to generate presence stanzas of type "probe". In this document we make use of this ability to query the target entity's server regarding the entity's physical presence.
In the following example, a star-crossed lover pokes the server of his beloved to determine her physical presence (notice that the value of 'to' address lacks a resource identifier and therefore is a bare JID, not a full JID).
If the user's server does not support the POKE protocol, it SHOULD ignore the extension and treat the presence stanza as a normal (non-IRL) presence probe. However, the user's server MAY return a "Service Unavailable" error to the requesting entity to inform the requesting entity that IRL probes are not supported (for details regarding error syntax, refer to &jep0086;):
+If the user's server does not support the POKE protocol, it SHOULD ignore the extension and treat the presence stanza as a normal (non-IRL) presence probe. However, the user's server MAY return a "Service Unavailable" error to the requesting entity to inform the requesting entity that IRL probes are not supported (for details regarding error syntax, refer to &xep0086;):
If the requesting entity has permission to discover the user's physical presence, the server SHOULD attempt to determine if the user is physically present. Methods for doing so are implementation-specific and therefore out of scope for this JEP, but possible mechanisms might include:
+If the requesting entity has permission to discover the user's physical presence, the server SHOULD attempt to determine if the user is physically present. Methods for doing so are implementation-specific and therefore out of scope for this document, but possible mechanisms might include:
If the server determines that the user is physically present in the vicinity of a client, it SHOULD return that information to the requesting entity, including the appropriate resource:
The server SHOULD NOT return a "Not Found" error unless the user does not exist. If the server determines that the user has died, it MAY return a "Gone" error with appropriate descriptive text, although it SHOULD wait to do so pending notification of next-of-kin; note well that such notification is out of scope for this JEP (though this seems like a sensible application of the &jep0060; protocol):
+The server SHOULD NOT return a "Not Found" error unless the user does not exist. If the server determines that the user has died, it MAY return a "Gone" error with appropriate descriptive text, although it SHOULD wait to do so pending notification of next-of-kin; note well that such notification is out of scope for this document (though this seems like a sensible application of the &xep0060; protocol):
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; shall add the 'http://jabber.org/protocol/poke' namespace to its registry of protocol namespaces.
The Jabber Registrar shall maintain a registry of values for the 'method' attribute. The following values shall be added initially:
+The XMPP Registrar shall maintain a registry of values for the 'method' attribute. The following values shall be added initially:
There exists a set of common service-level tasks that administrators often need to perform in relation to Jabber/XMPP servers and components. Examples include creating users, disabling accounts, and blacklisting domains for inbound or outbound communications. Because such tasks can be performed with respect to a server or with respect to many kinds of add-on components (e.g., a text conferencing component that conforms to &jep0045;), it makes sense to define a generic protocol for such interactions. This JEP describes such a protocol by specifying a profile of &jep0050; and associated &jep0004; fields, rather than by defining a specialized and distinct protocol.
+There exists a set of common service-level tasks that administrators often need to perform in relation to Jabber/XMPP servers and components. Examples include creating users, disabling accounts, and blacklisting domains for inbound or outbound communications. Because such tasks can be performed with respect to a server or with respect to many kinds of add-on components (e.g., a text conferencing component that conforms to &xep0045;), it makes sense to define a generic protocol for such interactions. This document describes such a protocol by specifying a profile of &xep0050; and associated &xep0004; fields, rather than by defining a specialized and distinct protocol.
This JEP addresses the following requirements:
+This document addresses the following requirements:
A server or component MUST advertise any administrative commands it supports via &jep0030; (as described in JEP-0050: Ad-Hoc Commands); such commands exist as well-defined discovery nodes associated with the service in question.
+A server or component MUST advertise any administrative commands it supports via &xep0030; (as described in XEP-0050: Ad-Hoc Commands); such commands exist as well-defined discovery nodes associated with the service in question.
In order to interact with a particular component attached to a server, an administrator needs to first discover that component and the commands it support, then send the appropriate command to the component itself. A server SHOULD NOT process commands on behalf of associated components, just as it does not handle service discovery requests on behalf of such components.
This JEP defines a profile of JEP-0050: Ad-Hoc Commands that enables a service-level administrator to complete the following use cases:
+This document defines a profile of XEP-0050: Ad-Hoc Commands that enables a service-level administrator to complete the following use cases:
Naturally, not all of these use cases apply to all service types (e.g., adding a user may not apply to a multi-user chat service). An implementation or deployment MAY support any subset of the use cases defined herein. In addition, although this JEP aims to define common use cases, an implementation or deployment MAY support additional commands not defined herein, which may or may not be publicly registered.
-Note: The text that follows assumes that implementors have read and understood JEP-0050: Ad-Hoc Commands and JEP-0004: Data Forms.
+Naturally, not all of these use cases apply to all service types (e.g., adding a user may not apply to a multi-user chat service). An implementation or deployment MAY support any subset of the use cases defined herein. In addition, although this document aims to define common use cases, an implementation or deployment MAY support additional commands not defined herein, which may or may not be publicly registered.
+Note: The text that follows assumes that implementors have read and understood XEP-0050: Ad-Hoc Commands and XEP-0004: Data Forms.
A user is defined as any entity that has a persistent relationship with a service (most commonly through the creation a registered account with the service) and whose account is in some sense hosted by the service. Adding a user MUST result in the creation of an account, along with any implementation-specific data for such an account (e.g., database entries or a roster file). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#add-user".
A sample protocol flow for this use case is shown below.
@@ -1223,7 +1223,7 @@ ]]>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 an IM session, as specified in Section 3 of RFC 3921 or its equivalent (e.g., &jep0078;), 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 an IM session, as specified in Section 3 of RFC 3921 or its equivalent (e.g., &xep0078;), 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.
On a server or service without many registered users, it may be helpful to enable an administrator to retrieve a list of all registered users. The service may need to truncate the result-set, since it could be quite large (however, any ability to limit or page through the result-set is outside the scope of this JEP). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-registered-users-list".
+On a server or service without many registered users, it may be helpful to enable an administrator to retrieve a list of all registered users. The service may need to truncate the result-set, since it could be quite large (however, any ability to limit or page through the result-set is outside the scope of this document). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-registered-users-list".
A sample protocol flow for this use case is shown below.
The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.
-The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the Jabber Registrar; however, such fields are not defined herein.
+The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.
It may be helpful to enable an administrator to retrieve a list of all disabled users. The service may need to truncate the result-set, since it could be quite large (however, any ability to limit or page through the result-set is outside the scope of this JEP). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-disabled-users-list".
+It may be helpful to enable an administrator to retrieve a list of all disabled users. The service may need to truncate the result-set, since it could be quite large (however, any ability to limit or page through the result-set is outside the scope of this document). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-disabled-users-list".
A sample protocol flow for this use case is shown below.
The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.
-The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the Jabber Registrar; however, such fields are not defined herein.
+The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.
It may be helpful to enable an administrator to retrieve a list of all online users. Because the number of online users may be quite large, the service may need to truncate the result-set, since it could be quite large (however, any ability to limit or page through the result-set is outside the scope of this JEP). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-online-users".
+It may be helpful to enable an administrator to retrieve a list of all online users. Because the number of online users may be quite large, the service may need to truncate the result-set, since it could be quite large (however, any ability to limit or page through the result-set is outside the scope of this document). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-online-users".
A sample protocol flow for this use case is shown below.
The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.
-The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the Jabber Registrar; however, such fields are not defined herein.
+The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.
It may be helpful to enable an administrator to retrieve a list of all active users. Because the number of active users may be quite large, the service may need to truncate the result-set, since it could be quite large (however, any ability to limit or page through the result-set is outside the scope of this JEP). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-active-users".
+It may be helpful to enable an administrator to retrieve a list of all active users. Because the number of active users may be quite large, the service may need to truncate the result-set, since it could be quite large (however, any ability to limit or page through the result-set is outside the scope of this document). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-active-users".
A sample protocol flow for this use case is shown below.
The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.
-The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the Jabber Registrar; however, such fields are not defined herein.
+The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.
It may be helpful to enable an administrator to retrieve a list of all idle users. Because the number of idle users may be quite large, the service may need to truncate the result-set, since it could be quite large (however, any ability to limit or page through the result-set is outside the scope of this JEP). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-idle-users".
+It may be helpful to enable an administrator to retrieve a list of all idle users. Because the number of idle users may be quite large, the service may need to truncate the result-set, since it could be quite large (however, any ability to limit or page through the result-set is outside the scope of this document). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-idle-users".
A sample protocol flow for this use case is shown below.
The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.
-The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the Jabber Registrar; however, such fields are not defined herein.
+The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.
Administrators of some existing Jabber servers have found it useful to be able to send an announcement to all online users of the server (e.g., to announce a server shutdown); this concept can be extended to any service (such as a multi-user chat service or a gateway to a foreign IM service). The message shall be sent only to users who currently have a "session" with the service. Obviously there may be latency in sending the message if the number of active users is extremely large. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#announce".
@@ -2527,25 +2527,25 @@For the syntax of these errors, see &jep0086;. Naturally, other errors may be returned as well (e.g., &internalserver; if the service cannot be shut down).
+For the syntax of these errors, see &xep0086;. Naturally, other errors may be returned as well (e.g., &internalserver; if the service cannot be shut down).
The ability to complete the administrative tasks specified herein MUST NOT be granted to users who lack service-level administrative privileges.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; shall include the following information in its registries.
Upon advancement of this JEP to a status of Active, the Jabber Registrar shall add "http://jabber.org/protocol/admin" to its registry of protocol namespaces.
+The XMPP Registrar includes "http://jabber.org/protocol/admin" in its registry of protocol namespaces.
&jep0068; defines a process for standardizing the fields used within Data Forms scoped by a particular namespace. The reserved fields for the 'http://jabber.org/protocol/admin' namespace are specified below.
+&xep0068; defines a process for standardizing the fields used within Data Forms scoped by a particular namespace. The reserved fields for the 'http://jabber.org/protocol/admin' namespace are specified below.
http://jabber.org/protocol/admin
- JEP-0133
+ XEP-0133
Forms used for administration of servers and components.
Because the protocol defined here is a profile of JEP-0050: Ad-Hoc Commands, no schema definition is needed.
+Because the protocol defined here is a profile of XEP-0050: Ad-Hoc Commands, no schema definition is needed.
Background
When the &JSF; submitted the XMPP Core and XMPP IM specifications to the &IETF;, it ceded change control over the core XML streaming technology developed by the Jabber community. However, the JSF has reserved the right to define extensions to XMPP; furthermore, that right is not exclusive to the JSF, since anyone can define their own public or private extensions to XMPP. These extensions are usually in the form of structured XML data that is qualified by a unique namespace other than those currently reserved by the IETF or the JSF.
Meaning
-When we say that "XMPP is Sacred", we mean that good protocol design must work within the context of XMPP and not require changes to the core protocols. For one thing, any such changes would need to be pursued within the IETF. Further, the core semantics most likely provide everything that a protocol designer needs. If you think that you need to define a new kind of top-level stanza (other than &MESSAGE;, &PRESENCE;, and &IQ;) or a new value of the 'type' attribute for any stanza kind, then you need to think again. Treat XMPP as a transport layer and build extensions on top of that layer (among other things, this implies that you must not modify the foundation when you are working on higher-level structures, for example by adding adding elements and attributes to the XMPP schemas on the theory that if applications will ignore them; define your own extensions in a separate namespace). A further implication of respecting XMPP is using structured data formats (e.g., applications of &w3xml; rather than binary or plaintext formats) whenever possible. Finally, as explained in XMPP Core, the &PRESENCE; stanza exists to broadcast network and communications availability only; for more advanced information publishing, use &jep0060;.
+When we say that "XMPP is Sacred", we mean that good protocol design must work within the context of XMPP and not require changes to the core protocols. For one thing, any such changes would need to be pursued within the IETF. Further, the core semantics most likely provide everything that a protocol designer needs. If you think that you need to define a new kind of top-level stanza (other than &MESSAGE;, &PRESENCE;, and &IQ;) or a new value of the 'type' attribute for any stanza kind, then you need to think again. Treat XMPP as a transport layer and build extensions on top of that layer (among other things, this implies that you must not modify the foundation when you are working on higher-level structures, for example by adding adding elements and attributes to the XMPP schemas on the theory that if applications will ignore them; define your own extensions in a separate namespace). A further implication of respecting XMPP is using structured data formats (e.g., applications of &w3xml; rather than binary or plaintext formats) whenever possible. Finally, as explained in XMPP Core, the &PRESENCE; stanza exists to broadcast network and communications availability only; for more advanced information publishing, use &xep0060;.
Examples
-A good example of honoring the XMPP specifications is &jep0126;; while the Jabber community had informally defined <presence type='invisible'/> at one point, that protocol was abandoned in favor of an XMPP-compliant approach. Another example is &jep0071;, which re-uses &w3xhtml; (a structured format that shares with XMPP a common root in XML) rather than &rtf; (an unstructured format that does not derive from XML). Further examples are the "extended presence" JEPS (see &jep0119;), which are built on top of JEP-0060 rather than overloading the &PRESENCE; stanza.
+A good example of honoring the XMPP specifications is &xep0126;; while the Jabber community had informally defined <presence type='invisible'/> at one point, that protocol was abandoned in favor of an XMPP-compliant approach. Another example is &xep0071;, which re-uses &w3xhtml; (a structured format that shares with XMPP a common root in XML) rather than &rtf; (an unstructured format that does not derive from XML). Further examples are the "extended presence" speficiations (see &xep0119;), which are built on top of XEP-0060 rather than overloading the &PRESENCE; stanza.
Background
@@ -74,15 +74,15 @@Examples
-One good example of keeping clients simple is the presence stanza: the client has only to send &PRESENCE; and the server takes care of presence probes, broadcasts, and appropriate routing decisions. Another example is &jep0045;: although the protocol involves some complexity, it was written so that older clients can join and participate in MUC rooms even if they don't understand the more advanced MUC extensions.
+One good example of keeping clients simple is the presence stanza: the client has only to send &PRESENCE; and the server takes care of presence probes, broadcasts, and appropriate routing decisions. Another example is &xep0045;: although the protocol involves some complexity, it was written so that older clients can join and participate in MUC rooms even if they don't understand the more advanced MUC extensions.
Background
The Jabber community has been developing wire protocols for XML streaming, presence, and instant messaging since 1999. In that time, members of the community have defined a number of building blocks that can be used as the basis for further development. Furthermore, many smart people have created open protocols within other standards development organizations, including the IETF, the &W3C;, &OASIS;, the &ITU;, and the &DUBLINCORE;.
Meaning
-Good protocol designers "stand on the shoulders of giants" by re-using protocols that have been defined within the JSF and within other standards development organizations. That does not mean we don't define new protocols, because sometimes that is necessary. However, we are aware of work completed by others and we make use of it, especially when that work is outside the Jabber community's core competence areas (e.g., security or multimedia data formats rather than XML streaming, presence, and real-time messaging). Furthermore, the JSF prefers to re-use open protocols wherever possible. Finally, just as with XMPP, so also with XMPP extensions defined through the JSF: do not modify existing schemas (e.g., adding new elements and attributes) except through the JEP process; instead, define extensions in a separate namespace).
+Good protocol designers "stand on the shoulders of giants" by re-using protocols that have been defined within the JSF and within other standards development organizations. That does not mean we don't define new protocols, because sometimes that is necessary. However, we are aware of work completed by others and we make use of it, especially when that work is outside the Jabber community's core competence areas (e.g., security or multimedia data formats rather than XML streaming, presence, and real-time messaging). Furthermore, the JSF prefers to re-use open protocols wherever possible. Finally, just as with XMPP, so also with XMPP extensions defined through the JSF: do not modify existing schemas (e.g., adding new elements and attributes) except through the XMPP extension process; instead, define extensions in a separate namespace).
Examples
-Examples of re-using existing Jabber protocols include &jep0095; (which re-uses &jep0020;) and JEP-0126: Invisibility (which re-uses the privacy lists protocol defined in XMPP IM). Examples of re-using non-Jabber protocols include &jep0065; (which makes use of &rfc1928;) and &jep0127; (which defines a way to send &oasiscap; data via Jabber). Here again JEP-0071 provides an example: it re-uses XHTML 1.0 (an open protocol developed by a recognized standards development organization) rather than RTF (a closed protocol under the control of the Microsoft Corporation).
+Examples of re-using existing Jabber protocols include &xep0095; (which re-uses &xep0020;) and XEP-0126: Invisibility (which re-uses the privacy lists protocol defined in XMPP IM). Examples of re-using non-Jabber protocols include &xep0065; (which makes use of &rfc1928;) and &xep0127; (which defines a way to send &oasiscap; data via Jabber). Here again XEP-0071 provides an example: it re-uses XHTML 1.0 (an open protocol developed by a recognized standards development organization) rather than RTF (a closed protocol under the control of the Microsoft Corporation).
Background
@@ -90,7 +90,7 @@Meaning
The best Jabber protocols are quite focused and provide limited but powerful functionality that can be applied in a specific domain or, sometimes, re-used by other Jabber protocols. Even if the domain is more complex, a protocol that addresses it needs to clearly define its scope, limit that scope as much as possible, and specify only the protocols necessary to meet the core requirements.
Examples
-&jep0030; and &jep0004; are good examples of focused, single-purpose protocols. By contrast, Multi-User Chat is more complex, but it limits itself to the domain of text conferencing in the context of virtual rooms (e.g., it does not address service-level administration) and consists of separate namespaces for end-user, moderator, and room owner functionality. A good example of a protocol that is focused on a smaller domain is &jep0144;.
+&xep0030; and &xep0004; are good examples of focused, single-purpose protocols. By contrast, Multi-User Chat is more complex, but it limits itself to the domain of text conferencing in the context of virtual rooms (e.g., it does not address service-level administration) and consists of separate namespaces for end-user, moderator, and room owner functionality. A good example of a protocol that is focused on a smaller domain is &xep0144;.
Background
@@ -100,13 +100,13 @@Examples
-&jep0096; is a good example of respecting the strengths and weaknesses of XMPP, since it specifies that going out of band is the preferred mechanism for bandwidth-heavy data transfers.
+&xep0096; is a good example of respecting the strengths and weaknesses of XMPP, since it specifies that going out of band is the preferred mechanism for bandwidth-heavy data transfers.
Background
In the beginning was the code (mainly &jabberd;). Although code is explicit in its own way, not everyone reads code, and detailed specifications are necessary in order to make functionality reproducible in different codebases. The Jabber community has learned that lesson the hard way.
Meaning
-Detailed, explicit specifications are good specifications. Define your terms. Use conformance terminology such as MUST and SHOULD rather than loose English words such as "does" and "will". Follow the &jep0143;. Specify error conditions. Include lots of examples. Restrict the allowable XML via schemas and datatypes as specified in &w3xmlschema1; and &w3xmlschema2;.
+Detailed, explicit specifications are good specifications. Define your terms. Use conformance terminology such as MUST and SHOULD rather than loose English words such as "does" and "will". Follow the &xep0143;. Specify error conditions. Include lots of examples. Restrict the allowable XML via schemas and datatypes as specified in &w3xmlschema1; and &w3xmlschema2;.
Examples
XMPP Core and XMPP IM are large documents that define the Extensible Messaging and Presence Protocol in excruciating detail. Although such specifications are not fun to write, they provide a model for good protocol design and documentation.
Meaning
In general, a protocol needs to define the skeleton of functionality, but not necessarily specific parameters or values to be used within a certain domain. In order to allow for growth and change, it often makes sense to specify that the ®ISTRAR; shall keep track of certain parameters and values, rather than to explicitly limit them in the protocol itself.
Examples
-Whereas the old &jep0094; and &jep0011; protocols defined certain hardcoded values for entity types and categories, Service Discovery has left that function up to the Jabber Registrar. Similarly, &jep0095; defines a registry for its profiles, &jep0079; defines registries for processing conditions and actions, and a number of JEPs register FORM_TYPE values as specified in &jep0068;.
+Whereas the old &xep0094; and &xep0011; protocols defined certain hardcoded values for entity types and categories, Service Discovery has left that function up to the XMPP Registrar. Similarly, &xep0095; defines a registry for its profiles, &xep0079; defines registries for processing conditions and actions, and a number of XMPP Extension Protocols register FORM_TYPE values as specified in &xep0068;.
Background
@@ -131,9 +131,9 @@There are no security features or concerns directly related to this proposal, which is informational in nature. However, as discussed above, protocols that are developed following these guidelines should appropriately address privacy and security considerations. Helpful guidelines for security in relation to Internet protocol design can be found in &rfc3552;.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
This JEP requires no interaction with the Jabber Registrar.
+This document requires no interaction with the XMPP Registrar.
Existing Jabber protocols provide a strong foundation for the controlled, permissions-based sharing of files between Jabber entities, e.g., to enable shared workspaces among ad-hoc workgroups and the attachment of files to &jep0045; rooms.
+Existing Jabber protocols provide a strong foundation for the controlled, permissions-based sharing of files between Jabber entities, e.g., to enable shared workspaces among ad-hoc workgroups and the attachment of files to &xep0045; rooms.
This document defines several additional building blocks (a simple request protocol along with well-known service discovery nodes) that tie together existing protocols to enable the sharing of files between Jabber entities.
If an entity directly supports the protocol defined herein, it SHOULD include a feature of "http://jabber.org/protocol/files" in its response to a &jep0030; information request. The protocol flow is shown in the following example (an end user querying a chatroom):
+If an entity directly supports the protocol defined herein, it SHOULD include a feature of "http://jabber.org/protocol/files" in its response to a &xep0030; information request. The protocol flow is shown in the following example (an end user querying a chatroom):
This JEP stipulates that communications regarding files MUST occur by sending stanzas to the well-known service discovery node "files" (or sub-nodes thereof as defined below). Therefore, even if (as in the foregoing example) the file owner directly supports the protocol defined herein, the requesting entity MUST send subsequent file-related service discovery requests to the node "files" (or sub-nodes thereof). The file owner also SHOULD list that node in its response to a service discovery items request, as shown in the following example:
+This document stipulates that communications regarding files MUST occur by sending stanzas to the well-known service discovery node "files" (or sub-nodes thereof as defined below). Therefore, even if (as in the foregoing example) the file owner directly supports the protocol defined herein, the requesting entity MUST send subsequent file-related service discovery requests to the node "files" (or sub-nodes thereof). The file owner also SHOULD list that node in its response to a service discovery items request, as shown in the following example:
Note: The NodeID MUST begin with the string 'files' followed by the '/' character followed the name of the directory or file; further subdirectories or files within a directory MUST follow the same pattern (e.g., "files/somedir/anotherfile"). Thus the protocol defined herein enforces semantic meaning on NodeIDs; this is OPTIONAL within Service Discovery but REQUIRED by this JEP.
+Note: The NodeID MUST begin with the string 'files' followed by the '/' character followed the name of the directory or file; further subdirectories or files within a directory MUST follow the same pattern (e.g., "files/somedir/anotherfile"). Thus the protocol defined herein enforces semantic meaning on NodeIDs; this is OPTIONAL within Service Discovery but REQUIRED by this document.
If the offering entity has only a few files to share, it may be appropriate to make them available via service discovery only, thus requiring the requesting entity to "walk the tree" of directories and files as described in the Finding All Files via Service Discovery section. However, if the offering entity has a larger number of files to share, the number of service discovery requests and responses required to "walk the tree" of all directories and files might result in excessive amounts of traffic between the requesting entity and the offering entity; in this case, the offering entity SHOULD provide a "tree file" that defines the hierarchy of directories and files in the standardized format specified in the Retrieving the Tree File section. The number of files that counts as "large" is not defined herein and is left up to the implementation or deployment; in practice, it is RECOMMENDED for the offering entity to provide a tree file if it has more than five (5) files to share.
Obviously, finding all files via service discovery is a tedious process. Therefore, it is RECOMMENDED that the offering entity provide a "tree file" if it has more than five (5) files to share. The format of the tree file is defined by the 'http://jabber.org/profile/si/profile/tree-transfer' namespace that is specified in &jep0105;. The tree file MUST be named "tree.xml" and MUST be available at the well-known service discovery node "tree.xml". The offering entity MAY create a different tree file for each requesting entity (depending on the requesting entity's permissions to view certain directories and files); for this reason, the tree file SHOULD NOT be contained in the root "files" directory itself (note that its NodeID is "tree.xml", not "files/tree.xml").
+Obviously, finding all files via service discovery is a tedious process. Therefore, it is RECOMMENDED that the offering entity provide a "tree file" if it has more than five (5) files to share. The format of the tree file is defined by the 'http://jabber.org/profile/si/profile/tree-transfer' namespace that is specified in &xep0105;. The tree file MUST be named "tree.xml" and MUST be available at the well-known service discovery node "tree.xml". The offering entity MAY create a different tree file for each requesting entity (depending on the requesting entity's permissions to view certain directories and files); for this reason, the tree file SHOULD NOT be contained in the root "files" directory itself (note that its NodeID is "tree.xml", not "files/tree.xml").
If the offering entity provides a tree file, it MUST communicate that fact in the disco#items result it returns to the requesting entity in response to the initial request:
As is evident from the foregoing examples, neither "walking the tree" via Service Discovery nor retrieving the tree file will yield the kind of detailed information about a file (MIME type, file size, descriptive text, etc.) that can help a user or application decide whether to retrieve the file.
-To address the felt need for more detailed information about files, an offering entity MAY provide such information in response to disco#info requests sent to a specific NodeID (file or directory) by including extended information structured according to &jep0128;. The following examples illustrate this usage.
+To address the felt need for more detailed information about files, an offering entity MAY provide such information in response to disco#info requests sent to a specific NodeID (file or directory) by including extended information structured according to &xep0128;. The following examples illustrate this usage.
The fields shown are RECOMMENDED, and are specified more fully in the Jabber Registrar Considerations section of this document.
+The fields shown are RECOMMENDED, and are specified more fully in the XMPP Registrar Considerations section of this document.
Note: If the requested file was found by means of the tree file rather than service discovery, the NodeID of the retrieve request MUST be constructed according to the rules specified above for service discovery NodeIDs (i.e., 'files' followed by the '/' character followed by the name of the directory or file, followed by additional '/' characters and subdirectory or file names as needed).
-If the offering entity agrees to share the file with the requesting entity, it MUST return an IQ result to the requesting entity and then immediately initiate a file transfer to the requesting entity following the protocol defined in &jep0096;:
+If the offering entity agrees to share the file with the requesting entity, it MUST return an IQ result to the requesting entity and then immediately initiate a file transfer to the requesting entity following the protocol defined in &xep0096;:
The value of the <si/> element's 'id' attribute MUST be the same as the value of the 'sid' attribute communicated in the tree file or the 'name' attribute communicated via service discovery; for this reason, the service discovery 'name' attribute is REQUIRED for NodeIDs that correspond to files, and its value MUST follow the rules for the 'sid' attribute specified in JEP-0105.
+The value of the <si/> element's 'id' attribute MUST be the same as the value of the 'sid' attribute communicated in the tree file or the 'name' attribute communicated via service discovery; for this reason, the service discovery 'name' attribute is REQUIRED for NodeIDs that correspond to files, and its value MUST follow the rules for the 'sid' attribute specified in XEP-0105.
Upon receiving the file transfer initiation from the offering entity, the requesting entity SHOULD check the SI 'id' in order to correlate the file transfer with the request; if there is a match, the requesting entity SHOULD silently accept the file transfer and not require intervention by a human before proceeding.
-If the offering entity does not agree to share the file with the requesting entity, it MUST return an appropriate IQ error to the requesting entity, such as "Not Authorized", "Forbidden", "Payment Required", "Registration Required", or "Not Found" (see &jep0086; regarding error syntax).
+If the offering entity does not agree to share the file with the requesting entity, it MUST return an appropriate IQ error to the requesting entity, such as "Not Authorized", "Forbidden", "Payment Required", "Registration Required", or "Not Found" (see &xep0086; regarding error syntax).
A dedicated file-hosting service may agree to host files on behalf of a user or other entity, in which case the hosting service (or, to be precise, a specific resource of the hosting service) becomes the offering entity in the use cases defined herein. While the nature of such hosting services is outside the scope of this document, the following guidelines may be helpful to implementers.
-First, a file-hosting service SHOULD provide a distinct JID for each account on the service in order to enable communications between the requesting entity and the hosting service. For example, let us suppose that <files.shakespeare.lit> is a file-hosting service; specific accounts on the service could be structured as JIDs of the form <account@files.shakespeare.lit> or <files.shakespeare.lit/account>, in which case the requesting entity would communicate directly with that JID and treat that JID as the offering entity. The file-hosting service SHOULD enable the file owner (e.g., an end user whose JID is <romeo@montague.net>) to upload files to the service using standard Internet protocols (such as HTTP, FTP, scp, or JEP-0096), control who can view or retrieve files, and otherwise configure the offering entity. The file owner SHOULD also list the JID of the "offering entity" in response to service discovery items requests sent to the user's bare JID, so that requesting entities can find files hosted by the service on the file owner's behalf.
+First, a file-hosting service SHOULD provide a distinct JID for each account on the service in order to enable communications between the requesting entity and the hosting service. For example, let us suppose that <files.shakespeare.lit> is a file-hosting service; specific accounts on the service could be structured as JIDs of the form <account@files.shakespeare.lit> or <files.shakespeare.lit/account>, in which case the requesting entity would communicate directly with that JID and treat that JID as the offering entity. The file-hosting service SHOULD enable the file owner (e.g., an end user whose JID is <romeo@montague.net>) to upload files to the service using standard Internet protocols (such as HTTP, FTP, scp, or XEP-0096), control who can view or retrieve files, and otherwise configure the offering entity. The file owner SHOULD also list the JID of the "offering entity" in response to service discovery items requests sent to the user's bare JID, so that requesting entities can find files hosted by the service on the file owner's behalf.
It is possible that some Jabber server deployments would choose to offer file-hosting capabilities for their users (if supported in the underlying server implementation), so that the offering entity would have the same <user@host> address as the file owner. In this case, the server itself can be considered a file-hosting service.
Managing access to files and directories is the responsibility of the offering entity. However, the offering entity SHOULD NOT share files with requesting entities that are not known to it via presence subscription, prior registration, room occupancy, or some similar mechanism.
No interaction with &IANA; is required as a result of this JEP.
+No interaction with &IANA; is required as a result of this document.
Upon advancement of this JEP to a status of Draft, the ®ISTRAR; shall add the 'http://jabber.org/protocol/files' namespace to its registry of protocol namespaces.
+Upon advancement of this document to a status of Draft, the ®ISTRAR; shall add the 'http://jabber.org/protocol/files' namespace to its registry of protocol namespaces.
Upon advancement of this JEP to a status of Draft, the Jabber Registrar shall add 'files' and 'tree.xml' to its registry of well-known service discovery nodes.
+Upon advancement of this document to a status of Draft, the XMPP Registrar shall add 'files' and 'tree.xml' to its registry of well-known service discovery nodes.
Upon advancement of this JEP to a status of Draft, the Jabber Registrar shall add a category of 'filesys' to its registry of service discovery identities, with two associated types: 'directory' and 'file'.
+Upon advancement of this document to a status of Draft, the XMPP Registrar shall add a category of 'filesys' to its registry of service discovery identities, with two associated types: 'directory' and 'file'.
&jep0068; defines a process for standardizing the fields used within Data Forms scoped by a particular namespace. This JEP reserves the FORM_TYPE "http://jabber.org/protocol/files" as well as specific fields for use within the context of that FORM_TYPE, as specified in the following registry submission.
+&xep0068; defines a process for standardizing the fields used within Data Forms scoped by a particular namespace. This document reserves the FORM_TYPE "http://jabber.org/protocol/files" as well as specific fields for use within the context of that FORM_TYPE, as specified in the following registry submission.
http://jabber.org/protocol/files
- JEP-01xx
+ XEP-01xx
Service Discovery extension for file descriptions.
Added preferences, results set management and notes; reinstated encryption and replication; simplified auto-archiving and off-the-record (with JEP-0155); many minor changes
Added preferences, results set management and notes; reinstated encryption and replication; simplified auto-archiving and off-the-record (with XEP-0155); many minor changes
Integrated text from server-side archiving proposal; added partial support to collection retrieval; harmonized XML formats and namespaces; defined Jabber Registrar considerations and XML schema.
Integrated text from server-side archiving proposal; added partial support to collection retrieval; harmonized XML formats and namespaces; defined XMPP Registrar considerations and XML schema.
Complying with XMPP Core, the server MUST respond to all &IQ; element of type 'get' or 'set'. However, most successful responses have been omitted from this document in the interest of conciseness.
A client discovers whether its server supports this protocol using &jep0030;.
+A client discovers whether its server supports this protocol using &xep0030;.
A user will sometimes exchange messages with contacts who prefer that their conversations are not archived by either party. Any client that archives messages SHOULD support &jep0155; and its 'otr' field both to give other contacts the opportunity to indicate this preference, and to negotiate an "Off The Record" (OTR) policy that complies with its user's own Archiving Preferences.
+A user will sometimes exchange messages with contacts who prefer that their conversations are not archived by either party. Any client that archives messages SHOULD support &xep0155; and its 'otr' field both to give other contacts the opportunity to indicate this preference, and to negotiate an "Off The Record" (OTR) policy that complies with its user's own Archiving Preferences.
A client MUST NOT agree to enable OTR unless it has confirmed that its server will allow it to switch off Automated Archiving.
If a Chat Session Negotiation agreed to enable OTR then the clients MUST NOT allow messages sent in either direction to be archived in any way (including Manual Archiving and Automated Archiving).
Note: If a contact does not include an 'otr' field in its initial Chat Session Negotiation request, and a user's Archiving Preferences indicate that OTR is required, then the client MUST refuse the request. It MAY then send its own Chat Session Negotiation request with an 'otr' field.
@@ -286,7 +286,7 @@While automated archiving is easy for the client and server to implement, there are many contexts in which manual archiving is required. For examples, when:
The client uniquely specifies a collection using a pair of attributes:
A friendly name for the collection MAY be specified with a 'subject' attribute. Note the Security Considerations regarding the subject attribute.
Each collection MAY contain <note/>, <to/> or <from/> elements (or <EncryptedData/> and <EncryptedKey/> elements - see Encryption).
@@ -352,7 +352,7 @@ ]]>A client MAY archive messages that it receives from &jep0045; rooms. The 'with' attribute MUST be the bare JID of the room. The client MUST include a 'name' attribute for each <from/> element to specify the room nickname of the message sender:
+A client MAY archive messages that it receives from &xep0045; rooms. The 'with' attribute MUST be the bare JID of the room. The client MUST include a 'name' attribute for each <from/> element to specify the room nickname of the message sender:
The examples above are not encrypted for clarity. However, clients SHOULD encrypt manually-archived collections (although early implementations of this protocol MAY prefer to defer encryption and decryption to later versions). Servers MUST support the manual-archiving of encrypted collections.
Before uploading a sequence of messages to a collection, the client SHOULD select a symmetric data encryption algorithm, generate a suitable random encryption key, give the key a unique (for the user) name, encrypt the symmetric key with one of the user's public keys, and wrap the result inside one or more <EncryptedKey/> elements, as specified in &w3xmlenc;.
-To ensure that all its user's clients will be able to decrypt the collection, the client SHOULD create one <EncryptedKey/> element for each of its user's public keys that are being published using &jep0189;. However, the client MUST NOT create an <EncryptedKey/> element for any public key until it has confirmed that it belongs to the user. Note: The fact that a public key is being published using Public Key Publishing is not sufficient proof of ownership, since the user's server may have been compromised at some stage. The method of confirmation is beyond the scope of this document.
+To ensure that all its user's clients will be able to decrypt the collection, the client SHOULD create one <EncryptedKey/> element for each of its user's public keys that are being published using &xep0189;. However, the client MUST NOT create an <EncryptedKey/> element for any public key until it has confirmed that it belongs to the user. Note: The fact that a public key is being published using Public Key Publishing is not sufficient proof of ownership, since the user's server may have been compromised at some stage. The method of confirmation is beyond the scope of this document.
The client SHOULD use the symmetric key to encrypt the joined sequence of <to/>, <from/> and <note/> elements, base64 encode the resulting sequence of bytes, and wrap it inside an <EncryptedData/> element, as described in XML Encryption.
Clients may add one or more <EncryptedData/> or <EncryptedKey/> elements to a collection using exactly the same method as for <to/>, <from/> and <note/> elements (see Uploading Messages to a Collection). One collection may contain <EncryptedData/> elements encrypted with different symmetric keys.
When appending <EncryptedData/> elements to a collection, the client MAY reuse a symmetric KEY that has already been uploaded to the collection. In this case the client SHOULD NOT resend <EncryptedKey/> elements.
@@ -424,7 +424,7 @@A client MAY enable or disable automatic archiving for messages sent over its stream. Automatic archiving MUST default to disabled for each new stream that is opened, unless administrator policies require that every message is logged automatically (see Security Considerations). Once automatic archiving is switched on then the server MUST automatically archive messages only according to the user's general Archiving Preferences.
-Note: Both parties to an ESession (see &jep0116;) MUST either disable archiving or use an archiving method other than automatic, since ESession decryption keys are short-lived - making it impossible to decrypt automatically archived messages.
+Note: Both parties to an ESession (see &xep0116;) MUST either disable archiving or use an archiving method other than automatic, since ESession decryption keys are short-lived - making it impossible to decrypt automatically archived messages.
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 &jep0059;. Clients and servers SHOULD support all the features defined in that protocol.
+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 Jabber Date and Time Profiles). The 'with' attribute MAY be specified to limit the list to a single participating full JID, bare JID or domain.
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.
@@ -901,7 +901,7 @@After receiving each result set page the client SHOULD delete from its local archive any collections that have been removed from the master archive. The client should also retrieve from the server the content of each collection that has been modified (see Retrieving a Collection) and add it to its local copy of the archive (deleting any older version of the same collection that it may already have).
Note the file format specified in this section is likely to be deprecated once a standards-based format has been published in a separate JEP.
+Note the file format specified in this section is likely to be deprecated once a standards-based format has been published in a separate specification.
So that clients can share archived messages, this document specifies a common format for storage on disk (similar to email formats like mbox and Maildir). The file format uses the same XML constructs as the protocol. Each file may contain messages exchanged with a single JID. Any number of items may be stored in an archive file.
When creating a new collection, it is RECOMMENDED that the client synchronizes the collection start time that it sends to the server with server time. This is important since the user may subsequently retrieve the stored collection using client machines whose UTC clocks are not synchronized with the client machine that stored the collection. (i.e. Either or both of the clients' UTC clocks may be wrong.) The client can achieve this synchronization with server time by using &jep0090; to estimate the difference between the server and client UTC clocks.
+When creating a new collection, it is RECOMMENDED that the client synchronizes the collection start time that it sends to the server with server time. This is important since the user may subsequently retrieve the stored collection using client machines whose UTC clocks are not synchronized with the client machine that stored the collection. (i.e. Either or both of the clients' UTC clocks may be wrong.) The client can achieve this synchronization with server time by using &xep0090; to estimate the difference between the server and client UTC clocks.
When retrieving collections, it is RECOMMENDED that the client adjusts the start times of the collections it receives from server to be synchronized with the clock of the client machine.
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 'otr' field defined in JEP-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 'otr' field defined in XEP-0155).
Since the subject of each collection will not be encrypted, the client MUST warn its human user (if any) before including 'subject' attributes on encrypted collections.
The client that originates a message MAY specify a 'false' value for the 'store' header (see &jep0131;). The recipient MUST NOT archive such a message or any of the information it contains.
+The client that originates a message MAY specify a 'false' value for the 'store' header (see &xep0131;). The recipient MUST NOT archive such a message or any of the information it contains.
If the sender plans to use 'store' headers it MUST use Service Discovery to determine whether or not the recipient supports them. Note: Since servers are not required to check the content of message stanzas for headers, if the recipient is using automatic archiving then it MUST indicate that it does not support 'store' headers.
If the recipient does not support 'store' headers, then the sender MUST confirm with its human user (if any) before sending such a message.
No interaction with &IANA; is required as a result of this JEP.
+No interaction with &IANA; is required as a result of this document.
The ®ISTRAR; shall include 'http://jabber.org/protocol/archive' in its registry of protocol namespaces (see &NAMESPACES;):
The Jabber Registrar shall include the following features in its registry of service discovery features (see &DISCOFEATURES;):
+The XMPP Registrar shall include the following features in its registry of service discovery features (see &DISCOFEATURES;):
&jep0095; defines a protocol to initiate a data stream between two Jabber/XMPP entities (e.g., for the purpose of &jep0096;). However, the sender is still responsible for informing potential receivers about the existence of a given stream. This JEP provides an automated way for a sender to announce the availability of a stream without initiating the data transfer. The purpose is to provide a "pull" protocol that enables a receiver to then request initiation of the stream from the sender.
+&xep0095; defines a protocol to initiate a data stream between two Jabber/XMPP entities (e.g., for the purpose of &xep0096;). However, the sender is still responsible for informing potential receivers about the existence of a given stream. This JEP provides an automated way for a sender to announce the availability of a stream without initiating the data transfer. The purpose is to provide a "pull" protocol that enables a receiver to then request initiation of the stream from the sender.
This proposal addresses the following requirements:
A stream owner uses the <sipub/> element to announce that it can perform a specific SI request. This element can be sent to a publish-subscribe (JEP-0060) node, or sent directly to potential recipients within a &MESSAGE; stanza.
+A stream owner uses the <sipub/> element to announce that it can perform a specific SI request. This element can be sent to a publish-subscribe (XEP-0060) node, or sent directly to potential recipients within a &MESSAGE; stanza.
The format of the <sipub/> element is as follows:
This format is nearly identical to that for the stream initiation <si/> element (see JEP-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 XEP-0095). 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.
@@ -126,7 +126,7 @@ ]]> -The <sipub/> element MAY also be included directly within a &MESSAGE; stanza sent to another entity (or multiple entities, e.g., in &jep0045; or via &jep0033;). This can be especially useful for informing an offline entity about an available stream.
+The <sipub/> element MAY also be included directly within a &MESSAGE; stanza sent to another entity (or multiple entities, e.g., in &xep0045; or via &xep0033;). This can be especially useful for informing an offline entity about an available stream.
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 &jep0122;. 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 JEP-0096:
+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:
This JEP introduces no security concerns beyond those specified in JEP-0060 and the relevant Stream Initiation profile in use.
+This JEP introduces no security concerns beyond those specified in XEP-0060 and the relevant Stream Initiation profile in use.
This JEP requires no interaction with &IANA;.
The ®ISTRAR; includes 'http://jabber.org/protocol/sipub' in its registry of protocol namespaces.
The Jabber Registrar includes 'sipub:' in its registry of Data Forms Validation Datatype Prefixes.
+The XMPP Registrar includes 'sipub:' in its registry of Data Forms Validation Datatype Prefixes.
Normally, each SI profile that wishes to be considered for use with Data Forms MUST register its own datatype qualified by the "sipub:" prefix. However, this JEP provides an initial seed, based on the currently accepted SI profiles. The following datatypes shall be registered for use with Data Forms Validation:
sipub:file-transfer
Datatype for publishing an SI using the File Transfer Profile
- JEP-0096
+ XEP-0096
]]>
&xmppcore; specifies the use of Transport Layer Security (TLS; see &rfc2246;) for encryption of XML streams, and TLS includes the ability to compress encrypted traffic (see &rfc3749;). However, not all computing platforms are able to implement TLS, and traffic compression may be desirable for communication by applications on such computing platforms. This JEP defines a mechanism for negotiating the compression of XML streams outside the context of TLS.
+&xmppcore; specifies the use of Transport Layer Security (TLS; see &rfc2246;) for encryption of XML streams, and TLS includes the ability to compress encrypted traffic (see &rfc3749;). However, not all computing platforms are able to implement TLS, and traffic compression may be desirable for communication by applications on such computing platforms. This document defines a mechanism for negotiating the compression of XML streams outside the context of TLS.
Because security is a core value within the Jabber community, it is appropriate for the Jabber Software Foundation to assess potential security threats related to technologies that implement the Jabber protocols (including XMPP and defined XMPP extensions), as well as ways to address the threats (for general information about the Internet threat model, see &rfc3552;). Furthermore, since security threats are wide-ranging and of broad concern, it would be valuable for interested members of the entire Jabber community to discuss these matters. Unfortunately, security discussions can often be theoretical, contentious, and inconclusive. Thus it is imperative that discussion proceed based on a methodical process of threat identification, risk analysis, and prioritization before moving on to documentation of threat responses (preferably in protocol specifications such as &jep0001;). This JEP proposes a forum and process for such security discussions in the form of a Jabber Interest Group (see &jep0002;) that shall report to the &COUNCIL; in accordance with Article VIII of the &BYLAWS;.
+Because security is a core value within the Jabber community, it is appropriate for the Jabber Software Foundation to assess potential security threats related to technologies that implement the Jabber protocols (including XMPP and defined XMPP extensions), as well as ways to address the threats (for general information about the Internet threat model, see &rfc3552;). Furthermore, since security threats are wide-ranging and of broad concern, it would be valuable for interested members of the entire Jabber community to discuss these matters. Unfortunately, security discussions can often be theoretical, contentious, and inconclusive. Thus it is imperative that discussion proceed based on a methodical process of threat identification, risk analysis, and prioritization before moving on to documentation of threat responses (preferably in protocol specifications such as &xep0001;). This document proposes a forum and process for such security discussions in the form of a Jabber Interest Group (see &xep0002;) that shall report to the &COUNCIL; in accordance with Article VIII of the &BYLAWS;.
The role of the Security JIG shall be to identify and describe security threats related to Jabber technologies, analyze their potential risk, assign priorities to each threat, provide references to existing responses, and (where appropriate) provisionally recommend improvements in Jabber protocols and technologies in order to address the identified threats. The Security JIG shall not itself develop or approve protocols, which tasks shall remain under the purview of the &SJIG; and the Jabber Council respectively.
@@ -75,7 +75,7 @@The template will not fully define the foregoing information, but instead specify what information must be defined for each threat when completing the analysis described in Step 3.
An evolving document that completes the template defined in Step 2 for all identified threats by following the process established in Step 1. The result will be a thorough analysis of all potential security threats related to Jabber protocols and technologies. Note: This document shall not define complete solutions to the identified threats, although it may outline potential and recommended approaches. Solutions shall be defined in standalone documents such as JEPs.
+An evolving document that completes the template defined in Step 2 for all identified threats by following the process established in Step 1. The result will be a thorough analysis of all potential security threats related to Jabber protocols and technologies. Note: This document shall not define complete solutions to the identified threats, although it may outline potential and recommended approaches. Solutions shall be defined in standalone documents such as XEPs.