RFC 2348 - TFTP Blocksize Option

Overview

Positive

what Ze has

Neutral

measures that are neither good news nor bad

The 8 shares marked as a part above are the whole of the 5 gated MUSTs: they add to 100%. Proven by a recorded break is a share of TAGGED UNITS, a different population, so it is not one of them.

At a glance

Enrolment

Enrolled: TFTP Blocksize Option: five MUST-level requirements, four met and tested, one client-side {not-applicable}. RFC2348-x-1 (acknowledged blksize <= requested) both polarities via TestRFC2348BlksizeAckNotAboveRequest: a request within Ze cap (1200) is acked as 1200, a request above the 1468 cap (60000) is acked as 1468 which never exceeds the request (producer handleRRQ min(opts.blksize, blksizeEthernet), handler.go:271-272). RFC2348-x-3 (valid range 8..65464) both polarities via TestRFC2348BlksizeRangeEnforced: 512 is acked, while 5 and 70000 are ignored and absent from the OACK (producer parseRRQ n >= blksizeMin && n <= blksizeMax, handler.go:122-125). RFC2348-x-4 (a short block ends the transfer) both polarities: TestTFTPReadLargeFile (1500 bytes over 512 ends after a 476-byte short block) and TestTFTPReadExact512 (a full 512-byte block does NOT end, block 2 follows). RFC2348-x-5 (exact multiple -> extra zero-length block) both polarities: TestTFTPReadExact512 (512-byte file -> 512 block + a 0-byte end block) and TestTFTPReadLargeFile (1500 is not a multiple, so no extra zero block). RFC2348-x-2 (client MUST use the OACK size or send ERROR 8) is {not-applicable}: Ze ships only a TFTP server, no client. No SHOULD/MAY requirements are gated.

What the public ledger says

No row in the public ledger, so its summary declares `| Support | - |` and docs/features/rfc-status.md carries no row for RFC 2348.

Coverage

Positive and negative tests (4): RFC2348-x-1, RFC2348-x-3, RFC2348-x-4, RFC2348-x-5

Annotated (including scoped evidence) (1): RFC2348-x-2

Requirements

Gaps and untested MUSTs

Proof state

A tagged unit reads unproven where no discrimination record exists for it: nothing in this tree has been observed to break it, so the claim its tag makes is unproven.

RFC2348-x-1

The specified value must be less than or equal to the value specified by the client. (§Blocksize Option Specification)

Audit verdict: enforced (the tests do what the requirement demands), fresh. (a) OACK blksize above the client's request; (b) 'above cap' subtest t.Errorf when acked > 60000, and the within-cap subtest pins 1200 == requested 1200, so an ack that ignores a smaller request also goes red.

RFC2348-x-2

The client must then either use the size specified in the OACK, or send an ERROR packet, with error code 8, to terminate the transfer. (§Blocksize Option Specification)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC2348-x-2, so no unit is bound to it.

RFC2348-x-3

Valid values range between "8" and "65464" octets, inclusive. (§Blocksize Option Specification)

Audit verdict: enforced (the tests do what the requirement demands), fresh. TestRFC2348BlksizeBoundsAreInclusive asserts both inclusive bounds and one past each: 8 is acked as 8 and block 1 carries 8 octets; 65464 is acked (as the 1468 cap, which x-1 allows), red on n<65464; 7 and 65465 beside tsize are absent from the OACK, red on n>=7 or n<=65465. Every off-by-one at either bound goes red.

RFC2348-x-4

The reception of a data packet with a data length less than the negotiated blocksize is the final packet. (§Blocksize Option Specification)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-09-30: TestTFTPReadLargeFile changed only by losing the retired RFC1350-5-2 tag comment; every assertion is unchanged. TestRFC2348ShortBlockIsTheFinalPacket at a negotiated 1024: a 600-octet file must be exactly [600] with silence after its ACK (a server comparing against 512 sends a block 2 and goes red), and 2500 must be [1024,1024,452] then silence (red on DATA after the short block). Negative: full 1024 blocks are followed by the next block.

RFC2348-x-5

If the amount of data to be transfered is an integral multiple of the blocksize, an extra data packet containing no data is sent to end the transfer. (§Blocksize Option Specification)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-09-30: TestTFTPReadLargeFile changed only by losing the retired RFC1350-5-2 tag comment; every assertion is unchanged. TestRFC2348ZeroLengthBlockEndsAnExactMultiple at a negotiated 1024: 2048 must be [1024,1024,0] (red with no empty terminator), and 1500 must be [1024,476] and 512 must be [512], each followed by 1 s of silence (red on an extra empty packet, including one computed against 512 instead of the negotiated size).

Extraction sign-off

Sections

Excluded sentences

Superseded

No document obsoletes RFC 2348, so its obligations are stated where they were written.