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

[Jernej Tuljak <[e-mail]>]

On 01/06/2023 21:10, Andy Bierman wrote:
>
>
> On Thu, Jun 1, 2023 at 2:13 AM Jernej Tuljak 
> <[e-mail]> wrote:
>
>     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>
>
>
>
> You should file an Errata.
>
> OLD:
>
>      <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>
> NEW:
>      <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
>              xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">nc:message-id</bad-attribute>
>             <bad-element
>              xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">nc:rpc</bad-element>
>           </error-info>
>         </rpc-error>
>       </rpc-reply>

The NETCONF "message-id" attribute does not belong to any namespace (it 
is in the null namespace when it appears in <rpc> and <rpc-reply>) - XML 
attributes do not inherit the default namespace like XML elements do. 
Your NEW proposal could actually be semantically equivalent to OLD.

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

XSD 1.1 namespace resolving of unprefixed text values of type "xs:QName" 
probably works like it does in YANG modeled data. Not sure why some 
sources say this is not so. There's this in their spec [1]:

"The host language, whether XML-based or otherwise, may specify whether 
unqualified names are bound to the default namespace (if any) or not; 
the host language may also place this under user control. If the host 
language does not specify otherwise, unqualified names are bound to the 
default namespace."

That would mean that eliminating the default namespace in effect on 
<bad-attribute> is the only way solve this.

I intend to file an errata, but here's what I'd file (if there's agreement):

OLD:

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

NEW:

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


BTW, there's no normative reference to XSD 1.1 in RFC 6241.

Jernej

[1] - https://www.w3.org/TR/xmlschema11-2/#QName


>
>     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
>
>     _______________________________________________
>     netconf mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/netconf
>