Uploaded image for project: 'yangtools'
  1. yangtools
  2. YANGTOOLS-765

yang-common: allow application-specific RpcErrors

XMLWordPrintable

    • Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Highest Highest
    • 14.0.0
    • None
    • None
    • None
    • Operating System: All
      Platform: All

      yang.common.RpcError does not model https://tools.ietf.org/html/rfc6241#section-4.3 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 (https://tools.ietf.org/html/rfc6241#appendix-A, see ' error-tag: missing-attribute').

      At least the cases covered in RFC6241 need to be covered, but there seems to be appetite to add more: https://lists.opendaylight.org/pipermail/yangtools-dev/2017-January/001730.html.

      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 – 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.

            Unassigned Unassigned
            rovarga Robert Varga
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: