<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>
<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>
<section1topic='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>
<section1topic='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 <utc/> 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 <utc/> element is explicitly UTC and therefore SHOULD NOT include the ending 'Z' character required by &iso8601;.</p>
</section1>
<section1topic='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>
<section1topic='IANA Considerations'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1topic='Jabber Registrar Considerations'>
<section1topic='XMPP Registrar Considerations'>
<p>The 'jabber:iq:time' namespace is registered in the protocol namespaces registry maintained by the ®ISTRAR;.</p>
</section1>
<section1topic='XML Schema'>
@ -95,7 +95,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
<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>
<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>
<section1topic='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>
<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>
<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>
<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>
<section1topic='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 <iq/> element that contains a <query/> scoped by the 'jabber:iq:version' namespace. The following children of the <query/> 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>
<section1topic='Security Considerations'>
<p>There are no security features or concerns related to this proposal.</p>
</section1>
<section1topic='IANA Considerations'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1topic='Jabber Registrar Considerations'>
<section1topic='XMPP Registrar Considerations'>
<p>The 'jabber:iq:version' namespace is registered in the protocol namespaces registry maintained by the ®ISTRAR;.</p>
</section1>
<section1topic='XML Schema'>
@ -94,7 +94,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
<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>
<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>
<section1topic='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>
<section1topic='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 <message/> element an <x/> child scoped by the 'jabber:x:roster' namespace. This <x/> element MUST contain at least one <item/> 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>
<section1topic='IANA Considerations'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1topic='Jabber Registrar Considerations'>
<section1topic='XMPP Registrar Considerations'>
<p>The 'jabber:x:roster' namespace is registered in the protocol namespaces registry maintained by the ®ISTRAR;.</p>
</section1>
<section1topic='XML Schema'>
@ -104,10 +104,10 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
<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>
<section1topic='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>
<section1topic='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>
<section1topic='IANA Considerations'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1topic='Jabber Registrar Considerations'>
<p>No action on the part of the ®ISTRAR; is necessary as a result of this JEP, since 'jabber:iq:agents' is already a registered namespace.</p>
<section1topic='XMPP Registrar Considerations'>
<p>No action on the part of the ®ISTRAR; is necessary as a result of this document, since 'jabber:iq:agents' is already a registered namespace.</p>
<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>
<section1topic='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>
<section1topic='Requirements'anchor='reqs'>
<ul>
@ -105,7 +105,7 @@
<li>Receiver rejects the stream initiation, EUC</li>
</ol>
<section2topic='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>
<examplecaption='Requesting Disco Information From Receiver'><![CDATA[
<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>
<examplecaption='Receiver Disco Information Result'><![CDATA[
<iqtype='result'
to='sender@jabber.org/resource'
@ -130,7 +130,7 @@
]]></example>
</section2>
<section2topic='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>
<section2topic='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>
<section1topic='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>
<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 <si/> The SUGGESTED format for profile namespaces is:</p>
<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 <si/>; 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>
<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 <si/> element is intended to do this. Once a session is fully negotiated, the value of the <si/> "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>
<p>The Jabber Registrar shall maintain a registry of stream initiation profiles, located at <<linkurl='http://www.jabber.org/registrar/si-profiles.html'>http://www.jabber.org/registrar/si-profiles.html</link>>. 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 <<linkurl='http://www.jabber.org/registrar/si-profiles.html'>http://www.jabber.org/registrar/si-profiles.html</link>>. 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>
<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>
<section1topic='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>
<section1topic='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
<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>
<p>The profile described in this JEP is included in the stream initiation profiles registry maintained by the ®ISTRAR; (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 ®ISTRAR; (see &SIPROFILES;). The registry submission is as follows:</p>
<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>
<p>To enable a second entity to send a file, the IRI/URI is of the following form:</p>
<examplecaption='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>
<examplecaption='Sending a File: Resulting Stanza'><![CDATA[
<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>
<examplecaption='Receiving a File: Resulting Stanza'><![CDATA[
<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>
<section1topic='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 <linkuri='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 <linkuri='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 @@
<section1topic='IANA Considerations'>
<p>This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA)</p>
</section1>
<section1topic='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>
<section1topic='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>
<section1topic='Formal Definition'>
<section2topic='Schema'>
@ -135,4 +135,4 @@
<li>How should attachments to ical be handled?</li>
<abstract>Standardizes "private" XML data storage.</abstract>
@ -32,7 +32,7 @@
</header>
<section1topic='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:
<errorcode="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>
<examplecaption='User Attempts to Get or Set Data in a Reserved Namespace'><
Peter Saint-Andre
17 years ago