Address issues #129 #131 #139 #140

[pavel-kirienko]

Closes #129
Closes #131
Closes #140

[Copilot]

Pull Request Overview

This PR addresses issues #129, #131, #139, and #140 by clarifying protocol specifications. Key changes include:

• Enhancements to the UDP multi-frame transfer payload size description.
• Revised definitions and behavior of transfer-ID counters, including conditions for cyclic versus monotonic identifiers.
• Updated reserved Node-ID values for diagnostic and debugging purposes.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
specification/transport/udp/udp.tex	Added clarifications regarding payload size consistency in multi-frame transfers.
specification/transport/abstract.tex	Updated transfer-ID counter definitions, uniqueness conditions, and service response timeout adjustments.
specification/application/conventions.tex	Revised reserved Node-ID values for diagnostic and debugging tools.

Comments suppressed due to low confidence (1)

specification/transport/abstract.tex:702

• [nitpick] Consider rewording this condition for increased clarity. For example, rephrase to clearly indicate that the 'one million counts' threshold defines the minimum drop needed to identify a transfer-ID counter reset, and ensure that the associated footnote fully explains this rationale.

    \item has a transfer-ID value that is at least one million counts less than that of the last successfully reassembled transfer,

[thirtytwobits]

I don't think we should change the transfer ID in 1.0. Let's move this to 1.1 so we have more time to discuss. I think it's a slight improvement but there's some opportunity for refinement I'd like to explore.

[pavel-kirienko]

But then should we keep the 1M count leap backward clause?

[scottdarch]

But then should we keep the 1M count leap backward clause?

No. I think we should just leave the transfer ID as is for 1.0. It's a fait accompli for anything existing anyway.