From 462ac0b137310a8f566c9338f1f8e219f4635f97 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Tue, 3 Oct 2006 23:03:58 +0000 Subject: [PATCH] JEP to XEP git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@32 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0040.xml | 24 ++++----- xep-0041.xml | 32 ++++++------ xep-0042.xml | 14 +++--- xep-0043.xml | 10 ++-- xep-0044.xml | 10 ++-- xep-0045.xml | 140 +++++++++++++++++++++++++-------------------------- xep-0046.xml | 14 +++--- xep-0047.xml | 30 +++++------ xep-0048.xml | 30 +++++------ xep-0049.xml | 28 +++++------ 10 files changed, 166 insertions(+), 166 deletions(-) diff --git a/xep-0040.xml b/xep-0040.xml index 534e1c5a..dd1631bd 100644 --- a/xep-0040.xml +++ b/xep-0040.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
Jabber Robust Publish-Subscribe - Note: This proposal has been superseded by JEP-0060; please refer to that document for the successor protocol. + Note: This proposal has been superseded by XEP-0060; please refer to that document for the successor protocol. &LEGALNOTICE; 0040 Retracted @@ -15,7 +15,7 @@ Standards None None - JEP-0060 + XEP-0060 None Tim @@ -27,7 +27,7 @@ 0.2 2004-07-26 psa - Formally retracted this proposal in favor of JEP-0060: Publish-Subscribe. + Formally retracted this proposal in favor of XEP-0060: Publish-Subscribe. 0.1 @@ -37,9 +37,9 @@
-

Note: This JEP has been superseded by &jep0060;; please refer to that document for the successor protocol.

+

Note: This XEP has been superseded by &xep0060;; please refer to that document for the successor protocol.

This document introduces and lays out a preliminary protocol for a robust form of publish-subscribe over the Jabber messaging environment -- Jabber Robust Publish Subscribe (JRPS).

-

Implementation issues in the environment are appended, covering Permissioning and Contributions. Both are likely to require separate JEPs, but need to be constructed sympathetically.

+

Implementation issues in the environment are appended, covering Permissioning and Contributions. Both are likely to require separate XEPs, but need to be constructed sympathetically.

In creating this addition, I have an underlying philosophy to sustain a "fractal" world of publish-subscribe components, such that a subscriber to a pubsub component may well be a pubsub component in itself, representing its own community of subscribers. This will allow Jabber to support organic scalability found on other platforms.

Publish-Subscribe and other messaging environments that exist are often classified as providing one or more of the following three levels of service.

@@ -63,7 +63,7 @@
  • Compare Jabber to "the competition" (other IM systems or other messaging protocols) and point out holes in the Jabber protocol that need to be filled in order to offer similar functionality.
  • Review the relevant history of thinking within the Jabber community.
    • -

    JRPS is a layer on Jabber Publish-Subscribe (JEP0024, JEP0036) and should interoperate with them and support namespaces and topics. Included in this document is the capability for permission tokens. It is included as the author believes that such tokens should exist within the <publish> tag, being a means to identify data much as the namespace or topic does.

    +

    JRPS is a layer on Jabber Publish-Subscribe (XEP0024, XEP0036) and should interoperate with them and support namespaces and topics. Included in this document is the capability for permission tokens. It is included as the author believes that such tokens should exist within the <publish> tag, being a means to identify data much as the namespace or topic does.

    JRPS is different from other IM systems in that the publisher and pubsub components send out the data so that downstream entities can detect if problems occur. As a comparison, a sender in, say, MSN is told that the packet they sent cannot be delivered but in JRPS, the receiver knows that a packet or packets have not been delivered and can ask for retransmissions. The sender need not normally know about such events as the intermediate components can usually cater for it. Thus JRPS has a future in areas such as Multicasting, large distributed and proxy-based environments where the end subscribers may be very remote from the publisher.

    Existing commercial middlewares provide such facilities and it is especially necessary when data is pushed between applications and may not have an obvious "context" in the stream to data immediately before or after. Thus, JRPS may seem over-the-top for a chatroom world, but is a basic requirement for, say, distributing real-time process states, events or persistent, mutable data.

     @@ -264,7 +264,7 @@ channel can be, but is not limited to the following:

    Further information on why tokenised grant and deny permissioning is advantageous can be provided upon request.

    Contributions in this context are when a subscriber publishes to one or more sources for redistribution so that it may reach the communities that subscribe to that source. By doing this, the subscriber reaches large communities, focus on specific communities and can abstract itself from delivery issues. The publisher gains information and broadens its appeal. Delivery abstraction is valuable, as a subscriber can then connect once to the publisher to gain access to all systems, networks, technologies, subscribers and media that the publisher and contributor agree upon. As you may guess, there is a need for content, flow control/throttling and ongoing permissioning to be specified and handled over time.

    -

    Contributions requires a separate JEP, but the issues are important to the implementation of pubsub and of its permissions (Contributors have specific, complex and business-critical reasons to tightly control who sees data -- e.g. only customers, not competition!)

    +

    Contributions requires a separate XEP, but the issues are important to the implementation of pubsub and of its permissions (Contributors have specific, complex and business-critical reasons to tightly control who sees data -- e.g. only customers, not competition!)

         -     + diff --git a/xep-0041.xml b/xep-0041.xml index 4aa78fca..9d8e3363 100644 --- a/xep-0041.xml +++ b/xep-0041.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
    Reliable Entity Link Protocol for linking a bytestream between two Jabber entities. @@ -13,9 +13,9 @@ Retracted Standards Track Standards JIG - XMPP Core, JEP-0020, JEP-0030 + XMPP Core, XEP-0020, XEP-0030 None - JEP-0065 + XEP-0065 rel Justin @@ -27,7 +27,7 @@ 0.2 2003-09-30 psa - At the request of the author, the status of this JEP has been changed to Retracted since it has been superseded by JEP-0065. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations. + At the request of the author, the status of this specification has been changed to Retracted since it has been superseded by &xep0065;. This specification will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations. 0.8 @@ -125,11 +125,11 @@ ibb - &jep0047; + &xep0047; s5b - &jep0065; + &xep0065; @@ -138,7 +138,7 @@ -

    Before using REL, ensure it is a supported service of the remote entity by using &jep0030;:

    +

    Before using REL, ensure it is a supported service of the remote entity by using &xep0030;:

    @@ -146,7 +146,7 @@ ]]> -The remote entity will advertise the "http://jabber.org/protocol/rel" namespace as a feature to represent they implement this JEP. +The remote entity will advertise the "http://jabber.org/protocol/rel" namespace as a feature to represent they implement this protocol. @@ -179,7 +179,7 @@ The remote entity will advertise the "http://jabber.org/protocol/rel" namespace     -

    The next step is to ask the remote entity which stream method it would like to use. We will use &jep0020; for this. The streams are listed using the short names from the table of supported streams.

    +

    The next step is to ask the remote entity which stream method it would like to use. We will use &xep0020; for this. The streams are listed using the short names from the table of supported streams.

    @@ -235,11 +235,11 @@ The remote entity will advertise the "http://jabber.org/protocol/rel" namespace     -

    This JEP requires no interaction with &IANA;.

    +

    This document requires no interaction with &IANA;.

     - -

    The ®ISTRAR; shall register the 'http://jabber.org/protocol/rel' namespace as a result of this JEP.

    + +

    The ®ISTRAR; shall register the 'http://jabber.org/protocol/rel' namespace as a result of this document.

     @@ -263,4 +263,4 @@ The remote entity will advertise the "http://jabber.org/protocol/rel" namespace ]]> - + diff --git a/xep-0042.xml b/xep-0042.xml index 3cdb02ce..a9b4f404 100644 --- a/xep-0042.xml +++ b/xep-0042.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
    Jabber OOB Broadcast Service (JOBS) A protocol for enabling uni-directional multicast data transfers out of band. @@ -107,7 +107,7 @@ -

    Discovering support for JOBS involves either "jabber:iq:browse"jabber:iq:browse -- http://www.jabber.org/jeps/jep-0011.html or "disco"http://jabber.org/protocol/disco -- http://www.jabber.org/jeps/jep-0030.html. This determines if the end-point understands the JOBS protocol.

    +

    Discovering support for JOBS involves either &xep0011; or &xep0030;. This determines if the end-point understands the JOBS protocol.

    To determine support for JOBS via jabber:iq:browse, look for an item with a nested <ns/> with a value of "http://jabber.org/protocol/jobs":

    Any parameters that exceed the minimums/maximums causes an error.

     -

    In some cases, the session creation process requires an interface more suitable for human consumption. In such cases the JOBS protocol helps by allowing for contained elements governed by other namespaces. For form-based creation, a "jabber:x:data" formjabber:x:data -- http://www.jabber.org/jeps/jep-0004.html can be embedded in the <session/>.

    +

    In some cases, the session creation process requires an interface more suitable for human consumption. In such cases the JOBS protocol helps by allowing for contained elements governed by other namespaces. For form-based creation, a &xep0004; form can be embedded in the <session/>.

    To create a session using forms, send a <session action="create"/> with an embedded <x xmlns="jabber:x:data"/>:

    @@ -1072,4 +1072,4 @@ BINDATA :=     - + diff --git a/xep-0043.xml b/xep-0043.xml index 9491d6e6..ee6576c6 100644 --- a/xep-0043.xml +++ b/xep-0043.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
    Jabber Database Access Expose RDBM systems directly to the jabber network @@ -790,4 +790,4 @@ name CDATA #IMPLIED

    Anyone care to do this?

    - + diff --git a/xep-0044.xml b/xep-0044.xml index 46b97299..72560ade 100644 --- a/xep-0044.xml +++ b/xep-0044.xml @@ -1,11 +1,11 @@ - + %ents; ]> - + - +
    Full Namespace Support for XML Streams @@ -169,4 +169,4 @@ RECV: - + diff --git a/xep-0045.xml b/xep-0045.xml index 4b5b1649..a8760b48 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -1,12 +1,12 @@ - + %ents; ]> - - + +
    Multi-User Chat This document defines an XMPP protocol extension for multi-user text conferencing. @@ -18,34 +18,34 @@ XMPP Core XMPP IM - JEP-0004 - JEP-0030 - JEP-0068 - JEP-0082 - JEP-0128 + XEP-0004 + XEP-0030 + XEP-0068 + XEP-0082 + XEP-0128 muc muc - http://jabber.org/protocol/muc/muc.xsd + http://www.xmpp.org/schemas/muc.xsd muc#admin - http://jabber.org/protocol/muc/admin.xsd + http://www.xmpp.org/schemas/muc-admin.xsd muc#owner - http://jabber.org/protocol/muc/owner.xsd + http://www.xmpp.org/schemas/muc-owner.xsd muc#unique - http://jabber.org/protocol/muc/unique.xsd + http://www.xmpp.org/schemas/muc-unique.xsd muc#user - http://jabber.org/protocol/muc/user.xsd + http://www.xmpp.org/schemas/muc-user.xsd &stpeter; @@ -63,7 +63,7 @@
  • Moved all service discovery use cases into dedicated section.
  • Changed jabber:x:delay support from SHOULD to MUST.
  • Clarified that _whois room configuration option specifies room type.
    • -
  • Defined JEP-0128 room information fields for discussion logs, associated pubsub node, and contact JID.
    • +
  • Defined XEP-0128 room information fields for discussion logs, associated pubsub node, and contact JID.
  • Specified that changing role to moderator upon affiliation change to admin or owner is recommended, not required.
  • Added internationalization consideration about localization of field labels for various data forms.
  • Specified that implementations may persist roles across visits and should do so for moderated rooms.
    • @@ -171,7 +171,7 @@ 1.5 2003-09-11 psa -

    Specified that ban occurs by JID, not roomnick; allowed privileged users to send messages to the room even if not present in the room; added note that service should remove occupant if a delivery-related stanza error occurs; enabled user to disco the room in order to discover registered roomnick; specified that "banning" by domain or regex is a service-level configuration matter and therefore out of scope for MUC; specified that role should be decremented as appropriate if affiliation is lowered; added some clarifying text to room creation workflow; added implementation note about sending an out-of-band message if a user's affiliation changes while the user is not in the room; fixed stringprep references (room nicks use Resourceprep); clarified relationship between Room ID (i.e., node identifier of Room JID, which may be opaque) and natural-language Room Name; specified Field Standardization profile per JEP-0068; defined Jabber Registrar submissions; added schema locations.

     +

    Specified that ban occurs by JID, not roomnick; allowed privileged users to send messages to the room even if not present in the room; added note that service should remove occupant if a delivery-related stanza error occurs; enabled user to disco the room in order to discover registered roomnick; specified that "banning" by domain or regex is a service-level configuration matter and therefore out of scope for MUC; specified that role should be decremented as appropriate if affiliation is lowered; added some clarifying text to room creation workflow; added implementation note about sending an out-of-band message if a user's affiliation changes while the user is not in the room; fixed stringprep references (room nicks use Resourceprep); clarified relationship between Room ID (i.e., node identifier of Room JID, which may be opaque) and natural-language Room Name; specified Field Standardization profile per XEP-0068; defined XMPP Registrar submissions; added schema locations.

     1.4 @@ -213,7 +213,7 @@ 0.22 2002-11-04 psa -

    Added example for disco#items; added support for cancellation of room configuration using type='cancel' from JEP-0004; noted 403 error for invites sent by non-admins in members-only room.

     +

    Added example for disco#items; added support for cancellation of room configuration using type='cancel' from XEP-0004; noted 403 error for invites sent by non-admins in members-only room.

         0.21 @@ -828,7 +828,7 @@ -

    A MUC implementation MUST support &jep0030;.

    +

    A MUC implementation MUST support &xep0030;.

    A Jabber entity may wish to discover if a service implements the Multi-User Chat protocol; in order to do so, it sends a service discovery information ("disco#info") query to the component's JID:

    ]]> -

    If the full list of rooms is large (see JEP-0030 for details), the service MAY return only a partial list of rooms.

    +

    If the full list of rooms is large (see XEP-0030 for details), the service MAY return only a partial list of rooms.

    Using the disco#info protocol, a user may also query a specific chat room for more detailed information about the room. A user SHOULD do so before entering a room in order to determine the privacy and security profile of the room configuration (see the Security Considerations for details).

    @@ -917,8 +917,8 @@ ]]> -

    Note: Because MUC is a superset of the old "groupchat 1.0" protocol, a MUC room SHOULD NOT return a <feature var='gc-1.0'/> entry in a disco#info result. The room SHOULD return the materially-relevant features it supports, such as password protection and room moderation (these are listed fully in the feature registry maintained by the Jabber Registrar; see also the Jabber Registrar section of this document).

    -

    A chatroom MAY return more detailed information in its disco#info response using &jep0128;, identified by inclusion of a hidden FORM_TYPE field whose value is "http://jabber.org/protocol/muc#roominfo". Such information might include a more verbose description of the room, the current room subject, and the current number of occupants in the room:

    +

    Note: Because MUC is a superset of the old "groupchat 1.0" protocol, a MUC room SHOULD NOT return a <feature var='gc-1.0'/> entry in a disco#info result. The room SHOULD return the materially-relevant features it supports, such as password protection and room moderation (these are listed fully in the feature registry maintained by the XMPP Registrar; see also the XMPP Registrar section of this document).

    +

    A chatroom MAY return more detailed information in its disco#info response using &xep0128;, identified by inclusion of a hidden FORM_TYPE field whose value is "http://jabber.org/protocol/muc#roominfo". Such information might include a more verbose description of the room, the current room subject, and the current number of occupants in the room:

    ]]> -

    Discussion history messages MUST be stamped with extended information qualified by the 'jabber:x:delay' namespace (see &jep0091;) to indicate that they are sent with delayed delivery and specify the times at which they were originally sent. The 'from' attribute SHOULD be the full JID of the original sender in non-anonymous rooms, but MUST NOT be in semi-anonymous rooms (the 'from' attribute SHOULD be set to the room JID in semi-anonymous rooms). The service SHOULD send all discussion history messages before delivering any "live" messages sent after the user enters the room.

    +

    Discussion history messages MUST be stamped with extended information qualified by the 'jabber:x:delay' namespace (see &xep0091;) to indicate that they are sent with delayed delivery and specify the times at which they were originally sent. The 'from' attribute SHOULD be the full JID of the original sender in non-anonymous rooms, but MUST NOT be in semi-anonymous rooms (the 'from' attribute SHOULD be set to the room JID in semi-anonymous rooms). The service SHOULD send all discussion history messages before delivering any "live" messages sent after the user enters the room.

    A user MAY want to manage the amount of discussion history provided on entering a room (perhaps because the user is on a low-bandwidth connection or is using a small-footprint client). This MUST be accomplished by including a <history/> child in the initial presence stanza sent when joining the room. There are four allowable attributes for this element:

    @@ -1424,7 +1424,7 @@ since dateTime - Send only the messages received since the datetime specified (which MUST conform to the DateTime profile specified in &jep0082;). + Send only the messages received since the datetime specified (which MUST conform to the DateTime profile specified in &xep0082;).

    The service MUST send the smallest amount of traffic that meets any combination of the above criteria, taking into account service-level and room-level defaults. The service MUST send complete message stanzas only (i.e., it MUST not literally truncate the history at a certain number of characters, but MUST send the largest number of complete stanzas that results in a number of characters less than or equal to the 'maxchars' value specified). If the client wishes to receive no history, it MUST set the 'maxchars' attribute to a value of "0" (zero).

    @@ -1933,7 +1933,7 @@

    An implementation MAY allow an unaffiliated user (in a moderated room, normally a participant) to register with a room and thus become a member of the room (conversely, an implementation MAY restrict this privilege and allow only room admins to add new members). In particular, it is not possible to join a members-only room without being on the member list, so an entity may need to request membership in order to join such a room.

    -

    If allowed, this functionality SHOULD be implemented by enabling a user to send a request for registration requirements to the room qualified by the 'jabber:iq:register' namespace as described in &jep0077;:

    +

    If allowed, this functionality SHOULD be implemented by enabling a user to send a request for registration requirements to the room qualified by the 'jabber:iq:register' namespace as described in &xep0077;:

    ]]> -

    If the user requesting registration requirements is not allowed to register with the room (e.g., because that privilege has been restricted), the room MUST return a ¬allowed; error to the user. If the user is already registered, the room MUST reply with an IQ stanza of type "result" that contains an empty <register/> element as described in JEP-0077. If the room does not exist, the service MUST return an ¬found; error.

    -

    Otherwise, the room MUST then return a Data Form to the user (as described in &jep0004;). The information required to register MAY vary by implementation or deployment and is not fully specified in this document (e.g., the fields registered by this document for the 'http://jabber.org/protocol/muc#register' FORM_TYPE may be supplemented in the future via the mechanisms described in the Field Standardization section of this document). The following can be taken as a fairly typical example:

    +

    If the user requesting registration requirements is not allowed to register with the room (e.g., because that privilege has been restricted), the room MUST return a ¬allowed; error to the user. If the user is already registered, the room MUST reply with an IQ stanza of type "result" that contains an empty <register/> element as described in XEP-0077. If the room does not exist, the service MUST return an ¬found; error.

    +

    Otherwise, the room MUST then return a Data Form to the user (as described in &xep0004;). The information required to register MAY vary by implementation or deployment and is not fully specified in this document (e.g., the fields registered by this document for the 'http://jabber.org/protocol/muc#register' FORM_TYPE may be supplemented in the future via the mechanisms described in the Field Standardization section of this document). The following can be taken as a fairly typical example:

    ]]> -

    If the user does not have a registered nickname, the room MUST return a service discovery &QUERY; element that is empty (in accordance with JEP-0030).

    +

    If the user does not have a registered nickname, the room MUST return a service discovery &QUERY; element that is empty (in accordance with XEP-0030).

    Even if a user has registered one room nickname, the service SHOULD allow the user to specify a different nickname on entering the room (e.g., in order to join from different client resources), although the service MAY choose to "lock down" nicknames and therefore deny entry to the user, including a ¬acceptable; error. The service MUST NOT return an error to the user if his or her client sends the foregoing request after having already joined the room, but instead SHOULD reply as described above.

    If another user attempts to join the room with a nickname reserved by the first user, the service MUST deny entry to the second user and return a &conflict; error as previously described.

     @@ -2628,7 +2628,7 @@
  • <domain/resource> (only that resource matches)
  • <domain> (the domain itself matches, as does any user@domain, domain/resource, or address containing a subdomain)
    • -

    Some administrators may wish to ban all users associated with a specific domain from all rooms hosted by a MUC service. Such functionality is a service-level feature and is therefore out of scope for this document (but see &jep0133;).

    +

    Some administrators may wish to ban all users associated with a specific domain from all rooms hosted by a MUC service. Such functionality is a service-level feature and is therefore out of scope for this document (but see &xep0133;).

    An admin can grant membership to a user; this is done by changing the user's affiliation to "member" (normally based on nick if the user is in the room, or on bare JID if not; in either case, if the nick is provided, that nick becomes the user's default nick in the room if that functionality is supported by the implementation):

    @@ -3049,12 +3049,12 @@ ]]>

    If the admin approves the registration request, the service shall register the user with the room.

    -

    More advanced registration approval mechanisms (e.g., retrieving a list of registration requests using &jep0050; as is done in &jep0060;) are out of scope for this document.

    +

    More advanced registration approval mechanisms (e.g., retrieving a list of registration requests using &xep0050; as is done in &xep0060;) are out of scope for this document.

    Every room MUST have at least one owner, and that owner (or a successor) is a long-lived attribute of the room for as long as the room exists (e.g., the owner does not lose ownership on exiting a persistent room). This document assumes that the (initial) room owner is the individual who creates the room and that only a room owner has the right to change defining room configuration settings such as the room type. Ideally, room owners will be able to specify not only the room types (password-protected, members-only, etc.) but also certain attributes of the room as listed in the Requirements section of this document. In addition, it would be good if an owner were able to specify the JIDs of other owners, but that shall be determined by the implementation.

    -

    In order to provide the necessary flexibility for a wide range of configuration options, Data Forms (JEP-0004) shall be used for room configuration, triggered by use of the 'http://jabber.org/protocol/muc' namespace. That is, if an entity does not include the MUC namespace in its room join/create request, then the service shall create the room and not wait for configuration via Data Forms before creating the room (this ensures backwards-compatibility with the old "groupchat 1.0" protocol); however, if the room join/create request includes the MUC extension, then the service shall require configuration via Data Forms before creating and unlocking the room.

    +

    In order to provide the necessary flexibility for a wide range of configuration options, Data Forms (XEP-0004) shall be used for room configuration, triggered by use of the 'http://jabber.org/protocol/muc' namespace. That is, if an entity does not include the MUC namespace in its room join/create request, then the service shall create the room and not wait for configuration via Data Forms before creating the room (this ensures backwards-compatibility with the old "groupchat 1.0" protocol); however, if the room join/create request includes the MUC extension, then the service shall require configuration via Data Forms before creating and unlocking the room.

    Note: The configuration options shown below address all of the features and room types listed in the requirements section of this document; however, the exact configuration options and form layout shall be determined by the implementation or specific deployment. Also, these are examples only and are not intended to define the only allowed or required configuration options for rooms. A given implementation or deployment MAY choose to provide additional configuration options (profanity filters, setting the default language for a room, message logging, etc.), which is why the use of the 'jabber:x:data' protocol is valuable here.

    @@ -3168,7 +3168,7 @@ ]]> -

    If the room does not already exist, the service MUST return an initial room configuration form to the user. (Note: The following example shows a representative sample of configuration options. A full list of x:data fields registered for use in room creation and configuration is maintained by the Jabber Registrar; see the Jabber Registrar Considerations section of this document.)

    +

    If the room does not already exist, the service MUST return an initial room configuration form to the user. (Note: The following example shows a representative sample of configuration options. A full list of x:data fields registered for use in room creation and configuration is maintained by the XMPP Registrar; see the XMPP Registrar Considerations section of this document.)

    -

    The error codes associated with the 'http://jabber.org/protocol/muc#user' namespace are fairly straightforward, as summarized in the following table. For detailed information about mapping legacy error codes to XMPP-style error types and conditions, refer to &jep0086;; implementations SHOULD support both legacy and XMPP error handling.

    +

    The error codes associated with the 'http://jabber.org/protocol/muc#user' namespace are fairly straightforward, as summarized in the following table. For detailed information about mapping legacy error codes to XMPP-style error types and conditions, refer to &xep0086;; implementations SHOULD support both legacy and XMPP error handling.

    @@ -4130,7 +4130,7 @@

    This document does not stipulate text strings (i.e., values of the XMPP <text/> element) associated with the foregoing error conditions.

    -

    Multi-User Chat uses a <status/> element (specifically, the 'code' attribute of the <status/> element) to communicate information about a user's status in a room. Over time, the number of status codes has grown quite large, and new status codes continue to be requested of the JEP author. Therefore, these codes are now documented in a registry maintained by the Jabber Registrar. For details, refer to the Status Codes Registry section of this document.

    +

    Multi-User Chat uses a <status/> element (specifically, the 'code' attribute of the <status/> element) to communicate information about a user's status in a room. Over time, the number of status codes has grown quite large, and new status codes continue to be requested of the author. Therefore, these codes are now documented in a registry maintained by the XMPP Registrar. For details, refer to the Status Codes Registry section of this document.

    Note: In general, MUC status codes tend to follow the "philosophy" of status codes that is implicit in &rfc2616; and &rfc1893; (1xx codes are informational, 2xx codes specify that it is fine to continue, 3xx codes specify redirects such as being kicked or banned, x3x codes refer to system status, x7x codes refer to security or policy matters, etc.).

    Note: If the MUC protocol were being designed today, it would specify a more flexible, XML-friendly approach rather than hardcoded status numbers; however, at this point the pain of changing the status reporting system would be greater than the benefit of doing so, which is why the status code numbers remain in use. A future version of this document may define a more XMPP-like approach to status conditions, retaining the code numbers but supplementing them with more descriptive child elements as is done in RFC 3920.

     @@ -4155,12 +4155,12 @@ -

    This JEP requires no interaction with &IANA;.

    +

    This document requires no interaction with &IANA;.

     - +

    The ®ISTRAR; includes the following information in its registries.

    -

    The Jabber Registrar includes the following MUC-related namespaces in its registry of protocol namespaces:

    +

    The XMPP Registrar includes the following MUC-related namespaces in its registry of protocol namespaces:

    • http://jabber.org/protocol/muc
    • http://jabber.org/protocol/muc#admin
      • @@ -4178,82 +4178,82 @@ http://jabber.org/protocol/muc#register Support for the muc#register FORM_TYPE - JEP-0045 + XEP-0045 http://jabber.org/protocol/muc#roomconfig Support for the muc#roomconfig FORM_TYPE - JEP-0045 + XEP-0045 http://jabber.org/protocol/muc#roominfo Support for the muc#roominfo FORM_TYPE - JEP-0045 + XEP-0045 muc_hidden Hidden room in Multi-User Chat (MUC) - JEP-0045 + XEP-0045 muc_membersonly Members-only room in Multi-User Chat (MUC) - JEP-0045 + XEP-0045 muc_moderated Moderated room in Multi-User Chat (MUC) - JEP-0045 + XEP-0045 muc_nonanonymous Non-anonymous room in Multi-User Chat (MUC) - JEP-0045 + XEP-0045 muc_open Open room in Multi-User Chat (MUC) - JEP-0045 + XEP-0045 muc_passwordprotected Password-protected room in Multi-User Chat (MUC) - JEP-0045 + XEP-0045 muc_persistent Persistent room in Multi-User Chat (MUC) - JEP-0045 + XEP-0045 muc_public Public room in Multi-User Chat (MUC) - JEP-0045 + XEP-0045 muc_rooms List of MUC rooms (each as a separate item) - JEP-0045 + XEP-0045 muc_semianonymous Semi-anonymous room in Multi-User Chat (MUC) - JEP-0045 + XEP-0045 muc_temporary Temporary room in Multi-User Chat (MUC) - JEP-0045 + XEP-0045 muc_unmoderated Unmoderated room in Multi-User Chat (MUC) - JEP-0045 + XEP-0045 muc_unsecured Unsecured room in Multi-User Chat (MUC) - JEP-0045 + XEP-0045 ]]> @@ -4263,12 +4263,12 @@

      The well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' enables discovery of the namespaces that are allowed in traffic sent through a room (see the Allowable Traffic section of this document).

      -

      &jep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. Within MUC, there are three uses of such forms: room registration within muc#user, room configuration within muc#owner, and service discovery extensions for room information. The reserved fields are defined below.

      +

      &xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. Within MUC, there are three uses of such forms: room registration within muc#user, room configuration within muc#owner, and service discovery extensions for room information. The reserved fields are defined below.

      http://jabber.org/protocol/muc#register - JEP-0045 + XEP-0045 Forms enabling user registration with a Multi-User Chat (MUC) room or admin approval @@ -4309,7 +4309,7 @@ http://jabber.org/protocol/muc#roomconfig - JEP-0045 + XEP-0045 Forms enabling creation and configuration of a Multi-User Chat (MUC) room. @@ -4393,7 +4393,7 @@ http://jabber.org/protocol/muc#roominfo - JEP-0045 + XEP-0045 Forms enabling the communication of extended service discovery information about a Multi-User Chat (MUC) room. @@ -4428,7 +4428,7 @@       -

      The Jabber Registrar maintains a registry of values for the 'code' attribute of the <status/> element when qualified by the 'http://jabber.org/protocol/muc#user' namespace.

      +

      The XMPP Registrar maintains a registry of values for the 'code' attribute of the <status/> element when qualified by the 'http://jabber.org/protocol/muc#user' namespace.

      ®PROCESS; @@ -4566,7 +4566,7 @@       -

      As authorized by &jep0147;, the Jabber Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).

      +

      As authorized by &xep0147;, the XMPP Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).

      The "join" querytype is registered as a MUC-related action, with an optional key of "password".

      join http://jabber.org/protocol/muc enables joining a multi-user chat room - JEP-0045 + XEP-0045 password @@ -4658,7 +4658,7 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password invite http://jabber.org/protocol/muc enables simultaneously joining a groupchat room and inviting others - JEP-0045 + XEP-0045 jid @@ -4684,7 +4684,7 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password

    • If a MUC service receives a message directed to the room or to a single occupant from a Jabber user who has a role of "none", the service MUST NOT deliver the message and SHOULD return the message to the sender with a &forbidden; error.

    • If a MUC service receives a message directed to a room that does not exist or is not yet unlocked, the service SHOULD return the message to the sender with an ¬found; error.

    • A MUC service SHOULD pass extended information (e.g., an XHTML version of the message body) through to occupants unchanged; however, a MUC service MAY disallow message specific extensions (see the Allowable Traffic section of this document).

      • -

    • A MUC client MAY generate extensions that conform to the &jep0022; or &jep0085; specification; however, a MUC service MAY disallow these extensions (see the Allowable Traffic section of this document).

      • +

    • A MUC client MAY generate extensions that conform to the &xep0022; or &xep0085; specification; however, a MUC service MAY disallow these extensions (see the Allowable Traffic section of this document).

      •  @@ -4713,7 +4713,7 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password

      The following guidelines may assist client and component developers in creating MUC implementations.

        -

      1. In handling messages sent by visitors in a moderated room, a MUC service MAY queue each message for approval by a moderator and MAY inform the sender that the message is being held for approval; however, such behavior is OPTIONAL, and definition of a message approval protocol (e.g., using Data Forms as defined in JEP-0004) is out of scope for this document.

        2. +

      2. In handling messages sent by visitors in a moderated room, a MUC service MAY queue each message for approval by a moderator and MAY inform the sender that the message is being held for approval; however, such behavior is OPTIONAL, and definition of a message approval protocol (e.g., using Data Forms as defined in XEP-0004) is out of scope for this document.

      3. It is common for MUC services to provide in-room messages when certain events occur, such as when the subject changes, when an occupant enters or exits, or when a room is destroyed. Such messages are entirely OPTIONAL and are left up to the implementation or deployment, but if used MUST be messages of type "groupchat" sent from the room JID itself (&ROOM;) rather than a specific occupant (&ROOMJID;). However, in general it is preferable for the receiving client to generate such messages based on events in the room (e.g., user entrances and exits) as well as specific status codes provided in MUC; this will help ensure correct localization of such messages.

      4. Out of courtesy, a MUC service MAY send an out-of-room <message/> to an occupant who is kicked or banned, and MAY broadcast an in-room <message/> to all remaining occupants informing them that the occupant has been kicked or banned from the room. However, such messages are OPTIONAL, and indeed are unnecessary since the information required for a receiving client to generate such messages is communicated in the presence stanzas (specifically the status codes) sent by a MUC service.

      5. Out of courtesy, a MUC service MAY send an out-of-room <message/> if a user's affiliation changes while the user is not in the room; the message SHOULD be sent from the room to the user's bare JID, MAY contain a <body/> element describing the affiliation change, and MUST contain a status code of 101.

        6. @@ -4724,11 +4724,11 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password

      6. A MUC service MAY choose to make available a special in-room resource that provides an interface to administrative functionality (e.g., a "user" named "ChatBot"), which occupants could interact with directly, thus enabling admins to type '/command parameter' in a private message to that "user". Obviously this kind of implementation would require the service to add a 'ChatBot' user to the room when it is created, and to prevent any occupant from having the nickname 'ChatBot' in the room. This might be difficult to ensure in some implementations or deployments. In any case, any such interface is OPTIONAL.

      7. A MUC service SHOULD remove a user if the service receives a delivery-related error in relation to a stanza it has previously sent to the user (remote server unreachable, user not found, etc.).

      8. A MUC service MAY choose to discard extended presence information that is attached to a &PRESENCE; stanza before reflecting the presence change to the occupants of a room. That is, an implementation MAY choose to reflect only the <show/>, <status/>, and <priority/> child elements of the presence element as specified in the XML schema for the 'jabber:client' namespace, with the result that presence "changes" in extended namespaces (e.g., gabber:x:music:info) are not passed through to occupants. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the Allowable Traffic section of this document.

        9. -

      9. A MUC service MAY choose to discard extended information attached to &MESSAGE; stanzas before reflecting the message to the occupants of a room. An example of such extended information is the lightweight text markup specified by &jep0071;. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the Allowable Traffic section of this document.

        10. +

      10. A MUC service MAY choose to discard extended information attached to &MESSAGE; stanzas before reflecting the message to the occupants of a room. An example of such extended information is the lightweight text markup specified by &xep0071;. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the Allowable Traffic section of this document.

      11. A MUC service MAY choose to "lock down" room nicknames (e.g., hardcoding the room nickname to the bare JID of the occupant). If so, the service MUST treat the locked down nickname as a reserved room nickname and MUST support the protocol specified in the Discovering Reserved Room Nickname section of this document.

      -

      As noted, a service (more precisely, a properly-configured room) MAY discard some or all extended namespaces attached to &MESSAGE; and &PRESENCE; stanzas that are intended for reflection from the sender through the room to all of the room occupants. If the room does so, it SHOULD enable senders to discover the list of allowable extensions by sending a disco#info query to the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic', returning one <feature/> element for each namespace supported in the result. If the room does not allow any extended namespaces, it MUST return an empty query as specified in JEP-0030. If the room does not support the "#traffic" node, it MUST return a &feature; error in response to queries sent to the 'http://jabber.org/protocol/muc#traffic' node.

      +

      As noted, a service (more precisely, a properly-configured room) MAY discard some or all extended namespaces attached to &MESSAGE; and &PRESENCE; stanzas that are intended for reflection from the sender through the room to all of the room occupants. If the room does so, it SHOULD enable senders to discover the list of allowable extensions by sending a disco#info query to the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic', returning one <feature/> element for each namespace supported in the result. If the room does not allow any extended namespaces, it MUST return an empty query as specified in XEP-0030. If the room does not support the "#traffic" node, it MUST return a &feature; error in response to queries sent to the 'http://jabber.org/protocol/muc#traffic' node.

      The following example shows a room that allows the 'http://jabber.org/protocol/xhtml-im' and 'http://jabber.org/protocol/rosterx' namespaces only, but no other extended namespaces.

      The protocol documented by this schema is defined in - JEP-0045: http://www.jabber.org/jeps/jep-0045.html + XEP-0045: http://www.xmpp.org/extensions/xep-0045.html @@ -4938,7 +4938,7 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password The protocol documented by this schema is defined in - JEP-0045: http://www.jabber.org/jeps/jep-0045.html + XEP-0045: http://www.xmpp.org/extensions/xep-0045.html @@ -5063,7 +5063,7 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password The protocol documented by this schema is defined in - JEP-0045: http://www.jabber.org/jeps/jep-0045.html + XEP-0045: http://www.xmpp.org/extensions/xep-0045.html @@ -5141,7 +5141,7 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password The protocol documented by this schema is defined in - JEP-0045: http://www.jabber.org/jeps/jep-0045.html + XEP-0045: http://www.xmpp.org/extensions/xep-0045.html @@ -5190,7 +5190,7 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password The protocol documented by this schema is defined in - JEP-0045: http://www.jabber.org/jeps/jep-0045.html + XEP-0045: http://www.xmpp.org/extensions/xep-0045.html @@ -5203,4 +5203,4 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password

      The author would like to thank the following individuals for their many helpful comments on various drafts of this proposal: David Sutton, Peter Millard, Joe Hildebrand, Craig Kaes, Alexey Shchepin, David Waite, Jean-Louis Seguineau, Jacek Konieczny, Gaston Dombiak, and many others in the jdev@conference.jabber.org conference room and on the Standards-JIG mailing list.

       - + diff --git a/xep-0046.xml b/xep-0046.xml index 4440ccaf..8511fa4e 100644 --- a/xep-0046.xml +++ b/xep-0046.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
      DTCP Direct TCP connection between two Jabber entities. @@ -15,7 +15,7 @@ Standards None None - JEP-0065 + XEP-0065 None Justin @@ -27,7 +27,7 @@ 0.8 2003-04-11 psa - At the request of the JEP author, changed status to Retracted. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations. + At the request of the author, changed status to Retracted. This specification will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations. 0.7 @@ -213,4 +213,4 @@ - + diff --git a/xep-0047.xml b/xep-0047.xml index cde74b24..bb894dae 100644 --- a/xep-0047.xml +++ b/xep-0047.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
      In-Band Bytestreams (IBB) - This JEP defines a protocol for bytestreaming data in band between any two entities over Jabber/XMPP. + This document defines an XMPP protocol extension for bytestreaming data in band between any two entities over Jabber/XMPP. &LEGALNOTICE; 0047 Draft @@ -15,12 +15,12 @@ Standards JIG XMPP Core - JEP-0079 + XEP-0079 - http://jabber.org/protocol/ibb/ibb.xsd + http://www.xmpp.org/schemas/ibb.xsd ibb &infiniti; @@ -40,7 +40,7 @@ 0.7 2003-05-23 jk - Use IQ for shutdown, remove JEP-0022 dependency, loop the counter + Use IQ for shutdown, remove XEP-0022 dependency, loop the counter 0.6 @@ -85,7 +85,7 @@ -

      IBB is a generic bytestream, and so its usage is left open-ended. It is likely to be useful for sending small payloads, such as files that would otherwise be too cumbersome to send as an instant message (such as a text file) or impossible to send (such as a small binary image file). It could also be useful for any kind of low-bandwidth activity, such as a chess game or a shell session. And, while it is mostly intended as a fallback in situations where a &jep0065; is unavailable, IBB could be more desirable for many of the simple bytestream use-cases that do not have high bandwidth requirements.

      +

      IBB is a generic bytestream, and so its usage is left open-ended. It is likely to be useful for sending small payloads, such as files that would otherwise be too cumbersome to send as an instant message (such as a text file) or impossible to send (such as a small binary image file). It could also be useful for any kind of low-bandwidth activity, such as a chess game or a shell session. And, while it is mostly intended as a fallback in situations where a &xep0065; is unavailable, IBB could be more desirable for many of the simple bytestream use-cases that do not have high bandwidth requirements.

       @@ -129,7 +129,7 @@ -

      Data is sent using message stanzas. Either participant in the bytestream may send such packets. The data to be sent, prior to any encoding or wrapping in the message stanza, must be no larger than the 'block-size' determined in the stream negotiation. All packets are to be addressed to the FULL JID of the bytestream peer. In order to keep track of stanzas sent and any errors received, the sender SHOULD include the 'id' attribute on stanzas sent to the recipient. Note that &jep0079; SHOULD be used to ensure that the data packet is not spooled or sent to the wrong resource.

      +

      Data is sent using message stanzas. Either participant in the bytestream may send such packets. The data to be sent, prior to any encoding or wrapping in the message stanza, must be no larger than the 'block-size' determined in the stream negotiation. All packets are to be addressed to the FULL JID of the bytestream peer. In order to keep track of stanzas sent and any errors received, the sender SHOULD include the 'id' attribute on stanzas sent to the recipient. Note that &xep0079; SHOULD be used to ensure that the data packet is not spooled or sent to the wrong resource.

      @@ -220,12 +220,12 @@       -

      This JEP requires no interaction with &IANA;.

      +

      This document requires no interaction with &IANA;.

       - + -

      The ®ISTRAR; shall register the 'http://jabber.org/protocol/ibb' namespace as a result of this JEP.

      +

      The ®ISTRAR; shall register the 'http://jabber.org/protocol/ibb' namespace as a result of this document.

             @@ -242,7 +242,7 @@ The protocol documented by this schema is defined in - JEP-0047: http://www.jabber.org/jeps/jep-0047.html + XEP-0047: http://www.xmpp.org/extensions/xep-0047.html @@ -288,4 +288,4 @@ ]]>       - + diff --git a/xep-0048.xml b/xep-0048.xml index 51856e87..a034dea2 100644 --- a/xep-0048.xml +++ b/xep-0048.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
      Bookmark Storage This specification documents a protocol for the storage of bookmarks to conference rooms and other entities in a Jabber user's account. @@ -15,13 +15,13 @@ Standards JIG XMPP Core - JEP-0049 + XEP-0049 bookmarks - http://jabber.org/protocol/bookmarks/bookmarks.xsd + http://www.xmpp.org/schemas/bookmarks.xsd Rachel @@ -56,8 +56,8 @@
      -

      For ease-of-use in a Jabber client, it is desirable to have a way to store shortcuts to various services and resources (such as conference rooms and webpages) as 'bookmarks' which can be displayed in the user's client. Several Jabber clients have already agreed on and implemented a method to provide this service; that informal agreement is documented and expanded upon in this JEP.

      -

      &jep0049; provides us with a convenient method for storing user data on the server using jabber:iq:private; all we need to do is define a namespace and schema for storing this sort of information. To this end, we introduce the 'storage' element, and the 'storage:bookmarks' to handle this data.

      +

      For ease-of-use in a Jabber client, it is desirable to have a way to store shortcuts to various services and resources (such as conference rooms and webpages) as 'bookmarks' which can be displayed in the user's client. Several Jabber clients have already agreed on and implemented a method to provide this service; that informal agreement is documented and expanded upon in this document.

      +

      &xep0049; provides us with a convenient method for storing user data on the server using jabber:iq:private; all we need to do is define a namespace and schema for storing this sort of information. To this end, we introduce the 'storage' element, and the 'storage:bookmarks' to handle this data.

      A storage element marked by the storage:bookmarks namespace will contain a collection of child elements, each representing a 'bookmark' to be displayed in the client. At present, only two sub-elements are defined, 'conference' for conference rooms and 'url' for normal URLs.

      @@ -80,7 +80,7 @@

      One of the most common uses of bookmarks will likely be to bookmark conference rooms on various Jabber servers. It is this aspect of the bookmark system which is used today by existing clients such as Exodus Exodus, see <http://exodus.jabberstudio.org/>. and Rival Messenger Rival Messenger, see <http://rival.chote.net/>.. In addition to the required 'jid' attribute, the conference element also possesses an 'autojoin' attribute, which determines whether or not the client should automatically join that conference room on login; this attribute is of type xs:boolean (see &w3xmlschema2;) and the default value is "false". &BOOLEANNOTE;

      -

      The conference element MAY also contain 'nick' and 'password' sub-elements; the XML character data from these elements should be used when joining the room from the bookmark. Password is, of course, important for joining potentially password-protected &jep0045; rooms.

      +

      The conference element MAY also contain 'nick' and 'password' sub-elements; the XML character data from these elements should be used when joining the room from the bookmark. Password is, of course, important for joining potentially password-protected &xep0045; rooms.

      @@ -99,13 +99,13 @@       -

      Security considerations related to private XML storage are described in JEP-0049.

      +

      Security considerations related to private XML storage are described in XEP-0049.

       -

      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.

       The protocol documented by this schema is defined in - JEP-0048: http://www.jabber.org/jeps/jep-0048.html + XEP-0048: http://www.xmpp.org/extensions/xep-0048.html @@ -168,4 +168,4 @@

      Peter Millard, a co-author of this specification from version 0.1 through version 1.0, died on April 26, 2006.

       -       + diff --git a/xep-0049.xml b/xep-0049.xml index 6bfbd0c1..1557413e 100644 --- a/xep-0049.xml +++ b/xep-0049.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
      Private XML Storage This specification provides canonical documentation of the 'jabber:iq:private' namespace currently in common usage. @@ -20,7 +20,7 @@ iq-private - http://jabber.org/protocol/iq-private/iq-private.xsd + http://www.xmpp.org/schemas/iq-private.xsd &stpeter; @@ -39,7 +39,7 @@ 1.1 2004-01-06 psa - Added XML schema; specified XMPP error handling; added security, IANA, and Jabber Registrar considerations. + Added XML schema; specified XMPP error handling; added security, IANA, and XMPP Registrar considerations. 1.0 @@ -80,11 +80,11 @@
      -

      The 'jabber:iq:private' namespace has previously been documented in the Jabber Programmers Guide, but not in a canonical form such as the Internet-Drafts or a JEP. This specification documents the existing usage of jabber:iq:private.

      +

      The 'jabber:iq:private' namespace has previously been documented in the Jabber Programmers Guide, but not in a canonical form such as the Internet-Drafts or a XEP. This specification documents the existing usage of jabber:iq:private.

       -

      A Jabber client can store any arbitrary XML on the server side by sending an &IQ; stanza of type "set" to the server with a &QUERY; child scoped by the 'jabber:iq:private' namespace. The &QUERY; element MAY contain any arbitrary XML fragment as long as the root element of that fragment is scoped by its own namespace. The data can then be retrieved by sending an &IQ; stanza of type "get" with a &QUERY; child scoped by the 'jabber:iq:private' namespace, which in turn contains a child element scoped by the namespace used for storage of that fragment. Using this method, Jabber entities can store private data on the server and retrieve it whenever necessary. The data stored might be anything, as long as it is valid XML. One typical usage for this namespace is the server-side storage of client-specific preferences; another is &jep0048;.

      +

      A Jabber client can store any arbitrary XML on the server side by sending an &IQ; stanza of type "set" to the server with a &QUERY; child scoped by the 'jabber:iq:private' namespace. The &QUERY; element MAY contain any arbitrary XML fragment as long as the root element of that fragment is scoped by its own namespace. The data can then be retrieved by sending an &IQ; stanza of type "get" with a &QUERY; child scoped by the 'jabber:iq:private' namespace, which in turn contains a child element scoped by the namespace used for storage of that fragment. Using this method, Jabber entities can store private data on the server and retrieve it whenever necessary. The data stored might be anything, as long as it is valid XML. One typical usage for this namespace is the server-side storage of client-specific preferences; another is &xep0048;.
    Code
    @@ -95,7 +95,7 @@
    -

    The root element of this namespace is query. At least one child element with a proper namespace MUST be included; otherwise the server MUST respond with a "Not Acceptable" error (see &jep0086; for information about error conditions). A client MUST NOT query for more than namespace in a single IQ get request. However, an IQ set or result MAY contain multiple elements qualified by the same namespace.

    +

    The root element of this namespace is query. At least one child element with a proper namespace MUST be included; otherwise the server MUST respond with a "Not Acceptable" error (see &xep0086; for information about error conditions). A client MUST NOT query for more than namespace in a single IQ get request. However, an IQ set or result MAY contain multiple elements qualified by the same namespace.

    A server MUST NOT allow any entity other than an authorized resource of the user to create, update, or delete private XML stored on behalf of that user.

     -

    This JEP requires no interaction with &IANA;.

    +

    This document requires no interaction with &IANA;.

     - -

    No action on the part of the ®ISTRAR; is necessary as a result of this JEP, since 'jabber:iq:private' is already a registered namespace.

    + +

    No action on the part of the ®ISTRAR; is necessary as a result of this document, since 'jabber:iq:private' is already a registered namespace.

     The protocol documented by this schema is defined in - JEP-0049: http://www.jabber.org/jeps/jep-0049.html + XEP-0049: http://www.xmpp.org/extensions/xep-0049.html @@ -249,4 +249,4 @@ SERVER (optional error): ]]> - +