[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: XML namespace advice
If it doesn't have the NETCONF NS, then how do you know you are parsing a true NETCONF message and not some other <rpc> construct?
It seems to me NS should be mandatory, if even defaulted they still exist in the internal DOM.
The contents of a <config> or <filter> should also be proprietary NS'd by the vendor associated with the payload.
I raised this a few weeks ago, the NETCONF base schema needs to allow <any> content inside a <config> or <filter> node, with the added attribute: namespace="##other" to force the payload to be of a different NS than NETCONF.
as in:
<xs:complexType name="configInlineType">
<xs:sequence>
<xs:any namespace="##other"/>
</xs:sequence>
</xs:complexType>
My payloads look something like:
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<Top xmlns="urn:nmie:fnc:fujitsu:com">
<Equipments>
<Equipment>
<Name>Ethernet0</Name>
<AdminState xc:operation="replace">DOWN</AdminState>
</Equipment>
</Equipments>
</Top>
</config>
I validate against my propietary schema, which in turn imports the NETCONF schema. My entire <rpc> passes schema validation.
---------------------------------
Michael Hare
NMI Engineering
GnuPG Key fingerprint = 1AD4 726D E359 A31D 05BF ACE5 CA93 7AD5 D8E3 A876
-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
Behalf Of Andy Bierman
Sent: Saturday, June 10, 2006 2:38 PM
To: Martin Bjorklund
Cc: netconf@ops.ietf.org
Subject: 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/>
--
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/>