View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006101 | 10000-004: Services | Spec | public | 2020-09-29 16:22 | 2020-10-13 15:54 |
| Reporter | David Levine | Assigned To | Jim Luth | ||
| Priority | high | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | no change required | ||
| Summary | 0006101: Is Browse service parameter requestedMaxReferencesPerNode supposed to indicate a server or client constraint? | ||||
| Description | Browse service parameter requestedMaxReferencesPerNode needs clarification. Is it supposed to indicate a server constraint or a client constraint? If it is a server constraint then how is the client supposed to "know" what the constraint is and what the value should be set to? Server-side constraints should be discoverable by the client - requiring advance knowledge of the server's constraints prevents interoperability. Use case: Desktop client browsing a UA server; the client can handle any size reply. A single Node in the server has 50k references (Variable Nodes). The client sets parameter RequestedMaxReferencesPerNode to 0 - the client imposes no limit on the number of references per reply. When the Node with 50k references is browsed the server tries to include 50k references in the reply. This fails somewhere on the server side. The client receives a reply with the status code set to BadEncodingLimitExceeded. Root problem: the client has no way of knowing how many references a Node has until it issues the Browse, and it has no way of knowing what limits the server has as it encodes a reply. The error code does not contain sufficient information for the client to retry the operation with a different limit. While the error code is technically correct it is not very helpful because it reflects where it failed, but what is needed is what lead up to the failure. A customer looking at this will not know that what the problem is or how to correct it. Is it a server problem, a client problem, or both? Currently it is a user problem because they must do something manually to recover from this. Editorial: only the server knows how many references a Node has so it should be the one that limits the reply to a size that will work with its stack. The spec should state that the server is responsible for ensuring the replies can be encoded, and issue a continuation point if the reply size exceeds the limits of its stack. | ||||
| Tags | No tags attached. | ||||
| Commit Version | |||||
| Fix Due Date | |||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-09-29 16:22 | David Levine | New Issue | |
| 2020-10-13 15:54 | Jim Luth | Assigned To | => Jim Luth |
| 2020-10-13 15:54 | Jim Luth | Status | new => closed |
| 2020-10-13 15:54 | Jim Luth | Resolution | open => no change required |
| 2020-10-13 15:54 | Jim Luth | Note Added: 0013045 |