Menu
▾
▴
[Dcplusplus-commit] SF.net SVN: adc:[132] trunk
|
From: <em...@us...> - 2025-05-07 13:45:42
|
Revision: 132
http://sourceforge.net/p/adc/code/132
Author: emtee
Date: 2025-05-07 13:45:18 +0000 (Wed, 07 May 2025)
Log Message:
-----------
Generated HTML documents for respective TXT document
Modified Paths:
--------------
trunk/ADC-EXT.html
trunk/ADC.html
trunk/readme.txt
Modified: trunk/ADC-EXT.html
===================================================================
--- trunk/ADC-EXT.html 2025-05-07 13:39:24 UTC (rev 131)
+++ trunk/ADC-EXT.html 2025-05-07 13:45:18 UTC (rev 132)
@@ -734,9 +734,10 @@
<body class="article">
<div id="header">
<h1>ADC Extensions</h1>
-<span id="author">Fredrik Ullner, ul...@gm...</span><br />
-<span id="revnumber">version 1.0.8,</span>
-<span id="revdate">February 2014</span>
+<span id="author">DC++ Team</span><br />
+<span id="email"><code><<a href="mailto:dcp...@li...">dcp...@li...</a>></code></span><br />
+<span id="revnumber">version 1.0.9,</span>
+<span id="revdate">May 2025</span>
<div id="toc">
<div id="toctitle">Table of Contents</div>
<noscript><p><b>JavaScript must be enabled in your browser to display the table of contents.</b></p></noscript>
@@ -757,9 +758,37 @@
<div class="paragraph"><p>The latest draft of the next version of this document as well as intermediate
and older versions can be downloaded from
$URL: <a href="https://svn.code.sf.net/p/adc/code/trunk/ADC-EXT.txt">https://svn.code.sf.net/p/adc/code/trunk/ADC-EXT.txt</a> $.</p></div>
-<div class="paragraph"><p>This version corresponds to $Revision: 121 $.</p></div>
+<div class="paragraph"><p>This version corresponds to $Revision: 131 $.</p></div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_version_1_0_9_2025_05_07">3. Version 1.0.9, 2025-05-07</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>DC++ Team <<a href="mailto:dcp...@li...">dcp...@li...</a>></p></div>
+<div class="ulist"><ul>
+<li>
+<p>
+Added implementation notes to BLOM
+</p>
+</li>
+<li>
+<p>
+Added <em>CCPM</em> extension for client to client private messages
+</p>
+</li>
+<li>
+<p>
+Editorial updates
+</p>
+</li>
+<li>
+<p>
+Clarified HH field in PING to be an ADC URL
+</p>
+</li>
+</ul></div>
<div class="sect2">
-<h3 id="_version_1_0_8">2.1. Version 1.0.8</h3>
+<h3 id="_version_1_0_8">3.1. Version 1.0.8</h3>
<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2014-02-11</p></div>
<div class="ulist"><ul>
<li>
@@ -815,7 +844,7 @@
</ul></div>
</div>
<div class="sect2">
-<h3 id="_version_1_0_7">2.2. Version 1.0.7</h3>
+<h3 id="_version_1_0_7">3.2. Version 1.0.7</h3>
<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2012-11-22</p></div>
<div class="ulist"><ul>
<li>
@@ -831,7 +860,7 @@
</ul></div>
</div>
<div class="sect2">
-<h3 id="_version_1_0_6">2.3. Version 1.0.6</h3>
+<h3 id="_version_1_0_6">3.3. Version 1.0.6</h3>
<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2010-09-29</p></div>
<div class="ulist"><ul>
<li>
@@ -882,7 +911,7 @@
</ul></div>
</div>
<div class="sect2">
-<h3 id="_version_1_0_5">2.4. Version 1.0.5</h3>
+<h3 id="_version_1_0_5">3.4. Version 1.0.5</h3>
<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2010-09-16</p></div>
<div class="ulist"><ul>
<li>
@@ -908,7 +937,7 @@
</ul></div>
</div>
<div class="sect2">
-<h3 id="_version_1_0_4">2.5. Version 1.0.4</h3>
+<h3 id="_version_1_0_4">3.5. Version 1.0.4</h3>
<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2010-06-29</p></div>
<div class="ulist"><ul>
<li>
@@ -939,7 +968,7 @@
</ul></div>
</div>
<div class="sect2">
-<h3 id="_version_1_0_3">2.6. Version 1.0.3</h3>
+<h3 id="_version_1_0_3">3.6. Version 1.0.3</h3>
<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2010-05-26</p></div>
<div class="ulist"><ul>
<li>
@@ -955,7 +984,7 @@
</ul></div>
</div>
<div class="sect2">
-<h3 id="_version_1_0_2">2.7. Version 1.0.2</h3>
+<h3 id="_version_1_0_2">3.7. Version 1.0.2</h3>
<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2010-04-04</p></div>
<div class="ulist"><ul>
<li>
@@ -966,7 +995,7 @@
</ul></div>
</div>
<div class="sect2">
-<h3 id="_version_1_0_1">2.8. Version 1.0.1</h3>
+<h3 id="_version_1_0_1">3.8. Version 1.0.1</h3>
<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2009-08-04</p></div>
<div class="ulist"><ul>
<li>
@@ -982,7 +1011,7 @@
</ul></div>
</div>
<div class="sect2">
-<h3 id="_version_1_0">2.9. Version 1.0</h3>
+<h3 id="_version_1_0">3.9. Version 1.0</h3>
<div class="paragraph"><p>Jacek Sieka <<a href="mailto:arn...@gm...">arn...@gm...</a>>, 2008-05-02</p></div>
<div class="ulist"><ul>
<li>
@@ -1000,23 +1029,23 @@
</div>
</div>
<div class="sect1">
-<h2 id="_extensions">3. Extensions</h2>
+<h2 id="_extensions">4. Extensions</h2>
<div class="sectionbody">
<div class="sect2">
-<h3 id="_tigr_tiger_tree_hash_support">3.1. TIGR - Tiger tree hash support</h3>
+<h3 id="_tigr_tiger_tree_hash_support">4.1. TIGR - Tiger tree hash support</h3>
<div class="sect3">
-<h4 id="_general">3.1.1. General</h4>
+<h4 id="_general">4.1.1. General</h4>
<div class="paragraph"><p>This extension adds Tiger tree hash support to the base protocol. It is
intended to be used both for identifying files and for purposes such as CID
-generation and password negotiation</p></div>
+generation and password negotiation.</p></div>
</div>
<div class="sect3">
-<h4 id="_tigr_for_shared_files">3.1.2. TIGR for shared files</h4>
+<h4 id="_tigr_for_shared_files">4.1.2. TIGR for shared files</h4>
<div class="paragraph"><p>All files shared by TIGR supporting clients must have been hashed using Merkle
Hash trees, as defined by
-<a href="http://web.archive.org/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html">http://web.archive.org/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html</a>.
+<a href="https://web.archive.org/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html">https://web.archive.org/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html</a>.
The Tiger
-algorithm, as specified by <a href="http://www.cs.technion.ac.il/~biham/Reports/Tiger/">http://www.cs.technion.ac.il/~biham/Reports/Tiger/</a>,
+algorithm, as specified by <a href="https://biham.cs.technion.ac.il/Reports/Tiger/">https://biham.cs.technion.ac.il/Reports/Tiger/</a>,
functions as the hash algorithm. A base segment size of 1024 bytes must be
used when generating the tree, but clients may then discard parts of the tree
as long as at least 7 levels are kept or a block granularity of 64 KiB is
@@ -1030,7 +1059,7 @@
<div class="paragraph"><p>In the file list, each File element carries an additional attribute "TTH"
containing the base32-encoded value of the Tiger tree root.</p></div>
<div class="paragraph"><p>In the GET/GFI type, the full tree may be accessed using the "tthl" type.</p></div>
-<div class="paragraph"><p>"tthl" transfers send the largest set of leaves available) as a binary stream
+<div class="paragraph"><p>"tthl" transfers send the largest set of leaves available as a binary stream
of leaf data, right-to-left, with no spacing in between them. <start_pos>
must be set to 0 and <bytes> to -1 when requesting the data. <bytes> must
contain the total binary size of the leaf stream in SND; by dividing this
@@ -1079,16 +1108,16 @@
</div>
</div>
<div class="sect2">
-<h3 id="_bzip_file_list_compressed_with_bzip2">3.2. BZIP - File list compressed with bzip2</h3>
+<h3 id="_bzip_file_list_compressed_with_bzip2">4.2. BZIP - File list compressed with bzip2</h3>
<div class="paragraph"><p>This extension adds a special file "files.xml.bz2" in the unnamed root of the
share which contains "files.xml" compressed with bzip2 1.0.3+ (www.bzip.org).</p></div>
</div>
<div class="sect2">
-<h3 id="_zlib_compressed_communication">3.3. ZLIB - Compressed communication</h3>
+<h3 id="_zlib_compressed_communication">4.3. ZLIB - Compressed communication</h3>
<div class="paragraph"><p>There are two variants of zlib support, FULL and GET, and only one should be
-used on a each communications channel set up.</p></div>
+used on each communications channel set up.</p></div>
<div class="sect3">
-<h4 id="_zlib_full">3.3.1. ZLIB-FULL</h4>
+<h4 id="_zlib_full">4.3.1. ZLIB-FULL</h4>
<div class="paragraph"><p>If, during SUP negotiation, a peer sends "ZLIF" in its support string, it must
accept two additional commands, ZON and ZOF. Upon reception of ZON the peer
must start decompressing the incoming stream of data with zlib before
@@ -1097,7 +1126,7 @@
chunk of data to allow for decompression by the peer.</p></div>
</div>
<div class="sect3">
-<h4 id="_zlib_get">3.3.2. ZLIB-GET</h4>
+<h4 id="_zlib_get">4.3.2. ZLIB-GET</h4>
<div class="paragraph"><p>The alternative is to send "ZLIG" to indicate that zlib is supported for
binary transfers using the GET command, but not otherwise. A flag "ZL1" is
added to the to the SND command to indicate that the data will come
@@ -1109,7 +1138,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_ping_pinger_extension">3.4. PING - Pinger extension</h3>
+<h3 id="_ping_pinger_extension">4.4. PING - Pinger extension</h3>
<div class="paragraph"><p>This extension can be supported by both clients and hubs, and when present, if hub
supports it, it must send additional information to the client ( otherwise normal
base client).</p></div>
@@ -1117,7 +1146,7 @@
that otherwise it would be impossible to get as a normal user (eg. minimum share,
maximum user count, etc).</p></div>
<div class="sect3">
-<h4 id="_inf">3.4.1. INF</h4>
+<h4 id="_inf">4.4.1. INF</h4>
<div class="paragraph"><p>Contexts : F</p></div>
<div class="paragraph"><p>When the client supporting the PING extension connects, the hub must send its
normal INF along with the following added fields ( none mandatory, if not present,
@@ -1139,8 +1168,8 @@
<tbody>
<tr>
<td align="left" valign="top"><p class="table">HH</p></td>
-<td align="left" valign="top"><p class="table">string</p></td>
-<td align="left" valign="top"><p class="table">Hub Host address ( DNS or IP )</p></td>
+<td align="left" valign="top"><p class="table">url</p></td>
+<td align="left" valign="top"><p class="table">Hub Host address (ADC/ADCS URL address form)</p></td>
</tr>
<tr>
<td align="left" valign="top"><p class="table">WS</p></td>
@@ -1262,7 +1291,7 @@
<pre><code>-pinger- HSUP ADBASE ADPING AD..
-hub- ISUP ADBASE ADPING AD..
-hub- ISID ..
--hub- IINF NIhubname DEcurrent\stopic VE.. HHexample.org:555 WShttp://example.org/ OWmyname UC2231 SS.. SF.. MS0 ML0 MC5000
+-hub- IINF NIhubname DEcurrent\stopic VE.. HHadc://example.org:555 WShttp://example.org/ OWmyname UC2231 SS.. SF.. MS0 ML0 MC5000
- (pinger may disconnect)</code></pre>
</div></div>
</div></div>
@@ -1269,7 +1298,7 @@
</div>
</div>
<div class="sect3">
-<h4 id="_hub_hublist_communication">3.4.2. Hub - Hublist communication</h4>
+<h4 id="_hub_hublist_communication">4.4.2. Hub - Hublist communication</h4>
<div class="paragraph"><p>The same extension goes for hub- hublist communication. This way, the hub
takes the role of the client and the hublist of the server.</p></div>
<div class="paragraph"><p>The hublist may send INF about itself with NI field which would become hublist
@@ -1291,15 +1320,15 @@
</div>
</div>
<div class="sect2">
-<h3 id="_ts_timestamp_in_msg">3.5. TS - Timestamp in MSG</h3>
+<h3 id="_ts_timestamp_in_msg">4.5. TS - Timestamp in MSG</h3>
<div class="paragraph"><p>Timestamp of the moment when the message was sent, expressed in seconds since the Unix Epoch (January 1 1970 00:00:00 GMT).</p></div>
</div>
<div class="sect2">
-<h3 id="_dfav_distributed_favorites">3.6. DFAV - Distributed Favorites</h3>
+<h3 id="_dfav_distributed_favorites">4.6. DFAV - Distributed Favorites</h3>
<div class="paragraph"><p>The idea behind this extension is to generate a public hublist from the users favorite hublist. Implementations should separate between public and private hubs in the favorite hublist of an user, in order not to distribute private hubs where one can not connect to anyway.</p></div>
<div class="paragraph"><p>Signal DFAV in SUP and the INF’s SU field.</p></div>
<div class="sect3">
-<h4 id="_gfa">3.6.1. GFA</h4>
+<h4 id="_gfa">4.6.1. GFA</h4>
<div class="literalblock">
<div class="content">
<pre><code>GFA</code></pre>
@@ -1308,7 +1337,7 @@
<div class="paragraph"><p>Asks all users within the same hub with the correct feature to send all publicly available hubs, in their favorite hub list to the requesting client.</p></div>
</div>
<div class="sect3">
-<h4 id="_rfa">3.6.2. RFA</h4>
+<h4 id="_rfa">4.6.2. RFA</h4>
<div class="literalblock">
<div class="content">
<pre><code>RFA</code></pre>
@@ -1337,7 +1366,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_ucmd_user_commands">3.7. UCMD - User commands</h3>
+<h3 id="_ucmd_user_commands">4.7. UCMD - User commands</h3>
<div class="literalblock">
<div class="content">
<pre><code>CMD name</code></pre>
@@ -1377,7 +1406,7 @@
</table>
</div>
<div class="sect3">
-<h4 id="_keywords">3.7.1. Keywords</h4>
+<h4 id="_keywords">4.7.1. Keywords</h4>
<div class="paragraph"><p>Keywords are specified using "%[keyword]". Unknown keywords must be replaced by the empty string. Additionally, all %-substitutions of the C function "strftime" must be supported.</p></div>
<div class="paragraph"><p>The following tables specify the keywords that must be supported.</p></div>
<div class="paragraph"><p>Client parameters</p></div>
@@ -1444,7 +1473,7 @@
</tr>
<tr>
<td align="left" valign="top"><p class="table">fileMN</p></td>
-<td align="left" valign="top"><p class="table">Specify magnet link. <a href="http://en.wikipedia.org/wiki/Magnet_link">Magnet links</a> are used to reference files across networks and applications. Clients may ignore parameters it does not understand, but are free to pass on the parameters to other programs.</p></td>
+<td align="left" valign="top"><p class="table">Specify magnet link. <a href="https://en.wikipedia.org/wiki/Magnet_link">Magnet links</a> are used to reference files across networks and applications. Clients may ignore parameters it does not understand, but are free to pass on the parameters to other programs.</p></td>
</tr>
</tbody>
</table>
@@ -1466,7 +1495,7 @@
</div>
</div>
<div class="sect3">
-<h4 id="_example_3">3.7.2. Example</h4>
+<h4 id="_example_3">4.7.2. Example</h4>
<div class="exampleblock">
<div class="content">
<div class="paragraph"><p>ICMD ADCH++/Hub\smanagement/Register\snick TTHMSG\s+regnick\s%[userNI]\s%[line:Password\s(leave\sempty\sto\sun-reg)]\s%[line:Level\s(facultative;\sdefaults\sto\syour\sown\slevel\sminus\sone)]\n CT2</p></div>
@@ -1478,10 +1507,10 @@
</div>
</div>
<div class="sect2">
-<h3 id="_blom_bloom_filter">3.8. BLOM- Bloom filter</h3>
+<h3 id="_blom_bloom_filter">4.8. BLOM - Bloom filter</h3>
<div class="paragraph"><p>Bloom filters allow the hub to filter certain searches using bitmap that represents the hashes of the files in the users share. BLOM is an extension that allows hub software to create a map (bloom filter) of the shared files on the hub, but with minimal effort, e.g. the hub doesn’t keep a list of files, but a filter that never produces false negatives but only possible false positives. This can potentially save bandwidth and effort on the client side. When the user updates the share, the client must send an INF containing the flag SF. The hub may at any time request that the client sends an updated version of its bloom filter by sending a GET command to the client. The client will then respond using SND and send the bloom filter binary data.</p></div>
<div class="sect3">
-<h4 id="_legend">3.8.1. Legend</h4>
+<h4 id="_legend">4.8.1. Legend</h4>
<div class="tableblock">
<table rules="all"
frame="border"
@@ -1511,7 +1540,7 @@
</tr>
<tr>
<td align="left" valign="top"><p class="table">p</p></td>
-<td align="left" valign="top"><p class="table">Propability of a false positive</p></td>
+<td align="left" valign="top"><p class="table">Probability of a false positive</p></td>
</tr>
</tbody>
</table>
@@ -1519,7 +1548,7 @@
<div class="paragraph"><p>The hub chooses k, h and m.</p></div>
</div>
<div class="sect3">
-<h4 id="_restrictions">3.8.2. Restrictions</h4>
+<h4 id="_restrictions">4.8.2. Restrictions</h4>
<div class="tableblock">
<table rules="all"
frame="border"
@@ -1543,7 +1572,7 @@
</div>
</div>
<div class="sect3">
-<h4 id="_probability">3.8.3. Probability</h4>
+<h4 id="_probability">4.8.3. Probability</h4>
<div class="tableblock">
<table rules="all"
frame="border"
@@ -1564,7 +1593,7 @@
</div>
</div>
<div class="sect3">
-<h4 id="_protocol_changes">3.8.4. Protocol changes</h4>
+<h4 id="_protocol_changes">4.8.4. Protocol changes</h4>
<div class="paragraph"><p>Signal BLOM in SUP.</p></div>
<div class="paragraph"><p>For the SND type, adds H as message type.</p></div>
<div class="paragraph"><p>For the GET type, adds I as message type.</p></div>
@@ -1593,35 +1622,40 @@
</div>
</div>
<div class="sect3">
-<h4 id="_algorithm">3.8.5. Algorithm</h4>
+<h4 id="_algorithm">4.8.5. Algorithm</h4>
<div class="paragraph"><p>The client constructs the bloom filter by creating a bit array of m bits set to 0 (zero). For each file it then sets to "1" k positions constructed from the file hash. Seeing the file hash as a stream of bits (starting from the lowest bit of the first byte, ending at the highest bit of the last byte), the client should use h bits starting at the first bit of the first byte to create an integer and apply modulo m to get the position in the bit array, then redo the process k times advancing the starting position by h each time.</p></div>
<div class="paragraph"><p>Once the hub has received the bloom filter bit array, for each search command it processes, if it contains a hash search term, it can skip broadcasting the search to a particular client if at least one of the k bits in that clients bit array is "0", calculating positions as the client does when setting bits to "1". The hub has to evaluate the filter for each client that it has a bloom filter for, for each search.</p></div>
</div>
<div class="sect3">
-<h4 id="_probability_calculations">3.8.6. Probability calculations</h4>
+<h4 id="_probability_calculations">4.8.6. Probability calculations</h4>
<div class="paragraph"><p>p = (1 - (1 - 1 / m)<sup>(k * n)</sup>)<sup>k</sup>, thus p becomes smaller as m grows and larger as n grows. Larger m means more bits to transfer but also fewer false positives. The optimum value for k given m and n is (m / n) * ln 2. The largest k supported by a hash of a certain size is b / h, so if the hub wants the smallest p possible, it should choose the smallest possible h which gives the largest k, and then calculate m = k * n/ln 2, checking that the resulting m < 2<sup>h</sup>. 2<sup>h</sup> should much be larger than m (at least 3-4 times), because of how the modulo operator works. Also, with m grows the required bandwidth to transfer the bloom filter, so the hub may wish to cap m. In that case, it should still choose k according to m / n * ln 2, but send an h as big as possible to alleviate biasing problems.</p></div>
</div>
<div class="sect3">
-<h4 id="_sample_implementations">3.8.7. Sample implementations</h4>
+<h4 id="_sample_implementations">4.8.7. Sample implementations</h4>
<div class="sect4">
<h5 id="_tiger">Tiger</h5>
<div class="paragraph"><p>For TTH roots, b is 192 and a reasonable value for h is 24, giving a maximum k = 8 which means that m = 8 * n / ln 2 ≈ 11.5 * n. The required bandwidth then becomes 11.5 * n / 8 bytes, so approximately 1.44 bytes per file in the users share. For 20000 files, m should then be 230016 (taking into account the modulo 64 requirement), giving a p = 0.004, in other words ~99.6% of all searches that don’t match a users share would not be sent, saving valuable upload bandwidth for the hub. The client calculates i valid positions, if x is an array of bytes containing the hash of the file, on a little-endian machine, by doing pos = x[0+i*h/8] | (x[1+i*h/8] << 8) | (x[2+i*h/8] << 16) for i = [0;k). This is of course a special case where h % 8 = 0, the actual algorithm has to take into consideration values for h where the integer crosses byte boundaries.</p></div>
-<div class="paragraph"><p>For test vectors, see the <a href="http://www.adcportal.com/wiki/index.php/Talk:BLOM">ADC wiki talk page</a>.</p></div>
+<div class="paragraph"><p>For test vectors, see the <a href="https://adc.sourceforge.io/wiki/index.php/Talk:BLOM">ADC wiki talk page</a>.</p></div>
</div>
</div>
+<div class="sect3">
+<h4 id="_implementation_notes">4.8.8. Implementation notes</h4>
+<div class="paragraph"><p>Clients do not signal each atomic user update of the share using the SF flag. Instead, they tend to send a cumulative result of multiple updates in a timely fashion. However, an unambiguous summary of the number of hash additions and removals may result in a lack of an update signal. Therefore, hubs are recommended to look for and process INFs containing the SS flag as well, since an incoming SS flag (especially when not accompanied by an SF) may also indicate an update in the hashes, one that occurs without a change in the total number of files shared.</p></div>
+<div class="paragraph"><p>Clients shall strive to signal multiple share updates in an unambiguous manner, thus enabling hubs to request the most accurate and up-to-date version of the client’s bloom filter.</p></div>
</div>
+</div>
<div class="sect2">
-<h3 id="_natt_nat_traversal">3.9. NATT - NAT traversal</h3>
-<div class="paragraph"><p>NAT traversal allow two passive clients to connect to each other. This specification is based on the TCP hole punching algorithm described in <span class="footnote" id="_footnote_Peer-to-Peer Communication Across Network Address Translators"><br />[B. Ford and P. Srisuresh and and D. Kegel. "Peer-to-Peer Communication Across Network Address Translators". In USENIX Technical Conference 2005 - pages 179–192. Online version: <a href="http://www.brynosaurus.com/pub/net/p2pnat/">http://www.brynosaurus.com/pub/net/p2pnat/</a>]<br /></span>.</p></div>
+<h3 id="_natt_nat_traversal">4.9. NATT - NAT traversal</h3>
+<div class="paragraph"><p>NAT traversal allow two passive clients to connect to each other. This specification is based on the TCP hole punching algorithm described in <span class="footnote" id="_footnote_Peer-to-Peer Communication Across Network Address Translators"><br />[B. Ford and P. Srisuresh and and D. Kegel. "Peer-to-Peer Communication Across Network Address Translators". In USENIX Technical Conference 2005 - pages 179–192. Online version: <a href="https://bford.info/pub/net/p2pnat/">https://bford.info/pub/net/p2pnat/</a>]<br /></span>.</p></div>
<div class="paragraph"><p>If a client does not support TCP4 or TCP6, it will send an RCM to the client it is trying to connect to. If the other client also doesn’t support TCP4 (or TCP6 correspondingly), NAT traversal may instead be used. Signal NATT in the INF’s SU field.</p></div>
<div class="paragraph"><p>Do note that the hub must forward I4 or I6 for respective clients' INF.</p></div>
<div class="paragraph"><p>An endpoint is the tuple of IP and port. The "private endpoint port" refers to the outbound port to the connected hub, as seen by the client. Each client must listen for incoming connections on this port. Note that this protocol extension uses only this port for the TCP hole punching, the use of the "public endpoint port" as specified in <span class="footnoteref"><br /><a href="#_footnote_Peer-to-Peer Communication Across Network Address Translators">[Peer-to-Peer Communication Across Network Address Translators]</a><br /></span> is not supported.</p></div>
<div class="sect3">
-<h4 id="_base_rcm_updates">3.9.1. BASE RCM updates</h4>
+<h4 id="_base_rcm_updates">4.9.1. BASE RCM updates</h4>
<div class="paragraph"><p>When receiving an RCM and the client does not support TCP4 or TCP6, and if NAT-T is supported in the remote client, a NAT command should be sent repeating the protocol and token. The port shall be the private endpoint port to the connected hub.</p></div>
</div>
<div class="sect3">
-<h4 id="_nat">3.9.2. NAT</h4>
+<h4 id="_nat">4.9.2. NAT</h4>
<div class="literalblock">
<div class="content">
<pre><code>NAT protocol separator port separator token</code></pre>
@@ -1631,7 +1665,7 @@
<div class="paragraph"><p>Upon receiving this, try and connect to the specified port. An RNT command should be sent repeating the protocol and token. The port shall be the private endpoint. Upon receiving this, try and connect to the specified port.</p></div>
</div>
<div class="sect3">
-<h4 id="_rnt">3.9.3. RNT</h4>
+<h4 id="_rnt">4.9.3. RNT</h4>
<div class="literalblock">
<div class="content">
<pre><code>RNT protocol separator port separator token</code></pre>
@@ -1641,7 +1675,7 @@
<div class="paragraph"><p>Upon receiving this, try and connect to the specified port.</p></div>
</div>
<div class="sect3">
-<h4 id="_example_4">3.9.4. Example</h4>
+<h4 id="_example_4">4.9.4. Example</h4>
<div class="paragraph"><p>Client A is connected to hub A with the private endpoint 1000 and client B is connected to hub A with the private endpoint 2000. Client A has the SID AAAA and client B has the SID BBBB.</p></div>
<div class="exampleblock">
<div class="content">
@@ -1654,7 +1688,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_rf_referrer_notification">3.10. RF - Referrer notification</h3>
+<h3 id="_rf_referrer_notification">4.10. RF - Referrer notification</h3>
<div class="paragraph"><p>Extends the RF field of the INF to STA, allowing a client to notify clients and hubs upon SUP-negotiation from where the C-C or C-H originated from.</p></div>
<div class="tableblock">
<table rules="all"
@@ -1671,7 +1705,7 @@
</table>
</div>
<div class="sect3">
-<h4 id="_example_5">3.10.1. Example</h4>
+<h4 id="_example_5">4.10.1. Example</h4>
<div class="exampleblock">
<div class="content">
<div class="paragraph"><p>CSUP ADBASE (…)</p></div>
@@ -1680,7 +1714,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_qp_upload_queue_notification">3.11. QP - Upload queue notification</h3>
+<h3 id="_qp_upload_queue_notification">4.11. QP - Upload queue notification</h3>
<div class="paragraph"><p>This extension’s purpose is creating a queue on a client, when multiple other clients want to download from it, but they have no slots. Currently, when a slot is being freed, the first connecting client gets it. Other clients that don’t have the luck of getting in time to attempt to download, have to wait again. The client who creates a queue must have a ticket number for each connecting client, which must be kept internally , and a difference between current connecting client’s queue number and the currently uploading client’s be provided to the connecting client, so that the clients are being deserved in the order they originally connected. The client could have a ticket incrementing starting from 1 for each session. Connecting clients must use the same token as they used when originally connected.</p></div>
<div class="tableblock">
<table rules="all"
@@ -1697,7 +1731,7 @@
</table>
</div>
<div class="sect3">
-<h4 id="_example_6">3.11.1. Example</h4>
+<h4 id="_example_6">4.11.1. Example</h4>
<div class="paragraph"><p>The following example will notify that the client’s slots are full and that there are three uploads in the queue.</p></div>
<div class="exampleblock">
<div class="content">
@@ -1706,12 +1740,12 @@
</div>
</div>
<div class="sect2">
-<h3 id="_pfsr_partial_file_sharing">3.12. PFSR - Partial file sharing</h3>
+<h3 id="_pfsr_partial_file_sharing">4.12. PFSR - Partial file sharing</h3>
<div class="paragraph"><p>Partial File Sharing allows sharing of files which are available in user’s download queue or in finished downloads list. As a result of this, new files will be spread much faster over whole network.</p></div>
<div class="paragraph"><p>When client receives search request (SCH), it looks into shared list to see whether requested hash is available between shared files. If it’s found, everything is processed as normally. In other case, it looks into download queue (then, into finished downloads list) and receives a list of available chunks for requested hash. It mustn’t take every chunk, but only that ones which are fully downloaded and has already been verified (e.g. against TTH leaves).</p></div>
<div class="paragraph"><p>The feature should be signalled in SUP as PFSR.</p></div>
<div class="sect3">
-<h4 id="_psr">3.12.1. PSR</h4>
+<h4 id="_psr">4.12.1. PSR</h4>
<div class="literalblock">
<div class="content">
<pre><code>PSR</code></pre>
@@ -1752,9 +1786,9 @@
</div>
</div>
<div class="sect2">
-<h3 id="_lc_locale_specification">3.13. LC - Locale specification</h3>
+<h3 id="_lc_locale_specification">4.13. LC - Locale specification</h3>
<div class="paragraph"><p>This extension’s purpose is to notify the hub which user locale the client is using as well as the default locale for the hub. This allows hubs to customize text sent to clients, depending on language, left-to-right or right-to-left and more. If the hub does not directly support the client’s locale, it should attempt to fall back to the same language group (e.g. hub supports en-US but not en-AU, so falls back to en-US), and if this is not available, then fall back to the hub’s own locale.</p></div>
-<div class="paragraph"><p><a href="http://tools.ietf.org/html/bcp47">BCP47</a> should be used as reference for locale structure.</p></div>
+<div class="paragraph"><p><a href="https://www.rfc-editor.org/info/bcp47">BCP47</a> should be used as reference for locale structure.</p></div>
<div class="tableblock">
<table rules="all"
frame="border"
@@ -1772,7 +1806,7 @@
<div class="paragraph"><p>Note that the standard suggest that the language should be in lowercase and the country in upper case. Note that the country code may be more than two characters. Additionally, dash (<em>-</em>) and underscore (<em>_</em>) are acceptable seperators.</p></div>
</div>
<div class="sect2">
-<h3 id="_hidden_status_for_client_type">3.14. Hidden status for client type</h3>
+<h3 id="_hidden_status_for_client_type">4.14. Hidden status for client type</h3>
<div class="paragraph"><p>This extension will add to the CT field enumeration in the INF to denote a user as "hidden". Other clients shall as appropriate not display the user in user lists etc.</p></div>
<div class="tableblock">
<table rules="all"
@@ -1805,7 +1839,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_invalid_feature_error_code">3.15. "Invalid feature" error code</h3>
+<h3 id="_invalid_feature_error_code">4.15. "Invalid feature" error code</h3>
<div class="paragraph"><p>This extension will add "Invalid feature" as error code in STA. Invalid features are features the hub or client deem inappropriate or simply not welcome. The error code should not be used for features the hub or client does not know of.</p></div>
<div class="tableblock">
<table rules="all"
@@ -1823,7 +1857,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_keyp_certificate_substitution_protection_in_conjunction_with_adcs">3.16. KEYP - Certificate substitution protection in conjunction with ADCS</h3>
+<h3 id="_keyp_certificate_substitution_protection_in_conjunction_with_adcs">4.16. KEYP - Certificate substitution protection in conjunction with ADCS</h3>
<div class="paragraph"><p>This extension adds a simple, but secure way to protect against man-in-the-middle attacks against ADC when wrapped with TLS (1.0 or later). It does not require setting up a CA or signing keys, but that is still possible if desired.</p></div>
<div class="paragraph"><p>The extension introduces a keyprint parameter to the ADCS URI. The keyprint parameter is a hash of the server certificate.</p></div>
<div class="paragraph"><p>The extension also requires clients to publish their own certificates' keyprint in the KP field in the INF. Assuming one trusts the hub enough not to maliciously change the keyprints en route (a reasonable assumption given the hub’s existing position of trust), and given that the connection to the hub has been similarly authenticated (either as above or via a directly downloaded trusted certificate), client-client connections are also protected against attempted man-in-the-middle attacks - without messing around with having to get everyone’s certificates signed in advance.</p></div>
@@ -1845,11 +1879,11 @@
</table>
</div>
<div class="sect3">
-<h4 id="_keyprint_replacement_behaviour">3.16.1. Keyprint replacement behaviour</h4>
+<h4 id="_keyprint_replacement_behaviour">4.16.1. Keyprint replacement behaviour</h4>
<div class="paragraph"><p>If a client receives a KP field in an FINF broadcast via a hub it is connected to using ADCS and a trusted key as above (or otherwise), it should be regarded as the valid and correct keyprint for that client’s IP/port/hub combination, replacing any earlier keyprint for that IP/port/hub combination.</p></div>
</div>
<div class="sect3">
-<h4 id="_keyprint_verification">3.16.2. Keyprint verification</h4>
+<h4 id="_keyprint_verification">4.16.2. Keyprint verification</h4>
<div class="paragraph"><p>When initiating a TLS handshake with a remote host where the keyprint is known, the client can verify that a man-in-the-middle attack is not occurring by checking if the hash given in the keyprint exactly matches that of the certificate presented during the handshake by the remote host.</p></div>
<div class="paragraph"><p>Suppose the client is aware of a remote host’s keyprint and is in the process of connecting to that host. A certificate substitution attack is in place if the hub presents itself with a certificate that does not match and where the certificate is not the root of the valid signature chain covering the certificate.
If the client detects such an attack, the client should abort the connection and notify the user with a message stating, for example, "Crypto error: Detected attempted man-in-the-middle attack, aborting". (This error quite possibly represents a real attempted attack that has been foiled; we may try auto-reconnecting but we should NEVER ignore it, or it will succeed. We may wish to avoid stating the keyprint of the certificate that was actually received.)</p></div>
@@ -1856,7 +1890,7 @@
<div class="paragraph"><p>Optionally, when receiving a TLS handshake, if the client knows what the remote host’s keyprint ought to be, the client could also verify this. However, note that only the initiating side needs to check this for the man-in-the-middle protection to be valid; specifically the hub doesn’t need to remember, or even understand, clients' keyprints.</p></div>
</div>
<div class="sect3">
-<h4 id="_security_considerations">3.16.3. Security Considerations</h4>
+<h4 id="_security_considerations">4.16.3. Security Considerations</h4>
<div class="sect4">
<h5 id="_general_2">General</h5>
<div class="paragraph"><p>The certificates, including the name fields, are sent in the clear during the initial handshake. Therefore it is recommended to avoid identifying marks in the certificates CommonName fields (for example) that would clearly single them out as being TLS keys used by ADCS:, and the CID field most definitely should not appear. Quite possibly no name fields should appear, or they should be blank.</p></div>
@@ -1907,7 +1941,7 @@
</div>
</div>
<div class="sect3">
-<h4 id="_example_7">3.16.4. Example</h4>
+<h4 id="_example_7">4.16.4. Example</h4>
<div class="exampleblock">
<div class="content">
<div class="paragraph"><p>adcs://example.com:1234/?kp=SHA256/G3PJC4F4MQ5KOXGE2MPYJW5EW63IC6M7RN7OS663JLLWN2M5I6FQ</p></div>
@@ -1915,7 +1949,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_sudp_encrypting_udp_traffic">3.17. SUDP - Encrypting UDP traffic</h3>
+<h3 id="_sudp_encrypting_udp_traffic">4.17. SUDP - Encrypting UDP traffic</h3>
<div class="paragraph"><p>This is an extension that allows UDP traffic to be encrypted.</p></div>
<div class="paragraph"><p>While assymetric encryption may be optimal in sense of security, a symmetric cipher will protect perfectly against outside adversaries given the hub-client connections is also running ADCS. New is that senders now create a random IV for their "request command" (e.g. searches) and send it along the "response command" (e.g. search result).</p></div>
<div class="paragraph"><p>Signal SUDP in SUP and in the INF’s SU field.</p></div>
@@ -1938,7 +1972,7 @@
<div class="paragraph"><p>A client that has a response for the command can now encrypt the response message by prepending 16 bytes of random data and afterwards encrypting it with AES/CBC/PKCS5Padding (Cipher/Blockmode/Padding) using 16 zero bytes as IV for CBC.</p></div>
<div class="paragraph"><p>In above scenario, the response would be a RES command.</p></div>
<div class="sect3">
-<h4 id="_decryption_notes">3.17.1. Decryption notes</h4>
+<h4 id="_decryption_notes">4.17.1. Decryption notes</h4>
<div class="paragraph"><p>In the case of searching, the searching client in return for decryption first has to guess which commands it receives are encrypted and which are not. It can do so for example by simply trying decryption with all currently active keys. If a key is wrong or the message was not encrypted, padding will fail and decryption is unsuccessful!</p></div>
<div class="paragraph"><p>Client may otherwise verify if the message is a U-type message, followed by a known command (and a space). If that is not the case, the client takes the most recent key and decrypts. If that succeed, the message is valid.</p></div>
<div class="paragraph"><p>There is a potential chance that decryption succeed with what is a bad key. If that is the case, the client should verify that the data is not garbled.</p></div>
@@ -1946,11 +1980,11 @@
</div>
</div>
<div class="sect2">
-<h3 id="_type_typing_notification">3.18. TYPE - Typing notification</h3>
-<div class="paragraph"><p>This extension adds a typing similar to Jabber’s <a href="http://www.xmpp.org/extensions/xep-0085.html">"Chat state notifications"</a>.</p></div>
+<h3 id="_type_typing_notification">4.18. TYPE - Typing notification</h3>
+<div class="paragraph"><p>This extension adds a typing similar to Jabber’s <a href="https://xmpp.org/extensions/xep-0085.html">"Chat state notifications"</a>.</p></div>
<div class="paragraph"><p>Signal TYPE in SUP and the INF’s SU field.</p></div>
<div class="sect3">
-<h4 id="_tpn">3.18.1. TPN</h4>
+<h4 id="_tpn">4.18.1. TPN</h4>
<div class="literalblock">
<div class="content">
<pre><code>TPN code</code></pre>
@@ -2004,11 +2038,11 @@
</div>
</div>
<div class="sect2">
-<h3 id="_feed_rss_feeds">3.19. FEED - RSS feeds</h3>
-<div class="paragraph"><p>The extension adds <a href="http://en.wikipedia.org/wiki/RSS">RSS feed</a> support.</p></div>
+<h3 id="_feed_rss_feeds">4.19. FEED - RSS feeds</h3>
+<div class="paragraph"><p>The extension adds <a href="https://en.wikipedia.org/wiki/RSS">RSS feed</a> support.</p></div>
<div class="paragraph"><p>Signal FEED in SUP and the INF’s SU field.</p></div>
<div class="sect3">
-<h4 id="_rss">3.19.1. RSS</h4>
+<h4 id="_rss">4.19.1. RSS</h4>
<div class="literalblock">
<div class="content">
<pre><code>RSS url</code></pre>
@@ -2061,7 +2095,7 @@
</div>
</div>
<div class="sect3">
-<h4 id="_examples">3.19.2. Examples</h4>
+<h4 id="_examples">4.19.2. Examples</h4>
<div class="paragraph"><p>Publish a new feed called <em>Example_feed</em> and with a description <em>description_of_feed</em>:</p></div>
<div class="exampleblock">
<div class="content">
@@ -2080,7 +2114,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_sega_grouping_of_file_extensions_in_sch">3.20. SEGA - Grouping of file extensions in SCH</h3>
+<h3 id="_sega_grouping_of_file_extensions_in_sch">4.20. SEGA - Grouping of file extensions in SCH</h3>
<div class="paragraph"><p>In BASE, clients add EX fields to SCH to denote which extension files should have. This can lead to a situation where the large bulk of extensions are of similar "type", e.g. audio files or documents. This extension intend to add a field GR which groups multiple extensions. In addition, the field RX shall be used for group-exclusion; if all extensions in a group but two are desired, field RX will be used to exclude those group items.</p></div>
<div class="paragraph"><p>Signal SEGA in the INF’s SU field for support of this extension.</p></div>
<div class="paragraph"><p>Field GR values, where multiple groups are specified by adding the numbers together:</p></div>
@@ -2142,7 +2176,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_fo_failover_hub_addresses">3.21. FO - Failover hub addresses</h3>
+<h3 id="_fo_failover_hub_addresses">4.21. FO - Failover hub addresses</h3>
<div class="paragraph"><p>If a hub goes down, the client’s only option is to keep re-trying the last known hub address. This extension will add a list of failover hub addresses, field FO, that the client can try to connect to, if the main hub address fail.</p></div>
<div class="paragraph"><p>Clients should decide the frequency of connection attempts (for the main hub as well as the failover addresses). The client should try connecting in the specified order. The client may decide what to do after the FO-list is exhausted, but recommended is to try to connect to the main hub and continue with the list as before.</p></div>
<div class="paragraph"><p>The client should display an appropriate message to the user that it has connected to a failover address.</p></div>
@@ -2164,7 +2198,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_fs_free_slots_in_client">3.22. FS - Free slots in client</h3>
+<h3 id="_fs_free_slots_in_client">4.22. FS - Free slots in client</h3>
<div class="paragraph"><p>This is an extension that will broadcast the amount of free slots the client has available.</p></div>
<div class="paragraph"><p>Field FS in the client’s INF:</p></div>
<div class="tableblock">
@@ -2183,20 +2217,20 @@
</div>
</div>
<div class="sect2">
-<h3 id="_adcs_symmetrical_encryption_in_adc">3.23. ADCS - Symmetrical Encryption in ADC</h3>
+<h3 id="_adcs_symmetrical_encryption_in_adc">4.23. ADCS - Symmetrical Encryption in ADC</h3>
<div class="paragraph"><p>ADCS is an extension that has the goal of adding the TLS/SSL layer just over the TCP layer and beneath the application layer (where ADC runs). This way, the ADC protocol remains unchanged while the connections are encrypted. The connecting party performs a TLS handshake immediately after the TCP connection is established. The ADC handshake is performed and once the TLS connection is established the ADC handshake proceeds as usual.</p></div>
<div class="paragraph"><p>Encrypted ADC connections can be established using a TLS tunnel, both for hub and for client connections. Certificates can be used to authenticate both hub and user, for example by making the hub the root CA, and only allow clients signed by the hub to connect. Ephemeral keys should be use to ensure forward secrecy when possible. A future extension or revision of this extension will provide ways to handle certificate based logins, who creates which certificates and who signs what, and all that is not specified in this revision.</p></div>
<div class="sect3">
-<h4 id="_client_hub_encryption">3.23.1. Client-Hub encryption</h4>
+<h4 id="_client_hub_encryption">4.23.1. Client-Hub encryption</h4>
<div class="paragraph"><p>TLS client-hub connections can be initiated either by negotiating the feature "ADCS" on connection or by using the protocol adcs:// when initiating the connection.</p></div>
</div>
<div class="sect3">
-<h4 id="_client_client_encryption">3.23.2. Client-Client encryption</h4>
+<h4 id="_client_client_encryption">4.23.2. Client-Client encryption</h4>
<div class="paragraph"><p>TLS client-client connections can be established either by negotiating the feature "ADCS" on connection or by specifying "ADCS/1.0" in the CTM protocol field. Clients supporting encrypted connections must indicate this in the INF SU field with "ADCS".</p></div>
</div>
</div>
<div class="sect2">
-<h3 id="_application_and_version_separation_in_inf">3.24. Application and version separation in INF</h3>
+<h3 id="_application_and_version_separation_in_inf">4.24. Application and version separation in INF</h3>
<div class="paragraph"><p>This extension adds the parameter <em>AP</em> to the INF to signal application. The current parameter in BASE, VE, will be used for version signalling.</p></div>
<div class="paragraph"><p>Example:</p></div>
<div class="exampleblock">
@@ -2205,7 +2239,7 @@
</div></div>
</div>
<div class="sect2">
-<h3 id="_onid_online_identification">3.25. ONID - Online identification</h3>
+<h3 id="_onid_online_identification">4.25. ONID - Online identification</h3>
<div class="paragraph"><p>The purpose of the OID and OIR commands is to allow users to exchange information about their accounts on various online services. The OID name has been intentionally chosen to be similar to OpenID, although its spread is broader.</p></div>
<div class="paragraph"><p>New commands are preferrable here over new INF fields to avoid clogging up its 2-letter identifiers. They also allow for more flexibility: multiple profiles of the same type (OIR only); multiple identification parameters.</p></div>
<div class="paragraph"><p>The OID command is similar to INF, guaranteeing up-to-date information, whereas OIR follows a request/response scheme. OIR parties are therefore not required to keep their OIR information up-to-date.</p></div>
@@ -2225,7 +2259,7 @@
</ul></div>
<div class="paragraph"><p>OID and OIR commands support all contexts (hub-client, client-client). They are allowed in client-client contexts were users to want to avoid their OID/OIR information travelling through hubs. Both clients and hubs MAY provide each other with OID/OIR information.</p></div>
<div class="sect3">
-<h4 id="_oid">3.25.1. OID</h4>
+<h4 id="_oid">4.25.1. OID</h4>
<div class="literalblock">
<div class="content">
<pre><code>OID service</code></pre>
@@ -2236,7 +2270,7 @@
<div class="paragraph"><p>Clients MAY send OID commands to other clients on hubs that do not advertise ONID support.</p></div>
</div>
<div class="sect3">
-<h4 id="_oir">3.25.2. OIR</h4>
+<h4 id="_oir">4.25.2. OIR</h4>
<div class="literalblock">
<div class="content">
<pre><code>OIR service</code></pre>
@@ -2247,7 +2281,7 @@
<div class="paragraph"><p>Any party MAY at any time send an OIR response without any prior request.</p></div>
</div>
<div class="sect3">
-<h4 id="_examples_2">3.25.3. Examples</h4>
+<h4 id="_examples_2">4.25.3. Examples</h4>
<div class="tableblock">
<table rules="all"
frame="border"
@@ -2291,7 +2325,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_adcs_transfers_are_required_error_code">3.26. "ADCS transfers are required" error code</h3>
+<h3 id="_adcs_transfers_are_required_error_code">4.26. "ADCS transfers are required" error code</h3>
<div class="paragraph"><p>This extension will add "ADCS transfers are required" as error code in STA. A client that has chosen to only allow encrypted transfers (with ADCS) should send this when a user without ADCS support tries to initiate a connection (via CTM/RCM etc).</p></div>
<div class="tableblock">
<table rules="all"
@@ -2309,7 +2343,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_asch_extended_searching_capability">3.27. ASCH - Extended searching capability</h3>
+<h3 id="_asch_extended_searching_capability">4.27. ASCH - Extended searching capability</h3>
<div class="paragraph"><p>This extension will increase searching capability in BASE. The extension also imply that searching in partial file lists are now easier.</p></div>
<div class="paragraph"><p>Signal ASCH in the INF’s SU field.</p></div>
<div class="paragraph"><p>The SCH command is extended to request a response (STA) indicating how many search results were sent. This will allow clients to indicate that all search results have been received (and can aptly indicate as such to the user). STA severity 0 and code 00 should be used.</p></div>
@@ -2453,7 +2487,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_em_date_em_attribute_in_file_list_for_files_and_directories">3.28. <em>Date</em> attribute in file list for files and directories</h3>
+<h3 id="_em_date_em_attribute_in_file_list_for_files_and_directories">4.28. <em>Date</em> attribute in file list for files and directories</h3>
<div class="paragraph"><p>This extension adds a <em>Date</em> attribute to files and directories in a file list. The attribute is the last modified date of the file or directory. Time specified is seconds since the Unix epoch.</p></div>
<div class="paragraph"><p>Implementations should be conservative when it includes the Date attribute. Only including the attribute in partial file lists can decrease overall network load requirements.</p></div>
<div class="paragraph"><p>The following changes are done to the file list XML schema:</p></div>
@@ -2469,7 +2503,7 @@
</div></div>
</div>
<div class="sect2">
-<h3 id="_em_size_em_attribute_in_file_list_for_directories">3.29. <em>Size</em> attribute in file list for directories</h3>
+<h3 id="_em_size_em_attribute_in_file_list_for_directories">4.29. <em>Size</em> attribute in file list for directories</h3>
<div class="paragraph"><p>This extension adds a <em>Size</em> attribute to directories in a file list. The attribute is the size of the directory as indicated in a RES.</p></div>
<div class="paragraph"><p>Implementations should be conservative when it includes the Size attribute.</p></div>
<div class="paragraph"><p>This attribute only makes sense in partial file lists (as it can be calculated in full lists).</p></div>
@@ -2481,7 +2515,7 @@
</div></div>
</div>
<div class="sect2">
-<h3 id="_em_children_em_attribute_in_file_list_for_directories">3.30. <em>Children</em> attribute in file list for directories</h3>
+<h3 id="_em_children_em_attribute_in_file_list_for_directories">4.30. <em>Children</em> attribute in file list for directories</h3>
<div class="paragraph"><p>This extension adds a <em>Children</em> attribute to directories in a file list. The attribute indicates whether there are additional sub-directories.</p></div>
<div class="paragraph"><p>Value <em>1</em> indicate that there are children.</p></div>
<div class="paragraph"><p>This attribute only makes sense in partial file lists.</p></div>
@@ -2498,7 +2532,7 @@
</div></div>
</div>
<div class="sect2">
-<h3 id="_downloaded_progress_report_for_uploaders_in_get">3.31. Downloaded progress report for uploaders in GET</h3>
+<h3 id="_downloaded_progress_report_for_uploaders_in_get">4.31. Downloaded progress report for uploaders in GET</h3>
<div class="paragraph"><p>The info in the current GET command does not permit displaying relative upload progress for the uploading party (for the whole file).</p></div>
<div class="paragraph"><p>To address this, this extension will add an additional field to the GET command for current downloaded (and verified) bytes before the request has been sent. While still not entirely accurate with this information, the uploader can see how much of the file the requesting party actually has instead of either assuming that the requester has the file up to the start position of the request or being forced to only show the progress of the currently requested part of the file. There is potentially a slight delay in the reporting of this info in scenarios where more than one segment of a file is simultaneously requested (by the downloader) and the uploader still lacks information about how many other sources the file is being downloaded from.</p></div>
<div class="tableblock">
@@ -2517,16 +2551,16 @@
</div>
</div>
<div class="sect2">
-<h3 id="_rdex_redirects_extended">3.32. RDEX - Redirects Extended</h3>
+<h3 id="_rdex_redirects_extended">4.32. RDEX - Redirects Extended</h3>
<div class="paragraph"><p>The goal of this extension is to enhance the redirect capabilities provided by BASE by adding support for two new redirect operations and a way for hubs and clients to communicate accepted redirect protocols. It also attempts to make the concept of redirects more unambiguous and less implementation defined. The two new types of redirects added are a multiple choice redirect and so-called permanent redirect as outlined below. These new redirect types are not necessarily mutually exclusive.</p></div>
<div class="sect3">
-<h4 id="_redirect_security">3.32.1. Redirect Security</h4>
+<h4 id="_redirect_security">4.32.1. Redirect Security</h4>
<div class="paragraph"><p>Hubs should always aim to include as much information pertaining to a redirect as possible using other fields defined in BASE. Clients may, for example, rely on the availability of such information to check the origin of a redirect before making irreversible decisions, such as accepting a redirect as permanent as defined below.</p></div>
<div class="paragraph"><p>Clients should not attempt to connect to an unreachable or otherwise invalid destination resources indefinitely or in otherwise abusive manner when responding to redirects. Whether clients respond to redirects using default user information or the same information as used on the hub that initiated the redirect is implementation defined, however, in the case that the same information is used careful consideration should be taken when it comes to automatically sending sensitive information such as passwords to other hubs especially if it provides less security to the user than the original hub.</p></div>
<div class="paragraph"><p>Both clients and hubs should also take note that the TL field, as defined by BASE, should only impact the current hub and its connection (if re-established) thus it should not be relied on to trigger a delayed response to a redirect.</p></div>
</div>
<div class="sect3">
-<h4 id="_accepted_redirect_protocols">3.32.2. Accepted Redirect Protocols</h4>
+<h4 id="_accepted_redirect_protocols">4.32.2. Accepted Redirect Protocols</h4>
<div class="paragraph"><p>Support for this extension is indicated by the presence of an RP field in the INF, which defines the accepted redirect protocols for the hub or a client as a bitmask using any combination of following values. Additional compatible values may be defined by other extensions.</p></div>
<div class="tableblock">
<table rules="all"
@@ -2571,17 +2605,17 @@
<div class="paragraph"><p>Clients should refrain from removing support of a previously signalled redirect protocol from their RP field. It is up to the hub to decide a corresponding course of action should the client do so. Additionally a special case is defined for clients as an RP field with the value of zero to indicate that the client may not react to redirects as defined by BASE or this extension at all or may do so only as a result of user action. As such clients defining a non-zero RP field should follow redirects to accepted protocols automatically and conversely any attempts to redirect clients that define RP as zero should result in normal disconnection as per BASE.</p></div>
</div>
<div class="sect3">
-<h4 id="_multiple_choice_redirect">3.32.3. Multiple Choice Redirect</h4>
+<h4 id="_multiple_choice_redirect">4.32.3. Multiple Choice Redirect</h4>
<div class="paragraph"><p>Multiple choice redirect is defined as a redirect where instead of a single destination resource a set of resource identifiers is provided. The methodology that is used to select the final destination resource for a multiple choice redirect is implementation defined. However, only one final destination resource may be chosen. For example a particular implementation may prefer one protocol over another, encrypted connection over an unencrypted one or even simply choose one at random.</p></div>
<div class="paragraph"><p>This type of redirect is signalled by the presence of an additional RX field in the QUI as defined for redirects by BASE. The value of the RX field is a comma separated list of resource identifiers to use in the redirect. The RD field should be defined for maximum compatibility and clients should add its value to the list of identifiers defined in RX when selecting the final destination resource.</p></div>
</div>
<div class="sect3">
-<h4 id="_permanent_redirect">3.32.4. Permanent Redirect</h4>
+<h4 id="_permanent_redirect">4.32.4. Permanent Redirect</h4>
<div class="paragraph"><p>Permanent redirect is defined as a redirect with reference updating. In the case of a permanent redirect, if and only if a successful connection is made to the destination resource, the connecting party will then update all relevant references of the original resource to the destination resource. Examples of such references may be hublist records for pingers or favorite entries for clients.</p></div>
<div class="paragraph"><p>This type of redirect is signalled by the presence of an additional PT field in the QUI, as defined for redirects by BASE, with the value of one. Upon receiving such redirect clients will proceed to update references as outlined above provided the conditions are met.</p></div>
</div>
<div class="sect3">
-<h4 id="_examples_3">3.32.5. Examples</h4>
+<h4 id="_examples_3">4.32.5. Examples</h4>
<div class="paragraph"><p>Multiple Choice Redirect (BASE compliant)</p></div>
<div class="tableblock">
<table rules="all"
@@ -2672,14 +2706,40 @@
</div>
</div>
</div>
+<div class="sect2">
+<h3 id="_ccpm_client_to_client_private_messages">4.33. CCPM - Client to client private messages</h3>
+<div class="paragraph"><p>This extension adds support for private messages in a client to client context. The extension adds support for the C-type for MSG, and uses the field "PM" in the (C-type) INF to signal that the connection should be used for private messages. Implementations supporting this extension must signal "CCPM" in the SU field of their hub-targeted INF.</p></div>
+<div class="paragraph"><p>Implementations should differentiate between a C-C transfer connection and a C-C private message connection, so as to allow transfers and chat at the same time. The initiating client should issue a secondary CTM/RCM sequence to deal with the other connection. Implementations shall disallow GET (and other file transfer commands) in the private message connection.</p></div>
+<div class="paragraph"><p>Implementations are strongly discouraged but may choose to allow private messages in unencrypted connections.</p></div>
+<div class="paragraph"><p>Implementations may choose for which users that are allowed to send them private messages, so as to avoid spam (e.g., only trusted users, hub operators etc may initiate a C-C private message).</p></div>
+<div class="paragraph"><p>Absence of the "PM" field from the (C-type) INF shall cause a disconnect of the connection (with an appropriate STA).</p></div>
+<div class="paragraph"><p>Implementations may decide what to do when the hub connection is lost during a private message connection.</p></div>
+<div class="paragraph"><p>Implementations should adhere to any requirements the DI field in the QUI command in BASE poses regarding non-file transfer connections. Further actions beyond that are up to implementations.</p></div>
+<div class="paragraph"><p>The same port may, but needn’t be, reused for a file transfer connection and a private message connection. Concurrent connections may be rendered unfeasible with extensions such as NATT.</p></div>
+<div class="paragraph"><p>The "PM" field of the MSG command should not be used in C-C private messages.</p></div>
+<div class="tableblock">
+<table rules="all"
+frame="border"
+cellspacing="0" cellpadding="4">
+<col />
+<col />
+<tbody>
+<tr>
+<td align="left" vali...
[truncated message content] |
