The following has been included in section C.2:

   The rules governing the use of the R-flag depend on the GIMPS message
   type.  It must always be set in Query messages (these always elicit a
   Response), and never in Confirm, Data or Error messages.  It is
   optional in a MA-Hello; if set, another MA-Hello is sent in reply.
   It is optional in a Response (but must be set if the Response
   contains a Responder cookie); if set, a Confirm is sent in reply.

The text has been updated accordingly in section 5.2.1 in the top level
description of each message, and the Responder cookie in the Confirm marked as
optional in the ABNF.

A consequence of this change is that the Responder cookie becomes conceptually
optional in the Confirm message. (You could send a Confirm because the Response
had the R flag, even though the Response has no Cookie. However, if the Response
does have a Cookie, echoing it in the Confirm is mandatory.)

A consequence of this change is that the Responder cookie becomes conceptually
optional in the Confirm message. (You could send a Confirm because the Response
had the R flag, even though the Response has no Cookie. However, if the Response
does have a Cookie, echoing it in the Confirm is mandatory.)

The common header includes an R flag, which is supposed to be set when a message
response is requested. Sometimes this is implicitly determined by the message
type, and sometimes by the message content (e.g. the R flag cannot be set on a
Confirm, while on the other hand a Query with a Cookie must have the R flag
set). These rules should be stated, and also that the R flag is 'authoritative'
in deciding that a next message in a handshake is required.