Subject: XML namespace advice

From: Andy Bierman <[email-masked]>
Date: Fri, 09 Jun 2006 21:53:51 -0700

Hi,

3 XML questions:

Section 3.1 of prot-12 clearly states that the NETCONF elements
reside in a specific namespace.

   Q1: Is it an error if a PDU (e.g., <hello> or <rpc>) is received by
       the peer, which does not use namespaces?  Or is it okay to set
       the default namespace to the NETCONF NS in this case?

My understanding of sec. 4.1 is that all of the attributes,
including the xmlns declarations, in the <rpc>, need to be
replicated exactly in the <rpc-reply> element. 
However, an agent may add attributes to the end of the list.

   Q2: Are xmlns declarations special, and not supposed to be
       included in the list of replicated attributes?  All the
       document examples show them replicated in the <rpc-reply>.

I am choosing to reuse any xmlns prefix values from the <rpc>
in the <rpc-reply>, but I believe an implementation could ignore
those prefixes, and add new xmlns declarations if it wanted.
A conforming manager must figure out the corresponding namespace
regardless of the prefix value. (It is a pain to minimize the
number of xmlns decls generated in the <rpc-reply>, but they
are so verbose!)

   Q3: Are there more xmlns processing and generation rules and/or
       guidelines to follow here? 

thanks,
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: Sat, 10 Jun 2006 01:57:12 -0400

>       the default namespace to the NETCONF NS in this case?

Does this fit under the 'be liberal in what you accept'
banner?  JUNOS tries to follow that, accepting either
an empty or an accurate namespace.

>       document examples show them replicated in the <rpc-reply>.

They are special, but only slightly.  JUNOS echoes them all,
but I know that some XML parsers discard unused namespaces,
so an xmlns:foo attribute may be trimmed from an element where
nothing in it or its children reference that prefix.  This
trim happens in the parser, so the netconf implementation
may never see the xmlns attribute.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sat, 10 Jun 2006 00:06:39 -0700

> an empty or an accurate namespace.

I believe the W3C documentation I read a long time ago
said no namespace is different than all the elements
and attributes in a default namespace.  I don't remember why.
If the targetNamespace attribute is missing from the <schema>
element, and the elementFormDefault and attributeFormDefault
are both 'unqualified', then there is no namespace at all.

Even if you assign a namespace, if there are child elements
of <config> or <filter> they should generate errors,
because they are not in the netconf namespace.

Of course, you could really follow the Postel Principle with zeal,
and ignore namespaces in the request entirely, figuring out
which element the manager is specifying (i.e., org. naming conventions
do not rely on namespaces to be unique).  I do that and also allow the
user to enter an owner="foo" attribute to help find the namespace.

However, in the <rpc-reply>, I always use namespaces,
even if they weren't used in the request.

> may never see the xmlns attribute.

In netconf, only the <rpc-reply> element is special.
There are no attribute requirements for any other element.
I replicate every attribute from the <rpc>, as the doc says,
and then add more attributes as needed.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 10 Jun 2006 08:52:55 -0700

>...

One more note:  attributes are unordered in XML.  The parser from libxml2
I am using does not preserve attribute order.  (It puts the namespace
decls first.)  This text in prot-12, sec. 4.1 is the only normative
mention of this, except a similar comment in the XSD:

    If additional attributes are present in an <rpc> element, a NETCONF
    peer MUST return them unmodified in the <rpc-reply> element.

This text means the individual attributes are returned unmodified,
not that the order is also preserved, which is implied in all the examples.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 10 Jun 2006 20:51:35 +0200 (CEST)

>        the default namespace to the NETCONF NS in this case?

Isn't the namespace in the <hello> message supposed to indicate which
version of the NETCONF protocol the peer supports?  If there is no
namespace, which version should we guess the other side is using?
(Ok, the answer is pretty obvious right now :)

Also, if you take the schema from the draft, and an instance document
which is a valid <hello> message but w/o the namespace, xmllint failes
to validate.

Although it's easy enough to implement both these cases, I think it's
better if the namespace declaration is required.

A follow-up question is if a peer is non-compliant if it requires a
correct xmlns attribute on the <hello> and <rpc> messages?

>        document examples show them replicated in the <rpc-reply>.

We replicate the xmlns attributes, but I honestly can't see why this
is important or even useful.

>        guidelines to follow here? 

If you accept a rpc w/o namespaces, you have to decide what to do with
e.g. an edit-config w/o namespaces.  But I think you mentioned that
you allow that.

However, if you get a <rpc> *with* a correct xmlns, and an edit-config
*without* a xmlns, I think you should generate an error, since it's
invalid per the XML Namespace Recommendation.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 10 Jun 2006 12:38:08 -0700

> (Ok, the answer is pretty obvious right now :)

Since it is implementation-dependent which namespace
the peer picks as a default, the answer isn't obvious.
I would pick the most current version the agent supports
as the default (usual choice).

> better if the namespace declaration is required.

Not so fast!
I don't want to force an agent to reject an otherwise valid
RPC request because the netconf namespace is missing.

And, as 8.1 clearly indicates, the <hello> PDU
does not rely on the xmlns decl anywhere in the PDU
to identify the version.  In the example, the first
capability for the protocol itself seems redundant,
but this mechanism works even if the namespace decl is missing.

> correct xmlns attribute on the <hello> and <rpc> messages?

I knew you would ask that!
I read through the draft.
I can't find any text that says that PDUs must use namespaces.
It's just shown that way in all the examples.

This requires more thought, before we start creating any CLRs.

> is important or even useful.

It's a lot of work for not much value.
If anything, it might help the operator more easily
analyze the reply by sight, instead of with tools.
That's why I bother doing it.  But just for <rpc-reply>,
no other nested elements.

> invalid per the XML Namespace Recommendation.

Yes -- I do.  But not for the rpc method, unless it is in
a different namespace than NETCONF.

I think you mean the namespace of the edit-config data:

   <rpc message-id="101" xmlns="netconf-blah">
     <edit-config>
       ...
       <config>
         <x:top xmlns:x="example.com-blah">
            <x:foo/>
         </x:top>
       </config>
     </edit-config>
   </rpc>

(Note the prefix 'x' is not required; the xmlns decl in the 'top'
element could have overridden the default namespace instead.)

Actually, if namespaces are not used at all, there is a
default 'owner' which happens to own the netconf RPCs
and the core data models.

However, an error will be generated if the "netconf-blah"
namespace decl is present but the "example.com" decl is
missing.  The parser knows if namespaces are being used or not
in the PDU.

Even if namespaces are used, attributes without namespace prefixes
will be classified by the libxml2 parser as "not in any namespace".
I'm not picky wrt/ stuff like:

   operation="create"
   ns:operation="create"

You have to check for both cases. (Love XML! ;-)

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Jun 2006 10:40:45 -0700

Hi,

> invalid per the XML Namespace Recommendation.

Agreed, but this is stated somewhat incorrectly.

IMO, it is reasonable for the agent to assign the netconf NS
as the default NS, in the event <hello> or <rpc> PDUs without any
NS declarations are received, if they are received on netconf
connections (i.e., any port the agent is listening as a netconf port).

If such a PDU contains elements or attributes that are not
in the netconf NS that the agent is using, then you should generate the
appropriate errors.  So even if the agent can figure it
out without namespaces, it SHOULD generate unknown-element
or unknown-attribute errors in this case.  (I think it's
anti-user-friendly, but what can you do, it's XML ;-)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 13 Jun 2006 21:18:57 +0200 (CEST)

> anti-user-friendly, but what can you do, it's XML ;-)

I don't think you'd have to generate unknown-element in this case
because of XML rules.  If you get an instance document w/o xmlns
declarations, the elements in the instance document don't belong to
any namespace.  If you treat an 'rpc' element without a namespace
declaration to mean the 'rpc' element from the netconf namespace, you
can treat the 'interfaces' element to mean the 'interfaces' element
from the ifMIB namespace.

I think it's logical to either be strict (which we are today) or else
allow an instance document w/o namespaces whatsoever.

(First I thought that the elementFormDefault="qualified" attribute in
the netconf schema meant that the schema required instance documents
to qualify the top-level elements with a namespace, but I'm not so
sure anymore (although libxml2 seems to work like that).  XML Schema
is tricky...)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Jun 2006 18:18:57 -0700

> from the ifMIB namespace.

Actually this is what I do now.
Instead of defaulting to the netconf NS,
I default to no namespace. If namespaces
are not used at all, then wrong-namespace won't
be generated.  If any of the elements are not owned by
the default owner, then an unknown-element would be generated.

Namespaces are fully supported if they are used, of course.

Andy