commit 78ffb3e52411761126e36de6116eaac95fef2ecd
parent 4952f2e02a1c4df80f8c0113cdd879d42e92dbb7
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Sun, 20 Aug 2023 17:44:13 +0200
improve English
Diffstat:
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -940,7 +940,8 @@ BEGIN
the number of concurrent requests may be problematic.
Hence, it is <bcp14>RECOMMENDED</bcp14> that implementations
track requests from local applications separately and
- preserve the information until the application explicitly
+ preserve the information about requests from local
+ applications until the local application explicitly
stops the request.
</t>
</section>
@@ -948,30 +949,33 @@ BEGIN
<section anchor="p2p_messages" numbered="true" toc="default">
<name>Message Processing</name>
<t>
- Further, the implementation <bcp14>MAY</bcp14> act as an initiator of
- messages.
+ An implementation will process
+ messages either because it needs to transmit messages as part of routing
+ table maintenance, or due to requests from local applications, or
+ because it received a message from a <em>neighbor</em>.
If instructed through an application-facing API such as the one outlined
- in <xref target="overlay"/>, the peer may acts as an initiator of <tt>GetMessage</tt>s
+ in <xref target="overlay"/>, a peer acts as an <em>initiator</em>
+ of <tt>GetMessage</tt>s
or <tt>PutMessage</tt>s.
The status of initiator is relevant for peers when processing <tt>ResultMessages</tt>
- and the potential handover of results to the application.
+ due to the required handover of results to the originating <em>application</em>.
</t>
<t>
The implementation <bcp14>MUST</bcp14> listen for <tt>RECEIVE(P, M)</tt> signals
- from the Underlay and respond to the respective messages sent by
+ from the underlay and react to the respective messages sent by
the peer <tt>P</tt>.
</t>
<t>
- Wheather initiated locally or received from a neighbour, the implementation
- processes the messages according to the wire formats and the required
- validations detailed in the following.
+ Whether initiated locally or received from a neighbor, an implementation
+ processes messages according to the wire formats and the required
+ validations detailed in the following sections.
Where required, the local peer's ID is referred to as <tt>SELF</tt>.
</t>
<section anchor="message_components">
<name>Message components</name>
<t>
This section describes some data structures and fields shared
- by various message types.
+ by various types of messages.
</t>
<section anchor="route_flags">
<name>Flags</name>
