From 48fc1a37c96b4b1692db4b2219bd4793825e6223 Mon Sep 17 00:00:00 2001 From: stpeter Date: Fri, 24 Jun 2011 15:41:32 -0600 Subject: [PATCH] 0.14rc2 --- xep-0234.xml | 97 ++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 94 insertions(+), 3 deletions(-) diff --git a/xep-0234.xml b/xep-0234.xml index 73c57080..f8081693 100644 --- a/xep-0234.xml +++ b/xep-0234.xml @@ -25,10 +25,20 @@ NOT_YET_ASSIGNED &stpeter; - 0.14rc1 - 2011-06-23 + 0.14rc2 + 2011-06-24 psa -

Defined file description format separate from XEP-0096; modified the checksum format to reuse the <hashes/> element from XEP-0300; removed the 'urn:xmpp:jingle:apps:file-transfer:info:2' namespace by putting all elements into the 'urn:xmpp:jingle:apps:file-transfer:3' namespace; incremented namespace version from 2 to 3.

 + +
    +
  • Defined file description format separate from XEP-0096
    • +
  • Modified the checksum format to reuse the <hashes/> element from incoming proposal
    • +
  • Described the process of aborting a file transfer.
    • +
  • Clarified the order of events (Jingle, then transport) when the session is terminated
    • +
  • Added section on determining spport, including service discovery feature for multi-file support
    • +
  • Removed the 'urn:xmpp:jingle:apps:file-transfer:info:2' namespace by putting all elements into the 'urn:xmpp:jingle:apps:file-transfer:3' namespace
    • +
  • Incremented namespace version from 2 to 3
    • +
+ 0.13 @@ -350,6 +360,7 @@ Initiator Responder ]]> +

After terminating the session, the parties would close the data transport as described in the relevant specification (e.g., XEP-0260 or XEP-0261).

For a description of the transport fallback scenario (from SOCKS5 Bytestreams to In-Band Bytestreams), refer to XEP-0260.

@@ -376,6 +387,45 @@ Initiator Responder ]]> + +

If either party wishes to abort the transfer of a file but not the entire session (e.g., when the parties are exchanging multiple files), it SHOULD send a Jingle session-info message containing an <abort/> child element qualified by the 'urn:xmpp:jingle:apps:file-transfer:3' namespace.

+ + + + + + a749930852c69ae5d2141d3766b1552d + + + + + + ]]> +

If either party wishes to end the entire file transfer session instead of aborting transfer of a particular file, it MUST instead send a session-terminate message containing a reason of <cancel/> as described in XEP-0166.

+ + + + + + + + ]]> +

After terminating the session, the parties would close the data transport as described in the relevant specification (e.g., XEP-0260 or XEP-0261).

+ +

If the entity that hosts a file has advertised its existence (or if a previous file transfer attempt has failed and the receiver would like to initiate another attempt), the entity that wishes to receive the file can "pull" the file from the hosting entity. This is done by sending a Jingle session-initiate to the hosting entity, including a &DESCRIPTION; element qualified by the 'urn:xmpp:jingle:apps:file-transfer:3' namespace and containing a <request/> element that defines the requested file.

a749930852c69ae5d2141d3766b1552d + ]]>

The hosting entity SHOULD NOT wait for arrival of the <received/> acknowledgement before starting to send the next file in its list.

After the recipient has received all of the files, it SHOULD send a final acknowledgement and then terminate the session.

+

After terminating the session, the parties would close the data transport as described in the relevant specification (e.g., XEP-0260 or XEP-0261).

OPEN ISSUE: Provide a way for the hosting entity to add more files to the original "manifest"?

+

Support for transferring multiple files is OPTIONAL. If an application supports multi-file exchange, it MUST advertise a service discovery feature of "urn:xmpp:jingle:apps:file-transfer:multi".

 @@ -646,6 +699,33 @@ Initiator Responder + +

To advertise its support for the Jingle File Transfer, when replying to service discovery information ("disco#info") requests an entity MUST return URNs for any version of this protocol that the entity supports -- e.g., "urn:xmpp:jingle:apps:file-transfer:3" for this version &VNOTE;.

+ + + + ]]> + + + + + + + + + ]]> +

As noted, if an application supports exchange of multiple files, it MUST advertise a service discovery feature of "urn:xmpp:jingle:apps:file-transfer:multi".

+

In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.

+ +

For historical reasons and for backward-compatibility with XEP-0096, the hashing algorithm used in computing the file checksum defaults to MD5. It is RECOMMENDED for implementations to use stronger hashing algorithms.

In order to secure the data stream, implementations SHOULD use encryption methods appropriate to the transport method being used. For example, end-to-end encryption can be negotiated over either SOCKS5 Bytestreams or In-Band Bytestreams as described in XEP-0260 and XEP-0261.

@@ -667,6 +747,17 @@ Initiator Responder &NSVER; + +

The service discovery feature for advertising support for exchange of multiple files is "urn:xmpp:jingle:apps:file-transfer:multi".

+

The registry submission is as follows.

+ + urn:xmpp:jingle:apps:file-transfer:multi + Signals support for exchange of multiple files. + XEP-0234 + + ]]> +

The XMPP Registrar shall include "file-transfer" in its registry of Jingle application formats. The registry submission is as follows: