Subject: XML Namespace usage in NETCONF

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Jun 2006 21:04:46 -0700

Hi,

I've been discussing this issue with Martin off-line.
I've been re-reading the prot-12 draft.
I've been writing code to implement this stuff.

The draft is a bit sloppy wrt/ namespace usage.

prot-12, pg. 11:

   3.  XML Considerations

      XML serves as the encoding format for NETCONF, allowing complex
      hierarchical data to be expressed in a text format that can be read,
      saved, and manipulated with both traditional text tools and tools
      specific to XML.

      This section discusses a small number of XML-related considerations
      pertaining to NETCONF.

   3.1.  Namespace

      All NETCONF protocol elements are defined in the following namespace:

         urn:ietf:params:xml:ns:netconf:base:1.0

Note the sentence regarding traditional tools.
(I'll bring it up later ;-)

Sec. 3.1 says that netconf XML is defined in a particular namespace,
which is the targetNamespace in the netconf XSD.

I cannot find any normative text in the document that says a manager MUST
use namespaces in NETCONF PDUs.  I know that they SHOULD use namespaces.

There is text in the subtree filter section which indicates namespace
usage is optional:

from 6.1:

      XML namespaces may be specified (via 'xmlns' declarations) within the
      filter data model.  If so, the declared namespace must first exactly
      match a namespace supported by the server.

   6.2.1.  Namespace Selection

      If namespaces are used then the filter output will only include
      elements from the specified namespace.  A namespace is considered to
      match (for filter purposes) if the content of the 'xmlns' attributes
      are the same in the filter and the underlying data model.  Note that
      namespace selection cannot be used by itself.  At least one element
      must be specified in the filter any elements to be included in the
      filter output.

     Example:

        <filter type="subtree">
          <top xmlns="http://example.com/schema/1.2/config"/>
        </filter>

This example implies another example that would not require
the top element to be in any particular namespace:

        <filter type="subtree">
          <top/>
        </filter>

There is a problem with this example.
The <get> RPC is missing:

   <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <get>
        <filter type="subtree">
          <top/>
        </filter>
     </get>
   </rpc>

The problem is that the <rpc> and <get> parent elements
are defined in a target namespace, so namespaces are being used.
Any traditional XML parser that followed namespace rules will
classify the <top> node from the example above as being
requested from the netconf namespace.

Only the following PDU would actually work as intended:

   <rpc message-id="101">
     <get>
        <filter type="subtree">
          <top/>
        </filter>
     </get>
   </rpc>

This assumes of course the agent doesn't have its own
<rpc> element in another namespace (bad idea but valid XML).

Relying on the presence or absence of xmlns directives
in child nodes of <filter>, but applying normal namespaces
rules in the nodes above and below it is a hack, and a violation
of the XML Namespace Guidelines.

NETCONF needs to follow the rules for XML,
otherwise traditional tools for XML are worthless
for NETCONF.  That would kind of defeat the purpose
of using XML in the first place.

So here is the rule:

  * Either use namespaces correctly, or don't use them at all.

Andy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Phil Shafer <[email-masked]>
Date: Fri, 16 Jun 2006 01:23:18 -0400

>are defined in a target namespace, so namespaces are being used.

Sure, since you haven't changed the namespace.  You can encode
this to but <top> in the default namespace as follows:

      <top xmlns=""/>
    </filter>
  </get>
</rpc>

or:

<nc:rpc message-id="101" xmlns:nc="urn:very:long">
  <nc:get>
    <nc:filter type="subtree">
      <top/>
    </nc:filter>
  </nc:get>
</nc:rpc>

These are different encoding for the same infoset.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 16 Jun 2006 07:47:21 -0700

> this to but <top> in the default namespace as follows:

Ok -  the text in the subtree filter section about presence or
absence of xmlns directives is misleading (I guess I am reading it
too literally).  It should be interpreted in the general sense.
Your example obviously shows it doesn't matter where the xmlns
directives are in the PDU.  All that matters is normal XML processing
rules are followed to determine the requested namepsace.

> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

This does not work.
Although extremely stupid, empty strings and whitespace-only strings
are valid namespace names.  (I wonder how many agents handle an empty
NS string correctly?)

>     <nc:filter type="subtree">

This works.
I forgot about this variant in my original mail,
but it is obviously the most correct one to be used here.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 16 Jun 2006 10:59:08 -0400

>rules are followed to determine the requested namepsace.

Yup, the text is an encoding of the infoset, and there are
multiple ways to encode it.

>are valid namespace names.  (I wonder how many agents handle an empty

You sure?  In section 5.2 of:

    http://www.w3.org/TR/1999/REC-xml-names-19990114/

it says:

    The default namespace can be set to the empty string. This has
    the same effect, within the scope of the declaration, of there
    being no default namespace.

There's an example also.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 16 Jun 2006 08:17:56 -0700

>     being no default namespace.

Okay, you are right. The libxml2 parser behaves this way:

   <foo/>                         no namespace

   <t:foo xmlns:t=""/>            namespace = ""

   <foo xmlns=""/>                no namespace

One more weird XML corner case to deal with :-(
Is this supposed to be a feature?

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 16 Jun 2006 11:17:38 -0400

>Is this supposed to be a feature?

Everything's a feature, as soon as enough people depend on it ;^)

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Jun 2006 16:23:14 -0700

> Phil Shafer wrote:

Final clarification on this issue:

If a particular filter node does not use any
namespace, then it must match a corresponding
node in the data model which also does not use
any namespace.  Use of the default namespace
does not act as a wildcard to ask the agent to
find the correct namespace.

Andy