Generic maps provide a way to extending the roster into a general display showing contacts (JIDs) together with further additional information. The further information is provided by the position in the map (and possibly by the dot type - e.g. shape or colour). In addition to showing people belonging to one roster group, it is possible to cluster people, use more detailed inset maps etc. each of these features providing a unique context.
-The motivations for this JEP are:
+The motivations for this document are:
The map in Example 1 uses an implicit map projection assuming that attributes x and y are directly the co-ordinates of a particular entity (e.g. buddy1@jabber.org) in the image (ortho_0.gif) expressed in pixels.
A similar map with coordinates specified using geographic latitude + longitude (possibly obtained using Geographic Location Information
A similar map with coordinates specified using geographic latitude + longitude (possibly obtained using Geographic Location Information
The following guidelines may assist the developers of a mapping plug-in in the Jabber clients.
The image files (maps) are transferred as an extra extension of packet using the filename as a unique id.
The attributes are either specified in the <map/> tag or known in the environment (e.g. presence), but they could be also provided by a subscribed service using Publish-Subscribe
The attributes are either specified in the <map/> tag or known in the environment (e.g. presence), but they could be also provided by a subscribed service using Publish-Subscribe
The clustering of items can be specified directly in the map tag or done using a pixel resolution of the display available.
@@ -138,19 +128,7 @@No IANA interaction required.
The Jabber Registrar
The ®ISTRAR; will need to register the new namespace of "http://jabber.org/protocol/map".
Note Well: This proposal has been retracted by the authors in favor of &jep0166;.
+Note Well: This proposal has been retracted by the authors in favor of &xep0166;.
The Session Description Protocol (SDP; see &rfc2327;) provides a mechanism for describing multimedia sessions that are advertised and negotiated over the Internet. The "Transport for Initiating and Negotiating Sessions" (TINS) specified herein describes how to use SDP to build a framework for media stream/session initiation and negotiation between entities that natively support XMPP (see &rfc3920;).
This JEP addresses the following requirements:
+This document addresses the following requirements:
The request stanza MAY also include either or both of the following:
In reply to a request, the receiver MUST send zero or more replies, with the value of the 'method' attribute set to a value of "result" and the value of the 'code' attribute set to one of the valid SIP response codes as specified in Section 21 of RFC 3261.
Before initiating a TINS negotiation, an XMPP entity SHOULD determine that the target entity supports the 'http://jabber.org/protocol/tins' namespace. Such discovery SHOULD occur by means of &jep0030;, either directly by querying the target entity or indirectly by means of &jep0115;. If the target entity is a non-XMPP entity that is contacted through a gateway, the gateway itself SHOULD reply to service discovery queries on behalf of the non-XMPP entity and SHOULD insert a client capabilities extension into the presence stanzas it generates on behalf of the non-XMPP entity.
-If an XMPP entity receives, or a gateway handles, a &MESSAGE; stanza containing a <tins/> element qualified by the 'http://jabber.org/protocol/tins' namespace but it does not understand the TINS protocol, it SHOULD either silently ignore it or return a &unavailable; error (see &jep0086; for error syntax).
+Before initiating a TINS negotiation, an XMPP entity SHOULD determine that the target entity supports the 'http://jabber.org/protocol/tins' namespace. Such discovery SHOULD occur by means of &xep0030;, either directly by querying the target entity or indirectly by means of &xep0115;. If the target entity is a non-XMPP entity that is contacted through a gateway, the gateway itself SHOULD reply to service discovery queries on behalf of the non-XMPP entity and SHOULD insert a client capabilities extension into the presence stanzas it generates on behalf of the non-XMPP entity.
+If an XMPP entity receives, or a gateway handles, a &MESSAGE; stanza containing a <tins/> element qualified by the 'http://jabber.org/protocol/tins' namespace but it does not understand the TINS protocol, it SHOULD either silently ignore it or return a &unavailable; error (see &xep0086; for error syntax).
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; shall include 'http://jabber.org/protocol/tins' in its registry of protocol namespaces.
NOTE WELL: The protocol defined herein has been folded into &jep0080;.
-This JEP defines an extension mechanism for capturing "extended presence" information about a user's current physical location. The information structures defined herein are intended to provide a format for describing a location or address that may change fairly frequently (e.g., one's location on a campus or in a large building) in situations where the user or application does not possess, or does not wish to communicate, detailed latitude/longitude data of the type defined in JEP-0080.
+NOTE WELL: The protocol defined herein has been folded into &xep0080;.
+This document defines an extension mechanism for capturing "extended presence" information about a user's current physical location. The information structures defined herein are intended to provide a format for describing a location or address that may change fairly frequently (e.g., one's location on a campus or in a large building) in situations where the user or application does not possess, or does not wish to communicate, detailed latitude/longitude data of the type defined in XEP-0080.
Information about the user's location is provided by the user and propagated on the network by the user's client. The information is structured by means of an <physloc/> element that is qualified by the 'http://jabber.org/protocol/physloc' namespace. The location information itself is provided as the XML character data of the following children of the <physloc/> element:
@@ -102,7 +99,7 @@The <physloc/> information SHOULD be communicated by means of &jep0060;. Because physical location information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.
+The <physloc/> information SHOULD be communicated by means of &xep0060;. Because physical location information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.
As mentioned in JEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &jep0033; protocol) to provide an explicit association between the published data and the user:
+As mentioned in XEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &xep0033; protocol) to provide an explicit association between the published data and the user:
There are many XML data formats for physical location or address information. It is beyond the scope of this JEP to provide a mapping from the extension defined herein to every such format. However, it would be valuable to provide a mapping from the Jabber/XMPP format to the formats used in other presence or extended presence protocols. The two main protocols of interest are:
+There are many XML data formats for physical location or address information. It is beyond the scope of this document to provide a mapping from the extension defined herein to every such format. However, it would be valuable to provide a mapping from the Jabber/XMPP format to the formats used in other presence or extended presence protocols. The two main protocols of interest are:
The Wireless Village (now "IMPS") specifications for mobile instant messaging; these specifications define a presence attribute for address information as encapsulated in the IMPS "Address" element
The SIP-based SIMPLE specifications; in particular, the IETF's GEOPRIV Working Group has defined an extension to the IETF's &pidf; for location information, as specified in &rfc4119; (also known as "PIDF-LO").
The following table also maps the format defined herein to the vCard XML format specified in &jep0054;.
+The following table also maps the format defined herein to the vCard XML format specified in &xep0054;.
| Jabber/XMPP | @@ -189,7 +186,7 @@<Country/> | <country/> | <CTRY/>
- |
|
|---|---|---|---|---|
| -- | <Accuracy/>
- |
-- | -- | @@ -275,11 +272,11 @@Requirement Level |
| JEP-0073: Basic IM Protocol Suite | +XEP-0073: Basic IM Protocol Suite | REQUIRED | ||
| &jep0045; | +&xep0045; | REQUIRED | ||
| &jep0071; | +&xep0071; | REQUIRED | ||
| &jep0096; | +&xep0096; | REQUIRED | ||
| &jep0115; | +&xep0115; | REQUIRED |
Note well that the foregoing protocols apply to clients only (i.e., they do not introduce new requirements for servers). In addition, these protocols have their own dependencies, which include the following JEPs (as well as various IETF RFCs and W3C specifications):
+Note well that the foregoing protocols apply to clients only (i.e., they do not introduce new requirements for servers). In addition, these protocols have their own dependencies, which include the following XEPs (as well as various IETF RFCs and W3C specifications):
In addition, because the intermediate suite builds on the basic suite, by definition all protocols required by JEP-0073 are also required by the intermediate suite (refer to JEP-0073 for details).
+In addition, because the intermediate suite builds on the basic suite, by definition all protocols required by XEP-0073 are also required by the intermediate suite (refer to XEP-0073 for details).
This JEP introduces no additional security considerations above and beyond those defined in the documents on which it depends.
+This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this JEP.
+No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this document.
This JEP defines a protocol for communicating information about the music to which a user is listening. Such information may be seen as a kind of "extended presence", and users may want to communicate such information to their contacts on the network as a fun add-on to traditional IM applications or to provide integration with common music-player applications.
+This document defines a protocol for communicating information about the music to which a user is listening. Such information may be seen as a kind of "extended presence", and users may want to communicate such information to their contacts on the network as a fun add-on to traditional IM applications or to provide integration with common music-player applications.
NOTE: The datatypes specified above are defined in &w3xmlschema2;.
Tune information SHOULD be communicated and transported by means of the &jep0060; protocol. Because tune information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.
+Tune information SHOULD be communicated and transported by means of the &xep0060; protocol. Because tune information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.
As mentioned in JEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &jep0033; protocol) to provide an explicit association between the published data and the user:
+As mentioned in XEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &xep0033; protocol) to provide an explicit association between the published data and the user:
Naturally, further extensions could be included, e.g., using &jep0066; to specify a URL where one could buy the recording.
+Naturally, further extensions could be included, e.g., using &xep0066; to specify a URL where one could buy the recording.
This protocol introduces no security considerations above and beyond those defined in Publish-Subscribe (JEP-0060).
+This protocol introduces no security considerations above and beyond those defined in Publish-Subscribe (XEP-0060).
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; includes 'http://jabber.org/protocol/tune' in its registry of protocol namespaces.
Retracted: superseded by Personal Eventing via Pubsub (JEP-0163).
Retracted: superseded by Personal Eventing via Pubsub (XEP-0163).
Updated to reflect Personal Eventing via Pubsub (JEP-0163).
Updated to reflect Personal Eventing via Pubsub (XEP-0163).
Note: This document has been retracted since its functionality is handled by &jep0163;.
+Note: This document has been retracted since its functionality is handled by &xep0163;.
A number of network services enable the exchange of information about an entity's availability for communications over the network. This information is usually called "presence". Examples include a person's availability to talk over a traditional or mobile telephony network, chat over an instant messaging (IM) network, or participate in a video conference. In this core sense, presence is a boolean, "on/off" indicator of network availability.
Over time, this core notion of presence has been extended to include other information about the entity that either (1) changes quickly or (2) affects the entity's interest in or ability to engage in communications. Examples of such "extended presence" include a person's proximity to or interaction with a user agent (e.g., "away" or "do not disturb"), activity (e.g., "driving"), ambient environment (e.g., "noisy"), and mood (e.g., "grumpy"). Related information includes data about the person's available devices (e.g., "phone" or "IM"), current contact modes or address, and date/time ranges for availability. Because extended presence information can change quite often (e.g., several times in the course of a typical IM session), it is distinct from more stable information about the individual (such as is captured in a vCard or other user profile).
This document describes a unified approach to the provision and communication of extended presence information using the Extensible Messaging and Presence Protocol (XMPP), in the form of a "protocol suite" that incorporates by reference a number of existing XMPP extensions.
XMPP began life as a dedicated instant messaging and presence protocol within the Jabber community. The needs of this community were not advanced (simple IM and presence), and the presence model designed by that community mainly takes account of basic presence only (i.e., on/off availability on an IM network). Within this model (and using the terminology of &rfc2778;), the only watchers are those in the principal's contact list (in XMPP called a "roster"). In addition, authorization to receive basic presence broadcasts is handled by the principal through a combination of roster management and basic presence subscriptions as defined in &xmppim;. The presence service is tied to the principal's session with a server, and the server's internal session manager handles both presence and instant messaging functionality (although IM and presence can be separated in system configuration or "on the fly" via negative presence priorities).
-This basic presence model was not designed for the more advanced world of extended presence. While some existing IM clients publish extended presence information as XML extensions to the XMPP &PRESENCE; stanza, that model does not scale well, does not respect the bandwidth restrictions of many clients on the network, and does not provide for more granular control over information access (anyone who receives presence will also receive geolocation data and the like). However, there is a more advanced protocol that is specially designed to fully implement the publish-subscribe design pattern on top of XMPP, specified in JEP-0060: &jep0060;. The publish-subscribe protocol can be used to create a service that provides full control over each type of extended presence data, sending that data only to those specifically authorized to receive it and those who have an active interest in each extension. In particular, for extended presence related to IM users, we specify the use of the personal eventing subset of JEP-0060, as defined in JEP-0163.
+This basic presence model was not designed for the more advanced world of extended presence. While some existing IM clients publish extended presence information as XML extensions to the XMPP &PRESENCE; stanza, that model does not scale well, does not respect the bandwidth restrictions of many clients on the network, and does not provide for more granular control over information access (anyone who receives presence will also receive geolocation data and the like). However, there is a more advanced protocol that is specially designed to fully implement the publish-subscribe design pattern on top of XMPP, specified in XEP-0060: &xep0060;. The publish-subscribe protocol can be used to create a service that provides full control over each type of extended presence data, sending that data only to those specifically authorized to receive it and those who have an active interest in each extension. In particular, for extended presence related to IM users, we specify the use of the personal eventing subset of XEP-0060, as defined in XEP-0163.
The provision and communication of extended presence information follows the classic publish-subscribe design pattern: an individual publishes information such as geographical location data, and the data is broadcasted to all subscribers who are authorized to receive that data. (Alternatively, the data can be published on behalf of the individual, such as by a mobile telephony service that has knowledge of the individual's geographical location and authorization to act as a publisher of that data.) In general, the relationship between the publisher and subscriber is mediated by a service that receives publication requests, broadcasts data to subscribers, and enables the individual to manage lists of entities that are authorized to publish or subscribe to the data. This model makes it possible to deploy highly flexible extended presence services within the context of XMPP.
The following diagram provides a schematic representation of such a service.
@@ -113,11 +113,11 @@ Service | Manager
In this example, there are six different extended presence nodes (these might be, for example, geographical location, avatar, activity, mood, network availability, etc.). The principal is authorized to publish to all six, a Mobile Telephony Service is also authorized to publish to Node 1 (e.g., geolocation), and an XMPP Session Manager is also authorized to publish to Node 6 (e.g., network availability). There are five subscribers: Subscriber 1 is authorized to receive data from Node 1 and Node 2, Subscriber 2 is authorized to Node 2 and Node 3, Subscriber 3 is authorized to receive data from Node 4 and Node 6, and Subscribers 4 and 5 are authorized to receive data from Node 6 only.
This document follows the same approach as &jep0073;. By design, the Basic IM Protocol Suite does not include more advanced functionality related to "extended presence"; the present document fills the need for a protocol suite that addresses such functionality.
+This document follows the same approach as &xep0073;. By design, the Basic IM Protocol Suite does not include more advanced functionality related to "extended presence"; the present document fills the need for a protocol suite that addresses such functionality.
A protocol is deemed worthy of inclusion in this protocol suite if:
* Note: The User Avatar specification (JEP-0084) has not yet advanced to a status of Draft within the JSF's standards process, and the Extended Presence Protocol Suite will not be submitted for approval until it does so.
+* Note: The User Avatar specification (XEP-0084) has not yet advanced to a status of Draft within the JSF's standards process, and the Extended Presence Protocol Suite will not be submitted for approval until it does so.
Discovery of extended presence pubsub nodes is expedited through the use of Personal Eventing via Pubsub (PEP), since in PEP services there is a one-to-one relationship between payload types and NodeIDs. The NodeIDs MUST be as follows:
@@ -173,9 +173,9 @@ Service | ManagerThis document introduces no new security considerations above and beyond those defined in the documents on which it depends. Because publicly exposing some forms of extended presence information (e.g., geolocation information) may lead to unnecessary risks, care should be taken in setting the access model for the relevant pubsub nodes (minimally, an access model of "presence" to take advantage of the bidirectional authorization scheme inherent in XMPP presence subscriptions).
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
This JEP requires no interaction with the ®ISTRAR;.
+This document requires no interaction with the ®ISTRAR;.