diff options
Diffstat (limited to 'draft-schanzen-r5n.xml')
-rw-r--r-- | draft-schanzen-r5n.xml | 90 |
1 files changed, 45 insertions, 45 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml index 33eb456..e5b8218 100644 --- a/draft-schanzen-r5n.xml +++ b/draft-schanzen-r5n.xml | |||
@@ -223,13 +223,13 @@ gnunet+tcp://12.3.4.5/ | |||
223 | </dd> | 223 | </dd> |
224 | <dt>HELLO block</dt> | 224 | <dt>HELLO block</dt> |
225 | <dd> | 225 | <dd> |
226 | A HELLO block is a block with a dedicated block type and is specified in this document. | 226 | A <tt>HELLO</tt> block is a block with a dedicated block type and is specified in this document. |
227 | The HELLO block is used to store and retrieve Peer addresses. | 227 | The <tt>HELLO</tt> block is used to store and retrieve Peer addresses. |
228 | In this document, HELLO blocks are used by the peer discovery mechanism. | 228 | In this document, <tt>HELLO</tt> blocks are used by the peer discovery mechanism. |
229 | </dd> | 229 | </dd> |
230 | <dt>HELLO URL</dt> | 230 | <dt>HELLO URL</dt> |
231 | <dd> | 231 | <dd> |
232 | HELLO URLs are URL-formatted HELLO blocks. | 232 | <tt>HELLO</tt> URLs are URL-formatted <tt>HELLO</tt> blocks. |
233 | They can used for out-of-band exchanges of peer information and are used for | 233 | They can used for out-of-band exchanges of peer information and are used for |
234 | address update signalling messages to neighbours. | 234 | address update signalling messages to neighbours. |
235 | </dd> | 235 | </dd> |
@@ -523,7 +523,7 @@ Connectivity | |Underlay| |Underlay| | |||
523 | local peer and that henceforth the peer may be reachable under this address. | 523 | local peer and that henceforth the peer may be reachable under this address. |
524 | This information is used to advertise | 524 | This information is used to advertise |
525 | connectivity information about the local peer to other peers. | 525 | connectivity information about the local peer to other peers. |
526 | <tt>A</tt> must be a URI suitable for inclusion in a HELLO payload | 526 | <tt>A</tt> must be a URI suitable for inclusion in a <tt>HELLO</tt> payload |
527 | <xref target="hello_block"/>. | 527 | <xref target="hello_block"/>. |
528 | </dd> | 528 | </dd> |
529 | <dt> | 529 | <dt> |
@@ -679,10 +679,10 @@ Connectivity | |Underlay| |Underlay| | |||
679 | Furthermore, the Underlay <bcp14>SHOULD</bcp14> provide the implementation with one or more | 679 | Furthermore, the Underlay <bcp14>SHOULD</bcp14> provide the implementation with one or more |
680 | addresses signalled through <tt>ADDRESS_ADDED</tt>. Zero addresses <bcp14>MAY</bcp14> be | 680 | addresses signalled through <tt>ADDRESS_ADDED</tt>. Zero addresses <bcp14>MAY</bcp14> be |
681 | provided if a peer can only establish outgoing connections and is otherwise unreachable. | 681 | provided if a peer can only establish outgoing connections and is otherwise unreachable. |
682 | <!-- FIXME: What about HelloMessages? What is the distinction between HELLO blocks | 682 | <!-- FIXME: What about HelloMessages? What is the distinction between <tt>HELLO</tt> blocks |
683 | and HELLO messages? --> | 683 | and <tt>HELLO</tt> messages? --> |
684 | The implementation periodically advertises all | 684 | The implementation periodically advertises all |
685 | active addresses in a HELLO block <xref target="hello_block"/>. | 685 | active addresses in a <tt>HELLO</tt> block <xref target="hello_block"/>. |
686 | </t> | 686 | </t> |
687 | </section> | 687 | </section> |
688 | <section anchor="routing_bloomfilter"> | 688 | <section anchor="routing_bloomfilter"> |
@@ -1227,7 +1227,7 @@ BEGIN | |||
1227 | it <bcp14>MAY</bcp14> disseminate those changes to neighbors using | 1227 | it <bcp14>MAY</bcp14> disseminate those changes to neighbors using |
1228 | <tt>HelloMessage</tt>s. | 1228 | <tt>HelloMessage</tt>s. |
1229 | <!-- FIXME yesyes this is blabla and obvious when reading the processing section. | 1229 | <!-- FIXME yesyes this is blabla and obvious when reading the processing section. |
1230 | In contrast to a HELLO block, a | 1230 | In contrast to a <tt>HELLO</tt> block, a |
1231 | <tt>HelloMessage</tt> does not contain the ID of | 1231 | <tt>HelloMessage</tt> does not contain the ID of |
1232 | the peer the address information is about: in a | 1232 | the peer the address information is about: in a |
1233 | <tt>HelloMessage</tt>, the address information is always | 1233 | <tt>HelloMessage</tt>, the address information is always |
@@ -1244,7 +1244,7 @@ BEGIN | |||
1244 | a peer about the sender's available addresses. The | 1244 | a peer about the sender's available addresses. The |
1245 | recipients use these messages to inform their respective | 1245 | recipients use these messages to inform their respective |
1246 | Underlays about ways to sustain the connections and to | 1246 | Underlays about ways to sustain the connections and to |
1247 | generate HELLO blocks (see <xref target="hello_block"/>) | 1247 | generate <tt>HELLO</tt> blocks (see <xref target="hello_block"/>) |
1248 | to answer peer discovery queries | 1248 | to answer peer discovery queries |
1249 | from other peers. | 1249 | from other peers. |
1250 | </t> | 1250 | </t> |
@@ -1287,14 +1287,14 @@ BEGIN | |||
1287 | is a 64 byte EdDSA signature using the sender's private | 1287 | is a 64 byte EdDSA signature using the sender's private |
1288 | key affirming the information contained in the message. | 1288 | key affirming the information contained in the message. |
1289 | The signature is signing exactly the same data that is being | 1289 | The signature is signing exactly the same data that is being |
1290 | signed in a HELLO block as described in <xref target="hello_block"/>. | 1290 | signed in a <tt>HELLO</tt> block as described in <xref target="hello_block"/>. |
1291 | </dd> | 1291 | </dd> |
1292 | <dt>EXPIRATION</dt> | 1292 | <dt>EXPIRATION</dt> |
1293 | <dd> | 1293 | <dd> |
1294 | denotes the absolute 64-bit expiration date of the content. | 1294 | denotes the absolute 64-bit expiration date of the content. |
1295 | The value specified is microseconds since midnight (0 hour), | 1295 | The value specified is microseconds since midnight (0 hour), |
1296 | January 1, 1970, but must be a multiple of one million | 1296 | January 1, 1970, but must be a multiple of one million |
1297 | (so that it can be represented in seconds in a HELLO URL). | 1297 | (so that it can be represented in seconds in a <tt>HELLO</tt> URL). |
1298 | Stored in network byte order. | 1298 | Stored in network byte order. |
1299 | </dd> | 1299 | </dd> |
1300 | <dt>ADDRESSES</dt> | 1300 | <dt>ADDRESSES</dt> |
@@ -1323,9 +1323,9 @@ BEGIN | |||
1323 | is in the future. If the signature is invalid, the message is discarded. | 1323 | is in the future. If the signature is invalid, the message is discarded. |
1324 | </li> | 1324 | </li> |
1325 | <li> | 1325 | <li> |
1326 | The HELLO information is cached in the routing table until it expires, | 1326 | The <tt>HELLO</tt> information is cached in the routing table until it expires, |
1327 | the peer is removed from the routing table, or the information is replaced by another message from the peer. | 1327 | the peer is removed from the routing table, or the information is replaced by another message from the peer. |
1328 | <!-- FIXME same problem as for HELLO blocks: We do not need to TRY_CONNECT here because we already have | 1328 | <!-- FIXME same problem as for <tt>HELLO</tt> blocks: We do not need to TRY_CONNECT here because we already have |
1329 | a connection, obviously. But we may want to TRY_CONNECT on the new addresses? Adding for now --> | 1329 | a connection, obviously. But we may want to TRY_CONNECT on the new addresses? Adding for now --> |
1330 | The implementation <bcp14>MAY</bcp14> instruct the Underlay to connect to all now available addresses | 1330 | The implementation <bcp14>MAY</bcp14> instruct the Underlay to connect to all now available addresses |
1331 | using <tt>TRY_CONNECT</tt> in order to make the underlay aware of alternative addresses for this connection. | 1331 | using <tt>TRY_CONNECT</tt> in order to make the underlay aware of alternative addresses for this connection. |
@@ -1553,12 +1553,12 @@ BEGIN | |||
1553 | be stored locally in the block storage. | 1553 | be stored locally in the block storage. |
1554 | </li> | 1554 | </li> |
1555 | <li> | 1555 | <li> |
1556 | If the <tt>BTYPE</tt> of the message indicates a HELLO block, the | 1556 | If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> block, the |
1557 | peer <bcp14>MUST</bcp14> be considered for the local routing | 1557 | peer <bcp14>MUST</bcp14> be considered for the local routing |
1558 | table if the respective k-bucket is not yet full. In this case, | 1558 | table if the respective k-bucket is not yet full. In this case, |
1559 | the local peer <bcp14>MUST</bcp14> try to establish a connection | 1559 | the local peer <bcp14>MUST</bcp14> try to establish a connection |
1560 | to the peer indicated in the HELLO block using the address information | 1560 | to the peer indicated in the <tt>HELLO</tt> block using the address information |
1561 | from the HELLO block and the Underlay function <tt>TRY_CONNECT</tt>. | 1561 | from the <tt>HELLO</tt> block and the Underlay function <tt>TRY_CONNECT</tt>. |
1562 | <!-- FIXME: The above behaviour has a catch: If the implementation only connects to one | 1562 | <!-- FIXME: The above behaviour has a catch: If the implementation only connects to one |
1563 | address from the hello using TRY_CONNECT, the Underlay also knows only about that connection | 1563 | address from the hello using TRY_CONNECT, the Underlay also knows only about that connection |
1564 | If that failes and PEER_DISCONNECT is called, this neighbor is dead. | 1564 | If that failes and PEER_DISCONNECT is called, this neighbor is dead. |
@@ -1755,11 +1755,11 @@ BEGIN | |||
1755 | </t> | 1755 | </t> |
1756 | <ol type="%c)"> | 1756 | <ol type="%c)"> |
1757 | <!-- FIXME: It is not clear that this is a fallthrough statement --> | 1757 | <!-- FIXME: It is not clear that this is a fallthrough statement --> |
1758 | <!-- FIXME: Are HELLO blocks according to the spec stored in block storage but never looked for? --> | 1758 | <!-- FIXME: Are <tt>HELLO</tt> blocks according to the spec stored in block storage but never looked for? --> |
1759 | <li> | 1759 | <li> |
1760 | If <tt>BTYPE</tt> indicates a request for a HELLO block or | 1760 | If <tt>BTYPE</tt> indicates a request for a <tt>HELLO</tt> block or |
1761 | <tt>ANY</tt>, | 1761 | <tt>ANY</tt>, |
1762 | the peer <bcp14>MUST</bcp14> consult its own HELLO as well as | 1762 | the peer <bcp14>MUST</bcp14> consult its own <tt>HELLO</tt> as well as |
1763 | the HELLOs it has cached for the | 1763 | the HELLOs it has cached for the |
1764 | peers in its routing table instead of the local block | 1764 | peers in its routing table instead of the local block |
1765 | storage (while continuing to respect flags like | 1765 | storage (while continuing to respect flags like |
@@ -1998,12 +1998,12 @@ BEGIN | |||
1998 | does not have to match the <tt>QUERY_HASH</tt>. | 1998 | does not have to match the <tt>QUERY_HASH</tt>. |
1999 | </li> | 1999 | </li> |
2000 | <li> | 2000 | <li> |
2001 | If the <tt>BTYPE</tt> of the message indicates a HELLO block, the | 2001 | If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> block, the |
2002 | peer <bcp14>MUST</bcp14> be considered for the local routing | 2002 | peer <bcp14>MUST</bcp14> be considered for the local routing |
2003 | table if the respective k-bucket is not yet full. In this case, | 2003 | table if the respective k-bucket is not yet full. In this case, |
2004 | the local peer <bcp14>MUST</bcp14> try to establish a connection | 2004 | the local peer <bcp14>MUST</bcp14> try to establish a connection |
2005 | to the peer indicated in the HELLO block using the address information | 2005 | to the peer indicated in the <tt>HELLO</tt> block using the address information |
2006 | from the HELLO block. If a connection is established, | 2006 | from the <tt>HELLO</tt> block. If a connection is established, |
2007 | the peer is added to the respective k-bucket of the routing table. | 2007 | the peer is added to the respective k-bucket of the routing table. |
2008 | Note that the k-bucket <bcp14>MUST</bcp14> be determined by the | 2008 | Note that the k-bucket <bcp14>MUST</bcp14> be determined by the |
2009 | key computed using <tt>DeriveBlockKey</tt> and not by the <tt>QUERY_HASH</tt>. | 2009 | key computed using <tt>DeriveBlockKey</tt> and not by the <tt>QUERY_HASH</tt>. |
@@ -2186,18 +2186,18 @@ BEGIN | |||
2186 | <name>HELLO Blocks</name> | 2186 | <name>HELLO Blocks</name> |
2187 | <t> | 2187 | <t> |
2188 | For bootstrapping and peer discovery, the DHT implementation uses | 2188 | For bootstrapping and peer discovery, the DHT implementation uses |
2189 | its own block type called "HELLO". HELLO blocks are the only type | 2189 | its own block type called "HELLO". <tt>HELLO</tt> blocks are the only type |
2190 | of block that <bcp14>MUST</bcp14> be supported by every | 2190 | of block that <bcp14>MUST</bcp14> be supported by every |
2191 | R<sup>5</sup>N implementation. A block with this block type | 2191 | R<sup>5</sup>N implementation. A block with this block type |
2192 | contains the peer ID of the peer that published the HELLO together | 2192 | contains the peer ID of the peer that published the <tt>HELLO</tt> together |
2193 | with a set of addresses of this peer. The key of a HELLO block | 2193 | with a set of addresses of this peer. The key of a <tt>HELLO</tt> block |
2194 | is the SHA-512 of the peer ID and thus the peer's address in the DHT. | 2194 | is the SHA-512 of the peer ID and thus the peer's address in the DHT. |
2195 | </t> | 2195 | </t> |
2196 | <t> | 2196 | <t> |
2197 | The HELLO block type wire format is illustrated in | 2197 | The <tt>HELLO</tt> block type wire format is illustrated in |
2198 | <xref target="figure_hello"/>. A query for block of type HELLO <bcp14>MUST NOT</bcp14> | 2198 | <xref target="figure_hello"/>. A query for block of type <tt>HELLO</tt> <bcp14>MUST NOT</bcp14> |
2199 | include extended query data (XQuery). Any implementation | 2199 | include extended query data (XQuery). Any implementation |
2200 | encountering a request for a HELLO with non-empty XQuery | 2200 | encountering a request for a <tt>HELLO</tt> with non-empty XQuery |
2201 | data <bcp14>MUST</bcp14> consider the request invalid and ignore it. | 2201 | data <bcp14>MUST</bcp14> consider the request invalid and ignore it. |
2202 | </t> | 2202 | </t> |
2203 | <figure anchor="figure_hello" title="The HELLO Block Format."> | 2203 | <figure anchor="figure_hello" title="The HELLO Block Format."> |
@@ -2235,7 +2235,7 @@ BEGIN | |||
2235 | denotes the absolute 64-bit expiration date of the content. | 2235 | denotes the absolute 64-bit expiration date of the content. |
2236 | The value specified is microseconds since midnight (0 hour), | 2236 | The value specified is microseconds since midnight (0 hour), |
2237 | January 1, 1970, but must be a multiple of one million (so that it | 2237 | January 1, 1970, but must be a multiple of one million (so that it |
2238 | can be represented in seconds in a HELLO URL). | 2238 | can be represented in seconds in a <tt>HELLO</tt> URL). |
2239 | Stored in network byte order. | 2239 | Stored in network byte order. |
2240 | </dd> | 2240 | </dd> |
2241 | <dt>ADDRESSES</dt> | 2241 | <dt>ADDRESSES</dt> |
@@ -2250,7 +2250,7 @@ BEGIN | |||
2250 | <t> | 2250 | <t> |
2251 | is the signature of the HELLO. | 2251 | is the signature of the HELLO. |
2252 | It covers a 64-bit pseudo header | 2252 | It covers a 64-bit pseudo header |
2253 | derived from the information in the HELLO block. | 2253 | derived from the information in the <tt>HELLO</tt> block. |
2254 | The pseudo header includes | 2254 | The pseudo header includes |
2255 | the expiration time, a constant that uniquely | 2255 | the expiration time, a constant that uniquely |
2256 | identifies the purpose of the signature, | 2256 | identifies the purpose of the signature, |
@@ -2299,24 +2299,24 @@ BEGIN | |||
2299 | <dd> | 2299 | <dd> |
2300 | a SHA-512 hash over the addresses in the HELLO. | 2300 | a SHA-512 hash over the addresses in the HELLO. |
2301 | H_ADDRS is generated over the ADDRESSES field | 2301 | H_ADDRS is generated over the ADDRESSES field |
2302 | as provided in the HELLO block using SHA-512 <xref target="RFC4634"/>. | 2302 | as provided in the <tt>HELLO</tt> block using SHA-512 <xref target="RFC4634"/>. |
2303 | </dd> | 2303 | </dd> |
2304 | </dl> | 2304 | </dl> |
2305 | </dd> | 2305 | </dd> |
2306 | </dl> | 2306 | </dl> |
2307 | <t> | 2307 | <t> |
2308 | The HELLO block functions <bcp14>MUST</bcp14> be implemented | 2308 | The <tt>HELLO</tt> block functions <bcp14>MUST</bcp14> be implemented |
2309 | as follows: | 2309 | as follows: |
2310 | </t> | 2310 | </t> |
2311 | <dl> | 2311 | <dl> |
2312 | <dt>ValidateBlockQuery(Key, XQuery) | 2312 | <dt>ValidateBlockQuery(Key, XQuery) |
2313 | -> RequestEvaluationResult</dt> | 2313 | -> RequestEvaluationResult</dt> |
2314 | <dd> | 2314 | <dd> |
2315 | To validate a block query for a HELLO is to simply check that the XQuery is empty. If it is empty, REQUEST_VALID ist returned. Otherwise, REQUEST_INVALID. | 2315 | To validate a block query for a <tt>HELLO</tt> is to simply check that the XQuery is empty. If it is empty, REQUEST_VALID ist returned. Otherwise, REQUEST_INVALID. |
2316 | </dd> | 2316 | </dd> |
2317 | <dt>DeriveBlockKey(Block) -> Key | NONE</dt> | 2317 | <dt>DeriveBlockKey(Block) -> Key | NONE</dt> |
2318 | <dd> | 2318 | <dd> |
2319 | To derive a block key for a HELLO is to simply | 2319 | To derive a block key for a <tt>HELLO</tt> is to simply |
2320 | hash the peer ID from the HELLO. The result of this function | 2320 | hash the peer ID from the HELLO. The result of this function |
2321 | is always the SHA-512 hash over the PEER-ID. | 2321 | is always the SHA-512 hash over the PEER-ID. |
2322 | </dd> | 2322 | </dd> |
@@ -2333,15 +2333,15 @@ BEGIN | |||
2333 | <dd> | 2333 | <dd> |
2334 | <t> | 2334 | <t> |
2335 | <!-- FIXME: I do not understand this. Isn't the element set E known | 2335 | <!-- FIXME: I do not understand this. Isn't the element set E known |
2336 | for HELLO blocks? Isn't it H_ADDRS XOR MUTATOR? --> | 2336 | for <tt>HELLO</tt> blocks? Isn't it H_ADDRS XOR MUTATOR? --> |
2337 | The RESULT_FILTER for HELLO blocks is implemented using a | 2337 | The RESULT_FILTER for <tt>HELLO</tt> blocks is implemented using a |
2338 | Bloom filter following the definition from <xref target="bloom_filters"/> | 2338 | Bloom filter following the definition from <xref target="bloom_filters"/> |
2339 | and consists of a variable number of buckets <tt>L</tt>. | 2339 | and consists of a variable number of buckets <tt>L</tt>. |
2340 | <tt>L</tt> depends on the number of elements <tt>|E|</tt> known to be filtered at the | 2340 | <tt>L</tt> depends on the number of elements <tt>|E|</tt> known to be filtered at the |
2341 | initiator. | 2341 | initiator. |
2342 | <!-- FIXME: Minimum space for used for what? There is no example given anywhere in the | 2342 | <!-- FIXME: Minimum space for used for what? There is no example given anywhere in the |
2343 | spec how this becomes relevant. Again, this is not some abstract block, | 2343 | spec how this becomes relevant. Again, this is not some abstract block, |
2344 | but specifically a HELLO (see above). --> | 2344 | but specifically a <tt>HELLO</tt> (see above). --> |
2345 | If <tt>|E|</tt> is zero, the size <tt>L</tt> is set to 32 bits to provide some minimum | 2345 | If <tt>|E|</tt> is zero, the size <tt>L</tt> is set to 32 bits to provide some minimum |
2346 | space (to be used by peers when forwarding the request after | 2346 | space (to be used by peers when forwarding the request after |
2347 | returning local results). | 2347 | returning local results). |
@@ -2354,7 +2354,7 @@ BEGIN | |||
2354 | The elements used in the Bloom filter | 2354 | The elements used in the Bloom filter |
2355 | consist of an XOR between the <tt>H_ADDRS</tt> field (as computed using | 2355 | consist of an XOR between the <tt>H_ADDRS</tt> field (as computed using |
2356 | SHA-512 over the <tt>ADDRESSES</tt>) and the SHA-512 | 2356 | SHA-512 over the <tt>ADDRESSES</tt>) and the SHA-512 |
2357 | hash of the <tt>MUTATOR</tt> field from a given HELLO block. | 2357 | hash of the <tt>MUTATOR</tt> field from a given <tt>HELLO</tt> block. |
2358 | The mapping function M(<tt>H_ADDRS XOR MUTATOR</tt>) is defined as follows: | 2358 | The mapping function M(<tt>H_ADDRS XOR MUTATOR</tt>) is defined as follows: |
2359 | </t> | 2359 | </t> |
2360 | <t> | 2360 | <t> |
@@ -2365,8 +2365,8 @@ BEGIN | |||
2365 | This resulting byte string is interpreted as k=16 32-bit | 2365 | This resulting byte string is interpreted as k=16 32-bit |
2366 | integers in network byte order which are used to set and check the bucket bits in | 2366 | integers in network byte order which are used to set and check the bucket bits in |
2367 | <tt>B</tt> using <tt>BF-SET</tt> and <tt>BF-TEST</tt>. | 2367 | <tt>B</tt> using <tt>BF-SET</tt> and <tt>BF-TEST</tt>. |
2368 | The 32-bit Mutator is prepended to the L-bit Bloom filter bucket field <tt>HELLO_BF</tt> containing <tt>B</tt> | 2368 | The 32-bit Mutator is prepended to the L-bit Bloom filter bucket field <tt>HELLO_BF</tt> containing <tt>B</tt> |
2369 | to create the result filter for a HELLO block: | 2369 | to create the result filter for a <tt>HELLO</tt> block: |
2370 | </t> | 2370 | </t> |
2371 | <figure anchor="hello_rf" title="The HELLO Block Result Filter."> | 2371 | <figure anchor="hello_rf" title="The HELLO Block Result Filter."> |
2372 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 2372 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
@@ -2409,7 +2409,7 @@ BEGIN | |||
2409 | false-positives. | 2409 | false-positives. |
2410 | </t> | 2410 | </t> |
2411 | <t> | 2411 | <t> |
2412 | HELLO result filters can be merged if the | 2412 | <tt>HELLO</tt> result filters can be merged if the |
2413 | Bloom filters have the same size and | 2413 | Bloom filters have the same size and |
2414 | <tt>MUTATOR</tt> by setting all bits to 1 that are | 2414 | <tt>MUTATOR</tt> by setting all bits to 1 that are |
2415 | set in either Bloom filter. This is done whenever | 2415 | set in either Bloom filter. This is done whenever |
@@ -2420,7 +2420,7 @@ BEGIN | |||
2420 | <dt>FilterResult(Block, Key, RF, XQuery) -> (FilterEvaluationResult, RF')</dt> | 2420 | <dt>FilterResult(Block, Key, RF, XQuery) -> (FilterEvaluationResult, RF')</dt> |
2421 | <dd> | 2421 | <dd> |
2422 | The <tt>H_ADDRS</tt> field is XORed with the SHA-512 | 2422 | The <tt>H_ADDRS</tt> field is XORed with the SHA-512 |
2423 | hash of the <tt>MUTATOR</tt> field from the HELLO block and the resulting | 2423 | hash of the <tt>MUTATOR</tt> field from the <tt>HELLO</tt> block and the resulting |
2424 | value is checked against the Bloom filter in RF. | 2424 | value is checked against the Bloom filter in RF. |
2425 | Consequently, HELLOs with completely identical sets of | 2425 | Consequently, HELLOs with completely identical sets of |
2426 | addresses will be filtered and FILTER_DUPLICATE is returned. | 2426 | addresses will be filtered and FILTER_DUPLICATE is returned. |
@@ -2997,7 +2997,7 @@ Type | Name | References | Description | |||
2997 | <section anchor="hello_url"> | 2997 | <section anchor="hello_url"> |
2998 | <name>HELLO URLs</name> | 2998 | <name>HELLO URLs</name> |
2999 | <t> | 2999 | <t> |
3000 | The general format of a HELLO URL uses "gnunet://" | 3000 | The general format of a <tt>HELLO</tt> URL uses "gnunet://" |
3001 | as the scheme, followed by "hello/" for the name | 3001 | as the scheme, followed by "hello/" for the name |
3002 | of the GNUnet subsystem, followed by "/"-separated values | 3002 | of the GNUnet subsystem, followed by "/"-separated values |
3003 | with the GNS Base32 encoding (<xref target="I-D.schanzen-gns"/>) of | 3003 | with the GNS Base32 encoding (<xref target="I-D.schanzen-gns"/>) of |
@@ -3038,7 +3038,7 @@ maybe generate proper test vector. | |||
3038 | DHT Underlay. | 3038 | DHT Underlay. |
3039 | </t> | 3039 | </t> |
3040 | <t> | 3040 | <t> |
3041 | The general syntax of HELLO URLs specified using | 3041 | The general syntax of <tt>HELLO</tt> URLs specified using |
3042 | Augmented Backus-Naur Form (ABNF) of <xref target="RFC5234"/> is: | 3042 | Augmented Backus-Naur Form (ABNF) of <xref target="RFC5234"/> is: |
3043 | </t> | 3043 | </t> |
3044 | <figure> | 3044 | <figure> |