From b09e9759ee2757ff5ea1693a7c9b7d68b8761328 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 4 Oct 2006 02:38:14 +0000 Subject: [PATCH] JEP to XEP git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@38 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0090.xml | 28 ++++++++++++++-------------- xep-0091.xml | 24 ++++++++++++------------ xep-0092.xml | 24 ++++++++++++------------ xep-0093.xml | 32 ++++++++++++++++---------------- xep-0094.xml | 28 ++++++++++++++-------------- xep-0095.xml | 46 +++++++++++++++++++++++----------------------- xep-0096.xml | 46 +++++++++++++++++++++++----------------------- xep-0097.xml | 18 +++++++++--------- xep-0098.xml | 15 +++++++-------- xep-0099.xml | 11 +++++------ 10 files changed, 135 insertions(+), 137 deletions(-) diff --git a/xep-0090.xml b/xep-0090.xml index 0f3dd377..869fde9e 100644 --- a/xep-0090.xml +++ b/xep-0090.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
Entity Time - This JEP provides canonical documentation of the existing 'jabber:iq:time' namespace currently used within the Jabber community. + This document provides canonical documentation of the existing 'jabber:iq:time' namespace currently used within the Jabber community. &LEGALNOTICE; 0090 Active @@ -20,7 +20,7 @@ iq-time - http://jabber.org/protocol/iq-time/iq-time.xsd + http://www.xmpp.org/schemas/iq-time.xsd &stpeter; @@ -37,7 +37,7 @@
-

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.

+

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.

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:

@@ -68,18 +68,18 @@ ]]> -

The standard error conditions described in &jep0086; apply (e.g., service unavailable if the entity does not support the namespace).

+

The standard error conditions described in &xep0086; apply (e.g., service unavailable if the entity does not support the namespace).

 -

&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;.

+

&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;.

 -

There are no security features or concerns related to this proposal.

+

There are no security features or concerns related to this document.

 -

This JEP requires no interaction with &IANA;.

+

This document requires no interaction with &IANA;.

 - +

The 'jabber:iq:time' namespace is registered in the protocol namespaces registry maintained by the ®ISTRAR;.

 @@ -95,7 +95,7 @@ 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 @@ -112,4 +112,4 @@ ]]> - + diff --git a/xep-0091.xml b/xep-0091.xml index 7c38ba73..db011fe4 100644 --- a/xep-0091.xml +++ b/xep-0091.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
Delayed Delivery - This JEP provides canonical documentation of the jabber:x:delay namespace currently used within the Jabber community. + This specification provides canonical documentation of the jabber:x:delay namespace currently used within the Jabber community. &LEGALNOTICE; 0091 Active @@ -21,7 +21,7 @@ x-delay - http://jabber.org/protocol/x-delay/x-delay.xsd + http://www.xmpp.org/schemas/x-delay.xsd &stpeter; @@ -50,7 +50,7 @@
-

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.

+

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.

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:

@@ -112,15 +112,15 @@ ]]> -

&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.

+

&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.

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.

 -

This JEP requires no interaction with &IANA;.

+

This document requires no interaction with &IANA;.

 - +

The 'jabber:x:delay' namespace is included in the protocol namespaces registry maintained by the ®ISTRAR;.

 @@ -136,7 +136,7 @@ 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 @@ -154,4 +154,4 @@ ]]> - + diff --git a/xep-0092.xml b/xep-0092.xml index a56157a2..e141f52b 100644 --- a/xep-0092.xml +++ b/xep-0092.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
Software Version - This JEP provides canonical documentation of the existing 'jabber:iq:version' namespace currently used within the Jabber community. + This specification provides canonical documentation of the existing 'jabber:iq:version' namespace currently used within the Jabber community. &LEGALNOTICE; 0092 Active @@ -20,7 +20,7 @@ iq-version - http://jabber.org/protocol/iq-version/iq-version.xsd + http://www.xmpp.org/schemas/iq-version.xsd &stpeter; @@ -37,7 +37,7 @@
-

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.

+

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.

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:

@@ -70,15 +70,15 @@ ]]> -

The standard error conditions described in &jep0086; apply (e.g., service unavailable if the entity does not support the namespace).

+

The standard error conditions described in &xep0086; apply (e.g., service unavailable if the entity does not support the namespace).

There are no security features or concerns related to this proposal.

 -

This JEP requires no interaction with &IANA;.

+

This document requires no interaction with &IANA;.

 - +

The 'jabber:iq:version' namespace is registered in the protocol namespaces registry maintained by the ®ISTRAR;.

 @@ -94,7 +94,7 @@ 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 @@ -111,4 +111,4 @@ ]]> - + diff --git a/xep-0093.xml b/xep-0093.xml index 35691d03..f9c44236 100644 --- a/xep-0093.xml +++ b/xep-0093.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
Roster Item Exchange - 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. + 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. &LEGALNOTICE; 0093 Deprecated @@ -19,18 +19,18 @@ - JEP-0144 + XEP-0144 x-roster - http://jabber.org/protocol/x-roster/x-roster.xsd + http://www.xmpp.org/schemas/x-roster.xsd &stpeter; 1.2 2005-08-26 psa - Per advancement of JEP-0144 by the Jabber Council, changed status to Deprecated. + Per advancement of XEP-0144 by the Jabber Council, changed status to Deprecated. 1.1 @@ -52,8 +52,8 @@
-

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.

-

NOTE WELL: This JEP has been superseded by &jep0144;.

+

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.

+

NOTE WELL: This document has been superseded by &xep0144;.

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).

@@ -86,9 +86,9 @@

There are no security features or concerns related to this proposal.

 -

This JEP requires no interaction with &IANA;.

+

This document requires no interaction with &IANA;.

 - +

The 'jabber:x:roster' namespace is registered in the protocol namespaces registry maintained by the ®ISTRAR;.

 @@ -104,10 +104,10 @@ 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 @@ -132,4 +132,4 @@ ]]> - + diff --git a/xep-0094.xml b/xep-0094.xml index 9b3b2a4f..e46c2212 100644 --- a/xep-0094.xml +++ b/xep-0094.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
Agent Information - This JEP provides canonical ocumentation of the obsolete Agent Information namespace. Note: This JEP is superseded by JEP-0030: Service Discovery. + This specification provides canonical documentation of the obsolete Agent Information namespace. Note: This document has been superseded by XEP-0030: Service Discovery. &LEGALNOTICE; 0094 Obsolete @@ -18,7 +18,7 @@ - JEP-0030 + XEP-0030 iq-agents &stpeter; @@ -26,7 +26,7 @@ 0.3 2003-10-08 psa - 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). + 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). 0.2 @@ -42,8 +42,8 @@
-

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.

-

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.

+

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.

+

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.

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.

@@ -53,7 +53,7 @@
  • description - a short phrase describing the service
  • transport - inclusion of this empty element signals that the service is a gateway to a non-Jabber instant messaging system
  • groupchat - inclusion of this empty element signals that the service is multi-user chat service
    • -
  • 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
    • +
  • 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
  • register - inclusion of this empty element signals that the service supports registration
  • search - inclusion of this empty element signals that the service supports searching
    • @@ -90,10 +90,10 @@

    There are no security features or concerns related to this proposal.

     -

    This JEP requires no interaction with &IANA;.

    +

    This document requires no interaction with &IANA;.

     - -

    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.

    + +

    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.

     ]]> -     + diff --git a/xep-0095.xml b/xep-0095.xml index bdc75b98..9fb0950f 100644 --- a/xep-0095.xml +++ b/xep-0095.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
    Stream Initiation - This JEP defines a protocol for initiating a stream (with meta information) between any two Jabber entities. + This document defines an XMPP protocol extension for initiating a stream (with meta information) between any two Jabber entities. &LEGALNOTICE; 0095 Draft @@ -15,13 +15,13 @@ Standards JIG XMPP Core - JEP-0030 + XEP-0030 si - http://jabber.org/protocol/si/si.xsd + http://www.xmpp.org/schemas/si.xsd &temas; @@ -31,7 +31,7 @@ 1.1 2004-04-13 psa - More fully defined the Jabber Registrar considerations. + More fully defined the XMPP Registrar considerations. 1.0 @@ -82,7 +82,7 @@
    -

    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.

    +

    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.
      @@ -105,7 +105,7 @@
    • Receiver rejects the stream initiation, EUC
      • -

      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;:

      +

      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;:

      ]]> -

      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:

      +

      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:

       -

      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;:

      +

      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;:

      ]]> -

      If the profile describes data to be sent back in the result it MUST be present as described in the profile's JEP.

      +

      If the profile describes data to be sent back in the result it MUST be present as described in the profile's specification.

      @@ -214,7 +214,7 @@ ]]>       -

      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.

      +

      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.

       @@ -273,7 +273,7 @@ The stream is rejected. -

      For further information about the relationship between XMPP error handling and "legacy" (HTTP-style) error codes, refer to &jep0086;.

      +

      For further information about the relationship between XMPP error handling and "legacy" (HTTP-style) error codes, refer to &xep0086;.

       @@ -281,13 +281,13 @@

      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 profile. 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.

      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:

      http://jabber.org/protocol/si/profile/profile-name -

      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.

      +

      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.

      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.

      -

      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.

      +

      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.

      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.

      -

      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.

      +

      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.

             @@ -298,17 +298,17 @@

      - 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.

      - +

      The ®ISTRAR; includes the 'http://jabber.org/protocol/si' namespace in its registry of protocol namespaces.

       -

      The Jabber Registrar shall maintain a registry of stream initiation profiles, located at <http://www.jabber.org/registrar/si-profiles.html>. 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.

      +

      The XMPP Registrar shall maintain a registry of stream initiation profiles, located at <http://www.jabber.org/registrar/si-profiles.html>. 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.

      ®PROCESS; 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 @@ -373,4 +373,4 @@ ]]>       - + diff --git a/xep-0096.xml b/xep-0096.xml index 886cd48b..e57bba5d 100644 --- a/xep-0096.xml +++ b/xep-0096.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
      File Transfer - This JEP defines a stream initiation profile for transferring files. + This document defines a stream initiation profile for transferring files. &LEGALNOTICE; 0096 Draft @@ -15,13 +15,13 @@ Standards JIG XMPP Core - JEP-0095 + XEP-0095 si-filetransfer - http://jabber.org/protocol/si/profile/file-transfer/file-transfer.xsd + http://www.xmpp.org/schemas/file-transfer.xsd &temas; &linuxwolf; @@ -30,7 +30,7 @@ 1.1 2004-04-13 psa - More fully defined the Jabber Registrar considerations. + More fully defined the XMPP Registrar considerations. 1.1 @@ -93,13 +93,13 @@
      -

      The traditional mechanism for transferring files in the Jabber community is the &jep0066; protocol. That protocol has several drawbacks:

      +

      The traditional mechanism for transferring files in the Jabber community is the &xep0066; protocol. That protocol has several drawbacks:

      1. It is not reliable.
      2. It does not work when one of the parties is behind a firewall.
      3. It provides limited metadata about files to be exchanged.
      -

      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.

      +

      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.
        @@ -131,7 +131,7 @@
      • size - The size, in bytes, of the data to be sent.
      • name - The name of the file that the Sender wishes to send.
      • date - The last modification time of the file. This is - specified using the DateTime profile as described in &jep0082;.
        • + specified using the DateTime profile as described in &xep0082;.
      • hash - The MD5 sum of the file contents.
      The size and name attributes MUST be present in the @@ -171,7 +171,7 @@ at the offset position for the length specified.

      -

      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.

      +

      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.

      Additionally, implementations MAY support other mechanisms.

             @@ -286,28 +286,28 @@       -

      No interaction with &IANA; is required as a result of this JEP.

      +

      No interaction with &IANA; is required as a result of this document.

       - + -

      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:

      +

      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:

      http://jabber.org/protocol/si/profile/file-transfer - JEP-0096 + XEP-0096 A profile for file transfer between any two entities. ]]>       -

      As authorized by &jep0147;, the Jabber Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).

      +

      As authorized by &xep0147;, the XMPP Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).

      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.

      To enable a second entity to send a file, the IRI/URI is of the following form:

      -

      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:

      +

      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:

      sendfile http://jabber.org/protocol/si/profile/file-transfer enables initiation of an inbound file transfer to XMPP entity - JEP-0096 + XEP-0096 ]]>       @@ -349,7 +349,7 @@ xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain&name= ]]> -

      In accordance with JEP-0137, the application SHOULD then initiate a file transfer exchange with by sending a stanza of the following form:

      +

      In accordance with XEP-0137, the application SHOULD then initiate a file transfer exchange with by sending a stanza of the following form:

      @@ -362,7 +362,7 @@ xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain&name= recvfile http://jabber.org/protocol/si/profile/file-transfer enables initiation of an outbound file transfer from XMPP entity - JEP-0096 + XEP-0096 mime-type @@ -399,7 +399,7 @@ xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain&name= 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 @@ -436,4 +436,4 @@ xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain&name= ]]>       - + diff --git a/xep-0097.xml b/xep-0097.xml index 92fecd0d..8aae76a5 100644 --- a/xep-0097.xml +++ b/xep-0097.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
      iCal Envelope A simple mechanism to transport iCal data over the jabber protocol @@ -13,7 +13,7 @@ Deferred Standards Track Standards - JEP-0030 + XEP-0030 None None ice @@ -31,7 +31,7 @@
      -

      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 iCaliCalendar http://www.ietf.org/html.charters/calsch-charter.html. Since iCal is a defined standard which is transport-agnostic, all this JEP will do is define how iCal will be transported over Jabber.

      +

      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 iCaliCalendar http://www.ietf.org/html.charters/calsch-charter.html. Since iCal is a defined standard which is transport-agnostic, all this JEP will do is define how iCal will be transported over Jabber.

      What this JEP will cover:

      • Sending iCal data
        • @@ -117,8 +117,8 @@

        This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA)

         - -

        The 'http://jabber.org/protocol/gw/ical' namespace is registered with the Jabber Registrar as a result of this JEP.

        + +

        The 'http://jabber.org/protocol/gw/ical' namespace is registered with the XMPP Registrar as a result of this JEP.

         @@ -135,4 +135,4 @@
      • How should attachments to ical be handled?
       -       + diff --git a/xep-0098.xml b/xep-0098.xml index ed9c5537..a6e6161f 100644 --- a/xep-0098.xml +++ b/xep-0098.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
      Enhanced Private XML Storage Standardizes "private" XML data storage. @@ -32,7 +32,7 @@

      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: Not Acceptable ]]> -

      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.

      +

      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.

      @@ -253,5 +253,4 @@ SERVER (server responds with success): ]]>       -       - + diff --git a/xep-0099.xml b/xep-0099.xml index 1987496c..157829ab 100644 --- a/xep-0099.xml +++ b/xep-0099.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
      IQ Query Action Protocol Standardizes behavior of &IQ; &QUERY; actions for generic query behavior. @@ -392,5 +392,4 @@ this JEP, you must specify the following:

     -     - +