In the description of OptFlds in Table 39, it says "The values of buffer-overflow and entryID shall be ignored". This statement should be removed. If it is not removed, it needs some clarification. Does it mean:
1. The server should not allow the client to set these bits to 1 in the RCB. If so, should it send an error response to the write request or just ignore those 2 bits in the write.
2. If these bits are set in the RCB, they should NOT be set in the OptFlds that is sent in the report.
3. These bits should be ignored by the "Server" and the "Client". If the bits are set in OptFlds in the RCB, the server should set these bits in the OptFlds sent in the report, but NOT include the "buffer-overflow and EntryID" data in the report and the client should ignore the bits and NOT expect the "buffer-overflow and EntryID data" in the report.
If #3 is the correct interpretation, this creates extra complexity for the "Client" application. There is nothing in a received report that indicates if it is a "Buffered" or "Unbuffered" report. The only way the client could determine this is if it stores this information somewhere when it enables an RCB. It would know that any rcb under the "RP" functional constraint is an Unbuffered RCB. It would have to save this information with a list of RptIDs, and when each report is received, it would have to find the RptID to determine if it is Unbuffered or Buffered.
The simplest and least confusing solution, would be to just eliminate this statement from the standard. If the client sets these bits, the server would send this data in the reports. The data would not be useful for a URCB, so a smart client would not set these bits for a URCB.
set to green
29 Nov 05
In Force (green)
ignored means, the server ignores the bits in a write request and the value is always 0 when reading these bits.
A clarification will be added to 8-1
10 Oct 05
I support moving for final proposal
20 Sep 05
20 Sep 05
Writing a bit string implies that all bits are present in the write request. I propose that the server shal just ignore those 2 bits in the write, as it does for the bit reserved. They remain 0 in the OptFlds even if they are set in the write request.