Typos and some precision.

pep-keysync/draft-hoeneisen-pep-keysync.mkd

@@ -262,15 +262,15 @@ after each diagram.
 
 <vspace blankLines="30" />
 
-As depicted above a user intends to form a Device Group, e.g. in order
-to securly share key material among its members. The group is formed
-by an 'Offerer'-Device and a Requester device. The name is derived
+As depicted above a user intends to form a Device Group, e.g., in order
+to securly share key material among its device members. The group is formed
+by an 'Offerer' device and a 'Requester' device. The name is derived
 from the implementation of the Finite State Machine (FSM),
-cf. {{simplified-finite-state-machine}}, where we an artificial
-hierachie between the devices needs to be introduced for the FSM to
-work properly. The roles ('Offerer' / 'Requester') are determined by a
-Transaction-ID (TID), a UUID version 4 variant 1. During
-initialization of pEp KeySync a TID is created and sent as challenge
+cf. {{simplified-finite-state-machine}}, where a start sequence, defining roles,
+between the devices involved is necessary for the FSM to
+work as intended. The roles ('Offerer' / 'Requester') are determined by a
+Transaction-ID (TID) -- a UUID version 4 variant 1 -- by their numeric value. 
+During initialization of pEp KeySync, a TID is created and sent as a challenge
 in a beacon over the mutual channel.
 
 Note: All messages are 'broadcast'. The TIDs added to each message
@@ -284,65 +284,66 @@ its sender.
    the lower challenge TID gets 'Requester', the one with higher
    challenge TID gets 'Offerer'.
    
-   Note: The 'Offerer'-Device MUST NOT start a Negotiation. Thus, it
+   Note: The 'Offerer' device MUST NOT start a Negotiation. Thus, it
    re-sends its own beacon (for robustness in case earlier beacon
    message got lost) and waits. Message 1(r) depicts the beacon
-   message sent by the 'Requester'-Device and is not required for the
+   message sent by the 'Requester' device and is not required for the
    process to coninue.
 
-2. After determination of the role, the 'Requester'-Device sends a
+2. After determination of the role, the 'Requester' device sends a
    NegotiationRequest message.
 
-3. The 'Requester'-Device displays the Trustwords to the user.
+3. The 'Requester' device displays the Trustwords to the user.
 
 4. Up on reception of the NegotiationRequest message, the
-   'Offerer'-Device sends a NegotiationOpen message. 
+   'Offerer' device sends a NegotiationOpen message. 
    
-5. The 'Offerer'-Device displays the Trustwords to the user.
+5. The 'Offerer' device displays the Trustwords to the user.
 
 6. The user compares the Trustwords of both devices. As the Trustwords
-   are the same on both Devices, the user presses the 'Accept'-Button
+   are the same on both Devices, the user presses the 'Accept' button
    on the 'Requester'-Device.
    
-   Note 1: The user may also press the 'Accept'-Button on the
-   'Offerer'-Device first. The end result is not affected by which
-   'Accept'-Button is pressed first. However, the order of the
+   Note 1: The user may also press the 'Accept' button on the
+   'Offerer' device first. The end result is not affected by which
+   'Accept' button is pressed first. However, the order of the
    messages slightly changes.
    
-   Note 2: The user may also choose to press the 'Cancel'-Button or
-   the 'Reject'-Button (see below).
+   Note 2: The user may also choose to press the 'Cancel' button or
+   the 'Reject' button (see below).
 
    <!-- Add (stable) internal reference -->
    
-7. On reception of the user's 'Accept', the 'Requester'-Device sends a
+7. On reception of the user's 'Accept', the 'Requester' device sends a
    CommitAcceptRequester message.
 
-   The 'Offerer'-Device receives this message and wait for the user to
-   press the local 'Accept'-Button.
+   The 'Offerer' device receives this message and waits for the user to
+   press the local 'Accept' button.
    
 8. The user compares the Trustwords of both devices and presses the
-   'Accept'-Button on the 'Offerer'-Device.
+   'Accept' button on the 'Offerer' device.
 
-   Note: The user may also choose to press the 'Cancel'-Button or the
-   'Reject'-Button (see below).
+   Note: The user may also choose to press the 'Cancel' button or the
+   'Reject' button (see below).
 
    <!-- Add (stable) internal reference -->
 
-9. On reception of the user's 'Accept', the 'Offerer'-Device sends
+9. On reception of the user's 'Accept', the 'Offerer' device sends
    a CommitAcceptRequester message.
 
-10. The 'Offerer'-Device then sends an OwnKeysOfferer messages along
-    with his own private keys.
+10. The 'Offerer' device then sends an OwnKeysOfferer messages along
+    with the the key pairs (private and publlic keys) for all the identities 
+    to be synchronized.
     
 11. Up on reception of the OwnKeysOfferer messages, the
-    'Requester'-Device is Grouped and sends an OwnKeysRequester
-    messages along with his own private keys.
+    'Requester' device is Grouped and sends an OwnKeysRequester
+    messages along with the key pairs (private and public keys) for all the
+    identities to be synchronized.
     
-    Up on reception of the OwnKeysReuester messages, also the
-    'Offerer'-Device is Grouped. The formation of the Device Group has
+    Up on reception of the OwnKeysRequester messages, also the
+    'Offerer' device is grouped. The formation of the Device Group has
     been successful.
 
-
 <vspace blankLines="50" />
 
 #### Unsuccessful Case