Erratum — draft-fossil-sync-protocol-01 §6.6

Document	draft-fossil-sync-protocol-01
Section	6.6 — Capability Model (file and cfile cards when push is not enabled)
Type	Technical (the text says later cards are still processed; Fossil stops at the first file or cfile card)
Status	Applied in draft-fossil-sync-protocol-01 (2026-10-12)
Reported	2026-10-12
Submitter	Dan Mestas
Found via	A reader implementing §6.6 from the text alone, then Fossil's source

1. Summary

The -01 refusal paragraph says that after a refused push "later file and cfile cards are refused individually, and later cards, including a pull, are still processed". The form of the refusal is not given, and the second half is wrong: in Fossil the first file or cfile card that arrives while push is not enabled is answered with a reset error not authorized to write and ends card processing for the request.

2. Location

§6.6, the sentence beginning "In both forms push is not enabled for the request".

3. The reference behavior

Fossil 2.28 page_xfer() (src/xfer.c:1360-1392): for a file or cfile card, if( !isPush ) resets the accumulated output, emits error not\sauthorized\sto\swrite, increments the error count, and executes break, which leaves the card loop. The same break follows a handler validation failure. A uvfile card is not gated on push and continues. After the loop, the end-of-request work for an accepted pull still runs (:1922-1925), as §6.4 already states for a failed login.

4. Impact

Observable. A conforming server that keeps parsing would answer a later pull card with inventory that Fossil would not send, and would process cards Fossil never reads.

5. Correction

-   forms push is not enabled for the request, so later file and cfile
-   cards are refused individually, and later cards, including a pull,
-   are still processed.  A client that sends both cards SHOULD send
+   forms push is not enabled for the request.  Later cards, including
+   a pull, are still processed until the first file or cfile card:
+   that card is refused with reset output and error not authorized to
+   write, and ends card processing for the request, as a handler
+   validation failure does (Section 5.2).  The end-of-request steps
+   for a direction established earlier, such as the igot inventory
+   for an accepted pull, are still performed (Section 6.4).  A client
+   that sends both cards SHOULD send

6. Rationale

States the refusal form and the stop, which are the same reset-and-stop shape §5.2 already defines for handler failures.

7. Verification

• Source: Fossil 2.28 src/xfer.c:1360-1392, :1922-1925.