[netconf] RFC6241: "xs:QName" text values in <nc:rpc-error> instances

[Jernej Tuljak <[e-mail]>]

Hi,

RFC 6241 contains the following example in section 4.3.

    Example:  An error is returned if an <rpc> element is received
       without a "message-id" attribute.  Note that only in this case is
       it acceptable for the NETCONF peer to omit the "message-id"
       attribute in the <rpc-reply> element.

      <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <get-config>
          <source>
            <running/>
          </source>
        </get-config>
      </rpc>

      <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <rpc-error>
          <error-type>rpc</error-type>
          <error-tag>missing-attribute</error-tag>
          <error-severity>error</error-severity>
          <error-info>
            <bad-attribute>message-id</bad-attribute>
            <bad-element>rpc</bad-element>
          </error-info>
        </rpc-error>
      </rpc-reply>

I think this <rpc-reply> is semantically incorrect. It should be 
corrected to:

      <nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
        <nc:rpc-error>
          <nc:error-type>rpc</nc:error-type>
          <nc:error-tag>missing-attribute</nc:error-tag>
          <nc:error-severity>error</nc:error-severity>
          <nc:error-info>
<nc:bad-attribute>message-id</nc:bad-attribute>
            <nc:bad-element>nc:rpc</nc:bad-element>
          </nc:error-info>
        </nc:rpc-error>
      </nc:rpc-reply>

NETCONF messages layer is modeled with XML Schema 1.1 (XSD 1.1) in 
Appendix B.

While the <rpc-reply> in the original example is valid according to XML 
1.1 Schema in Appendix B, it does not seem to be consistent with 
requirements described in Appendix A. The text value of XML elements 
<bad-attribute> and <bad-element> should be a valid "xs:QName" that 
references a known attribute or element by its name ({namepace-name, 
local-part} tuple, not a string literal). Since the "message-id" 
attribute and "rpc" element do not belong to the same namespace in an 
<rpc> message, one of the text values in the original <rpc-reply> cannot 
be semantically correct.

It is also unclear which namespace unprefixed text values of XSD 1.1 
modeled data map to (and RFC 6241 says nothing about this), so my 
correction above is intentionally verbose in order to eliminate the 
default namespace. Note that the intention of the authors of XSD 1.1 
specification seems to be that such values are _always_ mapped to the 
null namespace, unlike in some other XML schema languages, where the 
default namespace would be used instead (if it exists), which would 
imply that only the value of <bad-element> in the original <rpc-reply> 
is problematic. The following could also be semantically correct:

      <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" 
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
        <rpc-error>
          <error-type>rpc</error-type>
          <error-tag>missing-attribute</error-tag>
          <error-severity>error</error-severity>
          <error-info>
            <bad-attribute>message-id</bad-attribute>
            <bad-element>nc:rpc</bad-element>
          </error-info>
        </rpc-error>
      </rpc-reply>

However, XSD 1.1 specification does not seem to explicitly confirm this 
anywhere.

Can someone please clarify what the intention of RFC 6241 was here? 
Specifically, why was XSD 1.1 "xs:QName" chosen as the data type for 
such XML elements in Appendix B, and what does "name" in Appendix A 
refer to?

Jernej