301   SqNum in Buffered Reports

Created: 14 Mar 2006

Status: Not Applicable

Part: Part 8-1 (2004)

Links:

Page: 51

Clause: 17.1.1.1

Paragraph:

Category: Issue for edition 2 of this part

Issue

Part 8-1, clause 17.1.1.2 says "A transition of RptEna from FALSE to TRUE shall cause the value of SqNum to be set to zero (0)". This is true for Unbuffered Reporting only. This should not be true for Buffered Reporting. In Buffered Reporting the SqNum should be consecutive so that clients can properly re-syncronize with the reports after a lost connection.

Proposal

Clause 17.1.1.1 should contain an explanation of the conditions which cause the value of SqNum to be set to zero, and when it should not be set to zero.

Discussion Created Status
Changed to blue, being fixed as part of edition 2 of 7-2. 14 Nov 06 Not Applicable
Due to the un-interoperability issue turned to yellow 03 Apr 06 Future Improvement
31 Mar 06 Ballot Period
On behalf of Bruce Muschlitz:

Add a new paragraph to Clause 17.1.1.1: "SqNum - INTEGER value will roll
over to a value of 1 after reaching the maximum value {Editors: should
we say this is 65535?}"

This is now part of the resolution to Tissue 297 in 7-2. The change may not need to be made in 8-1.
17 Mar 06 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1