Folded in civil location from JEP-0112.
Folded in civil location from XEP-0112.
Corrected several errors; added reference to JEP-0033.
Corrected several errors; added reference to XEP-0033.
Reverted from infobits to geoloc elements; moved physical address protocol back to JEP-0112.
Reverted from infobits to geoloc elements; moved physical address protocol back to XEP-0112.
Merged in contents of JEP-0112.
Merged in contents of XEP-0112.
NOTE: The datatypes specified above are defined in &w3xmlschema2;.
The location information SHOULD be communicated by means of &jep0060; or the subset of pubsub defined in &jep0163;. Because 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;, although an application MAY do so if necessary.
+The location information SHOULD be communicated by means of &xep0060; or the subset of pubsub defined in &xep0163;. Because 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;, although an application MAY do so if necessary.
In order to provide information about one's location, the publishing entity should use the pubsub protocol (the following examples show use of the publish-subscribe subset specified in JEP-0163).
+In order to provide information about one's location, the publishing entity should use the pubsub protocol (the following examples show use of the publish-subscribe subset specified in XEP-0163).
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;.
| XMPP | @@ -378,7 +378,7 @@<Country/> | <country/> | <CTRY/>
- |
|---|---|---|---|
| -- | <Accuracy/>
- |
-- | -- | @@ -467,10 +467,10 @@
A client MUST allow the user to configure whether he or she wants to send chat state notifications.
-Note: Support for only <active/> and <composing/> is functionally equivalent to supporting the Composing event from JEP-0022.
+Note: Support for only <active/> and <composing/> is functionally equivalent to supporting the Composing event from XEP-0022.
Even if the user types continuously for a long time (e.g., while composing a lengthy reply), the client MUST NOT send more than one standalone <composing/> notification in a row. More generally, a client MUST NOT send a second instance of any given standalone notification (i.e., a standalone notification MUST be followed by a different state, not repetition of the same state). However, every content message SHOULD contain an <active/> notification.
@@ -278,7 +278,7 @@ INACTIVE <--> ACTIVE <--> COMPOSINGChat state notifications MAY be sent in the context of groupchat rooms (e.g., as defined in &jep0045;). The following business rules apply:
+Chat state notifications MAY be sent in the context of groupchat rooms (e.g., as defined in &xep0045;). The following business rules apply:
Servers in constrained network environments (e.g., serving small-footprint clients via &jep0025; or &jep0124;) and services that rebroadcast message stanzas (e.g., Multi-User Chat services) MAY process standalone notifications differently from other messages. In particular, a server or service MAY refuse to deliver standalone notifications to its users, and SHOULD NOT store them offline. In contrast to JEP-0022, chat state notifications are completely the responsibility of the client, and MUST NOT be generated by a server or service.
+Servers in constrained network environments (e.g., serving small-footprint clients via &xep0025; or &xep0124;) and services that rebroadcast message stanzas (e.g., Multi-User Chat services) MAY process standalone notifications differently from other messages. In particular, a server or service MAY refuse to deliver standalone notifications to its users, and SHOULD NOT store them offline. In contrast to XEP-0022, chat state notifications are completely the responsibility of the client, and MUST NOT be generated by a server or service.
The states of a chat thread may reveal information about a user's interaction with his or her computer, including his or her physical presence; such information SHOULD NOT be revealed to conversation partners who are not trusted to know such information. Client implementations MUST provide a mechanism that enables the user to disable chat state notifications if desired.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; includes 'http://jabber.org/protocol/chatstates' in its registry of protocol namespaces.
Mapping legacy error codes to XMPP-style errors is an inexact science, and there are likely to be inconsistencies in some places. However, it is the authors' belief that the mapping presented in this document will be adequate for the majority of cases, and will help smooth the migration to XMPP-compliant implementations.
As more people begin to make use of streams in Jabber, there becomes a need - for more descriptive negotiation of which stream to use. This JEP provides + for more descriptive negotiation of which stream to use. This document provides a method to negotiate a stream and provide some meta-information about the streams usage.
@@ -91,7 +91,7 @@Before a Stream Initiation is attempted the Sender should be sure that the Receiver supports both Stream Initiation and the specific profile that they - wish to use. This is discovered by using &jep0030;: + wish to use. This is discovered by using &xep0030;:
The Receiver will advertise the "http://jabber.org/protocol/si" namespace as - a feature to represent they implement this JEP. The specific profiles can + a feature to represent they implement this document. The specific profiles can be found by looking for "http://jabber.org/protocol/si/profile/profile-name". Shown in the result is a potential file transfer profile: @@ -302,16 +302,16 @@ <si> profile attribute. Next, the information for the headers is decided upon. Each piece of information will be transported in a <header> tag. The name attribute is a descriptive key that can be - looked up at the Jabber Registrar or JEP describing the profile. The + looked up at the XMPP Registrar or XEP describing the profile. The actual data in the <header> is the fact related to the name attribute. It must also be stated whether the header is required or optional.
- This JEP does not define any profiles, nor does it place any restrictions - on what type of information a profile should detail. This JEP also does + This document does not define any profiles, nor does it place any restrictions + on what type of information a profile should detail. This document also does not place restrictions on what may be placed in a <header>. Other - JEPs will define profiles to be used with Stream Initiation. + XEPs will define profiles to be used with Stream Initiation.
- This JEP uses the MIME types as recorded by IANA, but no other direct + This document uses the MIME types as recorded by IANA, but no other direct interaction is necessary.
The "http://jabber.org/protocol/si" namespace will be registered. The registrar will track header profiles for different stream initiation @@ -426,4 +426,4 @@
To follow.
Webtabs are a way for servers to specify a number to web pages which can be used in clients and displayed like the web-based services in Yahoo Messenger, MSN Messenger and JIM. This enables a server administrator to easily create services for Jabber clients and also help to integrate Jabber clients with existing web-based applications.
The motivations for this JEP are:
+The motivations for this document are:
&jep0030; SHALL be used for discovering support for webtabs on servers.
+&xep0030; SHALL be used for discovering support for webtabs on servers.
The webtab contains CDATA which is the URL of the webtab, the webtab is an HTML page retrieved from an HTTP server using a standard browser which you embed into your client UI using a technique such as the IWebBrowser2 control interface on windows which allows you to embed either the IE or Gecko engines depending on what you have installed, this data is REQUIRED.
-The "type" attribute tells the client what the service being provided is, this allows a client to display icons on the tabs to represent them, handling of the type in clients is OPTIONAL, inclusion of this attribute is REQUIRED (See "Jabber Registrar Considerations" for examples of values for this attribute).
+The "type" attribute tells the client what the service being provided is, this allows a client to display icons on the tabs to represent them, handling of the type in clients is OPTIONAL, inclusion of this attribute is REQUIRED (See "XMPP Registrar Considerations" for examples of values for this attribute).
The "name" attribute is the offical name of a particular service this can be displayed as the tab name, this attribute is REQUIRED.
The "id" attribute is a unique identifier for a service which you can use to refer to it later, used for when using private storage to store a preference to which tabs should be visible, this attribute is REQUIRED.
&jep0049; SHALL be used for storing webtab preferences.
+&xep0049; SHALL be used for storing webtab preferences.
It is RECOMMENDED that a mechanism such as &jep0101; be used for automatic service authentication.
+It is RECOMMENDED that a mechanism such as &xep0101; be used for automatic service authentication.
It is recommended that JEP-0101 be used to provide transparent authentication of the webtabs.
+It is recommended that XEP-0101 be used to provide transparent authentication of the webtabs.
No IANA interaction required.
The ®ISTRAR; will need to register the new namespace of "http://jabber.org/protocol/webtab" and possibly the list of offical types will need to be managed too.
Generic Alerts is a way to extend headlines to allow functionality similar to .NET Alerts.
The motivations for this JEP are:
+The motivations for this document are:
No IANA interaction required.
The ®ISTRAR; will need to register the new namespace of "http://jabber.org/protocol/alert".