Re: XML namespace advice

[Martin Bjorklund <mbj@tail-f.com>]

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

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?

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

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


/martin

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