moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

JEP to XEP

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@35 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-10-04 02:05:02 +00:00
parent fe1d5643e8
commit a3136dfe3a
10 changed files with 211 additions and 211 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
xep-0070.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Verifying HTTP Requests via XMPP</title>
<abstract>This document defines a protocol that enables verification of an HTTP request via XMPP.</abstract>
@ -17,13 +17,13 @@
<spec>XMPP Core</spec>
<spec>RFC 2616</spec>
<spec>RFC 2617</spec>
<spec>JEP-0030</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>http-auth</shortname>
<schemaloc>
<url>http://jabber.org/protocol/http-auth/http-auth.xsd</url>
<url>http://www.xmpp.org/schemas/http-auth.xsd</url>
</schemaloc>
&linuxwolf;
&hildjj;
@ -87,7 +87,7 @@
<version>0.2</version>
<date>2003-06-26</date>
<initials>lw</initials>
<remark>Updated to reflect feedback received (moved to using standard HTTP authentication headers; included token-authority JID in HTTP header; removed example involving deprecated JEP).</remark>
<remark>Updated to reflect feedback received (moved to using standard HTTP authentication headers; included token-authority JID in HTTP header; removed example involving deprecated protocol).</remark>
</revision>
<revision>
<version>0.1</version>
@ -181,7 +181,7 @@ WWW-Authenticate: Digest realm="xmpp",
<p>The HTTP Client responds with an Authorization Request as defined in <cite>RFC 2616</cite>. The following rules apply:</p>
<ol>
<li>The request MUST include the Jabber Identifier (JID) of the user making the request. This SHOULD be the full JID (&lt;user@host/resource&gt;) of a client that supports the protocol defined herein, although it MAY be the user's bare JID (&lt;user@host&gt;) instead.</li>
<li>The request MUST include a transaction identifier for the request. This identifier MUST be unique within the context of the HTTP Client's interaction with the HTTP Server. If the HTTP request is generated by the XMPP Client (e.g., because the HTTP URL was discovered via &jep0066;) then the transaction identifier SHOULD be generated by the client; if not, the transaction identifier SHOULD be provided by the human user who controls the HTTP Client.</li>
<li>The request MUST include a transaction identifier for the request. This identifier MUST be unique within the context of the HTTP Client's interaction with the HTTP Server. If the HTTP request is generated by the XMPP Client (e.g., because the HTTP URL was discovered via &xep0066;) then the transaction identifier SHOULD be generated by the client; if not, the transaction identifier SHOULD be provided by the human user who controls the HTTP Client.</li>
</ol>
<p>The Authorization Request process is described in the following subsections.</p>
<section3 topic='Basic Access Authentication Scheme' anchor='http-authz-basic'>
@ -329,7 +329,7 @@ Content-Length: 3032
<ol>
<li>The channel used for HTTP requests and responses SHOULD be encrypted via SSL (secure HTTP via https: URLs) or TLS (&rfc2817;).</li>
<li>If the standard binding of XMPP to TCP is used, TLS SHOULD be negotiated for the XMPP channel in accordance with <cite>RFC 3920</cite>.</li>
<li>If a binding of XMPP to HTTP is used (e.g., as specified in <cite>JEP-0124</cite>), exchanges between the XMPP Client and XMPP Server (connection manager) SHOULD be sent over a channel that is encrypted using SSL or TLS.</li>
<li>If a binding of XMPP to HTTP is used (e.g., as specified in <cite>XEP-0124</cite>), exchanges between the XMPP Client and XMPP Server (connection manager) SHOULD be sent over a channel that is encrypted using SSL or TLS.</li>
</ol>
</section2>
<section2 topic='End-to-End Encryption' anchor='security-e2e'>
@ -339,7 +339,7 @@ Content-Length: 3032
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; includes "http://jabber.org/protocol/http-auth" in its registry of protocol namespaces.</p>
</section2>
@ -357,7 +357,7 @@ Content-Length: 3032
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0070: http://www.jabber.org/jeps/jep-0070.html
XEP-0070: http://www.xmpp.org/extensions/xep-0070.html
</xs:documentation>
</xs:annotation>
@ -382,4 +382,4 @@ Content-Length: 3032
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

62
xep-0071.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>XHTML-IM</title>
<abstract>This JEP defines an XHTML 1.0 Integration Set for use in exchanging instant messages that contain lightweight text markup.</abstract>
<abstract>This document defines an XHTML 1.0 Integration Set for use in exchanging instant messages that contain lightweight text markup.</abstract>
&LEGALNOTICE;
<number>0071</number>
<status>Draft</status>
@ -18,22 +18,22 @@
<spec>XMPP IM</spec>
<spec>XHTML 1.0</spec>
<spec>Modularization of XHTML</spec>
<spec>JEP-0030</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>xhtml-im</shortname>
<schemaloc>
<ns>wrapper namespace</ns>
<url>http://jabber.org/protocol/xhtml-im/xhtml-im-wrapper.xsd</url>
<url>http://www.xmpp.org/schemas/xhtml-im/xhtml-im-wrapper.xsd</url>
</schemaloc>
<schemaloc>
<ns>schema driver</ns>
<url>http://jabber.org/protocol/xhtml-im/xhtml-im-driver.xsd</url>
<url>http://www.xmpp.org/schemas/xhtml-im/xhtml-im-driver.xsd</url>
</schemaloc>
<schemaloc>
<ns>content model</ns>
<url>http://jabber.org/protocol/xhtml-im/xhtml-im-model.xsd</url>
<url>http://www.xmpp.org/schemas/xhtml-im/xhtml-im-model.xsd</url>
</schemaloc>
&stpeter;
<revision>
@ -164,11 +164,11 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>This JEP defines methods for exchanging instant messages that contain lightweight text markup. In the context of this JEP, "lightweight text markup" is to be understood as a combination of minimal structural elements and presentational styles that can easily be rendered on a wide variety of devices without requiring a full rich-text rendering engine such as a web browser. Examples of lightweight text markup include basic text blocks (e.g., paragraphs), lists, hyperlinks, image references, and font styles (e.g., sizes and colors).</p>
<p>This document defines methods for exchanging instant messages that contain lightweight text markup. In the context of this document, "lightweight text markup" is to be understood as a combination of minimal structural elements and presentational styles that can easily be rendered on a wide variety of devices without requiring a full rich-text rendering engine such as a web browser. Examples of lightweight text markup include basic text blocks (e.g., paragraphs), lists, hyperlinks, image references, and font styles (e.g., sizes and colors).</p>
</section1>
<section1 topic='Choice of Technology' anchor='tech'>
<p>In the past, there have existed several incompatible methods within the Jabber community for exchanging instant messages that contain lightweight text markup. The most notable such methods have included derivatives of &w3xhtml; as well as of &rtf;.</p>
<p>Although it is sometimes easier for client developers to implement RTF support (this is especially true on certain Microsoft Windows operating systems), there are several reasons (consistent with the &jep0134;) for the &JSF; to avoid the use of RTF in developing a protocol for lightweight text markup. Specifically:</p>
<p>Although it is sometimes easier for client developers to implement RTF support (this is especially true on certain Microsoft Windows operating systems), there are several reasons (consistent with the &xep0134;) for the &JSF; to avoid the use of RTF in developing a protocol for lightweight text markup. Specifically:</p>
<ol type='1' start='1'>
<li>RTF is not a structured vocabulary derived from SGML (as is &w3html;) or, more relevantly, from XML (as is XHTML 1.0).</li>
<li>RTF is under the control of the Microsoft Corporation and thus is not an open standard maintained by a recognized standards development organization; therefore the JSF is unable to contribute to or influence its development if necessary, and any protocol the JSF developed using RTF would introduce unwanted dependencies.</li>
@ -178,7 +178,7 @@
<li>XHTML is a structured format that is defined as an application of &w3xml;, making it especially appropriate for sending over Jabber/XMPP, which is at root a technology for streaming XML (see &xmppcore;).</li>
<li>XHTML is an open standard developed by the &W3C;, a recognized standards development organization.</li>
</ol>
<p>Therefore, this JEP defines support for lightweight text markup in the form of an XMPP extension that encapsulates content defined by an XHTML 1.0 Integration Set that we label "XHTML-IM". The remainder of this JEP discusses lightweight text markup in terms of XHTML 1.0 only and does not further consider RTF or other technologies.</p>
<p>Therefore, this document defines support for lightweight text markup in the form of an XMPP extension that encapsulates content defined by an XHTML 1.0 Integration Set that we label "XHTML-IM". The remainder of this document discusses lightweight text markup in terms of XHTML 1.0 only and does not further consider RTF or other technologies.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>HTML was originally designed for authoring and presenting stuctured documents on the World Wide Web, and was subsequently extended to handle more advanced functionality such as image maps and interactive forms. However, the requirements for publishing documents (or developing transactional websites) for presentation by dedicated XHTML clients on traditional computers or small-screen devices are fundamentally different from the requirements for lightweight text markup of instant messages; for this reason, only a reduced set of XHTML features is needed for XHTML-IM. In particular:</p>
@ -186,9 +186,9 @@
<li><p>IM clients are not XHTML clients: their primary purpose is not to read pre-existing XHTML documents, but to read <em>and generate</em> relatively large numbers of fairly small instant messages.</p></li>
<li><p>The underlying context for XHTML content in Jabber/XMPP instant messaging is provided not by a full XHTML document, but by an XML stream, and specifically by a message stanza within that stream. Thus the &lt;head/&gt; element and all its children are unnecessary. Only the &lt;body/&gt; element and some of its children are appropriate for use in instant messaging.</p></li>
<li><p>The XHTML content that is read by one's IM client is normally generated on the fly by one's conversation partner (or, to be precise, by his or her IM client). Thus there is an inherent limit to the sophistication of the XHTML markup involved. Even in normal XHTML documents, fairly basic structural and rendering elements such as definition lists, abbreviations, addresses, and computer input handling (e.g., &lt;kbd/&gt; and &lt;var/&gt;) are relatively rare. There is little or no foreseeable need for such elements within the context of instant messaging.</p></li>
<li><p>The foregoing is doubly true of more advanced markup such as tables, frames, and forms (however, there exists an XMPP extension that provides an instant messaging equivalent of the latter, as defined in &jep0004;).</p></li>
<li><p>The foregoing is doubly true of more advanced markup such as tables, frames, and forms (however, there exists an XMPP extension that provides an instant messaging equivalent of the latter, as defined in &xep0004;).</p></li>
<li><p>Although ad-hoc styles are useful for messaging (by means of the 'style' attribute), full support for &w3css; (defined by the &lt;style/&gt; element or a standalone .css file, and implemented via the 'class' attribute) would be overkill since many CSS1 properties (e.g., box, classification, and text properties) were developed especially for sophisticated page layout.</p></li>
<li><p>Background images, audio, animated text, layers, applets, scripts, and other multimedia content types are unnecessary, especially given the existence of XMPP extensions such as &jep0096;.</p></li>
<li><p>Background images, audio, animated text, layers, applets, scripts, and other multimedia content types are unnecessary, especially given the existence of XMPP extensions such as &xep0096;.</p></li>
<li><p>Content transformations such as those defined by &w3xslt; must not be necessary in order for an instant messaging application to present lightweight text markup to an end user.</p></li>
</ol>
<p>As explained below, some of these requirements are addressed by the definition of the XHTML-IM Integration Set itself, while others are addressed by a recommended "profile" for that Integration Set in the context of instant messaging applications.</p>
@ -222,7 +222,7 @@
</section1>
<section1 topic='XHTML-IM Integration Set' anchor='def'>
<p>This section defines an XHTML 1.0 Integration Set for use in the context of instant messaging. Given its intended usage, we label it "XHTML-IM".</p>
<p><cite>Modularization of XHTML</cite> provides the ability to formally define subsets of XHTML 1.0 via the concept of "modularization" (which may be familiar from &w3xhtmlbasic;). Many of the defined modules are not necessary or useful in the context of instant messaging, and in the context of Jabber/XMPP instant messaging specifically some modules have been superseded by well-defined XMPP extensions. This JEP specifies that XHTML-IM shall be based on the following XHTML 1.0 modules:</p>
<p><cite>Modularization of XHTML</cite> provides the ability to formally define subsets of XHTML 1.0 via the concept of "modularization" (which may be familiar from &w3xhtmlbasic;). Many of the defined modules are not necessary or useful in the context of instant messaging, and in the context of Jabber/XMPP instant messaging specifically some modules have been superseded by well-defined XMPP extensions. This document specifies that XHTML-IM shall be based on the following XHTML 1.0 modules:</p>
<ul>
<li>Core Modules
<ul>
@ -355,7 +355,7 @@
<li>text-align</li>
<li>text-decoration</li>
</ul>
<p>Although a compliant implementation MAY generate or process other style properties defined in CSS1, such behavior is NOT RECOMMENDED by this JEP.</p>
<p>Although a compliant implementation MAY generate or process other style properties defined in CSS1, such behavior is NOT RECOMMENDED by this document.</p>
</section3>
</section2>
<section2 topic='Recommended Attributes' anchor='profile-attributes'>
@ -601,7 +601,7 @@
<example caption='Two lists'><![CDATA[
<message>
<body>Here&apos;s my .plan for today:
1. Add the following examples to JEP-0071:
1. Add the following examples to XEP-0071:
- ordered and unordered lists
- more styles (e.g., indentation)
2. Kick back and relax
@ -610,7 +610,7 @@
<body xmlns='http://www.w3.org/1999/xhtml'>
<p>Here&apos;s my .plan for today:</p>
<ol>
<li>Add the following examples to JEP-0071:
<li>Add the following examples to XEP-0071:
<ul>
<li>ordered and unordered lists</li>
<li>more styles (e.g., indentation)</li>
@ -626,7 +626,7 @@
<div class='example'>
<p>Here&apos;s my .plan for today:</p>
<ol type='1' start='1'>
<li>Add the following examples to JEP-0071:
<li>Add the following examples to XEP-0071:
<ul>
<li>ordered and unordered lists</li>
<li>more styles (e.g., indentation)</li>
@ -745,7 +745,7 @@ That seems fine to me.
<section1 topic='Discovering Support for XHTML-IM' anchor='discovery'>
<p>This section describes methods for discovering whether a Jabber client or other XMPP entity supports the protocol defined herein.</p>
<section2 topic='Explicit Discovery' anchor='discovery-explicit'>
<p>The primary means of discovering support for XHTML-IM is &jep0030;.</p>
<p>The primary means of discovering support for XHTML-IM is &xep0030;.</p>
<example caption='Seeking to Discover XHTML-IM Support'><![CDATA[
<iq type='get'
from='juliet@shakespeare.lit/balcony'
@ -824,7 +824,7 @@ That seems fine to me.
</section2>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
@ -857,13 +857,13 @@ That seems fine to me.
XHTML 1.0 Integration Set.
Full documentation of this Integration Set is contained in
"JEP-0071: XHTML-IM", a specification published by the
"XEP-0071: XHTML-IM", a specification published by the
Jabber Software Foundation.
http://www.jabber.org/jeps/jep-0071.html
http://www.xmpp.org/extensions/xep-0071.html
</xs:documentation>
<xs:documentation source="http://www.jabber.org/jeps/jep-0071.html"/>
<xs:documentation source="http://www.xmpp.org/extensions/xep-0071.html"/>
</xs:annotation>
<xs:element name='html'>
@ -915,14 +915,14 @@ That seems fine to me.
-//JSF//DTD Instant Messaging with XHTML//EN
Full documentation of this Integration Set is contained in
"JEP-0071: XHTML-IM", a specification published by the
"XEP-0071: XHTML-IM", a specification published by the
Jabber Software Foundation, which is available at the
following URL:
http://www.jabber.org/jeps/jep-0071.html
http://www.xmpp.org/extensions/xep-0071.html
</xs:documentation>
<xs:documentation source="http://www.jabber.org/jeps/jep-0071.html"/>
<xs:documentation source="http://www.xmpp.org/extensions/xep-0071.html"/>
</xs:annotation>
<xs:include
@ -989,13 +989,13 @@ That seems fine to me.
Common.extra
Full documentation of this Integration Set is contained in
"JEP-0071: XHTML-IM", a specification published by the
"XEP-0071: XHTML-IM", a specification published by the
Jabber Software Foundation.
http://www.jabber.org/jeps/jep-0071.html
http://www.xmpp.org/extensions/xep-0071.html
</xs:documentation>
<xs:documentation source="http://www.jabber.org/jeps/jep-0071.html"/>
<xs:documentation source="http://www.xmpp.org/extensions/xep-0071.html"/>
</xs:annotation>
<!-- BEGIN ATTRIBUTE GROUPS -->
@ -1175,4 +1175,4 @@ That seems fine to me.
<section1 topic='Acknowledgements' anchor='ack'>
<p>This specification formalizes and extends earlier work by Jeremie Miller and Julian Missig on XHTML formatting of Jabber messages. Many thanks to Shane McCarron for his assistance regarding XHTML modularization and conformance issues. Thanks also to contributors on the Standards-JIG list for their feedback and suggestions.</p>
</section1>
</jep>
</xep>

46
xep-0072.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>SOAP Over XMPP</title>
<abstract>This document defines methods for transporting SOAP messages over Jabber/XMPP.</abstract>
@ -16,14 +16,14 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>SOAP 1.2</spec>
<spec>JEP-0030</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>soap</shortname>
<schemaloc>
<ns>soap#fault</ns>
<url>http://jabber.org/protocol/soap/fault.xsd</url>
<url>http://www.xmpp.org/schemas/soap-fault.xsd</url>
</schemaloc>
<author>
<firstname>Fabio</firstname>
@ -48,7 +48,7 @@
<version>0.13</version>
<date>2005-11-01</date>
<initials>psa</initials>
<remark>In accordance with Council feedback: divided Sending Attachments text into multiple subsections and added XMPP examples to each subsection; specified use of JEP-0137 to publish SI requests related to file transfer; specified use of application-specific stanza errors; fixed typographical error in WSDL example.</remark>
<remark>In accordance with Council feedback: divided Sending Attachments text into multiple subsections and added XMPP examples to each subsection; specified use of XEP-0137 to publish SI requests related to file transfer; specified use of application-specific stanza errors; fixed typographical error in WSDL example.</remark>
</revision>
<revision>
<version>0.12</version>
@ -133,13 +133,13 @@
<section1 topic="Architectural Assumptions" anchor='arch'>
<p>The usual architecture of XMPP is described in Section 2 of <cite>RFC 3920</cite>. In essence, XMPP is most commonly deployed using a client-server (or logical peer-to-peer) architecture quite similar to that of the email system, except that XMPP does not have multiple hops between servers, enforces domain names to prevent address spoofing, and enables channel encryption (via TLS) and authentication (via SASL) between client and server as well as among servers.</p>
<p>The binding of SOAP to XMPP assumes that most SOAP-enabled XMPP entities will be implemented as XMPP clients that communicate with other entities as logical peers. However, in order to deploy more scalable services, such entities could also be implemented as server-side components (see &jep0114;) or even as special-purpose XMPP servers.</p>
<p>The SOAP specification defines the concepts of "SOAP intermediary" and "ultimate SOAP receiver" (see Section 1.5.3 of <cite>SOAP Version 1.2 Part 1</cite>). In general, this specification assumes that XMPP entities that support the SOAP XMPP Binding will be ultimate SOAP receivers, since SOAP intermediaries tend to be artifacts of the existing SOAP bindings (HTTP and SMTP) rather than applicable to all possible bindings. SOAP intermediaries are usually deployed in order to (1) cross trust boundaries in protocols that do not enforce domain names or authenticate end-points, (2) ensure scalability, (3) secure messages sent over unencrypted channels, and (4) provide message tracing. However, these issues are addressed natively in XMPP (e.g., channel encryption is defined in <cite>RFC 3920</cite>), in XMPP extensions (e.g., message tracing is defined in &jep0079;), or in deployment decisions such as business level agreements between XMPP domains. One final justification for SOAP intermediaries is to act as gateways between different transport mechanisms (e.g., between HTTP and SMTP), and XMPP entities may well be SOAP intermediaries for that reason. For further details about gateways between XMPP and other SOAP bindings, refer to the <link url='#impl'>Implementation Notes</link> section of this document.</p>
<p>The binding of SOAP to XMPP assumes that most SOAP-enabled XMPP entities will be implemented as XMPP clients that communicate with other entities as logical peers. However, in order to deploy more scalable services, such entities could also be implemented as server-side components (see &xep0114;) or even as special-purpose XMPP servers.</p>
<p>The SOAP specification defines the concepts of "SOAP intermediary" and "ultimate SOAP receiver" (see Section 1.5.3 of <cite>SOAP Version 1.2 Part 1</cite>). In general, this specification assumes that XMPP entities that support the SOAP XMPP Binding will be ultimate SOAP receivers, since SOAP intermediaries tend to be artifacts of the existing SOAP bindings (HTTP and SMTP) rather than applicable to all possible bindings. SOAP intermediaries are usually deployed in order to (1) cross trust boundaries in protocols that do not enforce domain names or authenticate end-points, (2) ensure scalability, (3) secure messages sent over unencrypted channels, and (4) provide message tracing. However, these issues are addressed natively in XMPP (e.g., channel encryption is defined in <cite>RFC 3920</cite>), in XMPP extensions (e.g., message tracing is defined in &xep0079;), or in deployment decisions such as business level agreements between XMPP domains. One final justification for SOAP intermediaries is to act as gateways between different transport mechanisms (e.g., between HTTP and SMTP), and XMPP entities may well be SOAP intermediaries for that reason. For further details about gateways between XMPP and other SOAP bindings, refer to the <link url='#impl'>Implementation Notes</link> section of this document.</p>
</section1>
<section1 topic="Use Cases" anchor='uc'>
<section2 topic="Discovering Support" anchor='disco'>
<p>In order to determine whether a potential responding entity supports the SOAP XMPP Binding, a requesting entity SHOULD send a &jep0030; information request to the potential responding entity:</p>
<p>In order to determine whether a potential responding entity supports the SOAP XMPP Binding, a requesting entity SHOULD send a &xep0030; information request to the potential responding entity:</p>
<example caption="Requester queries responder regarding protocol support"><![CDATA[
<iq from='requester@example.com/soap-client'
to='responder@example.com/soap-server'
@ -169,7 +169,7 @@
</ol>
<p>Examples of both approaches are provided below, encapsulating the SOAP message examples (a travel reservation flow) to be found in &w3soap0;.</p>
<section3 topic="Exchanging SOAP Messages Using XMPP IQ Stanzas" anchor='exchange-iq'>
<p>The transport with &IQ; stanzas is performed in a way similar to that described for XML-RPC in &jep0009;. Request envelopes are carried by &IQ; stanzas of type "set", and answer envelopes by &IQ; stanzas of type "result". SOAP errors are encoded with standard SOAP envelopes, and returned in stanzas of type "error" with appropriate codes in order to distinguish them from errors specific to the XMPP transport layer (see <link url='#errors'>Error Handling</link> for details).</p>
<p>The transport with &IQ; stanzas is performed in a way similar to that described for XML-RPC in &xep0009;. Request envelopes are carried by &IQ; stanzas of type "set", and answer envelopes by &IQ; stanzas of type "result". SOAP errors are encoded with standard SOAP envelopes, and returned in stanzas of type "error" with appropriate codes in order to distinguish them from errors specific to the XMPP transport layer (see <link url='#errors'>Error Handling</link> for details).</p>
<p>Each &IQ; stanza of type "set" MUST contain a SOAP envelope as the first-level child element, since it already represents a properly namespaced XML subtree qualified by the 'http://www.w3.org/2003/05/soap-envelope' namespace.</p>
<example caption="Requesting entity sends IQ-set"><![CDATA[
<iq from='requester@example.com/soap-client'
@ -341,13 +341,13 @@
</tr>
<tr>
<td>File Transfer</td>
<td>Negotiate file transfer using &jep0096; and &jep0137;.</td>
<td>Negotiate file transfer using &xep0096; and &xep0137;.</td>
<td>SHOULD</td>
<td>Recommended approach for file transfer over XMPP (e.g., see &jep0117;).</td>
<td>Recommended approach for file transfer over XMPP (e.g., see &xep0117;).</td>
</tr>
<tr>
<td>Include Link</td>
<td>Represent the binary data as a file, publish it to an accessible file server (e.g., HTTP or FTP URL), and insert a link to the file directly into the XMPP message stanza (via &jep0066;) or into the SOAP envelope (via &w3soaprep;).</td>
<td>Represent the binary data as a file, publish it to an accessible file server (e.g., HTTP or FTP URL), and insert a link to the file directly into the XMPP message stanza (via &xep0066;) or into the SOAP envelope (via &w3soaprep;).</td>
<td>MAY</td>
<td>Fallback if file transfer is not possible (not all clients can publish to file servers).</td>
</tr>
@ -366,8 +366,8 @@
</table>
<p>The recommended approaches (file transfer and including a link) are described more fully below.</p>
<section3 topic="File Transfer" anchor='data-ft'>
<p>The recommended method for sending associated data is to use the file transfer protocol described in <cite>JEP-0096</cite>. Because this is the common and standardized method for XMPP entities to transfer large or binary files outside the XMPP band, it SHOULD be used.</p>
<p>In particular, the entity that has the file SHOULD advertise the availability of the associated stream using <cite>JEP-0137</cite> by including the SI-pub data extension along with the XMPP &MESSAGE; stanza with which the data is associated: <note>In accordance with <cite>RFC 3920</cite>, an &IQ; stanza MUST NOT include multiple payload child elements; therefore, a &MESSAGE; stanza must be used when sending associated data.</note></p>
<p>The recommended method for sending associated data is to use the file transfer protocol described in <cite>XEP-0096</cite>. Because this is the common and standardized method for XMPP entities to transfer large or binary files outside the XMPP band, it SHOULD be used.</p>
<p>In particular, the entity that has the file SHOULD advertise the availability of the associated stream using <cite>XEP-0137</cite> by including the SI-pub data extension along with the XMPP &MESSAGE; stanza with which the data is associated: <note>In accordance with <cite>RFC 3920</cite>, an &IQ; stanza MUST NOT include multiple payload child elements; therefore, a &MESSAGE; stanza must be used when sending associated data.</note></p>
<example caption="Sender sends message with SI-pub"><![CDATA[
<message from='requester@example.com/soap-client'
id='soap2'
@ -446,7 +446,7 @@
</si>
</iq>
]]></example>
<p>For details regarding file transfer and advertising of file transfer stream initiation requests, refer to <cite>JEP-0096</cite> and <cite>JEP-0137</cite>.</p>
<p>For details regarding file transfer and advertising of file transfer stream initiation requests, refer to <cite>XEP-0096</cite> and <cite>XEP-0137</cite>.</p>
</section3>
<section3 topic="Including Links" anchor='data-link'>
<p>If the file transfer method is not possible (e.g., because file transfer is not implemented or transfer attempts fails), the entity that is sending the associated data MAY as a fallback publish the associated data as a file (e.g., at an HTTP or FTP URL) and include a link to the file as out-of-band content by including the out-of-band data extension along with the XMPP &MESSAGE; stanza with which the data is associated: <note>As above, in accordance with <cite>RFC 3920</cite>, an &IQ; stanza MUST NOT include multiple payload child elements; therefore, a &MESSAGE; stanza must be used when sending associated data.</note></p>
@ -619,7 +619,7 @@
</definitions>
]]></example>
<p>Although there is no standard procedure for publishing WSDL documents, usually they are made available through HTTP at some URL discoverable with public registries such as UDDI servers. WSDL descriptions for XMPP bindings MAY follow the same publishing process, or MAY be discoverable through Jabber/XMPP specific mechanisms such as &jep0030; or &jep0060;.</p>
<p>Although there is no standard procedure for publishing WSDL documents, usually they are made available through HTTP at some URL discoverable with public registries such as UDDI servers. WSDL descriptions for XMPP bindings MAY follow the same publishing process, or MAY be discoverable through Jabber/XMPP specific mechanisms such as &xep0030; or &xep0060;.</p>
</section2>
</section1>
@ -1036,7 +1036,7 @@
<section1 topic="W3C Considerations" anchor='w3c'>
<p>The main body of text that addresses the requirements of the W3C with regard to SOAP bindings is provided in the <link url='#binding'>SOAP XMPP Binding</link> section of this document. The current section addresses only the topic of organizational interaction between the W3C and the &JSF; regarding the SOAP XMPP Binding.</p>
<section2 topic='W3C Review' anchor='w3c-review'>
<p>As was done with &jep0071;, the SOAP XMPP Binding defined herein has been reviewed informally by one or more appropriate experts from the W3C before the &COUNCIL; advanced it to a status of Draft within the JSF's standards process. Before this specification proceeds to a status of Final within the JSF's standards process, it should undergo a formal review through communication with the W3C's <link url='http://www.w3.org/2000/xp/Group/'>XML Protocol Working Group</link>. To that end, revised versions of this specification will be announced on the W3C's public xml-dist-app@w3.org mailing list.</p>
<p>As was done with &xep0071;, the SOAP XMPP Binding defined herein has been reviewed informally by one or more appropriate experts from the W3C before the &COUNCIL; advanced it to a status of Draft within the JSF's standards process. Before this specification proceeds to a status of Final within the JSF's standards process, it should undergo a formal review through communication with the W3C's <link url='http://www.w3.org/2000/xp/Group/'>XML Protocol Working Group</link>. To that end, revised versions of this specification will be announced on the W3C's public xml-dist-app@w3.org mailing list.</p>
</section2>
<section2 topic='SOAP Versioning' anchor='w3c-soapversions'>
<p>This specification addresses SOAP 1.2 only. This specification may be superseded or supplemented in the future by a Jabber Enhancement Proposal that defines methods for encapsulating content defined by future versions of SOAP as published by the W3C.</p>
@ -1047,7 +1047,7 @@
</section1>
<section1 topic="Error Handling" anchor='errors'>
<p>SOAP provides its own encoding scheme for errors due to message processing or application execution, and it uses SOAP envelopes for reporting. In the SOAP HTTP Binding, these errors are mapped to corresponding HTTP status codes. In the SOAP XMPP Binding, they are mapped to the catch-all XMPP error of &undefined; along with application-specific error condition elements qualified by the 'http://jabber.org/protocol/soap#fault' namespace (this is consistent with Section 9.3.3 of <cite>RFC 3920</cite>, see also &jep0086;). The element names of these application-specific error conditions map directly to the SOAP fault codes specified in Section 5.4.6 of <cite>SOAP Version 1.2 Part 1</cite>.</p>
<p>SOAP provides its own encoding scheme for errors due to message processing or application execution, and it uses SOAP envelopes for reporting. In the SOAP HTTP Binding, these errors are mapped to corresponding HTTP status codes. In the SOAP XMPP Binding, they are mapped to the catch-all XMPP error of &undefined; along with application-specific error condition elements qualified by the 'http://jabber.org/protocol/soap#fault' namespace (this is consistent with Section 9.3.3 of <cite>RFC 3920</cite>, see also &xep0086;). The element names of these application-specific error conditions map directly to the SOAP fault codes specified in Section 5.4.6 of <cite>SOAP Version 1.2 Part 1</cite>.</p>
<p>The following table provides a mapping between SOAP, HTTP, and application-specific XMPP errors.</p>
<table caption="Mapping of SOAP Faults to HTTP Status Codes and XMPP Error Conditions">
<tr>
@ -1113,7 +1113,7 @@
<type>
<name>soap</name>
<desc>A SOAP receiver (either intermediate or ultimate).</desc>
<doc>JEP-0072</doc>
<doc>XEP-0072</doc>
</type>
</category>
]]></code>
@ -1137,7 +1137,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0072: http://www.jabber.org/jeps/jep-0072.html
XEP-0072: http://www.xmpp.org/extensions/xep-0072.html
</xs:documentation>
</xs:annotation>
@ -1201,4 +1201,4 @@
<p>Some text in the <link url='#binding'>SOAP XMPP Binding</link> section of this document is closely modelled on Section 7 of <cite>SOAP Version 1.2 Part 2</cite> and on <cite>SOAP Version 1.2 Email Binding</cite>.</p>
</section1>
</jep>
</xep>

50
xep-0073.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Basic IM Protocol Suite</title>
<abstract>This JEP defines a recommended suite of Jabber/XMPP protocols to be supported by basic instant messaging and presence applications.</abstract>
<abstract>This document defines a recommended suite of Jabber/XMPP protocols to be supported by basic instant messaging and presence applications.</abstract>
&LEGALNOTICE;
<number>0073</number>
<status>Draft</status>
@ -16,10 +16,10 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0030</spec>
<spec>JEP-0077</spec>
<spec>JEP-0078</spec>
<spec>JEP-0086</spec>
<spec>XEP-0030</spec>
<spec>XEP-0077</spec>
<spec>XEP-0078</spec>
<spec>XEP-0086</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -94,8 +94,8 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Given the large number of Jabber/XMPP protocols,
<note>The protocols developed by the Jabber community have matured considerably since 1999. The core protocols were originally created by a small group of developers who worked on early Jabber-related open-source software projects such as the &jabberd; server, the Winjab, Gabber, and Jarl clients, the Net::Jabber and Jabberbeans libraries, and gateways to consumer IM services. In the summer of 2001, the &JSF; was founded to institute a formal standards process within the growing Jabber community (codified in &jep0001;). In late 2002, the &IETF; formed the &XMPPWG;, which formalized the core Jabber protocols under the name Extensible Messaging and Presence Protocol (XMPP). In early 2004, the IETF approved the main XMPP specifications as Proposed Standards within the Internet Standards Process defined by &rfc2026;, resulting in publication of <cite>RFC 3920</cite> (&xmppcore;) and <cite>RFC 3921</cite> (&xmppim;). In the meantime, the JSF has continued to develop additional protocols on top of XMPP in order to address functionality areas (such as file transfer) that were too application-specific for consideration within the IETF.</note>
it is not always clear to developers exactly which protocols they need to implement in order to interoperate over Jabber/XMPP networks. This JEP attempts to assist developers by defining a protocol suite for basic instant messaging and presence.</p>
<note>The protocols developed by the Jabber community have matured considerably since 1999. The core protocols were originally created by a small group of developers who worked on early Jabber-related open-source software projects such as the &jabberd; server, the Winjab, Gabber, and Jarl clients, the Net::Jabber and Jabberbeans libraries, and gateways to consumer IM services. In the summer of 2001, the &JSF; was founded to institute a formal standards process within the growing Jabber community (codified in &xep0001;). In late 2002, the &IETF; formed the &XMPPWG;, which formalized the core Jabber protocols under the name Extensible Messaging and Presence Protocol (XMPP). In early 2004, the IETF approved the main XMPP specifications as Proposed Standards within the Internet Standards Process defined by &rfc2026;, resulting in publication of <cite>RFC 3920</cite> (&xmppcore;) and <cite>RFC 3921</cite> (&xmppim;). In the meantime, the JSF has continued to develop additional protocols on top of XMPP in order to address functionality areas (such as file transfer) that were too application-specific for consideration within the IETF.</note>
it is not always clear to developers exactly which protocols they need to implement in order to interoperate over Jabber/XMPP networks. This document attempts to assist developers by defining a protocol suite for basic instant messaging and presence.</p>
</section1>
<section1 topic='Requirements and Approach' anchor='reqs'>
<p>Defining a protocol suite provides a high-level "bucket" into which we can place specific functionality areas for development and compliance testing. A baseline is provided by RFCs 3920 and 3921, which define XML streams, JID processing, channel encryption, authentication, the three primary XML stanza types (&MESSAGE;, &PRESENCE;, and &IQ;), namespace handling, presence subscriptions, roster management, and privacy lists (whitelisting/blacklisting). However, basic Jabber instant messaging and presence applications should support several additional protocols that were not included in the XMPP specifications for either of the following reasons:</p>
@ -103,19 +103,19 @@
<li>They were not required to meet the requirements of &rfc2779; (e.g, service discovery)</li>
<li>They were and remain in common use within the Jabber community but did not meet the more stringent requirements of the IETF (e.g., old-style, non-SASL authentication)</li>
</ul>
<p>The Basic IM Protocol Suite does not include more advanced IM functionality, such as groupchat or HTML message formatting; see &jep0117; for such features.</p>
<p>The Basic IM Protocol Suite does not include more advanced IM functionality, such as groupchat or HTML message formatting; see &xep0117; for such features.</p>
</section1>
<section1 topic='Definition' anchor='def'>
<p>The software developed in the Jabber community is built on the foundation of XML streams, a consistent addressing scheme (JIDs), channel encryption, authentication of an entity (client or server) with a server, three core data elements (&MESSAGE;, &PRESENCE;, and &IQ;), and proper handling of XML namespaces. These foundational building blocks have been formalized within RFC 3920, support for which is REQUIRED by this protocol suite. However, XMPP Core is not fully congruent with the core of what has traditionally been known as "Jabber", and this divergence needs to be captured in the Basic IM Protocol Suite. In particular, the following are REQUIRED herein in order to ensure compatibility with the large deployed base of older Jabber software:
<note>Older software also used port 5223 for SSL-enabled communications between a client and a server, rather than upgrading port 5222 as is done during TLS negotiation (the equivalent for server-to-server communications was never implemented); while support for this behavior is OPTIONAL, it may be quite desirable in order to interoperate with older software and deployments.</note>
</p>
<ul>
<li>Support for &jep0078; as a fallback method for authentication.</li>
<li>Support for the error 'code' attribute specified in &jep0086;.</li>
<li>Support for &xep0078; as a fallback method for authentication.</li>
<li>Support for the error 'code' attribute specified in &xep0086;.</li>
</ul>
<p>RFC 3920 does not define everything that is normally expected of even a minimal instant messaging and presence application (in effect, it defines the transport layer rather than the IM and presence application layer). Much of this IM and presence functionality is defined in RFC 3921 in order to meet the requirements of RFC 2779. In particular, RFC 3921 defines roster management, presence subscriptions, privacy lists (whitelisting/blacklisting), and routing and delivery guidelines for clients and servers.</p>
<p>However, Jabber instant messaging and presence applications have traditionally also included the ability to discover information about other entities on the network, and to reply to queries for information. This behavior is extremely helpful because it ensures that entities on the network can determine each other's capabilities and thus understand how to communicate together. (The original such protocol was &jep0094;, but that protocol has been superseded by &jep0030;.) Support for Service Discovery is therefore REQUIRED by this protocol suite, as well.</p>
<p>Traditionally, Jabber servers (and some services) have also offered the ability for clients to register accounts "in-band" (i.e., over Jabber/XMPP) in order to bootstrap participation on the network; this protocol is defined in &jep0077; and support for it is REQUIRED for servers but RECOMMENDED for clients (however, any given server deployment MAY disable in-band registration as a matter of service provisioning).</p>
<p>However, Jabber instant messaging and presence applications have traditionally also included the ability to discover information about other entities on the network, and to reply to queries for information. This behavior is extremely helpful because it ensures that entities on the network can determine each other's capabilities and thus understand how to communicate together. (The original such protocol was &xep0094;, but that protocol has been superseded by &xep0030;.) Support for Service Discovery is therefore REQUIRED by this protocol suite, as well.</p>
<p>Traditionally, Jabber servers (and some services) have also offered the ability for clients to register accounts "in-band" (i.e., over Jabber/XMPP) in order to bootstrap participation on the network; this protocol is defined in &xep0077; and support for it is REQUIRED for servers but RECOMMENDED for clients (however, any given server deployment MAY disable in-band registration as a matter of service provisioning).</p>
<p>Thus we define the Basic IM Protocol Suite as follows:</p>
<table caption='Required and Recommended Specifications'>
<tr>
@ -131,30 +131,30 @@
<td>REQUIRED</td>
</tr>
<tr>
<td><strong>JEP-0078: Non-SASL Authentication</strong></td>
<td><strong>XEP-0078: Non-SASL Authentication</strong></td>
<td>REQUIRED</td>
</tr>
<tr>
<td><strong>JEP-0086: Error Condition Mappings</strong></td>
<td><strong>XEP-0086: Error Condition Mappings</strong></td>
<td>REQUIRED for servers; RECOMMENDED for clients</td>
</tr>
<tr>
<td><strong>JEP-0030: Service Discovery</strong></td>
<td><strong>XEP-0030: Service Discovery</strong></td>
<td>REQUIRED</td>
</tr>
<tr>
<td><strong>JEP-0077: In-Band Registration</strong></td>
<td><strong>XEP-0077: In-Band Registration</strong></td>
<td>REQUIRED for servers; RECOMMENDED for clients</td>
</tr>
</table>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>RFC 3920 requires support for SASL and TLS as must-implement protocols, and that support is not modified herein. Refer to <cite>JEP-0078: Non-SASL Authentication</cite> for an explanation of the older authentication method still in use by various existing client and server implementations and deployments, as well as the proper order of precedence between SASL authentication (RFC 3920) and non-SASL authentication (JEP-0078).</p>
<p>RFC 3920 requires support for SASL and TLS as must-implement protocols, and that support is not modified herein. Refer to <cite>XEP-0078: Non-SASL Authentication</cite> for an explanation of the older authentication method still in use by various existing client and server implementations and deployments, as well as the proper order of precedence between SASL authentication (RFC 3920) and non-SASL authentication (XEP-0078).</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this JEP.</p>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this document.</p>
</section1>
</jep>
</xep>

20
xep-0074.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Simple Access Control</title>
<abstract>A simple protocol for querying information for permissions.</abstract>
@ -13,7 +13,7 @@
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<dependencies>JEP0-0030</dependencies>
<dependencies>XEP-0030</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<shortname>sac</shortname>
@ -73,7 +73,7 @@
<p>The &lt;acl&gt; element provides the container for the query. It MUST have the three attributes: actor, oper, and target.</p>
<p>The actor attribute is set to the Jabber ID which is attempting to perform an operation. This need not be the JID sending the acl, although it may be. Remember this is to allow for the question, "Can X do Y to Z?", which is a question anyone can ask.</p>
<p>The oper attribute is application-specific and refers to the operation for which a permission check is required (e.g., read/write operations). This also defines the scope of the ACL check, so the implementation is responsible for interpreting the actor and target values based on the value of the 'oper' attribute.</p>
<p>The target is the object which the actor is trying to perform the operation on. This MUST be a node queryable via &jep0030;.</p>
<p>The target is the object which the actor is trying to perform the operation on. This MUST be a node queryable via &xep0030;.</p>
<p>Requests MUST be in the form of an empty &lt;acl/&gt; element with ALL the attributes specified. If not all attributes are specified, the request is incomplete and ambiguities arise; therefore the entity receving the request MUST return a "bad request" error to the sender. </p>
<p>Responses MUST be in one of three forms: allowed, denied, error.</p>
<p>The response is inserted into the &lt;acl/&gt; as a child element. If the response is allowed, then &lt;allowed/&gt; is inserted. If the JID is denied then &lt;denied/&gt; is returned. If there is inadequate information then &lt;error/&gt; is used following the standard Jabber error scheme.</p>
@ -152,10 +152,10 @@
<p>To follow.</p>
</section1>
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<p>As a result of this JEP, the &REGISTRAR; will need to register the 'http://jabber.org/protocol/sac' namespace.</p>
<section1 topic='XMPP Registrar Considerations'>
<p>As a result of this document, the &REGISTRAR; will need to register the 'http://jabber.org/protocol/sac' namespace.</p>
</section1>
<section1 topic='Open Issues'>
<ol>
@ -166,4 +166,4 @@
<li>Investigate possible integration with pubsub.</li>
</ol>
</section1>
</jep>
</xep>

24
xep-0075.xml
View File

@ -1,11 +1,11 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd'
[ <!ENTITY % ents SYSTEM "../jep.ent"> %ents;
<!DOCTYPE xep SYSTEM 'xep.dtd'
[ <!ENTITY % ents SYSTEM "xep.ent"> %ents;
<!ENTITY xmlrpc "XML-RPC<note><link url='http://www.xmlrpc.org/spec'>The XML-RPC Specification</link></note>">
]
>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jabber Object Access Protocol (JOAP)</title>
<abstract>The Jabber Object Access Protocol, or JOAP, defines a
@ -37,7 +37,7 @@
descriptions to object servers and classes. Changed the
'writeable' [sic] attribute to the more correct
'writable'. Added experimental namespace recommendation in
Jabber Registrar section.</remark>
XMPP Registrar section.</remark>
</revision>
<revision>
<version>0.2</version>
@ -125,7 +125,7 @@
instances.</li>
<li>Define a language for manipulating data.</li>
<li>Define a language for describing data structures.</li>
<li>Maintain compatibility with &jep0009;.</li>
<li>Maintain compatibility with &xep0009;.</li>
<li>Make classes and instances directly addressable.</li>
<li>Allow human- and programming-language independence.</li>
<li>Allow easy dynamic mapping of JOAP classes to local classes
@ -155,7 +155,7 @@
the structure of objects, to read object attributes, to edit
object attributes, to add new instances, to delete instances,
and to search classes.</li>
<li>An application of JEP-0009 for calling methods on
<li>An application of XEP-0009 for calling methods on
objects.</li>
</ul>
</section1>
@ -276,7 +276,7 @@
<section2 topic='Method'>
<p>A method is a unit of behavior that makes up part of an
object. Methods in JOAP are compatible with &xmlrpc;, as
specified in &jep0009;. In particular, methods have a name, a
specified in &xep0009;. In particular, methods have a name, a
return type, and 0 or more parameters, each of which has a
type.</p>
<p>The one exception to XML-RPC compatibility is that method
@ -1089,7 +1089,7 @@
</section2>
<section2 topic='Method Calls'>
<p>Method calls in JOAP are simply XML-RPC calls, as defined in
JEP-0009.<note>JEP-0009 leaves some open questions as to use
XEP-0009.<note>XEP-0009 leaves some open questions as to use
of widely-defined extensions to the XML-RPC standard, such as
the &lt;nil&gt; type (see
<link url='http://ontosys.com/xml-rpc/extensions.html'>&lt;nil&gt;
@ -1332,10 +1332,10 @@
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with the IANA.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<section1 topic='XMPP Registrar Considerations'>
<p>This protocol defines one new namespace, 'jabber:iq:joap'.</p>
<p>Experimental implementations of this protocol should use the
namespace '<tt>http://www.jabber.org/jeps/jep-0075.html#0.3</tt>' to
namespace '<tt>http://www.xmpp.org/extensions/xep-0075.html#0.3</tt>' to
avoid conflicts with future versions.</p>
</section1>
<section1 topic='Future Considerations'>
@ -1818,4 +1818,4 @@
Station: TrackSegment, Building
]]></example>
</section1>
</jep>
</xep>

20
xep-0076.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Malicious Stanzas</title>
<abstract>This JEP defines a protocol extension for flagging malicious stanzas within Jabber/XMPP.</abstract>
<abstract>This document defines a protocol extension for flagging malicious stanzas within Jabber/XMPP.</abstract>
&LEGALNOTICE;
<number>0076</number>
<status>Active</status>
@ -84,12 +84,12 @@
</section2>
</section1>
<section1 topic='Security Considerations'>
<p>Because the 'http://jabber.org/protocol/evil' namespace flags an XML stanza as malicious, it is critically important that an entity appropriately process an XML stanza that contains the evil extension. Mission-critical applications SHOULD ignore any stanzas tagged with the evil extension. Evil servers MAY pass through evil stanzas unmodified. Really evil servers MAY silently delete the evil extension. Jabber entities that are evil to the core SHOULD support channel-level evil as defined in RFC 3514, since this JEP defines per-stanza evil only.</p>
<p>Because the 'http://jabber.org/protocol/evil' namespace flags an XML stanza as malicious, it is critically important that an entity appropriately process an XML stanza that contains the evil extension. Mission-critical applications SHOULD ignore any stanzas tagged with the evil extension. Evil servers MAY pass through evil stanzas unmodified. Really evil servers MAY silently delete the evil extension. Jabber entities that are evil to the core SHOULD support channel-level evil as defined in RFC 3514, since this document defines per-stanza evil only.</p>
</section1>
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<p>The &REGISTRAR; shall register the 'http://jabber.org/protocol/evil' namespace as a result of this JEP.</p>
<section1 topic='XMPP Registrar Considerations'>
<p>The &REGISTRAR; shall register the 'http://jabber.org/protocol/evil' namespace as a result of this document.</p>
</section1>
</jep>
</xep>

48
xep-0077.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<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>
@ -20,7 +20,7 @@
<supersededby/>
<shortname>iq-register</shortname>
<schemaloc>
<url>http://jabber.org/protocol/iq-register/iq-register.xsd</url>
<url>http://www.xmpp.org/schemas/iq-register.xsd</url>
</schemaloc>
&stpeter;
<revision>
@ -75,7 +75,7 @@
<version>1.1</version>
<date>2003-10-02</date>
<initials>psa</initials>
<remark>Moved change password use case from JEP-0078.</remark>
<remark>Moved change password use case from XEP-0078.</remark>
</revision>
<revision>
<version>1.0</version>
@ -144,10 +144,10 @@
<section1 topic='Requirements' anchor='reqs'>
<p>In-band registration must make it possible for an entity to register with a host, cancel an existing registration with a host, or change a password with a host. By "host" is meant either of the following:</p>
<ol type='1' start='1'>
<li>an instant messaging server, such as described in <cite>XMPP IM</cite> and identified by the "server/im" &jep0030; category+type</li>
<li>an add-on service, such as a gateway (see &jep0100;) or a &jep0045; service</li>
<li>an instant messaging server, such as described in <cite>XMPP IM</cite> and identified by the "server/im" &xep0030; category+type</li>
<li>an add-on service, such as a gateway (see &xep0100;) or a &xep0045; service</li>
</ol>
<p>If needed, extensibility with regard to information gathered should be done using &jep0004;.</p>
<p>If needed, extensibility with regard to information gathered should be done using &xep0004;.</p>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='Entity Registers with a Host' anchor='usecases-register'>
@ -494,18 +494,18 @@
</section2>
</section1>
<section1 topic='Extensibility' anchor='extensibility'>
<p>The fields defined for the 'jabber:iq:register' namespace are strictly limited to those specified in the schema. If a host needs to gather additional information, <cite>JEP-0004: Data Forms</cite> ("x:data") SHOULD be used according to the following rules:</p>
<p>The fields defined for the 'jabber:iq:register' namespace are strictly limited to those specified in the schema. If a host needs to gather additional information, <cite>XEP-0004: Data Forms</cite> ("x:data") SHOULD be used according to the following rules:</p>
<ol>
<li>A host MUST NOT add new fields to the 'jabber:iq:register' namespace; instead, extensibility SHOULD be pursued via the <cite>Data Forms</cite> protocol as specified herein.</li>
<li>The x:data form shall be contained as a child element of the &lt;query xmlns='jabber:iq:register'/&gt; element (it cannot be a child of the &IQ; stanza and comply with Section 9.2.3 of &rfc3920;).</li>
<li>The x:data form SHOULD contain x:data fields that correspond to all of the iq:register fields (e.g., username and password).</li>
<li>The x:data form SHOULD use a hidden FORM_TYPE field for the purpose of standardizing field names within the form, as defined in &jep0068;.</li>
<li>The x:data form SHOULD use a hidden FORM_TYPE field for the purpose of standardizing field names within the form, as defined in &xep0068;.</li>
<li>The x:data form shall take precedence over the iq:register fields; if the submitting entity supports the <cite>Data Forms</cite> protocol, it SHOULD submit the data form rather than the predefined 'jabber:iq:register' fields, and MUST NOT submit both the data form and the predefined fields (see the <link url='#precedence'>Precedence Order</link> section of this document).</li>
</ol>
<p>Support for extensibility via <cite>Data Forms</cite> is RECOMMENDED but is not required for compliance with this JEP.</p>
</section1>
<section1 topic='Redirection' anchor='redirect'>
<p>A given deployment MAY wish to redirect users to another medium (e.g., a website) for registration, rather than allowing in-band registration. The recommended approach is to include only the &lt;instructions/&gt; element rather than the required fields or a data form in the IQ result, as well as a URL encoded using &jep0066; (see the <link url="#precedence">Precedence Order</link> section below for further details).</p>
<p>A given deployment MAY wish to redirect users to another medium (e.g., a website) for registration, rather than allowing in-band registration. The recommended approach is to include only the &lt;instructions/&gt; element rather than the required fields or a data form in the IQ result, as well as a URL encoded using &xep0066; (see the <link url="#precedence">Precedence Order</link> section below for further details).</p>
<example caption='Host Redirects Entity to Web Registration'><![CDATA[
<iq type='result'
from='contests.shakespeare.lit'
@ -602,7 +602,7 @@
<p>A server SHOULD NOT advertise in-band registration to another server (i.e., if the initial stream header was qualified by the 'jabber:server' namespace).</p>
</section1>
<section1 topic='Error Handling' anchor='errors'>
<p>As defined herein, the 'jabber:iq:register' namespace supports both the old (HTTP-style) error codes and the extensible error classes and conditions specified in XMPP Core. A compliant server or service implementation MUST support both old-style and new-style error handling. A compliant client implementation SHOULD support both. For mappings of HTTP-style errors to XMPP-style conditions, refer to &jep0086;.</p>
<p>As defined herein, the 'jabber:iq:register' namespace supports both the old (HTTP-style) error codes and the extensible error classes and conditions specified in XMPP Core. A compliant server or service implementation MUST support both old-style and new-style error handling. A compliant client implementation SHOULD support both. For mappings of HTTP-style errors to XMPP-style conditions, refer to &xep0086;.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>In-band registration is usually not included in other messaging protocols (for example, SMTP does not include a method for registering with an email server), often for reasons of security. The registration methods defined herein are known to be insecure and SHOULD NOT be used unless the channel between the registrant and the entity that accepts registration has been secured. For these reasons, the deployment of in-band registration is a policy matter and a given deployment MAY choose to disable in-band registration and password changes. Furthermore, this JEP should be deprecated as soon as a successor protocol is defined and implemented.</p>
@ -610,15 +610,15 @@
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; includes the 'jabber:iq:register' namespace in its registry of protocol namespaces.</p>
</section2>
<section2 topic='Stream Features' anchor='registrar-stream'>
<p>The Jabber Registrar includes the 'http://jabber.org/features/iq-register' namespace in its registry of stream feature namespaces.</p>
<p>The XMPP Registrar includes the 'http://jabber.org/features/iq-register' namespace in its registry of stream feature namespaces.</p>
</section2>
<section2 topic='URI Query Types' anchor='registrar-querytypes'>
<p>As authorized by &jep0147;, the Jabber Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).</p>
<p>As authorized by &xep0147;, the XMPP Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).</p>
<p>As described below, the registered querytypes for registration management are "register" and "unregister".</p>
<section3 topic='register' anchor='registrar-querytypes-register'>
<p>The 'jabber:iq:register' namespace include a mechanism for creating a registration. The registered querytype for doing so is "register".</p>
@ -654,7 +654,7 @@ xmpp:marlowe.shakespeare.lit?register
<name>register</name>
<proto>jabber:iq:register</proto>
<desc>enables registering with a server or service</desc>
<doc>JEP-0077</doc>
<doc>XEP-0077</doc>
</querytype>
]]></code>
</section3>
@ -676,7 +676,7 @@ xmpp:marlowe.shakespeare.lit?unregister
<name>unregister</name>
<proto>jabber:iq:register</proto>
<desc>enables cancellation of a registration with a server or service</desc>
<doc>JEP-0077</doc>
<doc>XEP-0077</doc>
</querytype>
]]></code>
</section3>
@ -687,7 +687,7 @@ xmpp:marlowe.shakespeare.lit?unregister
<code><![CDATA[
<form_type>
<name>jabber:iq:register</name>
<doc>JEP-0077</doc>
<doc>XEP-0077</doc>
<desc>Standardization of fields related to registration use case.</desc>
<field
var='username'
@ -764,7 +764,7 @@ xmpp:marlowe.shakespeare.lit?unregister
<code><![CDATA[
<form_type>
<name>jabber:iq:register:cancel</name>
<doc>JEP-0077</doc>
<doc>XEP-0077</doc>
<desc>Standardization of fields related to cancellation use case.</desc>
<field
var='password'
@ -781,7 +781,7 @@ xmpp:marlowe.shakespeare.lit?unregister
<code><![CDATA[
<form_type>
<name>jabber:iq:register:cancel</name>
<doc>JEP-0077</doc>
<doc>XEP-0077</doc>
<desc>Standardization of fields related to change password use case.</desc>
<field
var='old_password'
@ -821,7 +821,7 @@ xmpp:marlowe.shakespeare.lit?unregister
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0077: http://www.jabber.org/jeps/jep-0077.html
XEP-0077: http://www.xmpp.org/extensions/xep-0077.html
</xs:documentation>
</xs:annotation>
@ -881,7 +881,7 @@ xmpp:marlowe.shakespeare.lit?unregister
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0077: http://www.jabber.org/jeps/jep-0077.html
XEP-0077: http://www.xmpp.org/extensions/xep-0077.html
</xs:documentation>
</xs:annotation>
@ -897,4 +897,4 @@ xmpp:marlowe.shakespeare.lit?unregister
]]></code>
</section2>
</section1>
</jep>
</xep>

32
xep-0078.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Non-SASL Authentication</title>
<abstract>This document specifies a protocol for authentication with Jabber servers and services using the jabber:iq:auth namespace. Note Well: The protocol specified herein has been deprecated in favor of SASL authentication as specified in RFC 3920.</abstract>
@ -23,7 +23,7 @@
</supersededby>
<shortname>iq-auth</shortname>
<schemaloc>
<url>http://jabber.org/protocol/iq-auth/iq-auth.xsd</url>
<url>http://www.xmpp.org/schemas/iq-auth.xsd</url>
</schemaloc>
<expires>2007-03-13</expires>
<revision>
@ -42,7 +42,7 @@
<version>2.1</version>
<date>2004-12-09</date>
<initials>psa</initials>
<remark><p>Changed SHOULD to MUST regarding priority of SASL (RFC 3920) over jabber:iq:auth (JEP-0078).</p></remark>
<remark><p>Changed SHOULD to MUST regarding priority of SASL (RFC 3920) over jabber:iq:auth (XEP-0078).</p></remark>
</revision>
<revision>
<version>2.0</version>
@ -97,7 +97,7 @@
<version>1.1</version>
<date>2003-10-02</date>
<initials>psa</initials>
<remark><p>Moved change password use case to JEP-0077.</p></remark>
<remark><p>Moved change password use case to XEP-0077.</p></remark>
</revision>
<revision>
<version>1.0</version>
@ -156,7 +156,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p><em>Note Well: The protocol specified herein has been deprecated in favor of SASL authentication as specified in &rfc3920;.</em></p>
<p>Jabber technologies have long included a wire protocol that enables a client to authenticate with a server. <note>Component authentication is out of scope for this JEP, and is specified separately in &jep0114;.</note> The method originally used in the Jabber community makes use of the 'jabber:iq:auth' namespace and has been documented variously in Internet-Drafts and elsewhere. Because the XMPP specifications required upgraded authentication methods using SASL (see &rfc4422;) in order to progress through the Internet Standards Process, documentation of the 'jabber:iq:auth' namespace was removed from those specifications.</p>
<p>Jabber technologies have long included a wire protocol that enables a client to authenticate with a server. <note>Component authentication is out of scope for this document, and is specified separately in &xep0114;.</note> The method originally used in the Jabber community makes use of the 'jabber:iq:auth' namespace and has been documented variously in Internet-Drafts and elsewhere. Because the XMPP specifications required upgraded authentication methods using SASL (see &rfc4422;) in order to progress through the Internet Standards Process, documentation of the 'jabber:iq:auth' namespace was removed from those specifications.</p>
<p>The 'jabber:iq:auth' method specified herein has been deprecated. However, because it will take some time for existing implementations and deployments to be upgraded to SASL, client and server software implementations still need to include support for 'jabber:iq:auth' in order to interoperate, and this document provides canonical documentation of the 'jabber:iq:auth' method. Nevertheless, implementation and deployment of SASL authentication is strongly recommended, since the 'jabber:iq:auth' method will eventually be obsoleted entirely.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
@ -165,7 +165,7 @@
<li>plaintext</li>
<li>digest (using the SHA1 algorithm specified in &rfc3174;)</li>
</ol>
<p>Note: This JEP does not include the so-called "zero-knowledge" method; that method did not provide stronger security than digest authentication and thus is unnecessary.</p>
<p>Note: This document does not include the so-called "zero-knowledge" method; that method did not provide stronger security than digest authentication and thus is unnecessary.</p>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='User Authenticates with Server' anchor='usecases-auth'>
@ -285,7 +285,7 @@
<p>As defined herein, the 'jabber:iq:auth' namespace supports both the old (HTTP-style) error codes and the extensible error classes and conditions specified in <cite>RFC 3920</cite>. A compliant server or service implementation MUST support both old-style and new-style error handling. A compliant client implementation SHOULD support both.</p>
</section1>
<section1 topic='Expiration Date' anchor='expiration'>
<p>In accordance with Section 8 of &jep0001;, on 2004-10-20 this JEP was advanced to a status of Final with the understanding that it would expire in six months. On 2006-09-13, the Jabber Council changed the status of this JEP to Deprecated. The Jabber Council will review this JEP every six months to determine whether to change its status to Obsolete or to extend the expiration date for an additional six months; this process will continue until the JEP is obsoleted. For the latest expiration date, refer to the JEP Information block at the beginning of this document.</p>
<p>In accordance with Section 8 of &xep0001;, on 2004-10-20 this document was advanced to a status of Final with the understanding that it would expire in six months. On 2006-09-13, the Jabber Council changed the status of this document to Deprecated. The Jabber Council will review this document every six months to determine whether to change its status to Obsolete or to extend the expiration date for an additional six months; this process will continue until the document is obsoleted. For the latest expiration date, refer to the XEP Information block at the beginning of this document.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>Use of the 'jabber:iq:auth' method for client-server authentication is not as secure as SASL authentication (defined in <cite>RFC 3920</cite>). If both client and server implement SASL, they MUST use SASL. If a client attempts to authenticate using the 'jabber:iq:auth' namespace after an attempt at SASL authentication fails, the server MUST refuse the 'jabber:iq:auth' attempt by returning a &lt;policy-violation/&gt; stream error to the client.</p>
@ -293,14 +293,14 @@
<p>Authentication using the 'jabber:iq:auth' method is known to be less secure than SASL authentication, which is one reason why the 'jabber:iq:auth' method has been deprecated.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; includes the 'jabber:iq:auth' namespace in its registry of protocol namespaces.</p>
</section2>
<section2 topic='Stream Features' anchor='registrar-stream'>
<p>The Jabber Registrar includes the 'http://jabber.org/features/iq-auth' namespace in its registry of stream feature namespaces.</p>
<p>The XMPP Registrar includes the 'http://jabber.org/features/iq-auth' namespace in its registry of stream feature namespaces.</p>
</section2>
</section1>
<section1 topic='XML Schemas' anchor='schemas'>
@ -317,7 +317,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0078: http://www.jabber.org/jeps/jep-0078.html
XEP-0078: http://www.xmpp.org/extensions/xep-0078.html
</xs:documentation>
</xs:annotation>
@ -350,7 +350,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0078: http://www.jabber.org/jeps/jep-0078.html
XEP-0078: http://www.xmpp.org/extensions/xep-0078.html
</xs:documentation>
</xs:annotation>
@ -366,4 +366,4 @@
]]></code>
</section2>
</section1>
</jep>
</xep>

96
xep-0079.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Advanced Message Processing</title>
<abstract>This JEP defines a protocol that enables entities to request, and servers to perform, advanced processing of XMPP &lt;message/&gt; stanzas, including reliable data transport, time-sensitive delivery, and transient messages.</abstract>
<abstract>This document defines an XMPP protocol extension that enables entities to request, and servers to perform, advanced processing of XMPP &lt;message/&gt; stanzas, including reliable data transport, time-sensitive delivery, and transient messages.</abstract>
&LEGALNOTICE;
<number>0079</number>
<status>Draft</status>
@ -15,25 +15,25 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0030</spec>
<spec>JEP-0082</spec>
<spec>XEP-0030</spec>
<spec>XEP-0082</spec>
</dependencies>
<supersedes>
<spec>JEP-0023</spec>
<spec>XEP-0023</spec>
</supersedes>
<supersededby>None</supersededby>
<shortname>amp</shortname>
<schemaloc>
<ns>amp</ns>
<url>http://jabber.org/protocol/amp/amp.xsd</url>
<url>http://www.xmpp.org/schemas/amp.xsd</url>
</schemaloc>
<schemaloc>
<ns>amp#errors</ns>
<url>http://jabber.org/protocol/amp/errors.xsd</url>
<url>http://www.xmpp.org/schemas/amp-errors.xsd</url>
</schemaloc>
<schemaloc>
<ns>feature</ns>
<url>http://jabber.org/protocol/amp/feature.xsd</url>
<url>http://www.xmpp.org/schemas/amp-feature.xsd</url>
</schemaloc>
<registry/>
&linuxwolf;
@ -66,7 +66,7 @@
<version>0.11</version>
<date>2004-08-25</date>
<initials>lw/psa</initials>
<remark>Specified that the timestamp for an expire-at condition must be a UTC DateTime per JEP-0082; provided further explanation regarding expire-at and expire-in conditions.</remark>
<remark>Specified that the timestamp for an expire-at condition must be a UTC DateTime per XEP-0082; provided further explanation regarding expire-at and expire-in conditions.</remark>
</revision>
<revision>
<version>0.10</version>
@ -78,13 +78,13 @@
<version>0.9</version>
<date>2004-04-25</date>
<initials>psa</initials>
<remark>JEP Editor's review: clarified some matters in the text; fully defined the Jabber Registrar Considerations.</remark>
<remark>JEP Editor's review: clarified some matters in the text; fully defined the XMPP Registrar Considerations.</remark>
</revision>
<revision>
<version>0.8</version>
<date>2004-01-20</date>
<initials>lw</initials>
<remark>Reorganized for JEP editor's preferences; revised error conditions to properly align with XMPP-Core</remark>
<remark>Reorganized for JEP Editor's preferences; revised error conditions to properly align with XMPP-Core</remark>
</revision>
<revision>
<version>0.7</version>
@ -136,9 +136,9 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>This JEP defines a protocol that enables an end-point entity to specify additional delivery semantics for an XMPP &lt;message/&gt; stanza. This protocol is typically used by clients to inform the receiving server how to deliver a particular stanza, such as providing an expiration time or a resource-matching strategy.</p>
<p>This document defines a protocol that enables an end-point entity to specify additional delivery semantics for an XMPP &lt;message/&gt; stanza. This protocol is typically used by clients to inform the receiving server how to deliver a particular stanza, such as providing an expiration time or a resource-matching strategy.</p>
<section2 topic='Motivation' anchor='intro-motivation'>
<p>The built-in delivery semantics for &lt;message/&gt; stanzas (defined in &xmppcore; and, for instant messaging applications, also in &xmppim;) are adequate for most current applications. However, there are various cases where more stringent delivery semantics are necessary. The most common cases discussed in this JEP are:</p>
<p>The built-in delivery semantics for &lt;message/&gt; stanzas (defined in &xmppcore; and, for instant messaging applications, also in &xmppim;) are adequate for most current applications. However, there are various cases where more stringent delivery semantics are necessary. The most common cases discussed in this document are:</p>
<ul>
<li>Reliable data transport -- the sender requires notification (positive and/or negative) of message delivery.</li>
<li>Time-sensitive messages -- the message is valid only until a certain date and time.</li>
@ -147,7 +147,7 @@
</section2>
<section2 topic='Concepts' anchor='intro-concepts'>
<p>This protocol is mostly handled by the server or servers processing the &lt;message/&gt;. The protocol consists of a list of rules, with conditions and actions for each rule. Upon receipt of an appropriately marked message, the server interprets the rules in the order they are received, looking for met conditions. When a condition is met, the action for that rule is executed, and message processing stops.</p>
<p>Each rule is flagged for the scope it applies to, whether it be the overall route, or for each hop in the route. Additionally, while this JEP defines a default set of conditions and actions, the protocol is extensible enough to allow for more to be defined in the future.</p>
<p>Each rule is flagged for the scope it applies to, whether it be the overall route, or for each hop in the route. Additionally, while this document defines a default set of conditions and actions, the protocol is extensible enough to allow for more to be defined in the future.</p>
<p>The namespace for the protocol is "http://jabber.org/protocol/amp".</p>
</section2>
<section2 topic='Prerequisites' anchor='intro-prereq'>
@ -167,7 +167,7 @@
<li><cite>E2:</cite> The server does not support one or more specified rule conditions/actions (UCE unsuccessfully)</li>
</ul>
<section3 topic='Discovery' anchor='process-s2s-disco'>
<p>Sending entities that wish to use AMP SHOULD discover support for this protocol (using &jep0030;) along the intended path. Typically, this would involve sending disco#info queries to the sending entity's own server and the server of the intended recipient. The results of these queries MAY be cached for up to 24 hours, unless otherwise expired.</p>
<p>Sending entities that wish to use AMP SHOULD discover support for this protocol (using &xep0030;) along the intended path. Typically, this would involve sending disco#info queries to the sending entity's own server and the server of the intended recipient. The results of these queries MAY be cached for up to 24 hours, unless otherwise expired.</p>
<p>If a server supports Advanced Message Processing, it MUST report that by including a service discovery feature of "http://jabber.org/protocol/amp" in the service discovery information result that it returns to the requesting entity.</p>
<example caption="Initial Service Discovery information request"><![CDATA[
<iq from='northumberland@shakespeare.lit/westminster'
@ -295,7 +295,7 @@
</section2>
</section1>
<section1 topic='Conditions and Actions' anchor='conditionsactions'>
<p>The preceding sections of this JEP define the general behavior regarding AMP. This section outlines how &lt;rule/&gt; action and condition sets are specified. It also provides defined action and condition sets; these action and condition sets SHOULD be supported by any implementation of Advanced Message Processing, but support for any given action or condition set it not required. (Note: The action and condition sets defined herein may be supplemented in the future via registration of additional action and condition sets with the Jabber Registrar.)</p>
<p>The preceding sections of this document define the general behavior regarding AMP. This section outlines how &lt;rule/&gt; action and condition sets are specified. It also provides defined action and condition sets; these action and condition sets SHOULD be supported by any implementation of Advanced Message Processing, but support for any given action or condition set it not required. (Note: The action and condition sets defined herein may be supplemented in the future via registration of additional action and condition sets with the XMPP Registrar.)</p>
<section2 topic='Rule Condition Guidelines' anchor='conditions-guide'>
<p>The definition of a &lt;rule/&gt; condition MUST provide the following information:</p>
<ul>
@ -324,7 +324,7 @@
</section2>
<section2 topic='Defined Conditions' anchor='conditions-def'>
<p>The condition defines how or when a particular rule is triggered. The value of the condition attribute determines what the contents of the &lt;rule/&gt; mean.</p>
<p>The following conditions are defined by this JEP and SHOULD be supported by any implementation.</p>
<p>The following conditions are defined by this document and SHOULD be supported by any implementation.</p>
<p>In the following sections, the terms "content" and "contents" refers to the XML character data contained by the &lt;rule/&gt; element.</p>
<section3 topic='deliver' anchor='conditions-def-deliver'>
<p>The "deliver" condition is used to ensure delivery (or non-delivery) in one of five ways:</p>
@ -364,8 +364,8 @@
<p>This condition MAY be applied to each "hop" in the server route.</p>
</section3>
<section3 topic='expire-at' anchor='conditions-def-expireat'>
<p>The "expire-at" condition is used to ensure delivery before an absolute point in time. Naturally, this does not <em>guarantee</em> <note>Guarantee is a strong word. This JEP defines methods for making message delivery more reliable within certain bounds, but does not pretend that such methods provide any form of guaranteed delivery.</note> that the message will not be delivered after that time from the sender's perspective, since this JEP does not assume that all machine clocks (e.g., for all servers along the delivery route) are synchronized. However, in order to help ensure that this condition is met correctly, servers that implement this JEP (or the machines that host such servers) SHOULD use the Network Time Protocol (&rfc1305;) to keep in sync with established time authorities. Note also that expire-at functionality becomes less reliable the closer the expire-at time is to the present (e.g., the sender will receive less reliable delivery of a message speciifying an expire-at time two seconds in the future than of a message specifying an expire-at time two hours or two days in the future).</p>
<p>The content of the 'value' attribute specifies some point after the exact moment the message is sent; the content MUST be a DateTime as specified in &jep0082;, and the timezone MUST be UTC.</p>
<p>The "expire-at" condition is used to ensure delivery before an absolute point in time. Naturally, this does not <em>guarantee</em> <note>Guarantee is a strong word. This document defines methods for making message delivery more reliable within certain bounds, but does not pretend that such methods provide any form of guaranteed delivery.</note> that the message will not be delivered after that time from the sender's perspective, since this document does not assume that all machine clocks (e.g., for all servers along the delivery route) are synchronized. However, in order to help ensure that this condition is met correctly, servers that implement this document (or the machines that host such servers) SHOULD use the Network Time Protocol (&rfc1305;) to keep in sync with established time authorities. Note also that expire-at functionality becomes less reliable the closer the expire-at time is to the present (e.g., the sender will receive less reliable delivery of a message speciifying an expire-at time two seconds in the future than of a message specifying an expire-at time two hours or two days in the future).</p>
<p>The content of the 'value' attribute specifies some point after the exact moment the message is sent; the content MUST be a DateTime as specified in &xep0082;, and the timezone MUST be UTC.</p>
<p>The condition is met if the message would be delivered to the recipient after the specified datetime. To determine the datetime to compare to, the processor first determines if and when a message can be dispatched (e.g. not stored offline). The processor then records this datetime, and compares it with the specified datetime. If the current datetime is on or after that specified, the condition is met.</p>
<p>This condition MAY be applied to each "hop" in the server route.</p>
</section3>
@ -397,7 +397,7 @@
<p>The condition is met if the resource for the actual destination JID matches the intended JID using the above rules. For instance, if a message is intended for "romeo@montague.net/work" with the "match-resource" condition of "exact", the condition is met if the message can be immediately delivered only to "romeo@montague.net/work".</p>
<p>For purposes of this condition, an intended JID with no resource has the following behavior:</p>
<ul>
<li>If the value is "exact", the condition is met only if the server would deliver to a destination JID without a resource identifier (e.g., a &jep0045; room or offline storage).</li>
<li>If the value is "exact", the condition is met only if the server would deliver to a destination JID without a resource identifier (e.g., a &xep0045; room or offline storage).</li>
<li>If the value is "other", the condition is met only if the server would not deliver to a destination JID without a resource identifier.</li>
</ul>
<p>This condition MUST NOT be applied to each "hop" in the server route, only at the edge servers. If an &lt;amp/&gt; element includes this condition and also indicates that it should be processed per hop, this &lt;rule/&gt; shall be ignored.</p>
@ -406,7 +406,7 @@
</section2>
<section2 topic='Defined Actions' anchor='actions-def'>
<p>The action defines what occurs when a particular rule is triggered. The value of the action attribute determines the behavior if the rule's condition is met.</p>
<p>The following actions are defined by this JEP.</p>
<p>The following actions are defined by this document.</p>
<section3 topic='alert' anchor='actions-def-alert'>
<p>The "alert" action triggers a reply &MESSAGE; stanza to the sending entity. This &MESSAGE; stanza MUST contain the element &lt;amp status='alert'/&gt;, which itself contains the &lt;rule/&gt; that triggered this action. In all other respects, this action behaves as "drop".</p>
<example caption='Alert Response'><code><![CDATA[
@ -683,14 +683,14 @@
</section2>
<section2 topic='&lt;rule/&gt; Element' anchor='formal-rule'>
<p>Each semantic rule is specified with a &lt;rule/&gt; element. This element possesses attributes for the condition, value, and action.</p>
<p>The 'action' attribute defines the result for this rule. This attribute MUST be present, and MUST be either a value defined in the <link url="#actions-def">Defined Actions</link> section, or one registered with the Jabber Registrar.</p>
<p>The 'condition' attribute defines the overall condition this rule applies to. This attribute MUST be present, and MUST be either a value defined in the <link url="#conditions-def">Defined Conditions</link> section, or one registered with the Jabber Registrar.</p>
<p>The 'action' attribute defines the result for this rule. This attribute MUST be present, and MUST be either a value defined in the <link url="#actions-def">Defined Actions</link> section, or one registered with the XMPP Registrar.</p>
<p>The 'condition' attribute defines the overall condition this rule applies to. This attribute MUST be present, and MUST be either a value defined in the <link url="#conditions-def">Defined Conditions</link> section, or one registered with the XMPP Registrar.</p>
<p>The 'value' attribute defines how the condition is matched. This attribute MUST be present, and MUST NOT be an empty string (""). The interpretation of this attribute's value is determined by the 'condition' attribute.</p>
</section2>
</section1>
<section1 topic='Example Scenarios' anchor='examples'>
<section2 topic='Reliable Data Transport' anchor='examples-reliabledata'>
<p>The &MESSAGE; stanza is nearly ideal for data transport, but to ensure reliability it is often desirable that such messages not be delivered to any resource but that specified. To facilitate this, the sending entity includes a &lt;rule action='drop' condition='match-resource' value='other'/&gt; (if failure notification is unnecessary) or &lt;rule action='error' condition='match-resource' value='other'/&gt; (if failure notification is required). The following example illustrates this using &jep0047;:</p>
<p>The &MESSAGE; stanza is nearly ideal for data transport, but to ensure reliability it is often desirable that such messages not be delivered to any resource but that specified. To facilitate this, the sending entity includes a &lt;rule action='drop' condition='match-resource' value='other'/&gt; (if failure notification is unnecessary) or &lt;rule action='error' condition='match-resource' value='other'/&gt; (if failure notification is required). The following example illustrates this using &xep0047;:</p>
<example caption='Sending a message for reliable data transport'><![CDATA[
<message to='francisco@hamlet.lit/pda'
from='bernardo@hamlet.lit/elsinore'
@ -846,7 +846,7 @@
</table>
</section2>
<section2 topic='Examples' anchor='errors-examples'>
<p>This section shows examples of the error conditions described in the previous section (for information regarding mapping of XMPP error conditions to Jabber error codes, refer to &jep0086;).</p>
<p>This section shows examples of the error conditions described in the previous section (for information regarding mapping of XMPP error conditions to Jabber error codes, refer to &xep0086;).</p>
<section3 topic='Unsupported Action' anchor='errors-action'>
<example caption='A message with AMP semantics'><![CDATA[
<message
@ -1031,21 +1031,21 @@
</ul>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>No interaction with &IANA; is necessary as a result of this JEP.</p>
<p>No interaction with &IANA; is necessary as a result of this document.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; includes 'http://jabber.org/protocol/amp' and 'http://jabber.org/protocol/amp#errors' in its registry of protocol namespaces.</p>
</section2>
<section2 topic='Stream Features' anchor='registrar-stream'>
<p>The Jabber Registrar includes the 'http://jabber.org/features/amp' namespace in its registry of stream feature namespaces.</p>
<p>The XMPP Registrar includes the 'http://jabber.org/features/amp' namespace in its registry of stream feature namespaces.</p>
</section2>
<section2 topic='Well-Known Service Discovery Nodes' anchor='registrar-nodes'>
<p>The Jabber Registrar includes 'http://jabber.org/protocol/amp' in its registry of well-known Service Discovery nodes.</p>
<p>The XMPP Registrar includes 'http://jabber.org/protocol/amp' in its registry of well-known Service Discovery nodes.</p>
</section2>
<section2 topic='Registries' anchor='registrar-reg'>
<section3 topic='Rule Conditions Registry' anchor='registrar-reg-conditions'>
<p>The Jabber Registrar maintains a registry of AMP &lt;rule/&gt; conditions (see &lt;<link url='http://www.jabber.org/registrar/amp-conditions.html'>http://www.jabber.org/registrar/amp-conditions.html</link>&gt;).</p>
<p>The XMPP Registrar maintains a registry of AMP &lt;rule/&gt; conditions (see &lt;<link url='http://www.jabber.org/registrar/amp-conditions.html'>http://www.jabber.org/registrar/amp-conditions.html</link>&gt;).</p>
<section4 topic='Process' anchor='registrar-reg-conditions-process'>
&REGPROCESS;
<code><![CDATA[
@ -1058,7 +1058,7 @@
'value' attribute.
</value>
<processing>values that result in message processing</processing>
<doc>the document (e.g., JEP) in which this condition is specified</doc>
<doc>the document (e.g., XEP) in which this condition is specified</doc>
</condition>
]]></code>
<p>The registrant may register more than one condition at a time, each contained in a separate &lt;condition/&gt; element.</p>
@ -1080,19 +1080,19 @@
the message cannot be delivered at all, or (5) the value is
"stored" and the message can be stored for later delivery.
</processing>
<doc>JEP-0079</doc>
<doc>XEP-0079</doc>
</condition>
<condition>
<name>expire-at</name>
<ns>http://jabber.org/protocol/amp?condition=expire-at</ns>
<per-hop>true</per-hop>
<value>DateTime per JEP-0082</value>
<value>DateTime per XEP-0082</value>
<processing>
The condition is met if the message would be delivered after
the specified DateTime.
</processing>
<doc>JEP-0079</doc>
<doc>XEP-0079</doc>
</condition>
<condition>
@ -1109,13 +1109,13 @@
intended recipient has an available resource whose full JID is
other than that specified in the 'to' address.
</processing>
<doc>JEP-0079</doc>
<doc>XEP-0079</doc>
</condition>
]]></code>
</section4>
</section3>
<section3 topic='Rule Actions Registry' anchor='registrar-reg-actions'>
<p>The Jabber Registrar maintains a registry of AMP &lt;rule/&gt; actions (see &lt;<link url='http://www.jabber.org/registrar/amp-actions.html'>http://www.jabber.org/registrar/amp-actions.html</link>&gt;).</p>
<p>The XMPP Registrar maintains a registry of AMP &lt;rule/&gt; actions (see &lt;<link url='http://www.jabber.org/registrar/amp-actions.html'>http://www.jabber.org/registrar/amp-actions.html</link>&gt;).</p>
<section4 topic='Process' anchor='registrar-reg-actions-process'>
&REGPROCESS;
<code><![CDATA[
@ -1123,7 +1123,7 @@
<name>the value of the 'action' attribute</name>
<ns>the namespace to be used as a service discovery feature</ns>
<behavior>the expected behavior if the rule is triggered</behavior>
<doc>the document (e.g., JEP) in which this action is specified</doc>
<doc>the document (e.g., XEP) in which this action is specified</doc>
</action>
]]></code>
<p>The registrant may register more than one action at a time, each contained in a separate &lt;action/&gt; element.</p>
@ -1138,7 +1138,7 @@
The message is silently discarded but an alert is returned to the
sender.
</behavior>
<doc>JEP-0079</doc>
<doc>XEP-0079</doc>
</action>
<action>
@ -1147,7 +1147,7 @@
<behavior>
The message is silently discarded.
</behavior>
<doc>JEP-0079</doc>
<doc>XEP-0079</doc>
</action>
<action>
@ -1157,7 +1157,7 @@
The message is not processed and an error is returned to the sender,
specifying which rule resulted in failed processing.
</behavior>
<doc>JEP-0079</doc>
<doc>XEP-0079</doc>
</action>
<action>
@ -1167,7 +1167,7 @@
The message is processed and a notification message is returned to
the sender, specifying which rule was processed.
</behavior>
<doc>JEP-0079</doc>
<doc>XEP-0079</doc>
</action>
]]></code>
</section4>
@ -1188,7 +1188,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0079: http://www.jabber.org/jeps/jep-0079.html
XEP-0079: http://www.xmpp.org/extensions/xep-0079.html
</xs:documentation>
</xs:annotation>
@ -1252,7 +1252,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0079: http://www.jabber.org/jeps/jep-0079.html
XEP-0079: http://www.xmpp.org/extensions/xep-0079.html
</xs:documentation>
</xs:annotation>
@ -1288,7 +1288,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0079: http://www.jabber.org/jeps/jep-0079.html
XEP-0079: http://www.xmpp.org/extensions/xep-0079.html
</xs:documentation>
</xs:annotation>
@ -1307,4 +1307,4 @@
<section1 topic='Acknowledgements' anchor='acks'>
<p>Thanks to Marshall Rose and Craig Kaes for their comments.</p>
</section1>
</jep>
</xep>