https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/YANGTOOLS-765 yangtools <p>yang.common.RpcError does not model <a href="https://tools.ietf.org/html/rfc6241#section-4.3" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/rfc6241#section-4.3</a> correctly, specifically it misinterprets error-info as a String field, whereas the RFC defines it as a tag, which can be extended with richer content (<a href="https://tools.ietf.org/html/rfc6241#appendix-A" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/rfc6241#appendix-A</a>, see ' error-tag: missing-attribute').</p> <p>At least the cases covered in RFC6241 need to be covered, but there seems to be appetite to add more: <a href="https://lists.opendaylight.org/pipermail/yangtools-dev/2017-January/001730.html" class="external-link" target="_blank" rel="nofollow noopener">https://lists.opendaylight.org/pipermail/yangtools-dev/2017-January/001730.html</a>.</p> <p>We need to devise a way to channel this information in a way which will allow both XML and JSON encodings to work correctly. One way of achieving that would we to allow getInfo() to return a NormalizedNode structure, which would be allowed to only contain String leaves &#8211; but that is not possible due to this class being shared by both BI and BA applications. We may need to move RpcResult to its proper domain, i.e. have it defined in md-sal for both BA and BI interfaces and perform transcoding.</p> <p>Operating System: All<br/> Platform: All</p> YANGTOOLS-765

yang-common: allow application-specific RpcErrors

New Feature Highest Confirmed Unresolved Unassigned Robert Varga Wed, 22 Mar 2017 13:50:38 +0000 Tue, 19 Sep 2023 16:21:09 +0000 14.0.0 0 3 <p>&gt; does not model <a href="https://tools.ietf.org/html/rfc6241#section-4.3" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/rfc6241#section-4.3</a></p> <p>Are there any gotchas which would prevent us writing a Yang model to define the allowed structure?<br/> Or perhaps the XML/JSON serialization would need to behave differently from our usual codecs for yang modeled data?</p> <p>Well, first of all the data is not instantiated in the tree, hence it requires either RFC8040 yang-data or RFC8791 structure extension. The second is that the namespace itself seems to be rooted in RFC6241. The third is that this needs to be correctly mapped across all the spaces.</p> <p>We need the parser to understand RFC8791 constructs. We then need to a yang-data-api binding for those, which could be as simple as ContainerNode.</p> <p>We then need to decide what to do with yang-common implications.</p> <p>Finally, we want the yang-{model,data}-api model of RpcError be mirrored in MD-SAL's DOM layer. We want to generate bindings from RFC8791 constructs and have those be present in errors.</p> Blocks YANGTOOLS-1113 Relates YANGTOOLS-176 Development Epic Link YANGTOOLS-1023 External issue ID 8047 External issue URL Issue Type Rank 0|i0298v: