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

initial version 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@783 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-04-21 03:33:40 +00:00
parent d887f7b0a8
commit 25e6827148
5 changed files with 1017 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

192
xep-0210.xml Normal file
View File

@ -0,0 +1,192 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
<!ENTITY esupy "e<span class='super'>y</span>">
<!ENTITY dsupx "d<span class='super'>x</span>">
<!ENTITY gsupx "g<span class='super'>x</span>">
<!ENTITY gsupy "g<span class='super'>y</span>">
<!ENTITY isPKsubA "isPK<span class='sub'>A</span>">
<!ENTITY isPKsubB "isPK<span class='sub'>B</span>">
<!ENTITY NsubA "N<span class='sub'>A</span>">
<!ENTITY NsubB "N<span class='sub'>B</span>">
<!ENTITY CsubA "C<span class='sub'>A</span>">
<!ENTITY CsubB "C<span class='sub'>B</span>">
<!ENTITY MsubA "M<span class='sub'>A</span>">
<!ENTITY MsubB "M<span class='sub'>B</span>">
<!ENTITY KMsubA "KM<span class='sub'>A</span>">
<!ENTITY KMsubB "KM<span class='sub'>B</span>">
<!ENTITY KCsubA "KC<span class='sub'>A</span>">
<!ENTITY KCsubB "KC<span class='sub'>B</span>">
<!ENTITY KSsubA "KS<span class='sub'>A</span>">
<!ENTITY KSsubB "KS<span class='sub'>B</span>">
<!ENTITY twosup32 "2<span class='super'>32</span>">
<!ENTITY twosup2n "2<span class='super'>2n-1</span>">
<!ENTITY CBeCAx2n1 "&CsubB; = &CsubA; XOR 2<span class='super'>n-1</span>">
<!ENTITY IDA "ID<span class='sub'>A</span>">
<!ENTITY IDB "ID<span class='sub'>B</span>">
<!ENTITY formA "form<span class='sub'>A</span>">
<!ENTITY formB "form<span class='sub'>B</span>">
<!ENTITY formA2 "form<span class='sub'>A2</span>">
<!ENTITY formB2 "form<span class='sub'>B2</span>">
<!ENTITY macA "mac<span class='sub'>A</span>">
<!ENTITY macB "mac<span class='sub'>B</span>">
<!ENTITY signA "sign<span class='sub'>A</span>">
<!ENTITY signB "sign<span class='sub'>B</span>">
<!ENTITY signsA "signs<span class='sub'>A</span>">
<!ENTITY signsB "signs<span class='sub'>B</span>">
<!ENTITY pubKeyA "pubKey<span class='sub'>A</span>">
<!ENTITY pubKeyB "pubKey<span class='sub'>B</span>">
<!ENTITY signKeyA "signKey<span class='sub'>A</span>">
<!ENTITY signKeyB "signKey<span class='sub'>B</span>">
<!ENTITY pubKeysA "pubKeys<span class='sub'>A</span>">
<!ENTITY signKeysA "signKeys<span class='sub'>A</span>">
<!ENTITY x1xZ "x<span class='sub'>1</span>...x<span class='sub'>Z</span>">
<!ENTITY e1eZ "e<span class='sub'>1</span>...e<span class='sub'>Z</span>">
<!ENTITY He1HeZ "He<span class='sub'>1</span>...He<span class='sub'>Z</span>">
<!ENTITY RS1ARSZA "RS<span class='sub'>1A</span>...RS<span class='sub'>ZA</span>">
<!ENTITY RS1BRSZB "RS<span class='sub'>1B</span>...RS<span class='sub'>ZB</span>">
<!ENTITY RSH1ARSHZA "RSH<span class='sub'>1A</span>...RSH<span class='sub'>ZA</span>">
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Requirements for Encrypted Sessions</title>
<abstract>This document describes the requirements for an XMPP end-to-end encrypted session protocol.</abstract>
&LEGALNOTICE;
<number>0210</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<shortname>NOT YET ASSIGNED</shortname>
&ianpaterson;
<revision>
<version>0.1</version>
<date>2007-04-20</date>
<initials>ip</initials>
<remark><p>Initial version (extracted from XEP-0188 version 0.4).</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Existing approaches to encryption of Internet communications have generally assumed that the "thing" to be encrypted has a stable identity or is best understood as a standalone storeable object (e.g., a file or email message); the term "object encryption" well captures this assumption. Both &xep0027; and &rfc3923; assume that XMPP communications are more like the exchange of email messages than they are like an interactive session -- while <cite>Current Jabber OpenPGP Usage</cite> uses "old-style" PGP object encryption and <cite>RFC 3923</cite> uses "new-style" S/MIME object encryption, both specify the use of object encryption. Any new protocol based on &w3xmlenc; and &w3xmlsig;, would also be an "object encryption" protocol.</p>
<p>However, because XMPP is a session-oriented communication technology, encryption schemes that are appropriate for other Internet technologies may not be appropriate for XMPP. XMPP, with its in-order delivery of XML stanzas, is able to take advantage of much more secure approaches to encryption (including Perfect Forward Secrecy) that are not feasible for less dynamic technologies (like email). The focus should be on "session encryption" rather than "object encryption". The paradigm for XMPP encryption should be something closer to the widely-deployed Secure Shell technology (see &rfc4253;) or &zrtp; (an acclaimed SRTP - &rfc3711; - key agreement protocol) or TLS (see &rfc4346;) or IPsec (see &rfc4301;) than to traditional encryption of files and standalone email messages.</p>
<p>The session metaphor applies to communication between any two XMPP endpoints. For instance, in IM applications, most instant messaging exchanges occur in bursts within limited time periods (e.g., two people may send a fairly large number of messages during a five-minute chat and then not exchange messages again for hours or even days). The XML stanzas exchanged during such a session may not be limited to &MESSAGE; stanzas; for instance, the session may be triggered by a change in one of the parties' presence status (e.g., changing from away to available) and the session may involve the exchange of &IQ; stanzas (e.g., to transfer a file as specified in &xep0096;).</p>
</section1>
<section1 topic='Scope' anchor='scope'>
<p>The XMPP communications described above exist in the context of a one-to-one communication session between two entities. However, several forms of XMPP communication exist outside the context of one-to-one communication sessions:</p>
<ul>
<li>Many-to-many sessions, such as a text conference in a chatroom as specified in &xep0045;.</li>
<li>One-to-many "broadcast", such as undirected presence stanzas sent from one user to many contacts (see &rfc3921;) and data syndication implemented using &xep0060;.</li>
<li>One-to-one communications that are stored for later delivery rather than delivered immediately, such as so-called "offline messages".</li>
</ul>
<p>Ideally, any technology for end-to-end encryption in XMPP could be extended to cover all the scenarios above as well as one-to-one communication sessions. However, both many-to-many sessions and one-to-many broadcast are deemed out of scope for this document.</p>
<p>Communications where the receiving entity is offline should ideally be handled via a simple extension to the protocol for one-to-one sessions between two entities that are online simultaneously. This approach enables code reuse, minimises the points of failure and significantly increases the security (for example, by providing Perfect Forward Secrecy).</p>
</section1>
<section1 topic='Security Requirements' anchor='reqs-sec'>
<p>This document stipulates the following security requirements for end-to-end encryption of XMPP communications:</p>
<ul>
<li>Confidentiality</li>
<li>Integrity</li>
<li>Replay protection</li>
<li>Perfect forward secrecy</li>
<li>PKI Independence</li>
<li>Authentication</li>
<li>Identity Protection</li>
<li>Repudiability</li>
<li>Robustness</li>
<li>Upgradability</li>
</ul>
<p>Each of these requirements is explained in greater depth below.</p>
<section2 topic='Confidentiality' anchor='reqs-encrypt'>
<p>The one-to-one XML stanzas exchanged between two entities MUST NOT be understandable to any other entity that might intercept the communications. The encrypted stanzas should be understood by an intermediate server only to the extent required to route them. (One complicating factor is that routing information may include not only the stanza's 'to', 'from', 'type, and 'id' attributes, but also &xep0079; extensions.)</p>
</section2>
<section2 topic='Integrity' anchor='reqs-integrity'>
<p>Alice and Bob MUST be sure that no other entity may change the content of the XML stanzas they exchange, or remove or insert stanzas into the ESession undetected.</p>
</section2>
<section2 topic='Replay Protection' anchor='reqs-replay'>
<p>Alice or Bob MUST be able to identify and reject any communications that are copies of their previous communications resent by another entity.</p>
</section2>
<section2 topic='Perfect Forward Secrecy' anchor='reqs-forward'>
<p>The encrypted communication MUST NOT be revealed even if long-lived keys are compromised in the future (e.g., Steve steals Bob's computer). For long-lived sessions it MUST be possible to periodically change the decryption keys. <note>Long-lived keys are typically used for a few years, whereas Offline ESession keys are destroyed as soon as the stanza is decrypted - they typically exist for just a few hours. So Perfect Forward Secrecy should significantly enhance the security even of Offline ESessions.</note></p>
</section2>
<section2 topic='PKI Independence' anchor='reqs-pki'>
<p>The protocol MUST NOT rely on any public key infrastructure (PKI), certification authority, web of trust, or any other trust model that is external to the trust established between Alice and Bob. However, if external authentication or trust models are available then Alice and Bob MUST be able to use them to enhance any trust that exists between them.</p>
</section2>
<section2 topic='Authentication' anchor='reqs-auth'>
<p>Each party to a conversation MUST know that the other party is who they want to communicate with (Alice must be able to know that Bob really is Bob, and vice versa). <note>Authentication is not identification, authentication may be as simple as Alice confirming that Bob is the same Bob that she communicated with yesterday or that she talked to on the telephone. The reliable association between an entity and its public keys is "identification" and therefore beyond the scope of this document.</note></p>
</section2>
<section2 topic='Identity Protection' anchor='reqs-id-protect'>
<p>No other entity should be able to identify Alice or Bob. The JIDs they use to route their stanzas are unavoidably vulnerable to interception. So, even if Alice and Bob protect their identities by using different JIDs for each session, it MUST be possible for their clients to authenticate them transparently, without any other entity identifying them via an active ("man-in-the-middle") attack, or even linking them to their previous sessions. If that is not possible because Alice and Bob choose to authenticate using public keys instead of retained shared secrets, then the public keys MUST NOT be revealed to other entities using a passive attack. Bob MUST also be able to choose between protecting either his public key or Alice's public key from disclosure through an active attack.</p>
</section2>
<section2 topic='Repudiability' anchor='reqs-repudiate'>
<p>Alice and Bob MUST be able to repudiate any stanza that occurs within an ESession. After an ESession has finished, it MUST NOT be possible to <em>prove cryptographically</em> that any transcript has not been modified by a third party. <note>Naturally, it is possible that Alice or Bob may retain cleartext versions of the exchanged communications; however, that threat is out of scope for this document.</note></p>
</section2>
<section2 topic='Robustness' anchor='reqs-robust'>
<p>The protocol SHOULD provide more than one difficult challenge that has to be overcome before an attack can succeed (for example, by generating encryption keys using as many shared secrets as possible - like retained secrets or optional passwords).</p>
</section2>
<section2 topic='Upgradability' anchor='reqs-upgrade'>
<p>The protocol MUST be upgradable so that, if a vulnerability is discovered, a new version can fix it. Alice MUST tell Bob which versions of the protocol she is prepared to support. Then Bob MUST either choose one or reject the ESession. <note>It is exceptionally difficult to design a truly secure authenticated key-exchange protocol. Weaknesses are often only discovered after years of expert cryptographic analysis. In many cases, only the widespread use of a protocol will motivate experts to undertake exhaustive analyses and recommend enhancements.</note></p>
</section2>
</section1>
<section1 topic='Application Requirements' anchor='reqs-xmpp'>
<p>In addition to the foregoing security profile, this document also stipulates the following application-specific requirements for encrypted communication in the context of Jabber/XMPP technologies:</p>
<ul>
<li>Generality</li>
<li>Implementability</li>
<li>Usability</li>
<li>Efficiency</li>
<li>Flexibility</li>
<li>Offline "sessions"</li>
<li>Interoperability</li>
<li>Object encryption</li>
</ul>
<p>Each of these is explained in greater depth below.</p>
<section2 topic='Generality' anchor='reqs-generality'>
<p>The solution MUST be generally applicable to the full content of any XML stanza type (&MESSAGE;, &PRESENCE;, &IQ;) sent between two entities. It is deemed acceptable if the solution does not apply to many-to-many stanzas (e.g., groupchat messages sent within the context of multi-user chat) or one-to-many stanzas (e.g., presence "broadcasts" and pubsub notifications); end-to-end encryption of such stanzas may require separate solutions.</p>
</section2>
<section2 topic='Implementability' anchor='reqs-implement'>
<p>The only good security technology is an implemented security technology. The solution SHOULD be one that client developers can implement in a relatively straightforward and interoperable fashion.</p>
</section2>
<section2 topic='Usability' anchor='reqs-usable'>
<p>The requirement of usability takes implementability one step further by stipulating that the solution MUST be one that organizations may deploy and humans may use with 100% transparency (with the ease-of-use of https:). Experience has shown that: solutions requiring a full public key infrastructure do not get widely deployed, and solutions requiring any user action are not widely used. If, however, Alice and/or Bob are prepared to verify the integrity of their copies of each other's keys (thus enabling them to discover targeted active attacks or even the mass surveilance of a population), then the actions necessary for them to achieve that MUST be minimal (requiring no more effort than a one-time out-of-band verification of a string of up to 6 alphanumeric characters).</p>
</section2>
<section2 topic='Efficiency' anchor='reqs-efficient'>
<p>Cryptographic operations are highly CPU intensive, particularly public key and Diffie-Hellman operations. Cryptographic data structures can be relatively large, especially public keys and certificates. Network round trips can introduce unacceptable delays, especially over high-latency wireless connections. The solution MUST perform efficiently even when CPU and network bandwidth are constrained. The number of stanzas required for ESession negotiation MUST be minimized.</p>
</section2>
<section2 topic='Flexibility' anchor='reqs-flexible'>
<p>The solution MUST be compatible with a variety of existing (and future) cryptographic algorithms and identity certification schemes (including X.509 and PGP). The protocol MUST also be able to evolve to correct the weaknesses that are inevitably discovered once any cryptographic protocol is in widespread use.</p>
</section2>
<section2 topic='Offline Sessions' anchor='reqs-offline'>
<p>It SHOULD be possible to encrypt one-to-one communications that are stored for later delivery (instead of being delivered immediately - so-called "offline messages") and still benefit from Perfect Forward Secrecy (with a slightly longer period of vulnerability than if both parties were online simultaneously). However, any vulnerabilities introduced into the solution in order to enable such offline communications MUST NOT make online communications more vulnerable.</p>
</section2>
<section2 topic='Interoperability' anchor='reqs-interop'>
<p>Ideally, it would be possible for an XMPP user to exchange encrypted messages (and, potentially, presence information) with users of non-XMPP messaging systems.</p>
</section2>
<section2 topic='Object Encryption' anchor='reqs-object'>
<p>Ideally, it would be possible in cases where a session is not desired, to encrypt, sign and send a single stanza in isolation, so-called "object encryption".</p>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='sec'>
<p>Security issues are discussed throughout this document.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;. </p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This document requires no interaction with the &REGISTRAR;.</p>
</section1>
</xep>

77
xep-0211.xml Normal file
View File

@ -0,0 +1,77 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>XMPP Basic Client 2008</title>
<abstract>This document defines the XMPP Basic Client 2008 compliance level.</abstract>
&LEGALNOTICE;
<number>0211</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>XEP-0030</spec>
<spec>XEP-0115</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>0.1</version>
<date>2007-04-20</date>
<initials>psa</initials>
<remark><p>Initial published version.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2007-03-30</date>
<initials>psa</initials>
<remark><p>First draft, split from XEP-0073.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The &XSF; defines protocol suites for the purpose of compliance testing and software certification. This document specifies the XMPP Basic Client 2008 certification level.</p>
</section1>
<section1 topic='Definition' anchor='def'>
<p>The XMPP Basic Client 2008 certification level is defined as follows:</p>
<table caption='Required and Recommended Specifications'>
<tr>
<th>Specification</th>
<th>Requirement Level</th>
</tr>
<tr>
<td><strong>&rfc3920;</strong></td>
<td>REQUIRED</td>
</tr>
<tr>
<td><strong>&rfc3921;</strong></td>
<td>REQUIRED</td>
</tr>
<tr>
<td><strong>&xep0030;</strong></td>
<td>REQUIRED</td>
</tr>
<tr>
<td><strong>&xep0115;</strong></td>
<td>REQUIRED</td>
</tr>
</table>
<p>Note: Some of these protocols have their own dependencies. In addition, the XMPP RFCs are currently being revised to incorporate errata and feedback based on implementation experience; therefore implementors are advised to refer to &rfc3920bis; and &rfc3921bis; for the most up to date specifications and references.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This document requires no interaction with the &REGISTRAR;.</p>
</section1>
</xep>

84
xep-0212.xml Normal file
View File

@ -0,0 +1,84 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>XMPP Basic Server 2008</title>
<abstract>This document defines the XMPP Basic Server 2008 compliance level.</abstract>
&LEGALNOTICE;
<number>0212</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>XEP-0030</spec>
<spec>XEP-0078</spec>
<spec>XEP-0086</spec>
<spec>XEP-0115</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>0.1</version>
<date>2007-04-20</date>
<initials>psa</initials>
<remark><p>Initial published version.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2007-03-30</date>
<initials>psa</initials>
<remark><p>First draft, split from XEP-0073.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The &XSF; defines protocol suites for the purpose of compliance testing and software certification. This document specifies the XMPP Basic Server 2008 certification level.</p>
</section1>
<section1 topic='Definition' anchor='def'>
<p>The XMPP Basic Server 2008 certification level is defined as follows:</p>
<table caption='Required and Recommended Specifications'>
<tr>
<th>Specification</th>
<th>Requirement Level</th>
</tr>
<tr>
<td><strong>&rfc3920;</strong></td>
<td>REQUIRED</td>
</tr>
<tr>
<td><strong>&rfc3921;</strong></td>
<td>REQUIRED</td>
</tr>
<tr>
<td><strong>&xep0030;</strong></td>
<td>REQUIRED</td>
</tr>
<tr>
<td><strong>&xep0078;</strong></td>
<td>RECOMMENDED*</td>
</tr>
<tr>
<td><strong>&xep0086;</strong></td>
<td>RECOMMENDED*</td>
</tr>
</table>
<p>Some of these protocols have their own dependencies. In addition, the XMPP RFCs are currently being revised to incorporate errata and feedback based on implementation experience; therefore implementors are advised to refer to &rfc3920bis; and &rfc3921bis; for the most up to date specifications and references.</p>
<p>* Note: Support for XEP-0078 and XEP-0086 is recommended for backwards compatibility only. It is likely that compliance definitions for future years will remove these recommendations.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This document requires no interaction with the &REGISTRAR;.</p>
</section1>
</xep>

83
xep-0213.xml Normal file
View File

@ -0,0 +1,83 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>XMPP Intermediate Client 2008</title>
<abstract>This document defines the XMPP Intermediate Client 2008 compliance level.</abstract>
&LEGALNOTICE;
<number>0213</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>XEP-0045</spec>
<spec>XEP-0071</spec>
<spec>XEP-0085</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>0.1</version>
<date>2007-04-20</date>
<initials>psa</initials>
<remark><p>Initial published version.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2007-03-30</date>
<initials>psa</initials>
<remark>First draft, split from XEP-0117.</remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The &XSF; defines protocol suites for the purpose of compliance testing and software certification. This document specifies the XMPP Intermediate Client 2008 certification level.</p>
</section1>
<section1 topic='Definition' anchor='def'>
<p>The XMPP Intermediate Client 2008 certification level is defined as follows:</p>
<table caption='Required and Recommended Specifications'>
<tr>
<th>Specification</th>
<th>Requirement Level</th>
</tr>
<tr>
<td><strong>XMPP Basic Client 2008</strong></td>
<td>REQUIRED</td>
</tr>
<tr>
<td>&xep0045;</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>&xep0071;</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>&xep0085;</td>
<td>REQUIRED</td>
</tr>
</table>
<p>Note: These protocols have their own dependencies, which include the following XEPs (as well as various IETF RFCs and W3C specifications):</p>
<ul>
<li>&xep0004;</li>
<li>&xep0068;</li>
<li>&xep0082;</li>
</ul>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This document requires no interaction with the &REGISTRAR;.</p>
</section1>
</xep>

581
xep-0214.xml Normal file
View File

@ -0,0 +1,581 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>File Repository and Sharing</title>
<abstract>While a protocol has been described for initiating a file transfer from one user to another, there is not yet a way for users to designate a set of files as available for retrieval by other users of their choosing. This extension fills that functionality, with additional features such as file versioning, multiple download mirrors across several internet protocols, collaborative modification of the file listing, and all the other benefits of Pubsub.</abstract>
<legal>This XMPP Extension Protocol is copyright 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSF's Intellectual Property Rights Policy (<link url="http://www.xmpp.org/extensions/ipr-policy.shtml">http://www.xmpp.org/extensions/ipr-policy.shtml</link>). This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<link url="http://creativecommons.org/licenses/by/2.5/">http://creativecommons.org/licenses/by/2.5/</link>).</legal>
<number>0214</number>
<status>Experimental</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0001</spec>
<spec>XEP-0060</spec>
<spec>XEP-0082</spec>
<spec>XEP-0137</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>Not yet assigned</shortname>
<author>
<firstname>Nicholas</firstname>
<surname>Parker</surname>
<email>nickbp@gmail.com</email>
<jid>nickp@jabber.org</jid>
</author>
<revision>
<version>0.1</version>
<date>2007-04-20</date>
<initials>psa</initials>
<remark><p>Initial published version.</p></remark>
</revision>
<revision>
<version>0.0.3</version>
<date>2007-03-18</date>
<initials>nbp</initials>
<remark><p>Added support for Stream Initiation Requests. Clarified purpose of additional mirror types.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2007-01-26</date>
<initials>nbp</initials>
<remark><p>Rewritten to use Pubsub.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2006-09-01</date>
<initials>nbp</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Describes how a Jabber user may find and retrieve files which other Jabber users have published. The listing of files is done through a Pubsub (XEP-0060) server, allowing multiple users to manage the same listing. Other features include file metadata, revisions, and download mirrors.</p>
<p>Retrieval of the files provided in the listing MAY be performed through any relevant protocol for transferring data (http, ftp, etc), but this protocol emphasizes the use of Stream Initiation (XEP-0137) to establish the connection.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>The protocol defined herein provides the following functionality:</p>
<ol>
<li>Publication of a list of available files to a Pubsub server, with tree structure, file metadata, user permissions, and file versioning.</li>
<li>Request that a file be sent from a Jabber contact directly to oneself using Stream Initiation.</li>
</ol>
</section1>
<section1 topic='Glossary' anchor='glossary'>
<table caption="File Sharing Terms">
<tr><th>File Listing</th><td>Top-level Pubsub Collection Node, containing information about files and/or subsections which a user or group of users have published.</td></tr>
<tr><th>Subsection</th><td>Non-Root Collection Node which containts files and/or other subsections.</td></tr>
<tr><th>File</th><td>Pubsub Node, stored within a File Listing, which describes all revisions of a given file. The filename and (optionally) description are provided here.</td></tr>
<tr><th>Revision</th><td>Pubsub Item which describes a given file revision. Other metadata which can vary between revisions is provided here (file size, checksum, available mirrors, etc).</td></tr>
<tr><th>Mirror</th><td>A location which has a given Revision available for download. Additional information about a given Mirror MAY be provided for protocols that require it. A list of available protocols is provided below.</td></tr>
</table>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='File Listing' anchor='list'>
<p>The following use cases describe tasks which are already covered by XEP-0060 in a more generic context. These tasks are explicitly described in order to demonstrate the wide range of capabilities afforded by this system and convey the data structure of the file listing itself. Consult XEP-0060 for the full range of node and user management commands as well as their server responses.</p>
<section3 topic='Publication' anchor='list-publication'>
<p>Juliet wishes to make her sonnets available for retrieval by the public. She creates a Root Pubsub Collection Node which will contain her file listing:</p>
<example caption='Creating a New File Listing'><code><![CDATA[<iq type='set'
from='juliet@capulet.com/balcony'
to='pubsub.shakespeare.lit'
id='create3'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<create node='juliets_sonnets'/>
<configure>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#node_config</value>
</field>
<field var='pubsub#node_type'><value>collection</value></field>
</x>
</configure>
</pubsub>
</iq>
<iq type='set'
from='juliet@capulet.com/balcony'
to='pubsub.shakespeare.lit'
id='config2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<configure node='juliets_sonnets'/>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#meta-data</value>
</field>
<field var='pubsub#title'><value>Juliet's Sonnets</value></field>
<field var='pubsub#description'><value>Optional Description</value></field>
</x>
</configure>
</pubsub>
</iq>
]]></code></example>
<p>Juliet also wishes to add a subsection for her sonnets about Romeo. She creates another Pubsub Collection Node under the Root Node:</p>
<example caption='Adding a Subsection to the Listing'><code><![CDATA[<iq type='set'
from='juliet@capulet.com/balcony'
to='pubsub.shakespeare.lit'
id='create3'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<create node='35227eec194a4f3971a5f3771e9c2271'/>
<configure>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#node_config</value>
</field>
<field var='pubsub#collection'><value>juliets_sonnets</value></field>
<field var='pubsub#node_type'><value>collection</value></field>
</x>
</configure>
</pubsub>
</iq>
<iq type='set'
from='juliet@capulet.com/balcony'
to='pubsub.shakespeare.lit'
id='config2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<configure node='35227eec194a4f3971a5f3771e9c2271'/>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#meta-data</value>
</field>
<field var='pubsub#title'><value>Sonnets About Romeo</value></field>
<field var='pubsub#description'><value>Optional Description</value></field>
</x>
</configure>
</pubsub>
</iq>
]]></code></example>
</section3>
<section3 topic='Subscription' anchor='list-subscription'>
<p>Romeo wishes to view all of Juliet's shared sonnets. To do this, Romeo subscribes to the Root Collection Node:</p>
<example caption='Subscription to entire File Listing'><code><![CDATA[<iq type='set'
from='romeo@montague.net/orchard'
to='pubsub.shakespeare.lit'
id='collsub2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<subscribe jid='romeo@montague.net' node='juliets_sonnets'/>
<options>
<x xmlns='jabber:x:data'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#subscribe_options</value>
</field>
<field var='pubsub#subscription_type'><value>items</value></field>
<field var='pubsub#subscription_depth'><value>all</value></field>
</x>
</options>
</pubsub>
</iq>
]]></code></example>
</section3>
<section3 topic='Addition' anchor='list-addition'>
<p>Juliet has just finished a new sonnet and wishes to announce its availability on her File Listing. She adds the sonnet as a new Pubsub Node stored in her Collection Node, then inserts a first revision of her sonnet as an Item within that Node:</p>
<example caption='Adding a new File'><code><![CDATA[<iq type='set'
from='juliet@capulet.com/balcony'
to='pubsub.shakespeare.lit'
id='create4'>
<pubsub xmlns='http://jabber.org/protocol/pubsub#node_config'>
<create node='a6190c5d38e22452041d1c5798eff3f5'/>
<configure>
<x xmlns='jabber:x:data' type='submit'>
<field var='pubsub#collection'><value>juliets_sonnets</value></field>
</x>
</configure>
</pubsub>
</iq>
<iq type='set'
from='juliet@capulet.com/balcony'
to='pubsub.shakespeare.lit'
id='config2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<configure node='a6190c5d38e22452041d1c5798eff3f5'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#meta-data</value>
</field>
<field var='pubsub#title'><value>sonnet.txt</value></field>
<field var='pubsub#description'><value>Sonnet 42</value></field>
</x>
</configure>
</pubsub>
</iq>
<iq type='set'
from='juliet@capulet.com/balcony'
to='pubsub.shakespeare.lit'
id='publish1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='a6190c5d38e22452041d1c5798eff3f5'>
<item id='1'>
<entry xmlns='http://jabber.org/protocol/fileshare#item_meta-data'>
<size>5623</size>
<modified>2006-12-13T18:30:02Z</modified>
<checksum type="sha1">59282c5db190bdc3b152c5b38363442bfda8ebdd</checksum>
<mime>text/plain</mime>
<description>My Latest Sonnet!</description>
<mirrors>
<mirror type='sipub' description='File Transfer via capulet.com fileserver'>
<sipub xmlns='http://jabber.org/protocol/si-pub'
from='fileserver@capulet.com'
id='publish-sonnet.txt'
mime-type='text/plain'
profile='http://jabber.org/protocol/si/profile/file-transfer'>
<file xmlns='http://jabber.org/protocol/si/profile/file-transfer'
name='sonnet.txt'
size='5623'/>
</sipub>
</mirror>
<mirror type='sipub' description='Jingle HTTP File Transfer via capulet.com fileserver'>
<sipub xmlns='http://jabber.org/protocol/si-pub'
from='fileserver-httpft@capulet.com'
id='publish-sonnet.txt'
mime-type='text/plain'
profile='http://jabber.org/protocol/si/profile/jingle-httpft'>
<description xmlns='http://www.xmpp.org/extensions/xep-XXXX.html#ns'>
<manifest>
<file>
<name>sonnet.txt</name>
</file>
</manifest>
<http>
<url name='source-path'>/source/23A53F01/</url>
<url name='preview-path'>/preview/90266EA1/</url>
</http>
</description>
</sipub>
</mirror>
<mirror type='http' description='Shakespeare.lit Torrent'
address='www.shakespeare.lit'
ref='torrents/sonnet.torrent'/>
<mirror type='http' description='Shakespeare.lit Website'
address='www.shakespeare.lit'
ref='~juliet/sonnet.txt'/>
<mirror type='https' description='Shakespeare.lit Website (SSL)'
address='ssl.shakespeare.lit'
ref='~juliet/sonnet.txt'/>
<mirror type='ftp' description='Shakespeare.lit FTP'
user='guest' pass='guest'
address='files.shakespeare.lit' port='21'
ref='public/sonnet.txt'/>
<mirror type='sftp' description='Shakespeare.lit SFTP'
user='guest' pass='guest'
address='ssh.shakespeare.lit' port='22'
ref='public/sonnet.txt'/>
<mirror type='smb' description='Capulet Intranet SMB Share'
user='guest' pass='guest'
address='smbfiles.capulet.com'
ref='juliet/mysonnets/sonnet.txt'/>
</mirrors>
</entry>
</item>
</publish>
</pubsub>
</iq>
]]></code></example>
<p>The Item ID is set to 1, signifying the first revision for this file. Subsequent revisions/items will have incremented ID values, like one would see in a versioning system such as CVS or SVN. Implementations MAY follow this convention, but are not required to do so. For example, a given implementation may instead mark revisions using version numbers ("Beta 1", "6.2", etc) or use other arbitrary strings. However, no two revisions of a given file may share the same ID.</p>
<p>Here is a listing of the possible metadata in a file revision (Item), each field is OPTIONAL:</p>
<table caption="Revision Metadata">
<tr><th>Size</th><td>The size, in bytes, of the file.</td></tr>
<tr><th>Modified</th><td>The last modified time of the revision. Follows the format described in XEP-0082. If a publisher prefers to only make a single revision available to clients, the publisher MAY instead update this value (and others, such as size and/or checksum) to announce that a new version of the file is available.</td></tr>
<tr><th>Checksum</th><td>A checksum of the revision, using the specified hash algorithm. Acceptable types are "sha512", "sha1", "md5", and "crc32".</td></tr>
<tr><th>Mime</th><td>The file's MIME type.</td></tr>
<tr><th>Description</th><td>Description text for the revision. As an example, could contain release notes.</td></tr>
<tr><th>Mirrors</th><td>A list of mirrors; their properties are defined below. If no downloads are available, MAY be left empty or removed entirely.</td></tr>
</table>
<p>Because Romeo is now subscribed, he receives notice of Juliet's addition:</p>
<example caption='Notification of Addition'><code><![CDATA[<message from='pubsub.shakespeare.lit' to='romeo@montague.net' id='create4'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<collection>
<node id='a6190c5d38e22452041d1c5798eff3f5'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#node_config</value>
</field>
<field var='pubsub#collection'><value>juliets_sonnets</value></field>
</x>
</node>
</collection>
</event>
</message>
<message from='pubsub.shakespeare.lit' to='romeo@montague.net' id='config2'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<configuration node='a6190c5d38e22452041d1c5798eff3f5'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#meta-data</value>
</field>
<field var='pubsub#description'><var>Sonnet 42</var></field>
<field var='pubsub#title'><var>sonnet.txt</var></field>
</x>
</configuration>
</event>
</message>
<message from='pubsub.shakespeare.lit' to='romeo@montague.net' id='foo'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='a6190c5d38e22452041d1c5798eff3f5'>
<item id='1'>
<entry xmlns='http://jabber.org/protocol/fileshare#item_config'>
<size>5623</size>
<modified>2006-12-13T18:30:02Z</modified>
<checksum type="sha1">59282c5db190bdc3b152c5b38363442bfda8ebdd</checksum>
<mime>text/plain</mime>
<description>My Latest Sonnet!</description>
<mirrors>
... MIRRORS ...
</mirrors>
</entry>
</item>
</items>
</event>
</message>
]]></code></example>
<p>The above examples give a listing of available mirror protocols in probable configurations. As described in the <link url="#impl">Implementation Notes</link>, only the sipub mirror type is REQUIRED, the others are only given as examples for common protocols which are not already compatible with SI. Here is a full listing of those protocols and their available settings:</p>
<table caption="Mirror Settings">
<tr><th>Protocol</th>
<th>Description</th><th>Ref</th>
<th>Address</th><th>Port (default)</th>
<th>User</th><th>Pass</th></tr>
<tr><th><link url='#file-requests'>sipub</link></th>
<td>OPTIONAL</td><td></td>
<td></td><td></td>
<td></td><td></td></tr>
<tr><th>http</th>
<td>OPTIONAL</td><td>REQUIRED</td>
<td>REQUIRED</td><td>OPTIONAL (80)</td>
<td>OPTIONAL</td><td>OPTIONAL</td></tr>
<tr><th>https</th>
<td>OPTIONAL</td><td>REQUIRED</td>
<td>REQUIRED</td><td>OPTIONAL (443)</td>
<td>OPTIONAL</td><td>OPTIONAL</td></tr>
<tr><th>ftp</th>
<td>OPTIONAL</td><td>REQUIRED</td>
<td>REQUIRED</td><td>OPTIONAL (21)</td>
<td>OPTIONAL</td><td>OPTIONAL</td></tr>
<tr><th>sftp</th>
<td>OPTIONAL</td><td>REQUIRED</td>
<td>REQUIRED</td><td>OPTIONAL (22)</td>
<td>OPTIONAL</td><td>OPTIONAL</td></tr>
<tr><th>smb</th>
<td>OPTIONAL</td><td>REQUIRED (Incl. Share name)</td>
<td>REQUIRED</td><td>OPTIONAL (445)</td>
<td>OPTIONAL</td><td>OPTIONAL</td></tr>
</table>
<p>The Description field is where an arbitrary description of the mirror MAY be placed. For example, if a File Listing is advertising mirrors which are located in different geographic locations, then this field may be used to specify those locations.</p>
<p>The Ref field is a unique identifier which is used to request the file from the mirror server. In the above examples, it is used as a path to the file.</p>
<p>The address and port fields describe where the file may be retrieved using the specified protocol. If a port is not provided, the default value (specified in parentheses) is assumed.</p>
<p>The User and Pass fields are for providing credentials which, if given by the File Listing, SHOULD be used when requesting the file. For example, an sftp mirror MAY require that the user log in using specified credentials before the file may be retrieved.</p>
</section3>
<section3 topic='New Revisions' anchor='list-newrevisions'>
<p>Juliet has revised her sonnet and wishes to publish the new version, while still leaving the original copy available for retrieval. To do this, she inserts a new Item, representing her new revision, into the file's Node:</p>
<example caption='Adding a new Revision'><code><![CDATA[<iq type='set'
from='juliet@capulet.com/balcony'
to='pubsub.shakespeare.lit'
id='publish1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='a6190c5d38e22452041d1c5798eff3f5'>
<item id='2'>
<entry xmlns='http://jabber.org/protocol/fileshare#item_config'>
<size>6102</size>
<modified>2007-01-13T18:30:02Z</modified>
<checksum type="md5">6aaa20212a99548765b3b15f24f19aaa</checksum>
<checksum type="sha1">97cbc0e445435af94db5cc2133b94ab5faf1399a</checksum>
<mime>text/plain</mime>
<description>A revised copy, fixed some spelling errors.</description>
<mirrors>
<mirror type='ftp' description='Shakespeare.lit FTP'
user='guest' pass='guest'
address='files.shakespeare.lit' port='21'
ref='public/juliet/sonnet2.txt'/>
<mirror type='http' description='Shakespeare.lit Website'
address='www.shakespeare.lit'
ref='~juliet/sonnet2.txt'/>
<mirror type='sipub' description='File Transfer via capulet.com fileserver'>
<sipub xmlns='http://jabber.org/protocol/si-pub'
from='fileserver@capulet.com'
id='publish-sonnet2.txt'
mime-type='text/plain'
profile='http://jabber.org/protocol/si/profile/file-transfer'>
<file xmlns='http://jabber.org/protocol/si/profile/file-transfer'
name='sonnet2.txt'
size='6102'/>
</sipub>
</mirror>
</mirrors>
</entry>
</item>
</publish>
</pubsub>
</iq>
]]></code></example>
</section3>
<section3 topic='Modification/Deletion' anchor='list-deletion'>
<p>Juliet has uploaded a copy of her revised sonnet to a new mirror, and wishes to let her subscribers know about this secondary source. She is able to do this by modifying the revision in question to include a reference to her website, overwriting the existing mirrors in the Item with an updated list:</p>
<example caption='Modifying a Revision'><code><![CDATA[<iq type='set'
from='juliet@capulet.com/balcony'
to='pubsub.shakespeare.lit'
id='publish1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='a6190c5d38e22452041d1c5798eff3f5'>
<item id='2'>
<entry xmlns='http://jabber.org/protocol/fileshare#item_config'>
<mirrors>
<mirror type='ftp' description='Shakespeare.lit FTP'
user='guest' pass='guest'
address='files.shakespeare.lit' port='21'
ref='public/juliet/sonnet2.txt'/>
<mirror type='http' description='Shakespeare.lit Website'
address='www.shakespeare.lit'
ref='~juliet/sonnet2.txt'/>
<mirror type='sipub' description='File Transfer via capulet.com fileserver'>
<sipub xmlns='http://jabber.org/protocol/si-pub'
from='fileserver@capulet.com'
id='publish-sonnet2.txt'
mime-type='text/plain'
profile='http://jabber.org/protocol/si/profile/file-transfer'>
<file xmlns='http://jabber.org/protocol/si/profile/file-transfer'
name='sonnet2.txt'
size='6102'/>
</sipub>
</mirror>
<mirror type='http' description='Shakespeare.lit Boston Mirror'
address='www.capulet.com'
ref='~juliet/sonnet2.txt'/>
</mirrors>
</entry>
</item>
</publish>
</pubsub>
</iq>
]]></code></example>
<p>Juliet now wishes to allow others to contribute to her sonnet collection. She gives owner access for the entire Listing to Romeo, and publisher access to her nurse:</p>
<example caption='Modifying Users'><code><![CDATA[<iq type='set'
from='juliet@capulet.com/balcony'
to='pubsub.shakespeare.lit'
id='ent3'>
<pubsub xmlns='http://jabber.org/protocol/pubsub#owner'>
<affiliations node='juliets_sonnets'>
<affiliation jid='nurse@capulet.com' affiliation='publisher'/>
<affiliation jid='romeo@montague.net' affiliation='owner'/>
</affiliations>
</pubsub>
</iq>
]]></code></example>
<p>Romeo uses his owner access to remove the older revision of Juliet's sonnet:</p>
<example caption='Deleting a Revision'><code><![CDATA[<iq type='set'
from='romeo@montague.net/orchard'
to='pubsub.shakespeare.lit'
id='retract1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<retract node='a6190c5d38e22452041d1c5798eff3f5'>
<item id='1'/>
</retract>
</pubsub>
</iq>
]]></code></example>
<p>Other deletion, modification, and user management operations are available as described in XEP-0060. These examples are provided here to explicitly illustrate the capabilities offered by this system.</p>
</section3>
</section2>
<section2 topic='File Requests' anchor='file-requests'>
<p>Romeo is interested in seeing what files Juliet has made available. To do this, Romeo sends Juliet a request for repositories which she is associated with:</p>
<example caption='Request for File Repository listing'><code><![CDATA[<iq type='get'
from='romeo@montague.net/orchard'
to='juliet@capulet.com'
id='repolistreq'>
<fileshare xmlns='http://jabber.org/protocol/si/profile/fileshare'>
<list/>
</fileshare>
</iq>
]]></code></example>
<p>Juliet responds with a list of Pubsub nodes where she has published files or which she believes would be interesting to Romeo. If no such locations exist, Juliet SHOULD respond with an empty list.</p>
<example caption='File Repository listing'><code><![CDATA[<iq type='get'
from='romeo@montague.net/orchard'
to='juliet@capulet.com'
id='repolist'>
<fileshare xmlns='http://jabber.org/protocol/si/profile/fileshare'>
<list>
<repo address='pubsub.shakespeare.lit'
node='juliets_sonnets' description='My Sonnets'/>
</list>
</fileshare>
</iq>
]]></code></example>
<p>After browsing Juliet's repository, Romeo has chosen to download her sonnet. The most recent revision of this file contains a listing of available mirrors, and one of them is an SI stream. Romeo sends an SI request to that mirror:</p>
<example caption='Request that a file be sent'><code><![CDATA[<iq type='get'
id='sipub-request-0'
from='romeo@montague.net/orchard'
to='fileserver@capulet.com'>
<start xmlns='http://jabber.org/protocol/sipub'
id='publish-sonnet2.txt'/>
</iq>
]]></code></example>
<p>The rest of the negotiation and transfer occurs as described in XEP-0137.</p>
</section2>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>Since Pubsub is used for the File Listing, the access models described in XEP-0060 MUST be followed. Users MUST NOT be able to view or control information in the File Listing to which they do not have access.</p>
<p>Node IDs MAY take the form of "path/to/file.ext", rather than the randomized strings provided in the above use cases. For example, Juliet's sonnet MAY use a Node ID of "juliets_sonnets/sonnet.txt" rather than "a6190c5d38e22452041d1c5798eff3f5", as long as this ID is unique to the PubSub server. Randomized strings were used in order to explicitly illustrate that Node IDs SHOULD NOT be depended upon for storing information about files.</p>
<p>The "sipub" mirror type MUST be implemented by the client, while the other mirror types are entirely OPTIONAL, and are provided only as examples for custom client implementations which desire use of common protocols which are currently incompatible with SI requests.</p>
<p>If user access to files is restricted, the mirror servers and the File Listing server MUST be able to synchronize these restrictions between them. See <link url='#security'>Security Considerations</link>.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>When restricted files are being distributed, mirrors need to know which users have permission to access which files. If mirrors are not provided this information by the File Listing (or some other entity), unauthorized users could request files from mirrors directly, thus bypassing any such restrictions.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>No interaction with the Internet Assigned Numbers Authority (IANA) is required as a result of this XEP.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<p>TODO</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>TODO</p>
</section1>
</xep>