Initial JEP version.
Initial version.
When a Jabber instant messaging client connects to its server, it typically retrieves a great deal of information, such as a user's roster, privacy lists, and service discovery information. However, this information may not have changed since the client last retrieved the data. In order to improve client start-up time or conserve bandwidth in certain environments, it would be desirable if the client could cache the information and retrieve it only if it has changed.
-Such a mechanism exists as part of &rfc2616; in the form of the Entity Tags, which are included in the ETag and If-None-Match headers used for HTTP caching. Since &jep0131; enables an XMPP entity to communicate any HTTP header, it should be possible to re-use existing Entity Tag semantics for caching information sent over an XMPP network. This JEP defines best practices for such functionality, which could be used between any two XMPP entities that support SHIM headers (though it is envisioned to be most useful for clients that retrieve information from servers and services).
+Such a mechanism exists as part of &rfc2616; in the form of the Entity Tags, which are included in the ETag and If-None-Match headers used for HTTP caching. Since &xep0131; enables an XMPP entity to communicate any HTTP header, it should be possible to re-use existing Entity Tag semantics for caching information sent over an XMPP network. This document defines best practices for such functionality, which could be used between any two XMPP entities that support SHIM headers (though it is envisioned to be most useful for clients that retrieve information from servers and services).
This JEP addresses the following requirements:
+This document addresses the following requirements:
In HTTP, an "entity" is the information transferred as the payload of a request or response, and an "Entity Tag" is an opaque string that uniquely identifies that payload. For example, when an HTTP server sends an entity in an HTTP response, it can include an ETag header that identifies the payload as cacheable, and the client can cache that entity; in future requests, the client can include the same value in an If-None-Match header and the server will either return an HTTP 304 ("Not Modified") error if the entity has not changed or return the entity in the HTTP response if it has changed. (Note: For information about the semantics of Entity Tags, the ETag header, and the If-None-Match header, refer to Sections 3.11, 14.19, and 14.26 respectively of RFC 2616.)
-Similarly, the basic concept behind XMPP Entity Tag use is semantically equivalent to the use in HTTP; this is made possible by a straightforward application of SHIM headers as specified in JEP-0131. In the context of an IQ request-response interaction, the responding entity will include an ETag SHIM header in its IQ response (indicating that the data can be cached), the requesting entity will include that identical value in an If-None-Match SHIM header when it queries the server for the same entity, and the responding entity will return either an IQ result with the changed entity or an IQ error indicating that the entity has not changed.
+Similarly, the basic concept behind XMPP Entity Tag use is semantically equivalent to the use in HTTP; this is made possible by a straightforward application of SHIM headers as specified in 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 can be cached), the requesting entity will include that identical value in an If-None-Match SHIM header when it queries the server for the same entity, and the responding entity will return either an IQ result with the changed entity or an IQ error indicating that the entity has not changed.
Here is an example of such a request-response flow (the example is that of roster retrieval):
Note: The <not-modified/> error is not specified as a stanza error in &rfc3920; and an error code of 304 was not included in the older Jabber error codes (see &jep0086;). The authors of this proposal will request that the <not-modified/> error condition be added to the successor to RFC 3920 during the process of revising the XMPP specifications within the Internet Standards Process.
+Note: The <not-modified/> error is not specified as a stanza error in &rfc3920; and an error code of 304 was not included in the older Jabber error codes (see &xep0086;). The authors of this proposal will request that the <not-modified/> error condition be added to the successor to RFC 3920 during the process of revising the XMPP specifications within the Internet Standards Process.
Note: In HTTP, an Entity Tag may be either "strong" or "weak" (see Section 13.3.3 of RFC 2616); Entity Tags as used in XMPP extensions MUST be considered strong rather than weak.
-Note: The ETag and If-None-Match headers SHOULD be used only in &IQ; stanzas, although they MAY be used in &MESSAGE; stanza interactions if IQ request-response semantics are not appropriate, for example in &jep0072; and in certain applications that use &jep0004;.
+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;.
JEP-0131 specifies how support for a particular SHIM header can be determined using &jep0030;. To review, the protocol flow between a client and a server would be as follows:
+XEP-0131 specifies how support for a particular SHIM header can be determined using &xep0030;. To review, the protocol flow between a client and a server would be as follows:
The client now knows that the server supports the ETag and If-None-Match SHIM headers and can proceed accordingly.
Note: If an XMPP entity supports Entity Tags, it MUST at a minimum support both the ETag and If-None-Match SHIM headers.
-Note: Even if an entity supports the ETag and If-None-Match SHIM headers, it is not required to support Entity Tag functionality for all namespaces. For example, a server could support Entity Tags only for rosters and privacy lists but not for the 'jabber:iq:last' or 'jabber:iq:version' namespaces. Similarly, a &jep0045; service could support Entity Tags only for room lists (retrieved via a "disco#items" request) but not for other requests. As noted, if an entity does not support Entity Tags for a given namespace or request, it SHOULD proceed as if the ETag or If-None-Match SHIM header had not been included in the request.
+Note: Even if an entity supports the ETag and If-None-Match SHIM headers, it is not required to support Entity Tag functionality for all namespaces. For example, a server could support Entity Tags only for rosters and privacy lists but not for the 'jabber:iq:last' or 'jabber:iq:version' namespaces. Similarly, a &xep0045; service could support Entity Tags only for room lists (retrieved via a "disco#items" request) but not for other requests. As noted, if an entity does not support Entity Tags for a given namespace or request, it SHOULD proceed as if the ETag or If-None-Match SHIM header had not been included in the request.
Optionally, an entity MAY communicate the namespaces for which it supports Entity Tag functionality by listing those namespaces in its response to a "disco#info" request sent to a node of "http://jabber.org/protocol/shim#ETag":
This proposal requires no interaction with &IANA;.
This proposal requires no interaction with the ®ISTRAR;.
This JEP describes best practices for use of JEP-0131 and therefore does not require a dedicated schema.
+This document describes best practices for use of XEP-0131 and therefore does not require a dedicated schema.
Is the ETag tied to a bare JID or full JID?
Initial JEP version.
Initial version.
The traffic goals can be met by using only the initial &PRESENCE; stanza, which carries all required information, so that no peer-to-peer messages are required on entering. VP clients which gather additional information about peers (e.g. avatar images) should cache the data so that it can be re-used. This is especially important since users browsing virtually connected locations (i.e. linked pages) may meet very often in a short time.
-The virtual presence extensions make use of Jabber group chat. Virtual locations are implemented as public Jabber chat channels. The proposed protocol works with &jep0045; rooms and GroupChat 1.0 compatible services. Its core functionality described here uses only groupchat features.
+The virtual presence extensions make use of Jabber group chat. Virtual locations are implemented as public Jabber chat channels. The proposed protocol works with &xep0045; rooms and GroupChat 1.0 compatible services. Its core functionality described here uses only groupchat features.
The virtual presence extensions are supposed to be implemented by Jabber IM clients in addition to the IM functions or by pure virtual presence (Jabber VP) clients.
@@ -201,7 +201,7 @@Juliet gets the equivalent. Romeo's VP client shows Juliet's presence by adding a second avatar to the page. They now engage in a vivid conversation. In deviation to the original text Juliet would not ask "Who art thou, Romeo?", because she only knows the nickname and on the other hand she actually knows where Romeo is: he is on the same web page. There is nothing new until now. Everything happened according to GroupChat 1.0 (JEP-0045) without MUC features. Of course, users can join the same room with any client that supports GroupChat, if they know the room's JID.
+Juliet gets the equivalent. Romeo's VP client shows Juliet's presence by adding a second avatar to the page. They now engage in a vivid conversation. In deviation to the original text Juliet would not ask "Who art thou, Romeo?", because she only knows the nickname and on the other hand she actually knows where Romeo is: he is on the same web page. There is nothing new until now. Everything happened according to GroupChat 1.0 (XEP-0045) without MUC features. Of course, users can join the same room with any client that supports GroupChat, if they know the room's JID.
Extensions come into the play in order to make the virtual presence more attractive and more vivid.
@@ -790,8 +790,8 @@ http://www.shakespeare.com/_vpi.xml]]>The fact that clients may disclose their JID in order to provide access to their avatar server storage and in order to enable caching is a weak point. A different but equally unique ID could be for caching purposes, provided that it is part of the &PRESENCE; stanza. But traffic restrictions on the client connection prevent that additional data is exchanged between peers in a room. The data could be broadcast to the room, but this could end up in many people always broadcasting avatars while entering a room (web page). The chosen solution is to let peers download from public server storage. A better solution might be to let the conference component fetch from the server storage. In this case clients would need only the room-JID of the user, not the real JID.
-These namespaces need to be reviewed and/or registered with the Jabber Registrar as a result of this JEP.
+ These namespaces need to be reviewed and/or registered with the XMPP Registrar as a result of this document.
Initial JEP version.
Initial version.
Sometimes it is desirable or necessary to switch from instant messaging (IM) to another real-time communications medium, such as a telephone conversation conducted over the traditional public switched telephone network (PSTN) or more recent Voice over Internet Protocol (VoIP) applications. In order to facilitate switching from IM to telephony or some other medium, a user needs to advertise the address(es) at which they can be reached. There are several possible ways to do this:
Publish the reachability address(es) in the user's vCard (see &jep0054;); this is convenient, but is not very dynamic (e.g., reachability addresses might change when the user moves to a new conference room in an office building).
Publish the user's reachability status (but not addresses) as a feature bundle within &jep0115; information; this is somewhat dynamic (subscribers can be informed when reachability information is available) but requires every interested subscriber to perform service discovery in order to determine the reachability address(es).
Send the reachability address(es) within a &PRESENCE; stanza; this option is described in the Presence Broadcast section of this JEP and is consistent with Section 5.1.2 of &rfc3921; since reachability is one aspect of a user's availability for communication.
Send reachability address(es) to the appropriate &jep0163; node; this option is described in the PEP Transport section of this JEP but may not be available at all service providers.
Publish the reachability address(es) in the user's vCard (see &xep0054;); this is convenient, but is not very dynamic (e.g., reachability addresses might change when the user moves to a new conference room in an office building).
Publish the user's reachability status (but not addresses) as a feature bundle within &xep0115; information; this is somewhat dynamic (subscribers can be informed when reachability information is available) but requires every interested subscriber to perform service discovery in order to determine the reachability address(es).
Send the reachability address(es) within a &PRESENCE; stanza; this option is described in the Presence Broadcast section of this document and is consistent with Section 5.1.2 of &rfc3921; since reachability is one aspect of a user's availability for communication.
Send reachability address(es) to the appropriate &xep0163; node; this option is described in the PEP Transport section of this document but may not be available at all service providers.
This JEP addresses the following requirements:
+This document addresses the following requirements:
As described below, this JEP specifies two methods of advertising reachability addresses:
+As described below, this document specifies two methods of advertising reachability addresses:
This JEP does not recommend one transport method over the other.
+This document does not recommend one transport method over the other.
In addition, a contact MAY request a user's reachability addresses using an &IQ; request-response sequence.
In order to broadcast reachability addresses in presence information, a user's client includes the <reach/> element in the &PRESENCE; stanza it sends to its server:
@@ -111,7 +111,7 @@ ]]>In order to publish reachability via the publish-subscribe transport, an entity MUST first create the appropriate node as explained in JEP-0060. Here we assume that the node already exists.
+In order to publish reachability via the publish-subscribe transport, an entity MUST first create the appropriate node as explained in XEP-0060. Here we assume that the node already exists.
If a client supports the reachability addresses protocol described herein, it SHOULD include a &jep0030; feature of 'http://jabber.org/protocol/reach' in its replies to disco#info requests:
+If a client supports the reachability addresses protocol described herein, it SHOULD include a &xep0030; feature of 'http://jabber.org/protocol/reach' in its replies to disco#info requests:
If included, the <desc/> element SHOULD possess an 'xml:lang' attribute specifying the language of the human-readable descriptive text for a particular address.
This document introduces no security considerations above and beyond those described in RFC 3920, RFC 3921, and (for the personal eventing transport) JEP-0163.
+This document introduces no security considerations above and beyond those described in RFC 3920, RFC 3921, and (for the personal eventing transport) XEP-0163.
This document requires no interaction with &IANA;.
The ®ISTRAR; shall include 'http://jabber.org/protocol/reach' in its registry of protocol namespaces.
There exist several proposed protocols for communicating user avatar information over Jabber/XMPP (see &jep0008; and &jep0084;). This document describes another such protocol that is in use today on the Jabber/XMPP network. This document is historical and does not purport to propose a standards-track protocol. However, a future protocol may improve on the approach documented herein.
+There exist several proposed protocols for communicating user avatar information over Jabber/XMPP (see &xep0008; and &xep0084;). This document describes another such protocol that is in use today on the Jabber/XMPP network. This document is historical and does not purport to propose a standards-track protocol. However, a future protocol may improve on the approach documented herein.
The protocol described herein seems to have been designed with the following requirements in mind:
@@ -83,7 +83,7 @@Before informing contacts of the user's avatar, the user's client first publishes the avatar data to the user's public vCard using the protocol defined in &jep0054;.
+Before informing contacts of the user's avatar, the user's client first publishes the avatar data to the user's public vCard using the protocol defined in &xep0054;.
When the recipient's client receives the hash of the avatar image, it SHOULD check the hash to determine if it already has a cached copy of that avatar image. If not, it retrieves the sender's full vCard in accordance with the protocol flow describerd in JEP-0054 (note that this request is sent to the user's bare JID, not full JID):
+When the recipient's client receives the hash of the avatar image, it SHOULD check the hash to determine if it already has a cached copy of that avatar image. If not, it retrieves the sender's full vCard in accordance with the protocol flow describerd in XEP-0054 (note that this request is sent to the user's bare JID, not full JID):
The following rules apply to inclusion of the update child element (<x xmlns='vcard-temp:x:update'/>) in presence broadcasts:
If a client supports the protocol defined herein, it MUST include the update child element in every presence broadcast it sends and SHOULD also include the update child in directed presence stanzas (e.g., directed presence sent when joining &jep0045; rooms).
If a client supports the protocol defined herein, it MUST include the update child element in every presence broadcast it sends and SHOULD also include the update child in directed presence stanzas (e.g., directed presence sent when joining &xep0045; rooms).
If a client is not yet ready to advertise an image, it MUST send an empty update child element, i.e.:
This document introduces no security considerations above and beyond those described in &rfc3920;, &rfc3921;, and &jep0054;.
+This document introduces no security considerations above and beyond those described in &rfc3920;, &rfc3921;, and &xep0054;.
This document requires no interaction with &IANA;.
The ®ISTRAR; includes 'vcard-temp:x:update' in its registry of protocol namespaces (see &NAMESPACES;).
The author wishes to thank the helpful developers who have implemented this protocol and provided feedback regarding its documentation.
Updated to reflect changes to JEP-0163; added some mappings to the eduPerson object class.
Updated to reflect changes to XEP-0163; added some mappings to the eduPerson object class.
Initial JEP version.
Initial version.
It is widely acknowledged within the Jabber/XMPP community that the &jep0054; specification (JEP-0054) has outlived its usefulness. There are several reasons for this conclusion:
+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:
Given the weaknesses of vCard, there is interest across the broader Internet community in replacing vCard with something more modern and extensible. Unfortunately, no other standards development organization has developed an alternative to vCard. Part of the challenge is that quite detailed ontologies have been developed that might replace parts of the vCard specification (e.g., the Extensible Name and Address Language
Because of the unsettled landspace and the strong desire within the Jabber/XMPP community to move beyond JEP-0054, this JEP specifies methods for the representation of profile data in terms of the &jep0004; protocol (further qualified using the standardization concepts specified in &jep0068;) and for the management of profile data using standard IQ request-response semantics as well as, for more frequently-modified data, &jep0060; semantics (specifically the simplified subset of those semantics specified in &jep0163;). The rationale behind these design decisions is provided below.
+Because of the unsettled landspace and the strong desire within the Jabber/XMPP community to move beyond XEP-0054, this document specifies methods for the representation of profile data in terms of the &xep0004; protocol (further qualified using the standardization concepts specified in &xep0068;) and for the management of profile data using standard IQ request-response semantics as well as, for more frequently-modified data, &xep0060; semantics (specifically the simplified subset of those semantics specified in &xep0163;). The rationale behind these design decisions is provided below.
This JEP addresses the following requirements for data management:
+This document addresses the following requirements for data management:
This JEP addresses the following requirements for data representation:
+This document addresses the following requirements for data representation:
IQ (request-and-response) semantics.
-In the simplest case, an entity may store its own profile data and provide only the complete profile and only on request, using the request-response semantics of the XMPP &IQ; stanza type. This model is most appropriate for stable entities that are always online and whose profile data does not change frequently, such as servers and server-side components (entities that are not always online or that frequently modify their profile data, such as IM users, may prefer to publish their information to entities that are always online, such as an IM user's server). While it may seem desirable to embed profile data in the responses an entity provides to service discovery information requests using &jep0128;, it is likely that profile data will be quite extensive; therefore, we define a standalone "wrapper" element for profile data, qualified by the 'http://jabber.org/protocol/profile' namespace.
+In the simplest case, an entity may store its own profile data and provide only the complete profile and only on request, using the request-response semantics of the XMPP &IQ; stanza type. This model is most appropriate for stable entities that are always online and whose profile data does not change frequently, such as servers and server-side components (entities that are not always online or that frequently modify their profile data, such as IM users, may prefer to publish their information to entities that are always online, such as an IM user's server). While it may seem desirable to embed profile data in the responses an entity provides to service discovery information requests using &xep0128;, it is likely that profile data will be quite extensive; therefore, we define a standalone "wrapper" element for profile data, qualified by the 'http://jabber.org/protocol/profile' namespace.
Pubsub (publish-and-subscribe) semantics.
-A more complex model is for an entity to publish its profile data to a publish-subscribe node or nodes and allow other entities to subscribe to that node or nodes, thus receiving notifications whenever the profiled entity updates its data. This model is more appropriate for entities that modify their profile data on a regular basis or when other entities wish to be informed when the profile data changes. Because this model will most likely be used most often by IM users and other intermittently-connected network endpoints, we use the simplified subset of the XMPP publish-subscribe extension defined in JEP-0163 to implement this model.
+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.
As with data management, there are several possible approaches to representing profile data for communication over XMPP networks, including the following:
Structured data formats, such as &jep0080; and &jep0112;.
+Structured data formats, such as &xep0080; and &xep0112;.
Such data formats have the advantage of being human-readable. However:
A format represented by means of &w3rdf;.
An argument could be made that RDF is a reasonable approach for representing profile data for communication over the XMPP network; however, such an argument will not be made in the current proposal. The author has considered RDF and has concluded that there are several reasons why RDF is undesirable as an XMPP wire protocol:
A format represented by means of Data Forms (JEP-0004).
-The Data Forms protocol defined in JEP-0004 has several advantages for use over XMPP:
+A format represented by means of Data Forms (XEP-0004).
+The Data Forms protocol defined in XEP-0004 has several advantages for use over XMPP:
Therefore, this proposal specifies that profile data shall be scoped by a FORM_TYPE of 'http://jabber.org/protocol/profile', in accordance with the field standardization methods defined in JEP-0068. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the ®ISTRAR; (although they may or may not be defined in a Jabber Enhancement Proposal). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of JEP-0068.
Therefore, this proposal specifies that profile data shall be scoped by a FORM_TYPE of 'http://jabber.org/protocol/profile', in accordance with the field standardization methods defined in 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 Jabber Enhancement Proposal). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of 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 'http://jabber.org/protocol/profile', this proposal does not mean to imply that all profile data will or should be gathered in one data form. In reality, most such data will probably be gathered at the time of registration either at a website or via a "wizard" interface that breaks the process into smaller bundles (such as "Basic Personal Data", "Physical Location", "Internet Addresses", "Hobbies and Interests", and "Favorite Things"). The use of one FORM_TYPE is simply meant to scope the data fields so that each field is unique within the context of profile data. Any form that uses these fields along with a FORM_TYPE of 'http://jabber.org/protocol/profile' is of the "profile type" (i.e., is a specific instance of that type), which does not limit the number of forms that can be of that type.
However, scoping all data fields with a single FORM_TYPE implies it is necessary to define separate data fields for similar kinds of information. For example, the vCard specification (RFC 2426) defines "types" for certains kinds of data, such as email addresses, telephone numbers, and physical addresses, making it possible to specify that a telephone number corresponds to a fax machine or mobile phone or that a physical address corresponds to one's home or work location. In the Data Forms representation, any desired piece of information (e.g., work phone) must be represented with a separate data field.
-In order to address most (if not all) of the pieces of information described in existing profile specifications, this JEP defines a great number of data fields. Even so, the data fields specified herein are not exhaustive, and it is expected that additional fields will be registered in the future through the mechanisms specified in the Jabber Registrar Considerations section of this JEP.
+In order to 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 "http://jabber.org/protocol/profile" at its server using the PEP subset of the publish-subscribe extension, as specified in JEP-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 "http://jabber.org/protocol/profile" at its server using the PEP subset of the publish-subscribe extension, as specified in XEP-0163.
If an entity can provide profile data directly using the standalone 'http://jabber.org/protocol/profile' namespace, it SHOULD advertise that feature in response to &jep0030; information requests:
+If an entity can provide profile data directly using the standalone 'http://jabber.org/protocol/profile' namespace, it SHOULD advertise that feature in response to &xep0030; information requests:
If the server allows the subscription, it MUST return an IQ-result (see JEP-0163 for error scenarios):
+If the server allows the subscription, it MUST return an IQ-result (see XEP-0163 for error scenarios):
The following subsections specify common fields for defining various aspects of a person, which shall form the initial submission to the Jabber Registrar; many of these fields map to elements specified in vCard, xNAL, FOAF, LDAP (see &rfc2252;, &rfc2256;, and &rfc2798;)
The following subsections specify common fields for defining various aspects of a person, which shall form the initial submission to the XMPP Registrar; many of these fields map to elements specified in vCard, xNAL, FOAF, LDAP (see &rfc2252;, &rfc2256;, and &rfc2798;)
Mappings are provided to vCard, LDAP, xNAL, and FOAF.
Mappings are provided to vCard, xNAL, and JEP-0112 (&jep0112;).
+Mappings are provided to vCard, xNAL, and XEP-0112 (&xep0112;).
A country is the sovereign nation in which a person is located. Sometimes also called a "nation".
The Data Forms fields that represent a country are "country", "home_country", and "work_country" for generic addresses, home addresses, and work addresses respectively.
This field maps to:
This field maps to:
Mappings are provided to vCard and JEP-0080 (&jep0080;).
+Mappings are provided to vCard and XEP-0080 (&xep0080;).
Altitude is a person's height or depth in relationship to sea level, where positive altitude is meters above sea level and negative altitude is meters below sea level.
The Data Forms field that represents altitude is "alt".
This field maps to:
This field maps to:
This field maps to:
Profile data can be personally significant and even security critical. Due care should be taken in determining who shall have access to such information. In particular, an entity SHOULD ensure that its public profile contains only information that it deems safe to be world-readable, SHOULD ensure that any pubsub node it may create for profile data has an access model of "presence" or "roster", and SHOULD NOT publish private or restricted data except to such a pubsub node.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
To follow.
Added secure field from JEP-0116.
Added secure field from XEP-0116.
Further described contexts in which chat session negotiation could be useful; added more examples; added reference to SIP RFC and explained basic mapping to SIP INVITE method; added Jabber Registrar considerations.
Further described contexts in which chat session negotiation could be useful; added more examples; added reference to SIP RFC and explained basic mapping to SIP INVITE method; added XMPP Registrar considerations.
The traditional model for one-to-one chat "sessions" in Jabber/XMPP is for a user to simply send a message to a contact without any formal negotiation of chat session parameters (e.g., see &xmppim;). This informal approach to initiation of a chat session is perfectly acceptable in many contexts, environments, and cultures. However, it may be desirable to formally request the chat and negotiate its parameters before beginning the chat session in some circumstances, such as:
This proposal defines best practices for such a negotiation, re-using the protocol defined in &jep0020;.
+This proposal defines best practices for such a negotiation, re-using the protocol defined in &xep0020;.
In the foregoing example, Romeo requests a chat with Juliet and also queries her regarding whether she wants to disable all message logging (see &jep0136;)
In the foregoing example, Romeo requests a chat with Juliet and also queries her regarding whether she wants to disable all message logging (see &xep0136;)
Juliet's server delivers Romeo's request to her most available resource (which happens to be "balcony").
In any response to the request, the contact's client MUST mirror the 'id' attribute and &THREAD;value so that the user's client can correctly track the response.
We assume that Juliet accepts the chat and specifies that she does not want to log messages or use XHTML formatting but that she does want to use Chat State Notifications:
@@ -486,7 +486,7 @@A client MAY require a human user to approve each chat session negotiation request or MAY auto-accept and auto-reject requests based on some user-configurable policy.
If a party receives XMPP presence of type "unavailable" from the full JID (&FULLJID;) of the other party (i.e., the resource with which it has had an active session) during a chat session, the receiving party MAY assume that the other client will still be unable to continue the session (perhaps it simply became "invisible", or it is persisting the state of the negotiated chat until it reconnects and receives "offline" messages). -However, if the receiving party assumes that the other client will not be able to continue the session, then it MUST explicitly terminate the session (see Terminating a Chat) - since its assumption could be incorrect. If the receiving party later receives presence of type "available" from that same resource or another resource associated with the other party and the receiving party desires to restart the chat session, it MUST initiate a new chat session (including a newly-generated ThreadID) with the other party rather than renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in JEP-0085.)
+However, if the receiving party assumes that the other client will not be able to continue the session, then it MUST explicitly terminate the session (see Terminating a Chat) - since its assumption could be incorrect. If the receiving party later receives presence of type "available" from that same resource or another resource associated with the other party and the receiving party desires to restart the chat session, it MUST initiate a new chat session (including a newly-generated ThreadID) with the other party rather than renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in XEP-0085.)If a contact accepts a user's request or returns an error to the user, the user will effectively discover the contact's presence (at least the presence of one of the contact's resources). Due care must therefore be exercised in determining whether to accept the request or return an error. For examples, the contact's client SHOULD NOT automatically (i.e. without first asking the contact) either accept the user's request or return an error to the user unless the user is subscribing to the contact's presence (and the contact's presence is not currently "invisible" to the user). Furthermore, the contact's client MUST NOT take either action if the user is in the contact's block list.
@@ -494,23 +494,23 @@ However, if the receiving party assumes that the other client will notThis JEP requires no interaction with &IANA;.
The ®ISTRAR; shall include 'http://jabber.org/protocol/chatneg' in its registry of Service Discovery features.
http://jabber.org/protocol/chatneg
Support for Chat Session Negotiation and its FORM_TYPE
- JEP-0155
+ XEP-0155
]]>
&jep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. The following fields shall be registered for use in Chat Session Negotiation:
+&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. The following fields shall be registered for use in Chat Session Negotiation:
http://jabber.org/protocol/chatneg
- JEP-0155
+ XEP-0155
Forms enabling negotation of a one-to-one
chat session between two entities.
@@ -522,15 +522,15 @@ However, if the receiving party assumes that the other client will not
not
This proposal re-uses the format defined in JEP-0020 and therefore does not require a separate schema.
+This proposal re-uses the format defined in XEP-0020 and therefore does not require a separate schema.
Thanks to Thomas Charron and Jean-Louis Seguineau for their feedback.
Although &rfc3920; specifies the use of TCP as the method of connecting to an XMPP server, other connection methods are possible. These include the older &jep0025; method, the more recent &jep0124; method, and less common methods such as &wap;. For some of these methods, it is necessary to discover further parameters before connecting, such as the HTTP URL of an alternative connection manager. Currently, if a client application needs to discover connection methods before connecting to an XMPP service, the relevant information must be provided manually by a human user, which is cumbersome and error-prone. Thankfully, there are several potential ways to complete this pre-connection service discovery in an automated fashion:
+Although &rfc3920; specifies the use of TCP as the method of connecting to an XMPP server, other connection methods are possible. These include the older &xep0025; method, the more recent &xep0124; method, and less common methods such as &wap;. For some of these methods, it is necessary to discover further parameters before connecting, such as the HTTP URL of an alternative connection manager. Currently, if a client application needs to discover connection methods before connecting to an XMPP service, the relevant information must be provided manually by a human user, which is cumbersome and error-prone. Thankfully, there are several potential ways to complete this pre-connection service discovery in an automated fashion:
Specify a &w3wsdl; definition (or other XML file format) and a canonical URL for that definition at a domain that offers XMPP services. Unfortunately, this approach requires access to the HTTP server for the domain (and quite possibly to the root directory thereof), which may be difficult for XMPP server administrators to arrange. In addition, it requires a client to retrieve the relevant file via HTTP before performing DNS lookups and XMPP connection; it would be more efficient to use recognized DNS methods since DNS lookups are already required by RFC 3920.
Specify a way to define the required service discovery information as part of the existing DNS SRV records (see &rfc2782;) for a domain that offers XMPP services. While this approach sounds promising, it is not feasible since the DNS SRV Target field can be used only to specify domain names and cannot be used to specify full URIs (such as the URL for an HTTP connection manager).
The following examples show three DNS TXT resource records: the first indicates support for the httpbind connection method defined in JEP-0124 including the appropriate URL, the second indicates support for the httppoll connection method defined in JEP-0025 including the appropriate URL, and the third indicates support for WAP connections including the appropriate URL.
+The following examples show three DNS TXT resource records: the first indicates support for the httpbind connection method defined in XEP-0124 including the appropriate URL, the second indicates support for the httppoll connection method defined in XEP-0025 including the appropriate URL, and the third indicates support for WAP connections including the appropriate URL.
This JEP requires no interaction with &IANA;.
The Jabber Registrar shall maintain a registry of attributes for use in DNS TXT resource records that advertise XMPP connection methods.
+The XMPP Registrar shall maintain a registry of attributes for use in DNS TXT resource records that advertise XMPP connection methods.
_xmpp-client-httpbind
the HTTP Binding connection method
the http: or https: URL at which to contact the HTTP Binding connection manager or proxy
- JEP-0124
+ XEP-0124
_xmpp-client-httppoll
the HTTP Polling connection method
the http: or https: URL at which to contact the HTTP Polling connection manager or proxy
- JEP-0025
+ XEP-0025
@@ -157,4 +157,4 @@ _xmppconnect IN TXT "_xmpp-client-wap=http://wap.jabber.org/connector.cgi"
Initial JEP version.
Initial version.
Added security considerations and Jabber Registrar considerations.
Added security considerations and XMPP Registrar considerations.
The appearance of large public IM services based on &rfc3920; and &rfc3921; makes it desirable to implement protocols that discourage the sending of large quantities of IM SPAM (SPIM) from XMPP clients (connected to legitimate servers) and XMPP servers (with virtual clients) -- all hosted on networks of 'zombie' machines. SPIM is defined here as any type of unsolicited XMPP stanza sent by a 'robot' and delivered to a human, including messages and subscription requests. SPIM has the potential to disrupt people even more than SPAM, because each message interrupts the receiver (humans typically filter SPAM in batch mode).
Several of the most effective techniques developed to combat SPAM require humans to be differentiated from bots using a "Completely Automated Public Turing Test to Tell Computers and Humans Apart" or CAPTCHA (see <http://www.captcha.net/>). These challenge techniques are easily adapted to discourage SPIM. The very occasional inconvenience of responding to a CAPTCHA (for example, when creating an IM account or sending a message to a new correspondent) is small and perfectly acceptable -- especially when compared to the countless robot-generated interruptions people might otherwise have to filter every day.
An alternative technique to CAPTCHAs requires Desktop PC clients to undertake a Hashcash
The generic challenge protocol described in this document is designed for incorporation into other protocols like &jep0077; and &jep0159;.
+The generic challenge protocol described in this document is designed for incorporation into other protocols like &xep0077; and &xep0159;.
This protocol requires multimedia to be included within &jep0004;. This section defines a new namespace ('http://jabber.org/protocols/media') for that purpose. The root element for the namespace is <media/>. It MUST be contained within a <field/> element qualified by the 'jabber:x:data' namespace.
+This protocol requires multimedia to be included within &xep0004;. This section defines a new namespace ('http://jabber.org/protocols/media') for that purpose. The root element for the namespace is <media/>. It MUST be contained within a <field/> element qualified by the 'jabber:x:data' namespace.
If the media is an image or video then the <media/> element SHOULD include 'width' and 'height' attributes specifying the recommended display size of the media in pixels.
The <media/> element SHOULD contain at least one <uri/> element to specify the out-of-band location of the media data.
The <media/> element MAY also contain one or more <data/> elements for distributing the media in-band. The <data/> element MUST contain the Base64 encoded (in accordance with Section 3 of &rfc3548;) media data. The encoded data SHOULD NOT be larger than 8 KB. Note that if a stanza contains more than one <data/> element then the sending entity MUST take care not to trigger karma limits.
@@ -102,8 +102,8 @@ ]]>Each of the challenge form's <field/> elements (see Data Forms) that are not hidden MAY contain a different challenge and any media required for the challenge. The hidden 'from' field MUST contain the value of the 'to' attribute of the client's stanza that triggered the challenge. If the stanza from the client included an 'id' attribute then the hidden 'sid' field MUST be set to that value. The 'xml:lang' attribute of the challenge stanza SHOULD be the same as the one received from the client. The hidden 'FORM_TYPE' field MUST have a value of "http://jabber.org/protocol/challenge" in accordance with &jep0068;.
-The challenger SHOULD include an explanation (in the &BODY; element) for clients that do not support this protocol. The challenger MAY also include a URL (typically a Web page with instructions) using &jep0066; as an alternative for clients that do not support the challenge form. Note: even if it provides a URL, a challenger MUST always provide a challenge form.
Each of the challenge form's <field/> elements (see Data Forms) that are not hidden MAY contain a different challenge and any media required for the challenge. The hidden 'from' field MUST contain the value of the 'to' attribute of the client's stanza that triggered the challenge. If the stanza from the client included an 'id' attribute then the hidden 'sid' field MUST be set to that value. The 'xml:lang' attribute of the challenge stanza SHOULD be the same as the one received from the client. The hidden 'FORM_TYPE' field MUST have a value of "http://jabber.org/protocol/challenge" in accordance with &xep0068;.
+The challenger SHOULD include an explanation (in the &BODY; element) for clients that do not support this protocol. The challenger MAY also include a URL (typically a Web page with instructions) using &xep0066; as an alternative for clients that do not support the challenge form. Note: even if it provides a URL, a challenger MUST always provide a challenge form.
This JEP introduces no security considerations above and beyond those described in RFC 3920 and RFC 3921.
+This document introduces no security considerations above and beyond those described in RFC 3920 and RFC 3921.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
Upon approval of this JEP, the ®ISTRAR; shall register the following protocol namespaces:
+Upon approval of this document, the ®ISTRAR; shall register the following protocol namespaces:
Upon approval of this JEP, the Jabber Registrar shall register the following new FORM_TYPE. Additional fields will be defined in future submissions.
+Upon approval of this document, the XMPP Registrar shall register the following new FORM_TYPE. Additional fields will be defined in future submissions.
http://jabber.org/protocol/challenge
- JEP-0158
+ XEP-0158
forms enabling robot challenges
Upon approval of this JEP, the Jabber Registrar shall register the following new fields for the existing jabber:iq:register FORM_TYPE. Additional fields will be defined in future submissions.
+Upon approval of this document, the XMPP Registrar shall register the following new fields for the existing jabber:iq:register FORM_TYPE. Additional fields will be defined in future submissions.
jabber:iq:register
- JEP-0077
+ XEP-0077
Another protocol could allow users to edit the challenges their server will make on their behalf. For example, the number of SHA-256 bits, a personal or original question and answer, a picture, a video, or a sound recording... Of course Aunt Tillie would typically only use this feature if she was plagued by SPIM.
A client MAY confirm that its server supports SPIM-Blocking Control using &jep0030;.
+A client MAY confirm that its server supports SPIM-Blocking Control using &xep0030;.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
Upon approval of this JEP, the Jabber Registrar shall register the following well-known Service Discovery node:
+Upon approval of this document, the XMPP Registrar shall register the following well-known Service Discovery node: