[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XML namespace advice

Martin Bjorklund wrote:

Andy Bierman <ietf@andybierman.com> wrote:

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?


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



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




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.



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.




A follow-up question is if a peer is non-compliant if it requires a
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.



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


We replicate the xmlns attributes, but I honestly can't see why this
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.





   Q3: Are there more xmlns processing and generation rules and/or
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.



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! ;-)







/martin



Andy


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