moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

JEP to XEP 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@41 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-10-04 15:48:05 +00:00
parent 8c1c4c17c8
commit a4cfd1ab6b
10 changed files with 138 additions and 138 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
xep-0100.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>Gateway Interaction</title>
<abstract>This JEP specifies best practices for interactions between Jabber clients and client proxy gateways to legacy IM services.</abstract>
<abstract>This document specifies best practices for interactions between Jabber clients and client proxy gateways to legacy IM services.</abstract>
&LEGALNOTICE;
<number>0100</number>
<status>Active</status>
@ -16,15 +16,15 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0030</spec>
<spec>JEP-0077</spec>
<spec>JEP-0144</spec>
<spec>XEP-0030</spec>
<spec>XEP-0077</spec>
<spec>XEP-0144</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>gateway</shortname>
<schemaloc>
<url>http://jabber.org/protocol/iq-gateway/iq-gateway.xsd</url>
<url>http://www.xmpp.org/schemas/iq-gateway.xsd</url>
</schemaloc>
&stpeter;
&dizzyd;
@ -38,13 +38,13 @@
<version>0.10</version>
<date>2005-05-12</date>
<initials>psa</initials>
<remark>Modified text regarding address transformations and added reference to JEP-0106; corrected several small errors in the text and examples.</remark>
<remark>Modified text regarding address transformations and added reference to XEP-0106; corrected several small errors in the text and examples.</remark>
</revision>
<revision>
<version>0.9</version>
<date>2004-10-27</date>
<initials>psa</initials>
<remark>Added specification of jabber:iq:gateway namespace; added reference to JEP-0144.</remark>
<remark>Added specification of jabber:iq:gateway namespace; added reference to XEP-0144.</remark>
</revision>
<revision>
<version>0.8</version>
@ -96,8 +96,8 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>One distinguishing characteristic of Jabber technologies from their earliest days has been the existence of gateways (also called "transports") between the Jabber network and legacy instant messaging services such as AOL Instant Messenger (AIM), ICQ, MSN Messenger, and Yahoo! Messenger. Surprisingly, the recommended behavior of such gateways, including the protocol elements used by a client to interact with a gateway, has never been fully documented. This JEP attempts to fill that void by codifying best practices for gateway interaction.</p>
<p>Note well that this JEP defines protocol usage with regard to client proxy gateways, i.e., gateways that "masquerade" as a client on a non-Jabber IM service. Gateways that perform direct protocol translation without proxying for an account on a non-Jabber service are not addressed in this JEP. Furthermore, this JEP does not define any interaction between a gateway and the non-Jabber service, only interactions between a Jabber client and the gateway. Although what happens on the other side of the gateway is highly dependent on the nature of the legacy service, gateways should at least provide a common interface on the Jabber side of the gateway so that Jabber clients can be written in a consistent fashion.</p>
<p>One distinguishing characteristic of Jabber technologies from their earliest days has been the existence of gateways (also called "transports") between the Jabber network and legacy instant messaging services such as AOL Instant Messenger (AIM), ICQ, MSN Messenger, and Yahoo! Messenger. Surprisingly, the recommended behavior of such gateways, including the protocol elements used by a client to interact with a gateway, has never been fully documented. This document attempts to fill that void by codifying best practices for gateway interaction.</p>
<p>Note well that this document defines protocol usage with regard to client proxy gateways, i.e., gateways that "masquerade" as a client on a non-Jabber IM service. Gateways that perform direct protocol translation without proxying for an account on a non-Jabber service are not addressed in this document. Furthermore, this document does not define any interaction between a gateway and the non-Jabber service, only interactions between a Jabber client and the gateway. Although what happens on the other side of the gateway is highly dependent on the nature of the legacy service, gateways should at least provide a common interface on the Jabber side of the gateway so that Jabber clients can be written in a consistent fashion.</p>
</section1>
<section1 topic='Glossary' anchor='glossary'>
<table caption='Architectural Terms'>
@ -107,7 +107,7 @@
</tr>
<tr>
<td>Gateway</td>
<td>A service on the Jabber network that translates between the Jabber/XMPP protocols and the protocol used by a Legacy Service; in the context of this JEP, by "gateway" we mean a "client proxy service" that acts as a client with regard to a Legacy Service and thereby "masquerades" as a user on such a service.</td>
<td>A service on the Jabber network that translates between the Jabber/XMPP protocols and the protocol used by a Legacy Service; in the context of this document, by "gateway" we mean a "client proxy service" that acts as a client with regard to a Legacy Service and thereby "masquerades" as a user on such a service.</td>
</tr>
<tr>
<td>Jabber User</td>
@ -128,7 +128,7 @@
</table>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>The requirements defined by this JEP are captured in two sets of use cases: one set from the perspective of the Jabber User, and a smaller set from the perspective of the Legacy User who wants to interact with the Jabber User.</p>
<p>The requirements defined by this document are captured in two sets of use cases: one set from the perspective of the Jabber User, and a smaller set from the perspective of the Legacy User who wants to interact with the Jabber User.</p>
<p>The Jabber User use cases are:</p>
<ol>
<li>Register</li>
@ -146,7 +146,7 @@
<li>Delete Contact</li>
<li>Send Message</li>
</ol>
<p>While more advanced use cases (e.g., sending files and joining chat rooms) are of inherent interest, they are not covered in this JEP because registration, contact list management, and message exchange define the baseline functionality included in all gateway implementations; future JEPs may address the more advanced use cases.</p>
<p>While more advanced use cases (e.g., sending files and joining chat rooms) are of inherent interest, they are not covered in this document because registration, contact list management, and message exchange define the baseline functionality included in all gateway implementations; future specifications may address the more advanced use cases.</p>
</section1>
<section1 topic='Jabber User Use Cases' anchor='usecases-jabber'>
<section2 topic='Register' anchor='usecases-jabber-register'>
@ -154,7 +154,7 @@
<section3 topic='Primary Flow' anchor='usecases-jabber-register-pri'>
<ol>
<li>
<p>Jabber User sends IQ-get qualified by the &jep0030; information namespace to the Gateway, and/or IQ-get qualified by the &jep0094; namespace to the Gateway's parent (the latter method is deprecated but still in use).</p>
<p>Jabber User sends IQ-get qualified by the &xep0030; information namespace to the Gateway, and/or IQ-get qualified by the &xep0094; namespace to the Gateway's parent (the latter method is deprecated but still in use).</p>
<example caption="User Queries Gateway Regarding Service Discovery Identity"><![CDATA[
<iq type='get'
from='romeo@montague.net/orchard'
@ -209,7 +209,7 @@
<p>Note: Given the foregoing, a client can determine the identity of the gateway, specifically (1) that it is a gateway and (2) to which legacy service it provides a gateway.</p>
</li>
<li>
<p>Jabber User sends IQ-get qualified by the &jep0077; (jabber:iq:register) namespace to Gateway.</p>
<p>Jabber User sends IQ-get qualified by the &xep0077; (jabber:iq:register) namespace to Gateway.</p>
<example caption="User Queries Gateway Regarding Registration Requirements"><![CDATA[
<iq type='get'
from='romeo@montague.net/orchard'
@ -320,7 +320,7 @@
<li><p>User information not verified:
<ol>
<li>
<p>Gateway returns &notacceptable; error to Jabber User. (For detailed information regarding error conditions, refer to &jep0086;.)</p>
<p>Gateway returns &notacceptable; error to Jabber User. (For detailed information regarding error conditions, refer to &xep0086;.)</p>
<example caption="Gateway Informs Jabber User of Registration Error"><![CDATA[
<iq type='error'
from='aim.shakespeare.lit'
@ -708,7 +708,7 @@
</section3>
</section2>
<section2 topic='Send Message' anchor='usecases-jabber-send'>
<p>Naturally, the Jabber User may want to exchange messages with a Legacy User. For the purposes of this JEP, we discuss one-to-one messaging only (i.e., groupchat messages, such as those defined in &jep0045;, are out of scope).</p>
<p>Naturally, the Jabber User may want to exchange messages with a Legacy User. For the purposes of this document, we discuss one-to-one messaging only (i.e., groupchat messages, such as those defined in &xep0045;, are out of scope).</p>
<section3 topic='Primary Flow' anchor='usecases-jabber-send-pri'>
<ol>
<li>
@ -872,7 +872,7 @@
<p>Unfortunately, usernames on some Legacy Services may allow characters that are disallowed in Jabber usernames as specified by the Nodeprep profile of stringprep defined in <cite>RFC 3920</cite>. For example, the usernames for a Legacy Service may be of the form &lt;user@domain&gt;, which would result in an illegal JID such as &lt;user@domain@gateway.example.com&gt;.</p>
<p>There are two possible ways to solve this problem:</p>
<ol>
<li>Use &jep0106;.</li>
<li>Use &xep0106;.</li>
<li>Use the older 'jabber:iq:gateway' protocol (as documented in the following section).</li>
</ol>
<p>Gateways and clients SHOULD implement at least one of these protocols; at a minimum, it is RECOMMENDED for gateways and clients to implement the 'jabber:iq:gateway' protocol.</p>
@ -952,7 +952,7 @@
</section2>
</section1>
<section1 topic='Contact Lists' anchor='rosters'>
<p>Some legacy services maintain server-side contact lists, which are sent to the gateway when it logs in to the legacy service on behalf of the user. The gateway MAY initiate adding of the legacy contact list items to the user's Jabber roster. Some existing gateways do this by sending a presence stanza of type "subscribed" from the legacy contact's JID (e.g., &lt;LegacyUser@gateway.jabberserver.com&gt;) to the Jabber user; unfortunately, this behavior violates the presence stanza handling rules specified in <cite>RFC 3921</cite>. Therefore, a gateway SHOULD instead send the legacy contact list items to the Jabber User via the &jep0144; protocol.</p>
<p>Some legacy services maintain server-side contact lists, which are sent to the gateway when it logs in to the legacy service on behalf of the user. The gateway MAY initiate adding of the legacy contact list items to the user's Jabber roster. Some existing gateways do this by sending a presence stanza of type "subscribed" from the legacy contact's JID (e.g., &lt;LegacyUser@gateway.jabberserver.com&gt;) to the Jabber user; unfortunately, this behavior violates the presence stanza handling rules specified in <cite>RFC 3921</cite>. Therefore, a gateway SHOULD instead send the legacy contact list items to the Jabber User via the &xep0144; protocol.</p>
</section1>
<section1 topic='Business Rules' anchor='bizrules'>
<p>The following business rules apply:</p>
@ -963,7 +963,7 @@
<li><p>A gateway SHOULD map, as best it can, the legacy registration fields onto the fields defined for the 'jabber:iq:register' namespace.</p></li>
<li><p>A gateway SHOULD NOT attempt to emulate offline message storage functionality for legacy services that lack such functionality.</p></li>
<li>
<p>Existing gateway implementations do not strictly adhere to the bi-directional nature of Jabber presence notifications, since they do not broadcast presence from the gateway itself to registered users of the gateway, but rather wait for a registered user to send presence to the gateway before sending presence to the user. This sidesteps scalability challenges but may be sub-optimal; while this JEP does not require existing gateways to change their current behavior, it does RECOMMEND that they broadcast presence notifications to registered users in accordance with the standard Jabber presence model. Specifically:</p>
<p>Existing gateway implementations do not strictly adhere to the bi-directional nature of Jabber presence notifications, since they do not broadcast presence from the gateway itself to registered users of the gateway, but rather wait for a registered user to send presence to the gateway before sending presence to the user. This sidesteps scalability challenges but may be sub-optimal; while this document does not require existing gateways to change their current behavior, it does RECOMMEND that they broadcast presence notifications to registered users in accordance with the standard Jabber presence model. Specifically:</p>
<ul>
<li><p>On startup, a gateway (1) SHOULD send presence to all registered users of that gateway but (2) MAY wait to receive presence changes from each registered user.</p></li>
<li><p>On shutdown, a gateway SHOULD send unavailable presence to all registered users of the gateway.</p></li>
@ -986,9 +986,9 @@
<p>There is no foreseeable solution to these concerns, since they are instrinsic to the client proxy model. Some assurance regarding the second and third concerns can be achieved if the user runs his or her own Jabber server and gateways. However, the only true solution is to move beyond the client proxy model, either by using Jabber for all IM communications or to convince legacy IM services to allow federated server-to-server communications using open protocols such as Jabber/XMPP, thus obviating the need for client proxy gateways entirely.</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 'jabber:iq:gateway' in its registry of protocol namespaces.</p>
</section2>
@ -1006,7 +1006,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0100: http://www.jabber.org/jeps/jep-0100.html
XEP-0100: http://www.xmpp.org/extensions/xep-0100.html
</xs:documentation>
</xs:annotation>
@ -1025,4 +1025,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

18
xep-0101.xml
View File

@ -1,19 +1,19 @@
<?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>HTTP Authentication using Jabber Tickets</title>
<abstract>This JEP defines a protocol for authenticating HTTP requests using Jabber Tickets.</abstract>
<abstract>This document defines a protocol for authenticating HTTP requests using Jabber Tickets.</abstract>
&LEGALNOTICE;
<number>0101</number>
<status>Deferred</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<dependencies>RFC 2616, RFC 2617, JEP-0030</dependencies>
<dependencies>RFC 2616, RFC 2617, XEP-0030</dependencies>
<dependencies>
<spec>XMPP Core</spec>
<spec>RFC 2616</spec>
@ -47,7 +47,7 @@
<p>Tickets also mean the jabber ticket provider and the web server do not need to be tightly integrated for authentication to work, also because its not tightly integrated it means webmasters do not need to setup their own jabber server to provide tickets, they can use a third party provider even a central "tickets.jabber.org". Also because tickets are not tightly integrated it makes it far easier for webmasters to integrate with Jabber, it also makes web farms far more scalable and reliable.</p>
</section1>
<section1 topic='Requirements'>
<p>The motivations for this JEP are:</p>
<p>The motivations for this document are:</p>
<ul>
<li>To provide a method of using a jabber connections authenticated stream to provide a method of authenticating with an HTTP server.</li>
<li>To provide this authentication without needing the jabber ticket component and the webserver to be tightly coupled, this is essential in a web farm environment for scalability.</li>
@ -118,7 +118,7 @@ Content-Type: text/html]]></example>
<section1 topic='IANA Considerations'>
<p>The HTTP authentication scheme "JabberTicket" may need to be registered with IANA.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<section1 topic='XMPP Registrar Considerations'>
<p>The &REGISTRAR; will need to register the new namespace of "http://jabber.org/protocol/ticket".</p>
</section1>
</jep>
</xep>

10
xep-0102.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0'?>
<!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>Security Extensions</title>
<abstract>Security extensions for Jabber/XMPP.</abstract>
@ -1686,4 +1686,4 @@ B1D510BD 7EE74D73 FAF36BC3 1ECFA268 359046F4 EB879F92
<p>The generator is: 2. </p>
</section2>
</section1>
</jep>
</xep>

34
xep-0103.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>URL Address Information</title>
<abstract>This JEP defines a structure for providing information about an Uniform Resource Locator (URL), and a protocol signaling retrieval states.</abstract>
<abstract>This document defines a structure for providing information about an Uniform Resource Locator (URL), and a protocol signaling retrieval states.</abstract>
&LEGALNOTICE;
<number>0103</number>
<status>Deferred</status>
@ -15,7 +15,7 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0095</spec>
<spec>XEP-0095</spec>
<spec>RFC 3986</spec>
</dependencies>
<supersedes/>
@ -54,14 +54,14 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>As Jabber becomes more widely utilized, applications of the protocol are veering away from traditional use as an IM product and are utilizing it for more generic data transportation and negotiation. While many advances are being made to facilitate non-IM data transportation, they do not address the use of already-established mechanisms of transporting data via URLs. This JEP provides a method that is compatible with these data transportation mechanisms and that is based on standard Internet Uniform Resource Locators (see &rfc3986;).</p>
<p>As Jabber becomes more widely utilized, applications of the protocol are veering away from traditional use as an IM product and are utilizing it for more generic data transportation and negotiation. While many advances are being made to facilitate non-IM data transportation, they do not address the use of already-established mechanisms of transporting data via URLs. This document provides a method that is compatible with these data transportation mechanisms and that is based on standard Internet Uniform Resource Locators (see &rfc3986;).</p>
</section1>
<section1 topic='Requirements'>
<p>The requirements this protocol fulfills are:</p>
<ul>
<li>Simple usage that can be easily extended</li>
<li>Provide any meta-data necessary for using the URL</li>
<li>Compatibility with &jep0095;</li>
<li>Compatibility with &xep0095;</li>
</ul>
</section1>
<section1 topic='Use Cases'>
@ -76,7 +76,7 @@
target='http://festhall.outer-planes.net/d20M/announce/latest/'/>
</message>
]]></example>
<p>If more information is necessary for successfully using the URL, the sender includes meta-information in a scheme-specific format such as that defined in &jep0104;:</p>
<p>If more information is necessary for successfully using the URL, the sender includes meta-information in a scheme-specific format such as that defined in &xep0104;:</p>
<example caption='Exchanging a HTTP URL with Headers'><![CDATA[
<message from='d20M@festhall.outer-planes.net'
to='linuxwolf@outer-planes.net'>
@ -90,7 +90,7 @@
</message>
]]></example>
<p>The above example illustrates supplying a HTTP URL with a cookie header. Additional information could be provided, such as HTTP authentication requirements or even POST data.</p>
<p>To support the use of bulk publishing methods such as &jep0060; or messages of type "headline", the &lt;desc/&gt; element is used to provide a textual description:</p>
<p>To support the use of bulk publishing methods such as &xep0060; or messages of type "headline", the &lt;desc/&gt; element is used to provide a textual description:</p>
<example caption='&MESSAGE; Headines'><![CDATA[
<message
from='d20M@festhall.outer-planes.net'
@ -123,7 +123,7 @@
</section2>
<section2 topic='SI Usage'>
<p>To use "url-data" in conjunction with SI, the "sid" attribute of &lt;url-data/&gt; is used. This attribute MUST be equal to the SI session id.</p>
<p>The general process flow for using "url-data" with SI is as follows<note>The error conditions for SI are fully-documented in that JEP, and are therefore not included here.</note>:</p>
<p>The general process flow for using "url-data" with SI is as follows<note>The error conditions for SI are fully-documented in that document, and are therefore not included here.</note>:</p>
<ol>
<li>The sender makes a SI request, adding "http://jabber.org/protocols/url-data" as one of the "stream-method" features.</li>
<li>The receiver accepts the SI request, and selects "http://jabber.org/protocols/url-data".</li>
@ -135,7 +135,7 @@
<li><b>E1:</b> The given URL is not supported/understood</li>
<li><b>E2:</b> Failure to connect to the given URL</li>
</ul>
<p>The sender starts with an SI request, using the semantics from JEP-0095:</p>
<p>The sender starts with an SI request, using the semantics from XEP-0095:</p>
<example caption='Requesting SI transfer'><![CDATA[
<iq type='set' id='offer1' to='receiver@jabber.org/resource'>
<si xmlns='http://jabber.org/protocol/si'
@ -324,12 +324,12 @@
</section2>
</section1>
<section1 topic='Security Considerations'>
<p>This JEP does not yet have any security considerations.</p>
<p>This document does not yet have any security considerations.</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 namespace "http://jabber.org/protocol/url-data" as a standard namespace. Also, the Jabber Registrar shall register the &jep0020; option "url-data" for use with Stream Initiation.</p>
<section1 topic='XMPP Registrar Considerations'>
<p>The &REGISTRAR; shall register the namespace "http://jabber.org/protocol/url-data" as a standard namespace. Also, the XMPP Registrar shall register the &xep0020; option "url-data" for use with Stream Initiation.</p>
</section1>
</jep>
</xep>

30
xep-0104.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>HTTP Scheme for URL Data</title>
<abstract>This JEP provides a schema description for detailed information about HTTP URLs.</abstract>
<abstract>This document provides a schema description for detailed information about HTTP URLs.</abstract>
&LEGALNOTICE;
<number>0104</number>
<status>Deferred</status>
@ -18,7 +18,7 @@
<spec>RFC 3986</spec>
<spec>RFC 2616</spec>
<spec>RFC 2617</spec>
<spec>JEP-0103</spec>
<spec>XEP-0103</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -33,7 +33,7 @@
<version>0.3</version>
<date>2004-01-20</date>
<initials>lw</initials>
<remark>Reorganized for JEP Editor preferences; Removed (outdated) references to JEP-0070</remark>
<remark>Reorganized for JEP Editor preferences; Removed (outdated) references to XEP-0070</remark>
</revision>
<revision>
<version>0.2</version>
@ -49,22 +49,22 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>The most common URL scheme distributed over the Internet is HTTP and HTTPS. This JEP defines a structure that extends &jep0103; to enable more advanced access to such URLs within Jabber.</p>
<p>The most common URL scheme distributed over the Internet is HTTP and HTTPS. This document defines a structure that extends &xep0103; to enable more advanced access to such URLs within Jabber.</p>
</section1>
<section1 topic='Requirements'>
<p>This JEP supplements JEP-0103 to provide more detailed information about HTTP and HTTPS URLs. The requirements this JEP fulfills are:</p>
<p>This document supplements XEP-0103 to provide more detailed information about HTTP and HTTPS URLs. The requirements this document fulfills are:</p>
<ul>
<li>Provide authentication information.</li>
<li>Provide cookie data.</li>
<li>Provide necessary headers.</li>
</ul>
<p>The intent of this information is to provide an HTTP client with enough information in order to construct the HTTP request and entity headers necessary, as defined in &rfc2616;.</p>
<p>The use of this JEP in conjunction with JEP-0103 is OPTIONAL. The entity sending the URL is not required to provide any of this information, and receiving entities MAY ignore it.</p>
<p>The use of this document in conjunction with XEP-0103 is OPTIONAL. The entity sending the URL is not required to provide any of this information, and receiving entities MAY ignore it.</p>
</section1>
<section1 topic='Basic Usage'>
<p>The two most typical types of information that can be necessary for accessing an HTTP URL are authentication details and cookies. In some cases, custom headers MAY also be necessary for successful use. Authentication information is provided in a scheme-independent format. Cookie data provided includes what would be necessary for a client to properly persist the value.</p>
<section2 topic='Providing Authentication'>
<p>At a minimum, this JEP allows for an entity to indicate what authentication scheme is in use:</p>
<p>At a minimum, this document allows for an entity to indicate what authentication scheme is in use:</p>
<example caption='Indicating auth scheme'><![CDATA[
<message to='client@domain.com'>
<url-data xmlns='http://jabber.org/protocol/url-data'
@ -227,13 +227,13 @@
</section1>
<section1 topic='Security Considerations'>
<section2 topic='Authentication Information'>
<p>This JEP allows complete authentication information to be passed. This information is only as secure as the connection-path between the provider and acceptor.</p>
<p>This document allows complete authentication information to be passed. This information is only as secure as the connection-path between the provider and acceptor.</p>
</section2>
</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'>
<section1 topic='XMPP Registrar Considerations'>
<p>The &REGISTRAR; shall register the "http://jabber.org/protocol/url-data/scheme/http" namespace.</p>
</section1>
</jep>
</xep>

24
xep-0105.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>Tree Transfer Stream Initiation Profile</title>
<abstract>A profile describing meta-data for transferring trees of files using stream inititation.</abstract>
@ -13,7 +13,7 @@
<status>Deferred</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<dependencies>JEP-0095, JEP-0096</dependencies>
<dependencies>XEP-0095, XEP-0096</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<shortname>si-treetransfer</shortname>
@ -54,14 +54,14 @@
</section1>
<section1 topic='Usage'>
<p>The tree transfer profile is in the "http://jabber.org/protocol/si/profile/tree-transfer" namespace. The profile is fairly simple: it consists of the root element with child elements that specify a directory structure of files with stream ids that will be used for each file.</p>
<p>This profile requires support for the File Transfer profile described in &jep0096;. Once you have accepted this SI, a new SI using the File Transfer profile will be offered for each file in the tree. This profile provides a mapping of files with paths and reserved stream ids which will be used to auto-accept a File Transfer SI that uses that same stream id from the sender.</p>
<p>This profile requires support for the File Transfer profile described in &xep0096;. Once you have accepted this SI, a new SI using the File Transfer profile will be offered for each file in the tree. This profile provides a mapping of files with paths and reserved stream ids which will be used to auto-accept a File Transfer SI that uses that same stream id from the sender.</p>
<p>The root element is &lt;tree&gt; and has two attributes. The attributes are used only during the offer stage of stream initiation:</p>
<ul>
<li><em>size</em> - The size, in bytes, of all of the files to be sent.</li>
<li><em>numfiles</em> - The number of files/File Transfer SIs that are in the tree.</li>
</ul>
<p>The <em>size</em> and <em>numfiles</em> attributes MUST be present in the profile.</p>
<p>The only possible child element of the root is &lt;directory/&gt; since there are other JEPs that handle single file transfers. The directory structure is sent in a hierarchical manner with nested &lt;directory/&gt; and/or &lt;file/&gt; tags. One or more &lt;file/&gt; elements will be sent, one for each file. One or more &lt;directory/&gt; elements will be sent, one for each directory.</p>
<p>The only possible child element of the root is &lt;directory/&gt; since there are other specifications that handle single file transfers. The directory structure is sent in a hierarchical manner with nested &lt;directory/&gt; and/or &lt;file/&gt; tags. One or more &lt;file/&gt; elements will be sent, one for each file. One or more &lt;directory/&gt; elements will be sent, one for each directory.</p>
<p>The &lt;directory/&gt; element has one attribute:</p>
<ul>
<li><em>name</em> - The name of the directory to create on the target system.</li>
@ -74,7 +74,7 @@
</ul>
<p>Both attributes are REQUIRED on each &lt;file/&gt; element. The total number of &lt;file&gt; elements MUST equal the numfiles attribute sent in the &lt;tree/&gt; element.</p>
<p>The stream-method that is accepted for a Tree Profile SI MUST be remembered and the subsequent File Transfer SIs MUST NOT provide a Feature Negotiation packet. The stream-method has already been chosen and should be used for all of the streams.</p>
<p>Implementations of this profile MUST support &jep0095; and JEP-0096.</p>
<p>Implementations of this profile MUST support &xep0095; and XEP-0096.</p>
</section1>
<section1 topic='Examples'>
<example caption='Profile Usage in Stream Initiation Offer'><![CDATA[
@ -148,12 +148,12 @@
</section1>
<section1 topic='IANA Considerations'>
<p>
No interaction with &IANA; is required as a result of this JEP.
No interaction with &IANA; is required as a result of this document.
</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<section1 topic='XMPP Registrar Considerations'>
<p>
The profile described in this JEP will be registered with &REGISTRAR; as a valid Stream
The profile described in this document will be registered with &REGISTRAR; as a valid Stream
Initiation profile.
</p>
</section1>
@ -193,4 +193,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

30
xep-0106.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>JID Escaping</title>
<abstract>This JEP specifies a mechanism that enables the display of Jabber Identifiers (JIDs) with characters disallowed by the Nodeprep profile of stringprep.</abstract>
<abstract>This document specifies a mechanism that enables the display of Jabber Identifiers (JIDs) with characters disallowed by the Nodeprep profile of stringprep.</abstract>
&LEGALNOTICE;
<number>0106</number>
<status>Draft</status>
@ -15,7 +15,7 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0030</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
@ -90,7 +90,7 @@
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>This JEP addresses the following requirements:</p>
<p>This document addresses the following requirements:</p>
<ol>
<li>The escaping mechanism shall apply to the node identitier portion of a JID only, and MUST NOT be applied to domain identifiers or resource identifiers.</li>
<li>Escaped JIDs MUST conform to the definition of a Jabber ID as specified in <cite>RFC 3920</cite>, including the Nodeprep profile of stringprep. In particular this means that even after passing through Nodeprep, the JID MUST be valid, with the result that Unicode look-alikes like U+02BC (Modifier Letter Apostrophe) MUST NOT be used.</li>
@ -102,7 +102,7 @@
</section1>
<section1 topic='Discovery' anchor='discovery'>
<p>If an entity needs to discover whether another entity supports JID escaping, it MUST send a disco#info request to the other entity as specified in &jep0030;.</p>
<p>If an entity needs to discover whether another entity supports JID escaping, it MUST send a disco#info request to the other entity as specified in &xep0030;.</p>
<example caption='Client requests features'><![CDATA[
<iq type='get'
from='porthos@musketeers.bourbon.gov/gate'
@ -127,7 +127,7 @@
<section1 topic='Transformations' anchor='transforms'>
<section2 topic='Concepts' anchor='concepts'>
<p>This JEP specifies encoding each disallowed character as \hexhex -- where "hexhex" is the hexadecimal value of the Unicode code point in question, ignoring the leading "00" in the code point (e.g., 27 for the ' character, resulting in an encoding of \27). (Note: This escaping method is quite similar to that used for disallowed characters in LDAP distinguished names, as specified in &rfc2253;.) Full encoding and decoding transformations for all nine disallowed characters are provided in the following sections. In addition, encoding and decoding transformations are shown for the \ character in case it needs to be "double-escaped" when it occurs in a non-XMPP address as part of a string that corresponds to one of the other encoded characters.</p>
<p>This document specifies encoding each disallowed character as \hexhex -- where "hexhex" is the hexadecimal value of the Unicode code point in question, ignoring the leading "00" in the code point (e.g., 27 for the ' character, resulting in an encoding of \27). (Note: This escaping method is quite similar to that used for disallowed characters in LDAP distinguished names, as specified in &rfc2253;.) Full encoding and decoding transformations for all nine disallowed characters are provided in the following sections. In addition, encoding and decoding transformations are shown for the \ character in case it needs to be "double-escaped" when it occurs in a non-XMPP address as part of a string that corresponds to one of the other encoded characters.</p>
<p>Note: All transformations are exactly as specified below. CASE IS SIGNIFICANT. Lowercase was selected since Nodeprep will case fold to lowercase for US-ASCII characters such as A, C, E, and F.</p>
</section2>
<section2 topic='Encoding Transformation' anchor='encoding'>
@ -211,7 +211,7 @@
<section2 topic='JID Escaping vs. Older Methods' anchor='bizrules-othermethods'>
<p>When a client attempts to communicate with another entity through a gateway, it needs to know which encoding mechanism to use. A client MUST assume that the gateway does not support the JID escaping mechanism unless it explicitly discovers support for the <strong>jid\20escaping</strong> [sic] feature via Service Discovery as shown above. If there any errors in the service discovery exchange or if support for JID escaping is not discovered, the client SHOULD proceed as follows:</p>
<ol>
<li>If the gateway supports the 'jabber:iq:gateway' protocol (as specified in &jep0100;), use that protocol.</li>
<li>If the gateway supports the 'jabber:iq:gateway' protocol (as specified in &xep0100;), use that protocol.</li>
<li>If the gateway does not support the 'jabber:iq:gateway' protocol, use customary escaping mechanisms (such as transformation of the @ character to the % character).</li>
</ol>
</section2>
@ -332,7 +332,7 @@ here\27s_a_wild_\26_\2fcr%zy\2f_address_for\3a\3cwv\3e(\22IMPS\22)@example.com
here's_a_wild_&_/cr%zy/_address_for:<wv>("IMPS")@example.com
]]></example>
<p>Unlike the foregoing address types, IMPS addresses are allowed to contain backslashes. This implies that it is possible for an IMPS address to contain a string that corresponds to one of the encoded character representations for code points that are disallowed in XMPP node identifiers. An example would be the IMPS address &lt;wv:\3and\2is\5@example.com&gt;, where the string "\3a" could be interpreted as the : character if that IMPS address is directly converted into a JID. Therefore, the leading \ character MUST be transformed to "\5c" in order to avoid possible ambiguity. Thus the transformed JID would be &lt;\5c3and\2is\5@example.com&gt;, which would be presented to a user as &lt;\3and\2is\5@example.com&gt;.</p>
<p>If an IMPS address contains a private resource, a gateway between XMPP and IMPS should process the resource and append it to the end of the JID; however, such gateway behavior is out of scope for this JEP.</p>
<p>If an IMPS address contains a private resource, a gateway between XMPP and IMPS should process the resource and append it to the end of the JID; however, such gateway behavior is out of scope for this document.</p>
<p>The foregoing example showed how to transform a wv: URI into a JID. However, it also may be necessary to convert a JID into a wv: URI, as shown in the following example.</p>
<example caption='User Enters Address, Including Disallowed Characters'><![CDATA[
here's_a_wild_&_/cr%zy/_address_for:<wv>("IMPS")@example.com
@ -361,7 +361,7 @@ CN=D\27Artagnan\20Saint-Andr\E9,O=Example\20\26\20Company,\20Inc.,DC=example,DC=
<example caption='The JID as Presented to a User'>
CN=D'Artagnan Saint-Andr&#xe9;,O=Example &amp; Company, Inc.,DC=example,DC=com@st.example.com
</example>
<p>Naturally, a more intelligent gateway could use the Domain Components to construct a more readable JID, such as &lt;D\27Artagnan\20Saint-Andr&#xe9;@example.com&gt;; however, such gateway behavior is out of scope for this JEP.</p>
<p>Naturally, a more intelligent gateway could use the Domain Components to construct a more readable JID, such as &lt;D\27Artagnan\20Saint-Andr&#xe9;@example.com&gt;; however, such gateway behavior is out of scope for this document.</p>
<p>The foregoing example showed how to transform an LDAP distinguished name into a JID. However, it also may be necessary to convert a JID into an LDAP distinguished name, as shown in the following example.</p>
<example caption='User Enters Address, Including Disallowed Characters'><![CDATA[
CN=D'Artagnan Saint-Andr&#xe9;,O=Example &amp; Company, Inc.,DC=example,DC=com@st.example.com
@ -384,13 +384,13 @@ CN=D'Artagnan Saint-Andr&#xe9;,O=Example &amp; Company, Inc.,DC=example,DC=com
</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='Service Discovery Features' anchor='registrar-features'>
<p>The &REGISTRAR; includes the <strong>jid\20escaping</strong> [sic] feature in its registry of service discovery features.</p>
</section2>
</section1>
</jep>
</xep>

26
xep-0107.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>User Mood</title>
<abstract>This JEP defines a protocol for communicating information about user moods.</abstract>
@ -15,13 +15,13 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0060</spec>
<spec>XEP-0060</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>mood</shortname>
<schemaloc>
<url>http://jabber.org/protocol/mood/mood.xsd</url>
<url>http://www.xmpp.org/schemas/mood.xsd</url>
</schemaloc>
&stpeter;
&ralphm;
@ -41,7 +41,7 @@
<version>0.5</version>
<date>2004-04-25</date>
<initials>psa</initials>
<remark>Corrected several errors; added reference to JEP-0033.</remark>
<remark>Corrected several errors; added reference to XEP-0033.</remark>
</revision>
<revision>
<version>0.4</version>
@ -91,7 +91,7 @@
]]></code>
</section2>
<section2 topic='Pubsub Transport' anchor='proto-pubsub'>
<p>The &lt;mood/&gt; element SHOULD be communicated by means of &jep0060; but MAY be provided in a message as well. Because mood information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.</p>
<p>The &lt;mood/&gt; element SHOULD be communicated by means of &xep0060; but MAY be provided in a message as well. Because mood information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.</p>
<p>If the user wishes to publish his mood to all of those who are subscribed to his mood information, the user SHOULD use publish-subscribe.</p>
<example caption='User Publishes Mood'><![CDATA[
<iq type='set'
@ -130,7 +130,7 @@
.
.
]]></example>
<p>As mentioned in JEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &jep0033; protocol) to provide an explicit association between the published data and the user:</p>
<p>As mentioned in XEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &xep0033; protocol) to provide an explicit association between the published data and the user:</p>
<example caption='Event notification with extended stanza addressing'><![CDATA[
<message
from='pubsub.shakespeare.lit'
@ -163,7 +163,7 @@
</mood>
</message>
]]></example>
<p>The &lt;mood/&gt; element could even contain a URL reference structured according to the &jep0066; protocol:</p>
<p>The &lt;mood/&gt; element could even contain a URL reference structured according to the &xep0066; protocol:</p>
<example caption='User Provides Mood and URL in Message'><![CDATA[
<message from='ralphm@ik.nu/work'
to='stpeter@jabber.org/home'
@ -173,7 +173,7 @@
<happy/>
<text>Yay, the mood JEP has been published!</text>
<x xmlns='jabber:x:oob'>
<url>http://www.jabber.org/jeps/jep-0107.html</url>
<url>http://www.xmpp.org/extensions/xep-0107.html</url>
</x>
</mood>
</message>
@ -273,7 +273,7 @@
<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 'http://jabber.org/protocol/mood' in its registry of protocol namespaces.</p>
</section2>
@ -368,4 +368,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

28
xep-0108.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>User Activity</title>
<abstract>This JEP defines a protocol for communicating information about user activities.</abstract>
<abstract>This document defines an XMPP protocol extension for communicating information about user activities.</abstract>
&LEGALNOTICE;
<number>0108</number>
<status>Draft</status>
@ -15,13 +15,13 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0060</spec>
<spec>XEP-0060</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>activity</shortname>
<schemaloc>
<url>http://jabber.org/protocol/activity/activity.xsd</url>
<url>http://www.xmpp.org/schemas/activity/activity.xsd</url>
</schemaloc>
&ralphm;
&stpeter;
@ -41,7 +41,7 @@
<version>0.3</version>
<date>2004-04-25</date>
<initials>psa</initials>
<remark>Corrected several errors; added reference to JEP-0033.</remark>
<remark>Corrected several errors; added reference to XEP-0033.</remark>
</revision>
<revision>
<version>0.2</version>
@ -57,7 +57,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>This JEP defines an extension mechanism for capturing "extended presence" data about user activities, above and beyond availability as defined in &xmppim; (e.g., the 'away', 'extended away', and 'dnd' values of the &lt;show/&gt; child of the &lt;presence/&gt; stanza).</p>
<p>This document defines an extension mechanism for capturing "extended presence" data about user activities, above and beyond availability as defined in &xmppim; (e.g., the 'away', 'extended away', and 'dnd' values of the &lt;show/&gt; child of the &lt;presence/&gt; stanza).</p>
</section1>
<section1 topic='Protocol' anchor='proto'>
<section2 topic='Data Format' anchor='proto-format'>
@ -91,7 +91,7 @@
<p>In accordance with &xmppcore;, the receiving application MUST ignore a specific activity element or detailed activity element if it does not understand the namespace that qualifies the element.</p>
</section2>
<section2 topic='Pubsub Transport' anchor='proto-pubsub'>
<p>The &lt;activity/&gt; element SHOULD be communicated by means of &jep0060;. Because activity information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.</p>
<p>The &lt;activity/&gt; element SHOULD be communicated by means of &xep0060;. Because activity information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.</p>
<example caption='User Publishes Activity'><![CDATA[
<iq type='set'
from='juliet@capulet.com/balcony'
@ -133,7 +133,7 @@
.
.
]]></example>
<p>As mentioned in JEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &jep0033; protocol) to provide an explicit association between the published data and the user:</p>
<p>As mentioned in XEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &xep0033; protocol) to provide an explicit association between the published data and the user:</p>
<example caption='Event notification with extended stanza addressing'><![CDATA[
<message
from='pubsub.shakespeare.lit'
@ -365,9 +365,9 @@
<p>Because user activities may be published to a large number of pubsub subscribers, users should take care in approving subscribers and in characterizing their current activities.</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 'http://jabber.org/protocol/activity' in its registry of protocol namespaces.</p>
</section2>
@ -480,4 +480,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

22
xep-0109.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>Vacation Messages</title>
<abstract>A protocol for setting up vacation messages in Jabber.</abstract>
@ -13,7 +13,7 @@
<status>Deferred</status>
<type>Informational</type>
<jig>Standards JIG</jig>
<dependencies>JEP-0030, JEP-0082</dependencies>
<dependencies>XEP-0030, XEP-0082</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<shortname>vacation</shortname>
@ -60,7 +60,7 @@
<section2 topic='Discovering support for vacation messages'>
<p>Before attempting to set or retrieve its current vacation settings, a user SHOULD first verify that their server supports vacation messages. To do this, the user makes a &jep0030; "#info" query to their server. If supported, the server includes a feature of "http://www.jabber.org/protocol/vacation" in the result.</p>
<p>Before attempting to set or retrieve its current vacation settings, a user SHOULD first verify that their server supports vacation messages. To do this, the user makes a &xep0030; "#info" query to their server. If supported, the server includes a feature of "http://www.jabber.org/protocol/vacation" in the result.</p>
<example caption='Discovering support for vacation messages'><![CDATA[
<iq type='get' to='cataclysm.cx' id='disco1'>
@ -102,7 +102,7 @@
</iq>
]]></example>
<p>&lt;start/> and &lt;end/> define the times between which this vacation message is valid. These are in the format specified by &jep0082;.</p>
<p>&lt;start/> and &lt;end/> define the times between which this vacation message is valid. These are in the format specified by &xep0082;.</p>
<p>&lt;message/> contains the text of the message that will be sent to a remote user that sends the user a message while they have active vacation settings.</p>
<p>If the user has no stored vacation settings, the user will receive a result like the following:</p>
@ -166,10 +166,10 @@
<p>None yet defined.</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 'http://jabber.org/protocol/vacation' namespace shall be registered with the &REGISTRAR; as a result of this JEP.</p>
<section1 topic='XMPP Registrar Considerations'>
<p>The 'http://jabber.org/protocol/vacation' namespace shall be registered with the &REGISTRAR; as a result of this document.</p>
</section1>
<section1 topic='XML Schema'>
@ -200,4 +200,4 @@
]]></code>
</section1>
</jep>
</xep>