Re: element order error processing

[Andy Bierman <ietf@andybierman.com>]

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>   
> > Hi,
> >
> > I am confused as to which error-tag to use for wrong element order.
> >
> > For example:
> >
> > Given a simple data model:
> >
> > element foo {
> >    element a,
> >    element b,
> >    element c
> > }
> >
> > The use of missing-element vs. unknown-element error-tag is confusing:
> >
> > Given this PDU fragment:
> >  
> >   <foo>
> >      <a/>
> >      <c/>
> >   </foo>
> >
> > It is clear that a 'missing-element' error for "/foo/b" should
> > be generated here.
> >
> > What about this?:
> >
> >   <foo>
> >      <a/>
> >      <c/>
> >      <b/>
> >   </foo>
> >
> > A reasonable implementation choice would lead one to generate
> > a 'missing-element' error for "/foo/b" when "/foo/c" is encountered.
> > But "b" isn't missing, it is in the wrong place.
> >     
>
> We're generating 'missing-element' in this case.
>
>   

me too

> > The only other
> > error choice seems to be  'unknown-element' for "/foo/b"
> >     
>
> I'd say that the other alternative would be unknown-element for
> /foo/c.
>   

Well, once I see that 'b' is missing, I bump the
current-node pointer to 'c', so it is not unexpected.

Since 'c' is last, the error code that looks for extra nodes will catch 
this,
and generate an (unexpected) unknown-element error for 'b'.

It's the combination that seems crazy, and yet also appears to be most 
correct,
at the same time.

>   
> > in this case, which is totally confusing because "b" is not unknown
> > at all.
> >     
>
> Actually, unknown-element is defined as "An unexpected element is
> present".  So it just says that the element is "unexpected" not that
> it actually is "unknown".
>   

I know -- I was trying to point out that our error codes are overloaded.

IMO, we will probably want to refine this sooner or later.
An application really wants to know the difference between:
- agent doesn't know this node (maybe misspelled, or data model version 
mismatch?)
- node is in the wrong order
- more than the expected number of instances of a node are present

But the 'unknown-element' error-tag will be returned for all these error 
conditions.


>   
> > Generating a 'missing-element' and 'unknown-element' for "b"
> > in the same <rpc-reply> is even worse.
> >
> > What should the correct error response be in this case?
> >     
>
> I think missing-element for /foo/b and unknown-element for /foo/c are
> equally good (or bad).
>
> However, your implementation could use an error-app-tag to further
> describe this situation, if you can detect it.
>   

Yes, I guess I will.
But this is not good enough for an interoperable standard.

>   
> > Is an agent implementation allowed to ignore wrong-order errors
> > or must all elements always be given in a fixed order?
> >     
>
> This must be depending on the data model.  A data model could be
> defined with a strict order or not.  (compare w/ xs:all in a
> complexType in XML Schema).
>   

So it's up to the data modeling language, not XML itself?
That's what I was hoping.

So we don't HAVE to ignore the Postel Principle if we don't want to?

It really goes against common sense to reject an RPC with an error
like "parameter 2 and 3 are in the wrong order".  If the agent knows
all the parameters are present and accounted for,  that is good enough.
I'm not trying to force every agent to do this (I would say MAY, not MUST).

You may have noticed that CLI and Unix config file implementations
only enforce command order when they absolutely have to. 

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