mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-26 19:22:15 -05:00
abstracts
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1555 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
fbc9a9df15
commit
089bd66e2f
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Data Forms</title>
|
||||
<abstract>This document defines an XMPP protocol extension for data forms and generic data description.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension for data forms that can be used in worklows such as service configuration as well as for application-specific data description and reporting. The protocol includes lightweight semantics for forms processing (such as request, response, submit, and cancel), defines several common field types (boolean, list options with single or multiple choice, text with single line or multiple lines, single or multiple JabberIDs, hidden fields, etc.), provides extensibility for future data types, and can be embedded in a wide range of applications. The protocol is not intended to provide complete forms-processing functionality as is provided in the W3C XForms technology, but instead provides a basic subset of such functionality for use by XMPP entities.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0004</number>
|
||||
<status>Final</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Jabber-RPC</title>
|
||||
<abstract>This specification defines a method for transporting XML-RPC encoded requests and responses over Jabber/XMPP.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension for transporting XML-RPC encoded requests and responses between two XMPP entities. The protocol supports all syntax and semantics of XML-RPC except that it uses XMPP instead of HTTP as the underlying transport.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0009</number>
|
||||
<status>Final</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Last Activity</title>
|
||||
<abstract>This document defines an XMPP protocol extension for retrieving information about the last activity associated with a Jabber entity.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension for communicating information about the last activity associated with an XMPP entity. It is typically used by an IM client to retrieve the most recent presence information from an offline contact by sending a last activity request to the server that hosts the account controlled by the contact.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0012</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Flexible Offline Message Retrieval</title>
|
||||
<abstract>This document defines an XMPP protocol extension for flexible, POP3-like handling of offline messages.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension for flexible, POP3-like handling of offline messages. The protocol enables a connecting client to retrieve its offline messages on login in a controlled fashion, without receiving a flood of messages. Messages can also be left on the server for later retrieval.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0013</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Privacy Lists</title>
|
||||
<abstract>This specification defines an XMPP protocol extension for enabling or disabling communication with other entities on a network; the main body of this document has been copied without modification from Section 10 of RFC 3921.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension for enabling or disabling communication with other entities on a network. The protocol, which was first standardized in Section 10 of RFC 3921, can be used to block communication with unknown or undesirable entities. Blocking can be based on Jabber Identifier, subscription state, or roster group. The blocked stanzas can be messages, IQs, inbound or outbound presence stanzas, or all stanzas. The protocol also enables an entity to create, modify, or delete its privacy lists, apply different lists to different connected resources, define a default list, and decline the use of any privacy list during a particular communications session.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0016</number>
|
||||
<status>Draft</status>
|
||||
@ -828,6 +828,13 @@
|
||||
xmlns='jabber:iq:privacy'
|
||||
elementFormDefault='qualified'>
|
||||
|
||||
<xs:annotation>
|
||||
<xs:documentation>
|
||||
The protocol documented by this schema is defined in
|
||||
XEP-0016: http://www.xmpp.org/extensions/xep-0016.html
|
||||
</xs:documentation>
|
||||
</xs:annotation>
|
||||
|
||||
<xs:element name='query'>
|
||||
<xs:complexType>
|
||||
<xs:sequence>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Feature Negotiation</title>
|
||||
<abstract>This document defines an XMPP protocol extension that enables two entities to mutually negotiate feature options.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension that enables two entities to mutually negotiate feature options, such as parameters related to a file transfer or a communications session.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0020</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Service Discovery</title>
|
||||
<abstract>This document defines an XMPP protocol extension for discovering (1) information about Jabber entities and (2) the items associated with such entities.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension for discovering information about other XMPP entities. Two kinds of information can be discovered: (1) the identity and capabilities of an entity, including the protocols and features it supports; and (2) the items associated with an entity, such as the list of rooms hosted at a multi-user chat service.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0030</number>
|
||||
<status>Final</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Extended Stanza Addressing</title>
|
||||
<abstract>This document specifies an XMPP protocol extension that enables entities to include RFC822-style address headers within XMPP stanzas in order to specify multiple recipients or sub-addresses.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension that enables entities to include RFC822-style address headers within XMPP stanzas in order to specify multiple recipients or sub-addresses.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0033</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>In-Band Bytestreams (IBB)</title>
|
||||
<abstract>This document defines an XMPP protocol extension for bytestreaming data in band between any two entities over Jabber/XMPP.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension that enables any two entities to establish a one-to-one bytestream between themselves, where the data is broken down into smaller chunks and transported in-band over XMPP.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0047</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Bookmarks</title>
|
||||
<abstract>This document defines an XML data format for storing bookmarks to chat rooms and web pages in XMPP.</abstract>
|
||||
<abstract>This specification defines an XML data format for use by XMPP clients in storing bookmarks to mult-user chatrooms and web pages. The chatroom bookmarking function includes the ability to auto-join rooms on login.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0048</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Ad-Hoc Commands</title>
|
||||
<abstract>This document defines an XMPP protocol extension for reporting and executing ad-hoc, human-oriented commands.</abstract>
|
||||
<abstract>This document defines an XMPP protocol extension for advertising and executing application-specific commands, such as those related to a configuration workflow. Typically the commands contain data forms (XEP-0004) in order to structure the information exchange.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0050</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Result Set Management</title>
|
||||
<abstract>This document defines an XMPP protocol extension to enable entities to page through and otherwise manage the receipt of large result sets.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension that enables an entity to page through and otherwise manage the receipt of large result sets. The protocol can be used in the context of any XMPP protocol that might send large result sets (such as service discovery, multi-user chat, and publish-subscribe). While the requesting entity in such an interaction can explicitly request the use of result set management, an indication that result set management is in use can also be proactively included by the responding entity when returning a limited result set in response to a query.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0059</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -10,7 +10,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Publish-Subscribe</title>
|
||||
<abstract>This document specifies an XMPP protocol extension for generic publish-subscribe functionality.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension for generic publish-subscribe functionality. The protocol enables XMPP entities to create nodes (topics) at a pubsub service and publish information at those nodes; an event notification (with or without payload) is then broadcasted to all entities that have subscribed to the node. Pubsub therefore adheres to the classic Observer design pattern and can serve as the foundation for a wide variety of applications, including news feeds, content syndication, rich presence, geolocation, workflow systems, network management systems, and any other application that requires event notifications.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0060</number>
|
||||
<status>Draft</status>
|
||||
@ -288,7 +288,7 @@
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<section2 topic='Overview' anchor='intro-overview'>
|
||||
<p>As Jabber/XMPP technologies have matured, the need for a generic publish-subscribe ("pubsub") mechanism has arisen in a number of domains. These include (but are not limited to): news feeds and content syndication, extended presence, avatar management, shared bookmarks, auction and trading systems, online catalogs, workflow systems, network management systems, NNTP gateways, profile management, and event notification.</p>
|
||||
<p>As Jabber/XMPP technologies have matured, the need for a generic publish-subscribe ("pubsub") mechanism has arisen in a number of domains. These include (but are not limited to): news feeds, content syndication, extended presence, geolocation, avatar management, shared bookmarks, auction and trading systems, workflow systems, network management systems, NNTP gateways, profile management, and any other application that requires event notifications.</p>
|
||||
<p>In all of these domains, it is desirable for data communication to follow the classic "publish-subscribe" or "observer" design pattern: a person or application publishes information, and an event notification (with or without payload) is broadcasted to all authorized subscribers. In general, the relationship between the publisher and subscriber is mediated by a service that receives publication requests, broadcasts event notifications to subscribers, and enables privileged entities to manage lists of people or applications that are authorized to publish or subscribe. In most pubsub services, the focal point for publication and subscription is a "topic" or "node" to which publishers send data and from which subscribers receive notifications. Additionally, some nodes may also maintain a history of events and provide other services that supplement the pure pubsub model.</p>
|
||||
<p>This document defines a single, cohesive, generic protocol that all forms of pubsub can use. While compliant implementations are not required to implement all of the features defined herein, this document addresses most use cases that may be requested of a pubsub service. (For information about which features are required and which are recommended or optional, consult the <link url='#features'>Feature Summary</link>.) Other specifications may define "subsets" or "profiles" of publish-subscribe for use in specialized contexts, but such profiles are out of scope for this document.</p>
|
||||
</section2>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>SOCKS5 Bytestreams</title>
|
||||
<abstract>This document defines an XMPP protocol extension for establishing an out-of-band bytestream between any two Jabber entities.</abstract>
|
||||
<abstract>This document defines an XMPP protocol extension for establishing an out-of-band bytestream between any two XMPP users, mainly for the purpose of file transfer. The bytestream can be either direct (peer-to-peer) or mediated (though a special-purpose proxy server). The typical transport protocol used is TCP, although UDP may optionally be supported as well.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0065</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Out of Band Data</title>
|
||||
<abstract>This document provides canonical documentation of two XMPP protocol extensions for communicating URIs.</abstract>
|
||||
<abstract>This specification defines two XMPP protocol extensions for communicating URIs, one for use in XMPP message stanzas and the other for use in a structured request-response interaction via XMPP IQ stanzas. Among other things, this enables one entity to inform another entity about a file that is available at an HTTP URL.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0066</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Verifying HTTP Requests via XMPP</title>
|
||||
<abstract>This document defines an XMPP protocol extension that enables verification of an HTTP request via XMPP.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension that enables verification of an HTTP request via XMPP.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0070</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>XHTML-IM</title>
|
||||
<abstract>This document defines an XHTML 1.0 Integration Set for use in exchanging instant messages that contain lightweight text markup.</abstract>
|
||||
<abstract>This specification defines an XHTML 1.0 Integration Set for use in exchanging instant messages that contain lightweight text markup. The protocol enables an XMPP entity to format a message using a small range of commonly-used HTML elements, attributes, and style properties that are suitable for use in instant messaging. The protocol also excludes HTML constructs that may introduce malware and other vulnerabilities (such as scripts and objects) for improved security.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0071</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>SOAP Over XMPP</title>
|
||||
<abstract>This document defines methods for transporting SOAP messages over Jabber/XMPP.</abstract>
|
||||
<abstract>This specification defines methods for transporting SOAP messages over XMPP. Although the protocol supports only the request-response message exchange pattern, the protocol is formally defined as a SOAP Protocol Binding in accordance with version 1.2 of the W3C SOAP specification. In addition, a WSDL definition is defined for the purpose of advertising the availability of this protocol binding.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0072</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>In-Band Registration</title>
|
||||
<abstract>This specification documents a protocol for in-band registration with instant messaging servers and associated services using the jabber:iq:register namespace.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension for in-band registration with XMPP-based instant messaging servers and other services hosted on an XMPP network (such as groupchat rooms and gateways to non-XMPP IM services). The protocol is extensible via use of data forms, thus enabling services to gather a wide range of information during the registration process. The protocol also supports in-band password changes and cancellation of an existing registration.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0077</number>
|
||||
<status>Final</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Advanced Message Processing</title>
|
||||
<abstract>This document defines an XMPP protocol extension that enables entities to request, and servers to perform, advanced processing of XMPP <message/> stanzas, including reliable data transport, time-sensitive delivery, and transient messages.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension that enables entities to request, and servers to perform, advanced processing of XMPP message stanzas, including reliable data transport, time-sensitive delivery, and expiration of transient messages.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0079</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>User Location</title>
|
||||
<abstract>This document defines an XMPP protocol extension for communicating information about the current geographical location of an entity.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension for communicating information about the current geographical or physical location of an entity.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0080</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>User Avatar</title>
|
||||
<abstract>This document defines an XMPP protocol extension for exchanging user avatars.</abstract>
|
||||
<abstract>This document defines an XMPP protocol extension for exchanging user avatars, which are small images or icons associated with human users. The protocol specifies payload formats for both avatar metadata and the image data itself. The payload formats are typically transported using the personal eventing profile of XMPP publish-subscribe as specified in XEP-0163.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0084</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Chat State Notifications</title>
|
||||
<abstract>This document defines an XMPP protocol extension for communicating the status of a user in a chat session.</abstract>
|
||||
<abstract>This document defines an XMPP protocol extension for communicating the status of a user in a chat session, thus indicating whether a chat partner is actively engaged in the chat, composing a message, temporarily paused, inactive, or gone. The protocol can be used in the context of a one-to-one chat session or a multi-user chat room.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0085</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,8 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Software Version</title>
|
||||
<abstract>This specification provides canonical documentation of an XMPP protocol extension for retrieving information about the software version associated with another XMPP entity.</abstract> &LEGALNOTICE;
|
||||
<abstract>This specification defines an XMPP protocol extension for retrieving information about the software application associated with an XMPP entity. The protocol enables one entity to explicitly query another entity, where the response can include the name of the software application, the version of the software application, and the operating system on which the application is running.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0092</number>
|
||||
<status>Draft</status>
|
||||
<type>Standards Track</type>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Stream Initiation</title>
|
||||
<abstract>This document defines an XMPP protocol extension for initiating a stream (with meta information) between any two Jabber entities.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension for initiating a data stream between any two XMPP entities. The protocol includes the ability to include metadata about the stream and provides a pluggable framework so that various profiles of stream initiation can be defined for particular use cases (such as file transfer).</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0095</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>File Transfer</title>
|
||||
<abstract>This document defines a stream initiation profile for transferring files.</abstract>
|
||||
<abstract>This specification defines a profile of the XMPP stream initiation extension for transferring files between two entities. The protocol provides a modular framework that enables the exchange of information about the file to be transferred as well as the negotiation of parameters such as the transport to be used.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0096</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>JID Escaping</title>
|
||||
<abstract>This document specifies a mechanism that enables the display of Jabber Identifiers (JIDs) with characters disallowed by the Nodeprep profile of stringprep.</abstract>
|
||||
<abstract>This specification defines a mechanism that enables the display in Jabber Identifiers (JIDs) of characters disallowed by the Nodeprep profile of stringprep. Although these characters -- space, double quote, ampersand, single quote, forward slash, colon, less than, greater than, and at-sign -- cannot be included in XMPP node identifiers, JID Escaping provides a native XMPP escaping mechanism for these characters so that the displayed version of a Jabber Identifier can appear to include these characters. This mechanism can also be used to translate non-XMPP addreses into XMPP syntax, for example when gatewaying between XMPP and a non-XMPP communications technology such as email.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0106</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,8 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>User Mood</title>
|
||||
<abstract>This document defines an XMPP protocol extension for communicating information about user moods.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension for communicating information about user moods.</abstract>
|
||||
<abstract>This specification defines a payload format for communicating information about user moods, such as whether a person is currently happy, sad, angy, or annoyed. The payload format is typically transported using the personal eventing profile of XMPP publish-subscribe as specified in XEP-0163.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0107</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>User Activity</title>
|
||||
<abstract>This document defines an XMPP protocol extension for communicating information about user activities.</abstract>
|
||||
<abstract>This specification defines a payload format for communicating information about user activities, such as whether a person is currently working, travelling, or relaxing. The payload format is typically transported using the personal eventing profile of XMPP publish-subscribe as specified in XEP-0163.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0108</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Entity Capabilities</title>
|
||||
<abstract>This document defines an XMPP protocol extension for broadcasting and dynamically discovering client, device, or generic entity capabilities in a way that minimizes network impact.</abstract>
|
||||
<abstract>This document defines an XMPP protocol extension for broadcasting and dynamically discovering client, device, or generic entity capabilities. In order to minimize network impact, the transport mechanism is standard XMPP presence broadcast (thus forestalling the need for polling related to service discovery data), the capabilities information can be cached either within a session or across sessions. and the format has been kept as small as possible.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0115</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>User Tune</title>
|
||||
<abstract>This document defines an XMPP protocol extension for communicating information about the music to which a user is listening.</abstract>
|
||||
<abstract>This specification defines a payload format for communicating information about music to which a user is listening, including the title, track number, collection, performer, composer, and length. The payload format is typically transported using the personal eventing profile of XMPP publish-subscribe as specified in XEP-0163.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0118</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Data Forms Validation</title>
|
||||
<abstract>This document defines an extension to the Data Forms protocol that enables applications to specify additional validation guidelines.</abstract>
|
||||
<abstract>This specification defines a backwards-compatible extension to the XMPP Data Forms protocol that enables applications to specify additional validation guidelines related to a form, such as validation of standard XML datatypes, application-specific datatypes, value ranges, and regular expressions.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0122</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Bidirectional-streams Over Synchronous HTTP (BOSH)</title>
|
||||
<abstract>This document defines a transport protocol (formerly known as HTTP Binding) that emulates bidirectional connections efficiently using multiple synchronous HTTP request/response pairs (i.e. without polling or asynchronous chunking).</abstract>
|
||||
<abstract>This specification defines a transport protocol that emulates a bidirectional stream between two entities (such as a client and a server) by efficiently using multiple synchronous HTTP request/response pairs without requiring the use of polling or asynchronous chunking.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0124</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Stanza Headers and Internet Metadata</title>
|
||||
<abstract>This document defines an XMPP protocol extension for specifying headers about XMPP stanza content, including an XML representation of many kinds of standard Internet metadata.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension for representing non-address-related headers in an XML format that is appropriate for use in XMPP. While the protocol provides a flexible mechanism for representing many kinds of standard Internet metadata, a registry of values is defined to structure the possible range of headers, and the inital registration includes headers from email, HTTP, MIME, and SIP.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0131</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Publishing Stream Initiation Requests</title>
|
||||
<abstract>This documents defines an XMPP protocol extension for publishing the availability of a particular Stream Initiation request, such as a file.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension that enables an XMPP entity to advertise the fact that it is willing accept a particular Stream Initiation request. The protocol is used mainly to inform other entities that a particular file is available for transfer via the File Transfer protocol defined in XEP-0096.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0137</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Stream Compression</title>
|
||||
<abstract>This document defines an XMPP protocol extension for negotiating compression of XML streams.</abstract>
|
||||
<abstract>This document defines an XMPP protocol extension for negotiating compression of XML streams, especially in situations where standard TLS compression cannot be negotiated. The protocol provides a modular framework that can accommodate a wide range of compression algorithms; the ZLIB compression algorithm is mandatory-to-implement, but implementations may support other algorithms in addition.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0138</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Data Forms Layout</title>
|
||||
<abstract>This document defines an extension to the Data Forms protocol enabling an application to specify form layouts.</abstract>
|
||||
<abstract>This specification defines a backwards-compatible extension to the XMPP Data Forms protocol that enables an application to specify form layouts, including the layout of form fields, sections within pages, and subsections within sections.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0141</number>
|
||||
<status>Draft</status>
|
||||
@ -55,9 +55,9 @@
|
||||
<section1 topic='Requirements' anchor='reqs'>
|
||||
<p>The requirements for this document are:</p>
|
||||
<ul>
|
||||
<li>Provide hints for laying out form fields in pages.</li>
|
||||
<li>Provide hints for laying out pages in sections.</li>
|
||||
<li>Provide hints for laying out sections in subsections.</li>
|
||||
<li>Provide hints for the layout of form fields.</li>
|
||||
<li>Provide hints for the layout of sections within pages.</li>
|
||||
<li>Provide hints for the layout of subsections within sections.</li>
|
||||
<li>Ensure backwards-compatibility with the existing "x:data" protocol.</li>
|
||||
</ul>
|
||||
</section1>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Roster Item Exchange</title>
|
||||
<abstract>This document defines an XMPP protocol extension for exchanging roster items, including the ability to suggest whether the item is to be added, deleted, or modified.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension for exchanging contact list items, including the ability to suggest whether the item is to be added, deleted, or modified in the contact list of the recipient, as well as the suggested roster group for the item.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0144</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Stanza Session Negotiation</title>
|
||||
<abstract>This document specifies a feature negotiation profile for initiating an exchange of XML stanzas between two entities.</abstract>
|
||||
<abstract>This specification defines a method for formally negotiating the exchange of XML stanzas between two XMPP entities. The method uses feature negotiation forms sent via XMPP message stanzas to enable session initiation between entities that do not share presence information or have knowledge of full JabberIDs and therefore is also suitable for use across gateways to SIP-based systems. A wide range of session parameters can be negotiated, including the use of end-to-end encryption, chat state notifications, XHTML-IM formatting, and message archiving.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0155</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Personal Eventing via Pubsub</title>
|
||||
<abstract>This document specifies XMPP semantics for using the publish-subscribe protocol to broadcast state change events associated with an instant messaging and presence account.</abstract>
|
||||
<abstract>This specification defines semantics for using the XMPP publish-subscribe protocol to broadcast state change events associated with an instant messaging and presence account. This profile of pubsub therefore enables a standard XMPP user account to function as a virtual pubsub service, easing the discovery of syndicated data and event notifications associated with such an account.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0163</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Jingle</title>
|
||||
<abstract>This document defines a framework for initiating and managing peer-to-peer multimedia sessions (e.g., voice and video chat) between two Jabber/XMPP endpoints in a way that is interoperable with existing Internet standards.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension for initiating and managing peer-to-peer media sessions between two XMPP entities in a way that is interoperable with existing Internet standards. The protocol provides a pluggable model that enables the core session management semantics to be used for a wide variety of application types (e.g., voice chat, video chat, file sharing) and with a wide variety of transport methods (e.g., TCP, UDP, ICE, application-specific transports).</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0166</number>
|
||||
<status>Proposed</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Jingle Audio via RTP</title>
|
||||
<abstract>This document defines methods for negotiating Jingle audio sessions that use the Real-time Transport Protocol (RTP) for media exchange.</abstract>
|
||||
<abstract>This specification defines a Jingle application type for negotiating a voice chat or other audio session. The application type uses the Real-time Transport Protocol (RTP) for the underlying media exchange and provides a straightforward mapping to Session Description Protocol (SDP) for interworking with SIP media endpoints.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0167</number>
|
||||
<status>Proposed</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Link-Local Messaging</title>
|
||||
<abstract>This document describes how to establish XMPP-like communications over local networks using zero-configuration networking.</abstract>
|
||||
<abstract>This specification defines how to establish XMPP-like communications over local networks based on zero-configuration networking. This method uses DNS-based Service Discovery and Multicast DNS to discover entities that support the protocol, including their IP addresses and preferred ports. Any two entities can then negotiate a serverless connection using standard XML streams in order to exchange XMPP message and IQ stanzas.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0174</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Jingle ICE-UDP Transport Method</title>
|
||||
<abstract>This document defines a Jingle transport method that results in sending data between two XMPP entities via the User Datagram Protocol (UDP) as negotiated using the Interactive Connectivity Establishment (ICE) methodology.</abstract>
|
||||
<abstract>This specification defines a Jingle transport method that results in sending media data using raw datagram sockets via the User Datagram Protocol (UDP). This transport method is negotiated via the Interactive Connectivity Establishment (ICE) methodology defined by the IETF and thus provides robust NAT traversal for media traffic.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0176</number>
|
||||
<status>Proposed</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Jingle Raw UDP Transport Method</title>
|
||||
<abstract>This document defines a Jingle transport method that results in sending data over a raw User Datagram Protocol (UDP) connection.</abstract>
|
||||
<abstract>This specification defines a Jingle transport method that results in sending media data using raw datagram sockets via the User Datagram Protocol (UDP). This simple transport method does not provide NAT traversal, and the ICE-UDP transport method should be used if NAT traversal is required.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0177</number>
|
||||
<status>Proposed</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Jingle Video via RTP</title>
|
||||
<abstract>This document defines methods for negotiating Jingle video sessions that use the Real-time Transport Protocol (RTP) for media exchange.</abstract>
|
||||
<abstract>This specification defines a Jingle application type for negotiating a video chat or other video session. The application type uses the Real-time Transport Protocol (RTP) for the underlying media exchange and provides a straightforward mapping to Session Description Protocol (SDP) for interworking with SIP media endpoints.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0180</number>
|
||||
<status>Proposed</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Jingle DTMF</title>
|
||||
<abstract>This document specifies an XML format for encapsulating DTMF data in informational messages sent within the context of Jingle audio interactions.</abstract>
|
||||
<abstract>This specification defines an XML format for encapsulating Dual Tone Multi-Frequency (DTMF) data in informational messages sent within the context of Jingle audio sessions, e.g. to be used in the context of Interactive Voice Response (IVR) systems.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0181</number>
|
||||
<status>Proposed</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Message Receipts</title>
|
||||
<abstract>This document specifies an XMPP protocol extension for message receipts.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension for message receipts, whereby the sender of a message can request notification that it has been received by the intended recipient.</abstrace>
|
||||
&LEGALNOTICE;
|
||||
<number>0184</number>
|
||||
<status>Draft</status>
|
||||
|
||||
14
xep-0191.xml
14
xep-0191.xml
@ -281,6 +281,13 @@
|
||||
xmlns='urn:xmpp:blocking'
|
||||
elementFormDefault='qualified'>
|
||||
|
||||
<xs:annotation>
|
||||
<xs:documentation>
|
||||
The protocol documented by this schema is defined in
|
||||
XEP-0191: http://www.xmpp.org/extensions/xep-0191.html
|
||||
</xs:documentation>
|
||||
</xs:annotation>
|
||||
|
||||
<xs:element name='block'>
|
||||
<xs:complexType>
|
||||
<xs:sequence>
|
||||
@ -336,6 +343,13 @@
|
||||
xmlns='urn:xmpp:blocking:errors'
|
||||
elementFormDefault='qualified'>
|
||||
|
||||
<xs:annotation>
|
||||
<xs:documentation>
|
||||
The protocol documented by this schema is defined in
|
||||
XEP-0191: http://www.xmpp.org/extensions/xep-0191.html
|
||||
</xs:documentation>
|
||||
</xs:annotation>
|
||||
|
||||
<xs:element name='blocked' type='empty'/>
|
||||
|
||||
<xs:simpleType name='empty'>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>XMPP Ping</title>
|
||||
<abstract>This document defines an XMPP protocol extension for sending pings over XML streams.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension for sending application-level pings over XML streams. Such pings can be sent from a client to a server, from one server to another, or end-to-end.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0199</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Entity Time</title>
|
||||
<abstract>This document defines an XMPP protocol extension for communicating the local time of an entity.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension for communicating the local time of an entity, including the time in UTC according to the entity as well as the offset from UTC. The time format itself conforms to the dateTime profile of ISO 8601 defined in XEP-0082.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0202</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Delayed Delivery</title>
|
||||
<abstract>This document defines an XMPP protocol extension for communicating the fact that an XML stanza has been delivered with a delay.</abstract>
|
||||
<abstract>This specification defines an XMPP protocol extension for communicating the fact that an XML stanza has been delivered with a delay, for example because a message has been stored on a server while the intended recipient was offline or because a message is contained in the history of a multi-user chat room.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0203</number>
|
||||
<status>Draft</status>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>XMPP Over BOSH</title>
|
||||
<abstract>This document defines how the BOSH protocol (Bidirectional-streams Over Synchronous HTTP) may be used to transport XMPP stanzas.</abstract>
|
||||
<abstract>This specification defines how the Bidirectional-streams Over Synchronous HTTP (BOSH) technology may be used to transport XMPP stanzas. The result is an HTTP binding for XMPP communications that is useful in situations where a device or client is unable to maintain a long-lived TCP connection to an XMPP server.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0206</number>
|
||||
<status>Draft</status>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user