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@38 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-10-04 02:38:14 +00:00
parent 39e3ea4b7d
commit b09e9759ee
10 changed files with 135 additions and 137 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
xep-0090.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>Entity Time</title>
<abstract>This JEP provides canonical documentation of the existing 'jabber:iq:time' namespace currently used within the Jabber community.</abstract>
<abstract>This document provides canonical documentation of the existing 'jabber:iq:time' namespace currently used within the Jabber community.</abstract>
&LEGALNOTICE;
<number>0090</number>
<status>Active</status>
@ -20,7 +20,7 @@
<supersededby/>
<shortname>iq-time</shortname>
<schemaloc>
<url>http://jabber.org/protocol/iq-time/iq-time.xsd</url>
<url>http://www.xmpp.org/schemas/iq-time.xsd</url>
</schemaloc>
&stpeter;
<revision>
@ -37,7 +37,7 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>The Jabber protocols have long included a method for discovering the time at another entity's location. This method makes use of the 'jabber:iq:time' namespace and has been documented variously in Internet-Drafts and elsewhere. Because this protocol is not required by &rfc2779;, the 'jabber:iq:time' namespace was removed from &xmppim;. This JEP fills the void for canonical documentation.</p>
<p>The Jabber protocols have long included a method for discovering the time at another entity's location. This method makes use of the 'jabber:iq:time' namespace and has been documented variously in Internet-Drafts and elsewhere. Because this protocol is not required by &rfc2779;, the 'jabber:iq:time' namespace was removed from &xmppim;. This specification fills the void for canonical documentation.</p>
</section1>
<section1 topic='Definition'>
<p>The 'jabber:iq:time' namespace provides a standard way for Jabber entities to exchange information about the local time (e.g., to "ping" another entity or check network latency). The information is communicated in a request/response pair using an &IQ; element that contains a &QUERY; scoped by the 'jabber:iq:time' namespace. The following children of the &QUERY; element are allowed in an IQ result:</p>
@ -68,18 +68,18 @@
</query>
</iq>
]]></example>
<p>The standard error conditions described in &jep0086; apply (e.g., service unavailable if the entity does not support the namespace).</p>
<p>The standard error conditions described in &xep0086; apply (e.g., service unavailable if the entity does not support the namespace).</p>
</section1>
<section1 topic='A Note on Time Formats'>
<p>&jep0082; defines the lexical representation of dates, times, and datetimes in Jabber protocols. Unfortunately, the 'jabber:iq:time' namespace predates that definition, and uses a datetime format ("CCYYMMDDThh:mm:ss") that is inconsistent with JEP-0082 and &w3xmlschema2;. Because a large base of deployed software uses the old format, this JEP specifies that applications using 'jabber:iq:time' SHOULD use the old format, not the format defined in JEP-0082. In addition, note well that the datetime provided in the &lt;utc/&gt; element is explicitly UTC and therefore SHOULD NOT include the ending 'Z' character required by &iso8601;.</p>
<p>&xep0082; defines the lexical representation of dates, times, and datetimes in Jabber protocols. Unfortunately, the 'jabber:iq:time' namespace predates that definition, and uses a datetime format ("CCYYMMDDThh:mm:ss") that is inconsistent with XEP-0082 and &w3xmlschema2;. Because a large base of deployed software uses the old format, this document specifies that applications using 'jabber:iq:time' SHOULD use the old format, not the format defined in XEP-0082. In addition, note well that the datetime provided in the &lt;utc/&gt; element is explicitly UTC and therefore SHOULD NOT include the ending 'Z' character required by &iso8601;.</p>
</section1>
<section1 topic='Security Considerations'>
<p>There are no security features or concerns related to this proposal.</p>
<p>There are no security features or concerns related to this document.</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'>
<section1 topic='XMPP Registrar Considerations'>
<p>The 'jabber:iq:time' namespace is registered in the protocol namespaces registry maintained by the &REGISTRAR;.</p>
</section1>
<section1 topic='XML Schema'>
@ -95,7 +95,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0090: http://www.jabber.org/jeps/jep-0090.html
XEP-0090: http://www.xmpp.org/extensions/xep-0090.html
</xs:documentation>
</xs:annotation>
@ -112,4 +112,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

24
xep-0091.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>Delayed Delivery</title>
<abstract>This JEP provides canonical documentation of the jabber:x:delay namespace currently used within the Jabber community.</abstract>
<abstract>This specification provides canonical documentation of the jabber:x:delay namespace currently used within the Jabber community.</abstract>
&LEGALNOTICE;
<number>0091</number>
<status>Active</status>
@ -21,7 +21,7 @@
<supersededby/>
<shortname>x-delay</shortname>
<schemaloc>
<url>http://jabber.org/protocol/x-delay/x-delay.xsd</url>
<url>http://www.xmpp.org/schemas/x-delay.xsd</url>
</schemaloc>
&stpeter;
<revision>
@ -50,7 +50,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The Jabber protocols have long included a method for indicating that a message or presence stanza was delayed in being delivered (e.g., because it was stored offline). This method makes use of the 'jabber:x:delay' namespace and has been documented variously in Internet-Drafts and elsewhere. Because this protocol is not required by &rfc2779;, the 'jabber:x:delay' namespace was removed from &xmppim;. This JEP fills the void for canonical documentation.</p>
<p>The Jabber protocols have long included a method for indicating that a message or presence stanza was delayed in being delivered (e.g., because it was stored offline). This method makes use of the 'jabber:x:delay' namespace and has been documented variously in Internet-Drafts and elsewhere. Because this protocol is not required by &rfc2779;, the 'jabber:x:delay' namespace was removed from &xmppim;. This specification fills the void for canonical documentation.</p>
</section1>
<section1 topic='Protocol Definition' anchor='protocol'>
<p>The 'jabber:x:delay' namespace is used to provide timestamp information about data stored for later delivery. The most common uses of this namespace are to stamp:</p>
@ -112,15 +112,15 @@
]]></example>
</section1>
<section1 topic='A Note on Time Formats' anchor='time'>
<p>&jep0082; defines the lexical representation of dates, times, and datetimes in Jabber protocols. Unfortunately, the 'jabber:x:delay' namespace predates that definition, and uses a datetime format ("CCYYMMDDThh:mm:ss") that is inconsistent with JEP-0082 and &w3xmlschema2;. Because a large base of deployed software uses the old format, this JEP specifies that applications using 'jabber:x:delay' SHOULD use the old format, not the format defined in JEP-0082. The timezone is be understood as UTC.</p>
<p>&xep0082; defines the lexical representation of dates, times, and datetimes in Jabber protocols. Unfortunately, the 'jabber:x:delay' namespace predates that definition, and uses a datetime format ("CCYYMMDDThh:mm:ss") that is inconsistent with XEP-0082 and &w3xmlschema2;. Because a large base of deployed software uses the old format, this document specifies that applications using 'jabber:x:delay' SHOULD use the old format, not the format defined in XEP-0082. The timezone is be understood as UTC.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>Data qualified by the 'jabber:x:delay' can expose information about the sender's presence on the network at some time in the past. However, this introduces no new vulnerabilities, since the same information would have been available in real time.</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'>
<p>The 'jabber:x:delay' namespace is included in the protocol namespaces registry maintained by the &REGISTRAR;.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
@ -136,7 +136,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0091: http://www.jabber.org/jeps/jep-0091.html
XEP-0091: http://www.xmpp.org/extensions/xep-0091.html
</xs:documentation>
</xs:annotation>
@ -154,4 +154,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

24
xep-0092.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>Software Version</title>
<abstract>This JEP provides canonical documentation of the existing 'jabber:iq:version' namespace currently used within the Jabber community.</abstract>
<abstract>This specification provides canonical documentation of the existing 'jabber:iq:version' namespace currently used within the Jabber community.</abstract>
&LEGALNOTICE;
<number>0092</number>
<status>Active</status>
@ -20,7 +20,7 @@
<supersededby/>
<shortname>iq-version</shortname>
<schemaloc>
<url>http://jabber.org/protocol/iq-version/iq-version.xsd</url>
<url>http://www.xmpp.org/schemas/iq-version.xsd</url>
</schemaloc>
&stpeter;
<revision>
@ -37,7 +37,7 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>The Jabber protocols have long included a method for discovering version information about the software running at another entity's JID. This method makes use of the 'jabber:iq:version' namespace and has been documented variously in Internet-Drafts and elsewhere. Because this protocol is not required by &rfc2779;, the 'jabber:iq:version' namespace was removed from &xmppim;. This JEP fills the void for canonical documentation.</p>
<p>The Jabber protocols have long included a method for discovering version information about the software running at another entity's JID. This method makes use of the 'jabber:iq:version' namespace and has been documented variously in Internet-Drafts and elsewhere. Because this protocol is not required by &rfc2779;, the 'jabber:iq:version' namespace was removed from &xmppim;. This specification fills the void for canonical documentation.</p>
</section1>
<section1 topic='Definition'>
<p>The 'jabber:iq:version' namespace provides a standard way for Jabber entities to exchange information about the software version used by the entities. The information is communicated in a request/response pair using an &lt;iq/&gt; element that contains a &lt;query/&gt; scoped by the 'jabber:iq:version' namespace. The following children of the &lt;query/&gt; are allowed in an IQ result:</p>
@ -70,15 +70,15 @@
</query>
</iq>
]]></example>
<p>The standard error conditions described in &jep0086; apply (e.g., service unavailable if the entity does not support the namespace).</p>
<p>The standard error conditions described in &xep0086; apply (e.g., service unavailable if the entity does not support the namespace).</p>
</section1>
<section1 topic='Security Considerations'>
<p>There are no security features or concerns related to this proposal.</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'>
<section1 topic='XMPP Registrar Considerations'>
<p>The 'jabber:iq:version' namespace is registered in the protocol namespaces registry maintained by the &REGISTRAR;.</p>
</section1>
<section1 topic='XML Schema'>
@ -94,7 +94,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0092: http://www.jabber.org/jeps/jep-0092.html
XEP-0092: http://www.xmpp.org/extensions/xep-0092.html
</xs:documentation>
</xs:annotation>
@ -111,4 +111,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

32
xep-0093.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>Roster Item Exchange</title>
<abstract>This JEP provides canonical documentation of the jabber:x:roster namespace historically used within the Jabber community. NOTE WELL: This JEP has been superseded by JEP-0144.</abstract>
<abstract>This specification provides canonical documentation of the jabber:x:roster namespace historically used within the Jabber community. NOTE WELL: This specification has been superseded by XEP-0144.</abstract>
&LEGALNOTICE;
<number>0093</number>
<status>Deprecated</status>
@ -19,18 +19,18 @@
</dependencies>
<supersedes/>
<supersededby>
<spec>JEP-0144</spec>
<spec>XEP-0144</spec>
</supersededby>
<shortname>x-roster</shortname>
<schemaloc>
<url>http://jabber.org/protocol/x-roster/x-roster.xsd</url>
<url>http://www.xmpp.org/schemas/x-roster.xsd</url>
</schemaloc>
&stpeter;
<revision>
<version>1.2</version>
<date>2005-08-26</date>
<initials>psa</initials>
<remark>Per advancement of JEP-0144 by the Jabber Council, changed status to Deprecated.</remark>
<remark>Per advancement of XEP-0144 by the Jabber Council, changed status to Deprecated.</remark>
</revision>
<revision>
<version>1.1</version>
@ -52,8 +52,8 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>The Jabber protocols have long included a method for sending roster items to another entity. This method makes use of the 'jabber:x:roster' namespace and has been documented variously in Internet-Drafts and elsewhere. Because this protocol is not required by &rfc2779;, the 'jabber:x:roster' namespace was removed from &xmppim;. This JEP fills the void for canonical documentation.</p>
<p><em>NOTE WELL: This JEP has been superseded by &jep0144;.</em></p>
<p>The Jabber protocols have long included a method for sending roster items to another entity. This method makes use of the 'jabber:x:roster' namespace and has been documented variously in Internet-Drafts and elsewhere. Because this protocol is not required by &rfc2779;, the 'jabber:x:roster' namespace was removed from &xmppim;. This specification fills the void for canonical documentation.</p>
<p><em>NOTE WELL: This document has been superseded by &xep0144;.</em></p>
</section1>
<section1 topic='Definition'>
<p>The 'jabber:x:roster' namespace (which is not to be confused with the 'jabber:iq:roster' namespace) is used to send roster items from one Jabber entity to another. A roster item is sent by adding to the &lt;message/&gt; element an &lt;x/&gt; child scoped by the 'jabber:x:roster' namespace. This &lt;x/&gt; element MUST contain at least one &lt;item/&gt; child elements (one for each roster item to be sent).</p>
@ -86,9 +86,9 @@
<p>There are no security features or concerns related to this proposal.</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'>
<section1 topic='XMPP Registrar Considerations'>
<p>The 'jabber:x:roster' namespace is registered in the protocol namespaces registry maintained by the &REGISTRAR;.</p>
</section1>
<section1 topic='XML Schema'>
@ -104,10 +104,10 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0093: http://www.jabber.org/jeps/jep-0093.html
XEP-0093: http://www.xmpp.org/extensions/xep-0093.html
NOTE WELL: This protocol has been superseded by JEP-0144
http://www.jabber.org/jeps/jep-0144.html
NOTE WELL: This protocol has been superseded by XEP-0144
http://www.xmpp.org/extensions/xep-0144.html
</xs:documentation>
</xs:annotation>
@ -132,4 +132,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

28
xep-0094.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>Agent Information</title>
<abstract>This JEP provides canonical ocumentation of the obsolete Agent Information namespace. Note: This JEP is superseded by JEP-0030: Service Discovery.</abstract>
<abstract>This specification provides canonical documentation of the obsolete Agent Information namespace. Note: This document has been superseded by XEP-0030: Service Discovery.</abstract>
&LEGALNOTICE;
<number>0094</number>
<status>Obsolete</status>
@ -18,7 +18,7 @@
</dependencies>
<supersedes/>
<supersededby>
<spec>JEP-0030</spec>
<spec>XEP-0030</spec>
</supersededby>
<shortname>iq-agents</shortname>
&stpeter;
@ -26,7 +26,7 @@
<version>0.3</version>
<date>2003-10-08</date>
<initials>psa</initials>
<remark>Per a vote of the Jabber Council, changed status to Obsolete. The protocol described herein is accurately defined but actively deprecated in favor of Service Discovery (JEP-0030).</remark>
<remark>Per a vote of the Jabber Council, changed status to Obsolete. The protocol described herein is accurately defined but actively deprecated in favor of Service Discovery (XEP-0030).</remark>
</revision>
<revision>
<version>0.2</version>
@ -42,8 +42,8 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>Over the years there have been three different protocols used in the Jabber community to discover information about other entities on the network. The most recent protocol, and the only one that is standards-track, is &jep0030;. The protocol prior to Service Discovery was &jep0011;. Before Jabber Browsing, there was the 'jabber:iq:agents' namespace. This JEP provides historical documentation for the Agent Information protocol.</p>
<p>Note well that the Agent Information protocol is deprecated; applications desiring such functionality SHOULD implement Service Discovery. This JEP is provided only in order to ensure complete documentation of earlier protocols.</p>
<p>Over the years there have been three different protocols used in the Jabber community to discover information about other entities on the network. The most recent protocol, and the only one that is standards-track, is &xep0030;. The protocol prior to Service Discovery was &xep0011;. Before Jabber Browsing, there was the 'jabber:iq:agents' namespace. This specification provides historical documentation for the Agent Information protocol.</p>
<p>Note well that the Agent Information protocol is deprecated; applications desiring such functionality SHOULD implement Service Discovery. This specification is provided only in order to ensure complete documentation of earlier protocols.</p>
</section1>
<section1 topic='Definition'>
<p>The 'jabber:iq:agents' namespace was used to obtain a list of entities associated with another Jabber Entity; most commonly, the list of trusted services associated with a specific host.</p>
@ -53,7 +53,7 @@
<li>description - a short phrase describing the service</li>
<li>transport - inclusion of this empty element signals that the service is a gateway to a non-Jabber instant messaging system</li>
<li>groupchat - inclusion of this empty element signals that the service is multi-user chat service</li>
<li>service - the CDATA of this element specifies the type of gateway (aim, icq, irc, msn, yahoo), the type of conferencing service (public or private), or user directory (jud); these values were never standardized and are not registered with the Jabber Registrar</li>
<li>service - the CDATA of this element specifies the type of gateway (aim, icq, irc, msn, yahoo), the type of conferencing service (public or private), or user directory (jud); these values were never standardized and are not registered with the XMPP Registrar</li>
<li>register - inclusion of this empty element signals that the service supports registration</li>
<li>search - inclusion of this empty element signals that the service supports searching</li>
</ul>
@ -90,10 +90,10 @@
<p>There are no security features or concerns related to this proposal.</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>No action on the part of the &REGISTRAR; is necessary as a result of this JEP, since 'jabber:iq:agents' is already a registered namespace.</p>
<section1 topic='XMPP Registrar Considerations'>
<p>No action on the part of the &REGISTRAR; is necessary as a result of this document, since 'jabber:iq:agents' is already a registered namespace.</p>
</section1>
<section1 topic='XML Schema'>
<code><![CDATA[
@ -139,4 +139,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

46
xep-0095.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>Stream Initiation</title>
<abstract>This JEP defines a protocol for initiating a stream (with meta information) between any two Jabber entities.</abstract>
<abstract>This document defines an XMPP protocol extension for initiating a stream (with meta information) between any two Jabber entities.</abstract>
&LEGALNOTICE;
<number>0095</number>
<status>Draft</status>
@ -15,13 +15,13 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0030</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>si</shortname>
<schemaloc>
<url>http://jabber.org/protocol/si/si.xsd</url>
<url>http://www.xmpp.org/schemas/si.xsd</url>
</schemaloc>
<registry/>
&temas;
@ -31,7 +31,7 @@
<version>1.1</version>
<date>2004-04-13</date>
<initials>psa</initials>
<remark>More fully defined the Jabber Registrar considerations.</remark>
<remark>More fully defined the XMPP Registrar considerations.</remark>
</revision>
<revision>
<version>1.0</version>
@ -82,7 +82,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>As the Jabber protocols are extended beyond basic messaging and presence, the need has arisen for a generic protocol that can be used to negotiate content streams between any two entities. Such streams might be in-band, but more likely will be out-of-band, binary streams used in applications such as file transfer, voice chat, and video conferencing. This JEP provides a method for negotiating such streams, including meta-information about the intended usage of the stream.</p>
<p>As the Jabber protocols are extended beyond basic messaging and presence, the need has arisen for a generic protocol that can be used to negotiate content streams between any two entities. Such streams might be in-band, but more likely will be out-of-band, binary streams used in applications such as file transfer, voice chat, and video conferencing. This document provides a method for negotiating such streams, including meta-information about the intended usage of the stream.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<ul>
@ -105,7 +105,7 @@
<li>Receiver rejects the stream initiation, EUC</li>
</ol>
<section2 topic='Discovery' anchor='usecase-disco'>
<p>Before a Stream Initiation is attempted the Sender should be sure that the Receiver supports both Stream Initiation and the specific profile that they wish to use. This is typically accomplished using &jep0030;:</p>
<p>Before a Stream Initiation is attempted the Sender should be sure that the Receiver supports both Stream Initiation and the specific profile that they wish to use. This is typically accomplished using &xep0030;:</p>
<example caption='Requesting Disco Information From Receiver'><![CDATA[
<iq type='get'
to='receiver@jabber.org/resource'
@ -114,7 +114,7 @@
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<p>The Receiver advertises the "http://jabber.org/protocol/si" namespace as a feature to represent that they implement this JEP. The specific profiles are also announced this way; they can be found by looking for "http://jabber.org/protocol/si/profile/profile-name". Shown in the result is a potential file transfer profile:</p>
<p>The Receiver advertises the "http://jabber.org/protocol/si" namespace as a feature to represent that they implement this document. The specific profiles are also announced this way; they can be found by looking for "http://jabber.org/protocol/si/profile/profile-name". Shown in the result is a potential file transfer profile:</p>
<example caption='Receiver Disco Information Result'><![CDATA[
<iq type='result'
to='sender@jabber.org/resource'
@ -130,7 +130,7 @@
]]></example>
</section2>
<section2 topic='Negotiating Profile and Stream' anchor='usecase-neg'>
<p>Once support is determined, the Sender starts the negotiation with the Receiver by sending an &IQ; stanza of type "set", such as in the following example from &jep0096;:</p>
<p>Once support is determined, the Sender starts the negotiation with the Receiver by sending an &IQ; stanza of type "set", such as in the following example from &xep0096;:</p>
<example caption='Offer Stream Initiation'><![CDATA[
<iq type='set' id='offer1' to='receiver@jabber.org/resource'>
<si xmlns='http://jabber.org/protocol/si'
@ -169,7 +169,7 @@
</si>
</iq>
]]></example>
<p>If the profile describes data to be sent back in the result it MUST be present as described in the profile's JEP.</p>
<p>If the profile describes data to be sent back in the result it MUST be present as described in the profile's specification.</p>
<example caption='Accept Stream Initiation with Profile'><![CDATA[
<iq type='result' to='sender@jabber.org/resource' id='offer1'>
<si xmlns='http://jabber.org/protocol/si'>
@ -214,7 +214,7 @@
]]></example>
</section2>
<section2 topic='Preparing the Transfer' anchor='usecase-transfer'>
<p>At this point, the Sender and Receiver make any preparations necessary for the stream to be used. The exact process is specific to each protocol, and is beyond the scope of this JEP. This step now marks the end of SI's responsibilities.</p>
<p>At this point, the Sender and Receiver make any preparations necessary for the stream to be used. The exact process is specific to each protocol, and is beyond the scope of this document. This step now marks the end of SI's responsibilities.</p>
</section2>
</section1>
<section1 topic='Formal Definition' anchor='def'>
@ -273,7 +273,7 @@
<td>The stream is rejected.</td>
</tr>
</table>
<p>For further information about the relationship between XMPP error handling and "legacy" (HTTP-style) error codes, refer to &jep0086;.</p>
<p>For further information about the relationship between XMPP error handling and "legacy" (HTTP-style) error codes, refer to &xep0086;.</p>
</section2>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
@ -281,13 +281,13 @@
<p>Stream Initiation on its own is of limited use; the Receiver almost always requires some reason for SI. Knowing this allows the Receiver to make a more educated choice about whether or not to accept the stream. This information is provided in Stream Initiation via a <em>profile</em>. A profile is a collection of information that describes the reason for and structure of the stream data, including what the data represents and what stream protocols are expected to be supported.</p>
<p>The initial request for Stream Initiation MUST have only one profile, and this profile is in its own namespace. The profile is indicated not only by the presence of a "root" element in that particular namespace, but also be the "profile" attribute in &lt;si/&gt; The SUGGESTED format for profile namespaces is:</p>
<code>http://jabber.org/protocol/si/profile/profile-name</code>
<p>The information that the profile presents SHOULD be defined in an official JEP. The JEP defining the profile SHOULD contain explanations of what the profile consists of and MUST define the profile in a complete manner using DTD, Schema or another appropiate definition language.</p>
<p>The information that the profile presents SHOULD be defined in an official XEP. The XEP defining the profile SHOULD contain explanations of what the profile consists of and MUST define the profile in a complete manner using DTD, Schema or another appropiate definition language.</p>
<p>A profile SHOULD define what stream protocols MUST be supported, and MUST define what stream protocols MAY be supported. If a profile specifies only a single stream protocol that MUST be supported (even if others MAY also be supported), the "fneg" for the stream protocol may be omitted from the initial &lt;si/&gt;; the receiving entity then assumes the stream protocol that MUST be supported is the one to use.</p>
<p>This JEP does not define any profiles, nor does it place any restrictions on what type of information a profile should detail. Other JEPs will define profiles to be used with Stream Initiation.</p>
<p>This document does not define any profiles, nor does it place any restrictions on what type of information a profile should detail. Other specifications will define profiles to be used with Stream Initiation.</p>
</section2>
<section2 topic='Stream Interaction' anchor='impl-stream'>
<p>While Stream Initiation is not directly required for stream usage, it does provide many benefits. In order to fully appreciate these benefits, streams must link the Stream Initiation to the stream. The "id" attribute transported on the &lt;si/&gt; element is intended to do this. Once a session is fully negotiated, the value of the &lt;si/&gt; "id" attribute is used during the actual stream negotiation as the protocol's stream identifier attribute.</p>
<p>To be compatible to this JEP, a stream protocol MUST define a stream identifier (typically "sid"), which MUST have a unique string representation. The stream protocol MUST be able to use any string identifier chosen during Stream Initiation, as long as the sending party does not use the same identifier more than once.</p>
<p>To be compatible to this document, a stream protocol MUST define a stream identifier (typically "sid"), which MUST have a unique string representation. The stream protocol MUST be able to use any string identifier chosen during Stream Initiation, as long as the sending party does not use the same identifier more than once.</p>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
@ -298,17 +298,17 @@
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>
This JEP uses the MIME types as recorded by the IANA, but no direct
This document uses the MIME types as recorded by the IANA, but no direct
interaction with the IANA is necessary.
</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 'http://jabber.org/protocol/si' namespace in its registry of protocol namespaces.</p>
</section2>
<section2 topic='Registries' anchor='registrar-reg'>
<section3 topic='Profiles Registry' anchor='registrar-reg-profiles'>
<p>The Jabber Registrar shall maintain a registry of stream initiation profiles, located at &lt;<link url='http://www.jabber.org/registrar/si-profiles.html'>http://www.jabber.org/registrar/si-profiles.html</link>&gt;. Any such profile defined in a Jabber Enhancement Proposal MUST be submitted to the Jabber Registrar; profiles defined in non-standard protocol extensions SHOULD be submitted to the Jabber Registrar.</p>
<p>The XMPP Registrar shall maintain a registry of stream initiation profiles, located at &lt;<link url='http://www.jabber.org/registrar/si-profiles.html'>http://www.jabber.org/registrar/si-profiles.html</link>&gt;. Any such profile defined in a Jabber Enhancement Proposal MUST be submitted to the XMPP Registrar; profiles defined in non-standard protocol extensions SHOULD be submitted to the XMPP Registrar.</p>
<section4 topic='Process' anchor='registrar-reg-profiles-process'>
&REGPROCESS;
<code><![CDATA[
@ -339,7 +339,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0095: http://www.jabber.org/jeps/jep-0095.html
XEP-0095: http://www.xmpp.org/extensions/xep-0095.html
</xs:documentation>
</xs:annotation>
@ -373,4 +373,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

46
xep-0096.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>File Transfer</title>
<abstract>This JEP defines a stream initiation profile for transferring files.</abstract>
<abstract>This document defines a stream initiation profile for transferring files.</abstract>
&LEGALNOTICE;
<number>0096</number>
<status>Draft</status>
@ -15,13 +15,13 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0095</spec>
<spec>XEP-0095</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>si-filetransfer</shortname>
<schemaloc>
<url>http://jabber.org/protocol/si/profile/file-transfer/file-transfer.xsd</url>
<url>http://www.xmpp.org/schemas/file-transfer.xsd</url>
</schemaloc>
&temas;
&linuxwolf;
@ -30,7 +30,7 @@
<version>1.1</version>
<date>2004-04-13</date>
<initials>psa</initials>
<remark>More fully defined the Jabber Registrar considerations.</remark>
<remark>More fully defined the XMPP Registrar considerations.</remark>
</revision>
<revision>
<version>1.1</version>
@ -93,13 +93,13 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The traditional mechanism for transferring files in the Jabber community is the &jep0066; protocol. That protocol has several drawbacks:</p>
<p>The traditional mechanism for transferring files in the Jabber community is the &xep0066; protocol. That protocol has several drawbacks:</p>
<ol>
<li>It is not reliable.</li>
<li>It does not work when one of the parties is behind a firewall.</li>
<li>It provides limited metadata about files to be exchanged.</li>
</ol>
<p>The current document defines a profile of &jep0095; that solves the problems with out-of-band data, thus providing a robust, reliable mechanism for file transfers over the Jabber network. Implementors are referred to JEP-0095 regarding the underlying concepts of stream initiation.</p>
<p>The current document defines a profile of &xep0095; that solves the problems with out-of-band data, thus providing a robust, reliable mechanism for file transfers over the Jabber network. Implementors are referred to XEP-0095 regarding the underlying concepts of stream initiation.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<ul>
@ -131,7 +131,7 @@
<li><em>size</em> - The size, in bytes, of the data to be sent.</li>
<li><em>name</em> - The name of the file that the Sender wishes to send.</li>
<li><em>date</em> - The last modification time of the file. This is
specified using the DateTime profile as described in &jep0082;.</li>
specified using the DateTime profile as described in &xep0082;.</li>
<li><em>hash</em> - The MD5 sum of the file contents.</li>
</ul>
The <em>size</em> and <em>name</em> attributes MUST be present in the
@ -171,7 +171,7 @@
at the offset position for the length specified.
</p>
<section2 topic='Mandatory-to-Implement Technologies' anchor='protocol-tech'>
<p>In order to enable seamless file transfer and appropriate fall-back mechanisms, implementations of this profile MUST support both &jep0065; and &jep0047;, to be preferred in that order. The associated namespaces are to be included as option values for the "stream-method" variable as shown in the examples below.</p>
<p>In order to enable seamless file transfer and appropriate fall-back mechanisms, implementations of this profile MUST support both &xep0065; and &xep0047;, to be preferred in that order. The associated namespaces are to be included as option values for the "stream-method" variable as shown in the examples below.</p>
<p>Additionally, implementations MAY support other mechanisms.</p>
</section2>
</section1>
@ -286,28 +286,28 @@
</example>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>No interaction with &IANA; is required as a result of this JEP.</p>
<p>No interaction with &IANA; is required as a result of this document.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Stream Initiation Profiles' anchor='registrar-siprofiles'>
<p>The profile described in this JEP is included in the stream initiation profiles registry maintained by the &REGISTRAR; (see &SIPROFILES;). The registry submission is as follows:</p>
<p>The profile described in this document is included in the stream initiation profiles registry maintained by the &REGISTRAR; (see &SIPROFILES;). The registry submission is as follows:</p>
<code><![CDATA[
<profile>
<name>http://jabber.org/protocol/si/profile/file-transfer</name>
<doc>JEP-0096</doc>
<doc>XEP-0096</doc>
<desc>A profile for file transfer between any two entities.</desc>
</profile>
]]></code>
</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 file transfer actions are "sendfile" and "recvfile". Note well that "sendfile" means a second entity will send a file to the XMPP entity that controls the IRI/URI and that "recvfile" means a second entity will receive a file from the XMPP entity that controls the IRI/URI.</p>
<section3 topic='sendfile' anchor='registrar-querytypes-sendfile'>
<p>To enable a second entity to send a file, the IRI/URI is of the following form:</p>
<example caption='Sending a File: IRI/URI'><![CDATA[
xmpp:romeo@montague.net/orchard?sendfile
]]></example>
<p>The application SHOULD then present an interface enabling the user to provide information about the file to be sent (e.g., by "browsing" the file system of the user's computer in order to choose a file). As a result, the application SHOULD then send a &jep0137; message to the XMPP address encapsulated in the IRI/URI:</p>
<p>The application SHOULD then present an interface enabling the user to provide information about the file to be sent (e.g., by "browsing" the file system of the user's computer in order to choose a file). As a result, the application SHOULD then send a &xep0137; message to the XMPP address encapsulated in the IRI/URI:</p>
<example caption='Sending a File: Resulting Stanza'><![CDATA[
<message from='juliet@capulet.com/balcony' to='romeo@montague.net'>
<sipub xmlns='http://jabber.org/protocol/si-pub'
@ -327,7 +327,7 @@ xmpp:romeo@montague.net/orchard?sendfile
<name>sendfile</name>
<proto>http://jabber.org/protocol/si/profile/file-transfer</proto>
<desc>enables initiation of an inbound file transfer to XMPP entity</desc>
<doc>JEP-0096</doc>
<doc>XEP-0096</doc>
</querytype>
]]></code>
</section3>
@ -349,7 +349,7 @@ xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain&name=
</sipub>
</message>
]]></example>
<p>In accordance with <cite>JEP-0137</cite>, the application SHOULD then initiate a file transfer exchange with by sending a stanza of the following form:</p>
<p>In accordance with <cite>XEP-0137</cite>, the application SHOULD then initiate a file transfer exchange with by sending a stanza of the following form:</p>
<example caption='Receiving a File: Resulting Stanza'><![CDATA[
<iq from='juliet@capulet.com/balcony' to='romeo@montague.net/orchard'>
<start xmlns='http://jabber.org/protocol/si-pub' id='pub234'/>
@ -362,7 +362,7 @@ xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain&name=
<name>recvfile</name>
<proto>http://jabber.org/protocol/si/profile/file-transfer</proto>
<desc>enables initiation of an outbound file transfer from XMPP entity</desc>
<doc>JEP-0096</doc>
<doc>XEP-0096</doc>
<keys>
<key>
<name>mime-type</name>
@ -399,7 +399,7 @@ xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain&name=
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0096: http://www.jabber.org/jeps/jep-0096.html
XEP-0096: http://www.xmpp.org/extensions/xep-0096.html
</xs:documentation>
</xs:annotation>
@ -436,4 +436,4 @@ xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain&name=
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

18
xep-0097.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>iCal Envelope</title>
<abstract>A simple mechanism to transport iCal data over the jabber protocol</abstract>
@ -13,7 +13,7 @@
<status>Deferred</status>
<type>Standards Track</type>
<jig>Standards</jig>
<dependencies>JEP-0030</dependencies>
<dependencies>XEP-0030</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<shortname>ice</shortname>
@ -31,7 +31,7 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>This will be the first, in a series (hopefully), of JEPs which will define how to utilize GroupWare over jabber. While GroupWare is extremely broad subject, this jep will focus on iCal<note>iCalendar <link uri='http://www.ietf.org/html.charters/calsch-charter.html'>http://www.ietf.org/html.charters/calsch-charter.html</link></note>. Since iCal is a defined standard which is transport-agnostic, all this JEP will do is define how iCal will be transported over Jabber.</p>
<p>This will be the first, in a series (hopefully), of JEPs which will define how to utilize GroupWare over jabber. While GroupWare is extremely broad subject, this JEP will focus on iCal<note>iCalendar <link uri='http://www.ietf.org/html.charters/calsch-charter.html'>http://www.ietf.org/html.charters/calsch-charter.html</link></note>. Since iCal is a defined standard which is transport-agnostic, all this JEP will do is define how iCal will be transported over Jabber.</p>
<p>What this JEP will cover:</p>
<ul>
<li>Sending iCal data</li>
@ -117,8 +117,8 @@
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA)</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<p>The 'http://jabber.org/protocol/gw/ical' namespace is registered with the Jabber Registrar as a result of this JEP.</p>
<section1 topic='XMPP Registrar Considerations'>
<p>The 'http://jabber.org/protocol/gw/ical' namespace is registered with the XMPP Registrar as a result of this JEP.</p>
</section1>
<section1 topic='Formal Definition'>
<section2 topic='Schema'>
@ -135,4 +135,4 @@
<li>How should attachments to ical be handled?</li>
</ul>
</section1>
</jep>
</xep>

15
xep-0098.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>Enhanced Private XML Storage</title>
<abstract>Standardizes "private" XML data storage.</abstract>
@ -32,7 +32,7 @@
</header>
<section1 topic='Introduction'>
<p>The 'jabber:iq:private' namespace has been
documented in &jep0049; according to the historical behavior
documented in &xep0049; according to the historical behavior
of current implementations. However there are two backward compatible
improvements to the protocol introduced in this standard
that increase the future useability of the protocol: matching on the fully
@ -169,7 +169,7 @@ SERVER:
<error code="406">Not Acceptable</error>
</iq>
]]></example>
<p>Certain namespaces are reserved in Jabber (namespaces beginning with 'jabber:' or 'http://jabber.org/', as well as 'vcard-temp'). If a user attempts to get or set http://jabber.org/protocol/private-xml data in a reserved namespace, historically some server implementations have chosen to return an error (commonly 406 [Not Acceptable]) to the sender. Such behavior is not required in order to comply with this JEP, but may be encountered by clients when interacting with some current server implementations.</p>
<p>Certain namespaces are reserved in Jabber (namespaces beginning with 'jabber:' or 'http://jabber.org/', as well as 'vcard-temp'). If a user attempts to get or set http://jabber.org/protocol/private-xml data in a reserved namespace, historically some server implementations have chosen to return an error (commonly 406 [Not Acceptable]) to the sender. Such behavior is not required in order to comply with this document, but may be encountered by clients when interacting with some current server implementations.</p>
<example caption='User Attempts to Get or Set Data in a Reserved Namespace'><![CDATA[
CLIENT:
<iq type="set" id="1005">
@ -253,5 +253,4 @@ SERVER (server responds with success):
]]></code>
</section2>
</section1>
</jep>
</xep>

11
xep-0099.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>IQ Query Action Protocol</title>
<abstract>Standardizes behavior of &IQ; &QUERY; actions for generic query behavior.</abstract>
@ -392,5 +392,4 @@ this JEP, you must specify the following:</p>
</ul>
</section2>
</section1>
</jep>
</xep>