Subject: Re: [netmod] yang-json document

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Feb 2015 13:14:47 +0100

On Thu, Jan 29, 2015 at 05:09:11PM +0100, Ladislav Lhotka wrote:
> 
> Objections, comments, other issues?
>

The I-JSON document has changed its structure and the section
references now need updating.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Feb 2015 13:52:10 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> Hi,
> 
> $SUBJ is already several months late, so I think we should proceed
> towards delivering it. I checked my mail archive since the -02 revision,
> and it seems two issues need to be resolved:
> 
> 1. Andy objected to making redundant namespace prefixes illegal. I
>    propose the following change to 4th paragraph in sec. 4 (SHOULD NOT
>    instead of MUST NOT):
> 
>    OLD
> 
>    Names with namespace identifiers in the form shown in Figure 1 MUST
>    be used for all top-level YANG data nodes, and also for all nodes
>    whose parent node belongs to a different namespace.  Otherwise, names
>    with namespace identifiers MUST NOT be used.
> 
>    NEW
> 
>    Names with namespace identifiers in the form shown in Figure 1 MUST
>    be used for all top-level YANG data nodes, and also for all nodes
>    whose parent node belongs to a different namespace.  Otherwise, names
>    with namespace identifiers SHOULD NOT be used.

I don't think this is a good idea.  The reason is that it complicates
both client and server code.  An implementation cannot write code like
this:

   name = interface['name']
   mtu = interface['mtu']

instead we have to look for both 'name' and 'ietf-interfaces:name':

   if 'name' in interface:
     name = interface['name']
   else
     name = interface['ietf-interfaces:name']

One single deterministic encoding is simpler everywhere and less
error-prone.
  
> 2. anyxml encoding: although it is a misnomer, I propose to keep the
>    current definition (sec. 5.5), i.e. allow any valid JSON value in
>    JSON-encoded anyxml instances. I also think the text makes it
>    sufficiently clear that no standard mapping between XML- and
>    JSON-encoded instances is defined.

Ok.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 5 Feb 2015 14:01:35 +0100

> On 05 Feb 2015, at 13:14, Juergen Schoenwaelder <[email-masked]> wrote:
> 

I’ll check the changes.

Thanks, Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 5 Feb 2015 14:49:31 +0100

> On 05 Feb 2015, at 13:52, Martin Bjorklund <[email-masked]> wrote:
> 

I agree with you, this again makes standard JSON parsers (that give you a pointer to the parsed structure) considerably less useful.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Feb 2015 08:07:54 -0800

> I agree with you, this again makes standard JSON parsers (that give you a pointer to the parsed structure) considerably less useful.

Customers are not following this rule and they never will.
They avoid the problem by avoiding local-name conflicts
in the first place. It is not user-friendly or CLI-friendly
to allow sibling nodes to have the same local name.
These are not open systems so controlling the module set
is not a problem.

>>>   JSON-encoded instances is defined.

I am not so sure ignoring XML is OK.
There should be a warning that the JSON encoding the
sender picks is not "sticky".  The receiver MAY change it
to something else, such that if the original sender retrieves
a new copy from the server, the JSON types might have changed.

It is only safe to use the common features between XML and JSON.

>> /martin

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Feb 2015 08:27:46 -0800

>>>   with namespace identifiers SHOULD NOT be used.

I think MUST violates the RFC 2119 rules (issue Randy already raised).
If the receiver gets "interfaces" instead of "ietf-interfaces:interfaces",
and there is only 1 possible match, then the receiver is forced to
reject input that it understands.  Even if there are multiple matches,
the receiver may be able to detect which object is being sent.

Of course, if there are multiple matches and the receiver cannot
detect which one is sent, the input MUST be rejected.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Feb 2015 21:45:57 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> > I agree with you, this again makes standard JSON parsers (that give
> > you a pointer to the parsed structure) considerably less useful.
> >
> 

But this is *another* issue.  Neither of the alternatives support this
use case.

> I am not so sure ignoring XML is OK.

So how would you encode an arbitrary XML snippet (which is what anyxml
is) in JSON?  I know you want to restrict anyxml, but that is simply
not how it is defined in 6020.  For now we have to live with that.

> It is only safe to use the common features between XML and JSON.

Right, and you get this from anydata!

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Feb 2015 21:51:50 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> reject input that it understands.

What if it gets "Interfaces"?  Or "intrefaces"?  It is obvious what
was meant, so should we specify that these cases must be handled as
well?

Ths point is that if we allow multiple representations, *all* code
must handle *all* representations.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Feb 2015 13:21:55 -0800

> not how it is defined in 6020.  For now we have to live with that.

No -- the description-stmts for the anyxml nodes in YANG Patch
specify the limitations and an implementation of ietf-yang-patch
MUST support what it says.  If other individual YANG modules
want to constrain anyxml in specific ways, they can do that.
We can specify what an implementation of a particular module MUST
accept.

XML has simple nodes which are empty and those which are not empty.

  XML non-empty simple node <-->  JSON string
  XML empty node <--> JSON null
  XML complex node <--> JSON object

No requirement to send arrays, boolean, or numbers, but MAY send,
and MUST accept.  No requirement to preserve JSON type info.
Must preserve xmlns and other attributes if QName or XPath content found.
No XML PIs or mixed content allowed.
IMO this will make XML <--> JSON translation work.

> Right, and you get this from anydata!

Not as Lada defined his YANG to JSON mapping.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Feb 2015 13:27:20 -0800

> was meant, so should we specify that these cases must be handled as

This is a straw-man.
The identifier is case-sensitive, as defined in YANG and XML.
An exact-match on the local-name is required.
An unknown module-name MUST be rejected, not ignored.

> must handle *all* representations.

I think "sender SHOULD provide module-name" is better than MUST.
(Coupled with receiver MUST reject ambiguous input.)

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Feb 2015 22:46:30 +0100

> IMO this will make XML <--> JSON translation work.

Perhaps things work in YANG patch because it is constrained enough but
that does not mean things work for every possible valid usage of anyxml
according to RFC 6020. RFC 6020 says that anyxml is any xml.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Feb 2015 13:57:16 -0800

> according to RFC 6020. RFC 6020 says that anyxml is any xml.

That YANG text was written without any use-cases in mind.
If a YANG module is written that has a use-case for unconstrained XML,
then anyxml is ready to use.

I have never seen anyxml actually used that way.
In every case, there is a schema to apply, known to
the implementation somehow.  In every case there are
only YANG nodes expected. No PIs. No mixed context.

So I do not believe this is a real problem.
I think YANG 1.1 could spend a lot of effort defining
schema rules for unconstrained data, but this might not
help address the real uses of anyxml.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Feb 2015 23:09:03 +0100

> help address the real uses of anyxml.

The argument "my code has a more specific interpretation and I believe
everybody else does the same" only works if everybody confirms it. I
have not seen that confirmation. Hence, to fix this, we have Y34-05
for YANG 1.1.

This thread is about the current JSON mapping document, which is based
on YANG 1.0. Again, the argument "my code has a more specific
interpretation and I believe everybody else does the same" only works
if everybody confirms it. As long as we do not have a confirmation
that everybody happens to do what your code does, I think we have to
assume that anyxml means what RFC 6020 says, any xml.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Feb 2015 14:41:04 -0800

> assume that anyxml means what RFC 6020 says, any xml.

Maybe you misunderstood.
anyxml is being used as a placeholder for a "real schema"
that YANG is unable to express.  "my code knows how
to pick the real schema for this anyxml blob" is part of
the data model or protocol definition.

I don't think Y34-05 addresses this issue.

Even the "blog" use-case expects valid HTML to be specified
in the anyxml, not free-form, any XML.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 5 Feb 2015 23:48:23 -0500

>We can specify what an implementation of a particular module MUST

Doesn't this mean that yang-patch is not compatible with
yang, since one can define models in yang that yang-patch
will not handle?

>  XML complex node <--> JSON object

This is an extreme oversimplification.  Consider the real-world
case:

    anyxml web-banner {
        description "Chunk of XHTML that is placed at the
                top of every page for the embedded web server";
    }

    <web-banner>
        <p>This is <em>very</em> sensitive data </p>
        <img src="mister-yuk.png"/>
        <p>I'm serious, dude</p>
    </web-banner>

What does the JSON for this look like?  I think the only viable
answer is:

    "web-banner": "<p>This is <em>very</em> sensitive data </p>\n<img src="mister-yuk.png"/>\n<p>I'm serious, dude</p>\n"

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Thu, 5 Feb 2015 23:53:30 -0500

>the data model or protocol definition.

Consider the proxy case, where the main server does not know the
schema of the proxied device.  If you make the assumption that
anyxml is only used in certain select scenarios, you greatly
diminish its value.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Feb 2015 21:12:43 -0800

>         <img src="mister-yuk.png"/>

by real-world you mean your server actually supports this config?

>     "web-banner": "<p>This is <em>very</em> sensitive data </p>\n<img src="mister-yuk.png"/>\n<p>I'm serious, dude</p>\n"

It's OK with me if the optional JSON encoding is dropped.
If corner-cases like this are deemed to be so important,
then just use XML and forget about JSON.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Feb 2015 21:35:24 -0800

>     "web-banner": "<p>This is <em>very</em> sensitive data </p>\n<img src="mister-yuk.png"/>\n<p>I'm serious, dude</p>\n"

I don't see how this will possibly work.
How does the server know the JSON string is special
and should be rendered as raw XML?  A normal server
is going to escape all the angle brackets if rendered in XML.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 06 Feb 2015 13:05:06 +0100

> Customers are not following this rule and they never will.

Likewise, your customers may not be following the rule that the last
member in an object must not be followed by a comma, and your parser may
even tolerate it. Nevertheless, it still violates the JSON spec.

Martin's example is a real problem for application writers who want to
use standard JSON parsers - and support for as many existing parsers as
possible is exactly the reason why we decided to support
I-JSON. Consider that the disambiguation code above (with prefix or
without?) will have to be done essentially for all keys the application
needs to access.

I understand your JSON parser is custom-made so it is of no concern to you.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 06 Feb 2015 13:18:52 +0100

> We can specify what an implementation of a particular module MUST

Exactly! I think most, if not all, uses of anyxml and anydata will
assume some specific syntax and semantics (that needs to be explained in
the description). But this may also include a sensible, perhaps
non-trivial, way for mapping XML to JSON and back. And if there is no
sensible mapping, it is IMO also acceptable that certain uses of anyxml will
only be possible in XML encoding.

The point really is that there needn't be any common rules for all uses
of anyxml, except that it has to be well-formed for the given encoding. 

> Not as Lada defined his YANG to JSON mapping.

So far, anydata isn't covered at all.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 06 Feb 2015 13:49:02 +0100

Phil Shafer <[email-masked]> writes:

>     "web-banner": "<p>This is <em>very</em> sensitive data </p>\n<img
>     src="mister-yuk.png"/>\n<p>I'm serious, dude</p>\n"

I don't think so, the following is IMO a much better option:

    "web-banner":
      "This is *very sensitive* data.

       ![](mister-yuk.png)

       I'm serious, dude"

To be able to do this, it should be sufficient that the description of
the "web-banner" anyxml node states that HTML has to be used in XML
encoding and markdown in JSON.

Note that the -00 version of the draft contained a very similar example:

http://tools.ietf.org/html/draft-ietf-netmod-yang-json-00#section-3.2.5

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Feb 2015 14:36:07 +0100

> of anyxml, except that it has to be well-formed for the given encoding. 

Your interpretation that anyxml means any-encoding-specific-stuff does
apparently not match everybody's reading of RFC 6020's definition of
anyxml.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Feb 2015 14:38:43 +0100

> http://tools.ietf.org/html/draft-ietf-netmod-yang-json-00#section-3.2.5

As technical contributor, I do not agree that an encoder is tasked to
arbitrarily render XML content in the hope that the receiver likes the
result.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 6 Feb 2015 14:47:26 +0100

> On 06 Feb 2015, at 14:36, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Well, 6020 only deals with XML encoding and the definition is exactly what you said - any XML stuff:

   The "anyxml" statement is used to represent an unknown chunk of XML.
   No restrictions are placed on the XML.

I don’t know why JSON (or, for that matter, any other) encoding should be any different.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Feb 2015 14:54:42 +0100

> I don’t know why JSON (or, for that matter, any other) encoding should be any different.

RFC 6020 very clearly defines what anyxml is. With YANG 1.1, we are
likely 'deprecating' anyxml and adding anydata, which is any data that
can be modeled with YANG. This, however, does not mean that anyxml
suddenly changes its meaning. And so far, the JSON mapping is based on
YANG 1.0, that is RFC 6020, where anyxml means any xml.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 06 Feb 2015 14:57:38 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> 
> > On 06 Feb 2015, at 14:36, Juergen Schoenwaelder

Again we're going in circles.

Right now we have a problem:

  1.  We want YANG PATCH to be interoperable.

  2.  YANG PATCH uses anyxml.

  3.  YANG PATCH supports json encoding as defined in the json draft.

  4.  The json draft says that no encoding is defined for anyxml.

  5.  Conclusion: (1) cannot be true.

So how do we solve this?

  A.  Wait for anydata, and define json encoding rules for anydata.

  B.  Remove support for json from YANG PATCH.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 6 Feb 2015 14:59:19 +0100

> On 06 Feb 2015, at 14:54, Juergen Schoenwaelder <[email-masked]> wrote:
> 

How did you come to the conclusion that I want to change the meaning of the 6020 definition of anyxml?

Unlike others, I think anyxml in its current form can occasionally be useful.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 6 Feb 2015 15:12:43 +0100

> On 06 Feb 2015, at 14:57, Martin Bjorklund <[email-masked]> wrote:
> 

You probably mean the json draft defines no *mapping* for anyxml. This of course doesn’t prevent the YANG PATCH document from defining specific rules and XML-JSON mapping for the contents of its anyxml nodes, perhaps exactly in the sense of anydata.

Why is this a problem?

Lada

>  B.  Remove support for json from YANG PATCH.

  C. Define specific rules for anyxml appearing in YANG PATCH.

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 06 Feb 2015 15:22:23 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> You probably mean the json draft defines no *mapping* for anyxml.

Ok, there is no mapping defined, but also, the *encoding* is not
clear:

   An anyxml instance is encoded as a name/value pair.  The value can
   be of any valid JSON type

This means that in general, there is no interoperable way to encode
anyxml in json (and this I think is just fine).

> This
> of course doesn’t prevent the YANG PATCH document from defining
> specific rules and XML-JSON mapping for the contents of its anyxml
> nodes, perhaps exactly in the sense of anydata.

I don't think this proposal has come up before.

Then the json document should probably say that any usage of anyxml
MAY define specific encoding and mapping rules.

> Why is this a problem?

Well, it probably works in one or two use cases, but it is not very
scalable...

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 6 Feb 2015 15:51:24 +0100

> On 06 Feb 2015, at 15:22, Martin Bjorklund <[email-masked]> wrote:
> 

The description of “anyxml value” in yang-patch is pretty strict about what the content can be and the JSON encoding is then straightforward. The XML snippet in the description would become

"yang-patch:value": {
   "example-foo:foo": {
     "a": "some value",
     “b": 42
   }
}

Yes, it is possible that for certain use cases anyxml content will be defined only for XML encoding, a json client may simply receive null (and the description of that anyxml node should say so).

> I don't think this proposal has come up before.

I am lazy to search through the previous discussions but I've always claimed that every anyxml should be considered specific. If it is defined to carry configlets, the client cannot expect the server will accept an arbitrary XML content instead.

> MAY define specific encoding and mapping rules.

OK, this is possible, but I’d rather say

Any usage of anyxml MAY define a specific syntactic, semantic and mapping rules.

Actually, 6020bis can say it as well.

> scalable…

What do you mean by scalability? Every anyxml is a node with its own name, namespace and description. It is up to the data model designer to decide what makes sense.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 06 Feb 2015 16:16:17 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> I am lazy to search through the previous discussions but I've always
> claimed that every anyxml should be considered specific. If it is
> defined to carry configlets, the client cannot expect the server will
> accept an arbitrary XML content instead.
> 
> > 

It breaks all abstractions if the data model starts to talk about how
nodes are encoded to different formats.

> What do you mean by scalability? Every anyxml is a node with its own
> name, namespace and description. It is up to the data model designer
> to decide what makes sense.

Every such node would require special code.  There is no way in
general for the application developer to impact the encoding, but this
would be needed in order to support this - or the base code needs to
have special hacks for all such nodes.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Feb 2015 07:22:42 -0800

> nodes are encoded to different formats.

+1

> have special hacks for all such nodes.

This is the description-stmt for the anyxml 'value' node in YANG Patch:

           description
               "Value used for this edit operation.
                The anyxml value MUST represent a container with
                exactly one child node, which MUST identify the
                target resource associated with the 'target' leaf.

                For example, suppose the target node is a YANG container
                named foo:

                    container foo {
                      leaf a { type string; }
                      leaf b { type int32; }
                    }

                The value node will contain one instance of foo:

                    <value>
                       <foo xmlns='example-foo-namespace'>
                          <a>some value</a>
                          <b>42</b>
                       </foo>
                    </value>
                 ";

IMO this is the best we can do with YANG 1.0 and even YANG 1.1.
An implementation of this data model has rules to follow.
The description-stmt is just as normative as the type-stmt.
People seem to forget that.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 6 Feb 2015 10:36:34 -0500

>by real-world you mean your server actually supports this config?

Our DDL lacks anyxml, so we encode this as a string.

>then just use XML and forget about JSON.

I don't know that we can forget about JSON.  My suggestion is
encoding anyxml data as strings in JSON.  Seems simple enough.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Feb 2015 07:41:02 -0800

....
> This is an extreme oversimplification.

You are right. 2 more rules:

 - Multiple matching siblings or ordered-by user list or leaf-list MUST
   sent as a JSON array to preserve the order.
 - XML attributes MUST be preserved in case descendant-or-self nodes
   have QNames in the content (most common: identityref leaf)

> Consider the real-world

Our internal data structures have nowhere to put text interspersed
with the YANG nodes.  The "web-banner" would be a leaf of type
string,  not anyxml. This is the correct way to have the server store
arbitrary HTML.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 6 Feb 2015 10:41:05 -0500

>only be possible in XML encoding.

If you are saying that JSON can't traffic my entire config, then
RESTCONF can't be used for simple tasks like backup and restore,
since they won't see the full config.  I don't think that's reasonable.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Fri, 6 Feb 2015 10:44:40 -0500

>encoding and markdown in JSON.

Are you saying that YANG should not support HTML, only markdown?
Aren't we trying to support more flexibility than that in our data?

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Fri, 6 Feb 2015 10:54:49 -0500

Ladislav Lhotka writes:
>I don't know why JSON (or, for that matter, any other) encoding should be any different.

I think you're missing something here.  "anyxml banner" means that
in my datastore, "banner" is (conceptualy) an arbitrary chunk of
XML.  When you fetch that via traditional NETCONF, that chunk of
XML is copied into the data stream when/as needed.  Incoming values
for banner are stuffed into the database.

For this to work via JSON, the same abilities need to exist.  I
need to put my arbitrary chunk of XML out of my database and insert
it into my JSON data stream.  When a value for banner arrives, I
need to insert it into my database.  JSON is just a means of encoding
that data.  Use of JSON doesn't invent the right to redefine that data,
or to say that I should have been markdown, not HTML, or to say that
the JSON encoding just won't work for banner.

I continue to think that JSON needs to encode anyxml as strings.
I can't see anything else working here.

For that matter, I'm still not seeing way "anydata" isn't just "type string".

If you wanted anyjson, XML would need to encode that data as a
string.  Then again, anydata and anyjson are new features, so we
shouldn't go there.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Fri, 6 Feb 2015 10:55:53 -0500

>YANG 1.0, that is RFC 6020, where anyxml means any xml.

What's the logic/motivation in deprecating anyxml?

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 6 Feb 2015 16:58:23 +0100

> On 06 Feb 2015, at 16:16, Martin Bjorklund <[email-masked]> wrote:
> 

Well, talking about abstractions in connection to anyxml doesn’t make much sense to me. In my view, anyxml is just a backdoor that allows to piggyback some content that, for some reason, cannot be made part of a regular model. The position of anydata can be different but until we have it I think the best option is to accept that every anyxml is special.

> Every such node would require special code.  There is no way in

Yes, YANG PATCH requires special code, configlets require special code etc.

Lada

---

From: Phil Shafer <[email-masked]>
Date: Fri, 6 Feb 2015 11:01:03 -0500

Ladislav Lhotka writes:
>I am lazy to search through the previous discussions but I've always claimed that every 
>anyxml should be considered specific. If it is defined to carry configlets, the client c
>annot expect the server will accept an arbitrary XML content instead.

If every anyxml requires special encoding rules, then are we removing
the ability to generically process yang data?

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 6 Feb 2015 17:04:05 +0100

> On 06 Feb 2015, at 16:44, Phil Shafer <[email-masked]> wrote:
> 
> Ladislav Lhotka writes:

YANG as such supports neither HTML nor markdown but a given anyxml node could support both.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 6 Feb 2015 17:07:33 +0100

> On 06 Feb 2015, at 16:41, Phil Shafer <[email-masked]> wrote:
> 
> Ladislav Lhotka writes:

Most use cases for anyxml I am aware of are actually not in config. If you want to have an anyxml node in config, you should probably make sure a mapping exists in both ways. This is however still much easier than defining a universal mapping.

Lada

---

From: Phil Shafer <[email-masked]>
Date: Fri, 6 Feb 2015 11:07:54 -0500

>   have QNames in the content (most common: identityref leaf)

Still too simple, since XML can have matching siblings interleaved
with other nodes.

>with the YANG nodes.

Then you'd need to carry anyxml content as strings within your database.

>The "web-banner" would be a leaf of type

Your ability to dictate "the correct way" to the modeler is not always
guaranteed.  ;^)

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Feb 2015 08:10:35 -0800

> the ability to generically process yang data?

This reminds me of the SNMP debates about optimizing for generic tools
like a MIB walker, or data-model-aware tools like an NMS.

IMO your web-banner example is invalid because a string leaf is the proper
YANG data model design, not anyxml.

What do we expect tools to be able to do with anyxml if they
do not understand/implement the data model containing the
anyxml object?  IMO, just display it, and JSON is readable
enough whether the string is "42" instead of 42.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 6 Feb 2015 14:36:03 -0500

Ladislav Lhotka writes:
>Most use cases for anyxml I am aware of are actually not in config. If you want to have 
>an anyxml node in config, you should probably make sure a mapping exists in both ways. T
>his is however still much easier than defining a universal mapping.

Without a universal mapping, you're requiring that the central
agent/proxy know/support all the specific mappings.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Fri, 6 Feb 2015 14:39:20 -0500

>like a MIB walker, or data-model-aware tools like an NMS.

Sure and both types of tools have value.  Combinations of both tools
have value.

>YANG data model design, not anyxml.

Why isn't anyxml more proper?  It requires the data to be valid
XML, which is what I want.  Why would using an opaque data type
serve me better?

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Fri, 6 Feb 2015 14:56:09 -0500

>is going to escape all the angle brackets if rendered in XML.

The server is expected to have the data models for the content it
is carrying, so it will know that web-banner is "anyxml".  It knows
that anyxml values are encoded in JSON as strings.  It will accept
that string value and stuff it into the database.  If an XML client
retrieves it, the value will be sent according to the XML encoding
rules.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Feb 2015 12:02:10 -0800

> XML, which is what I want.  Why would using an opaque data type

Because there are very few implementations of anyxml.
The ones that do exist vary in the XML they accept as input
and the XML they generate as output.  Some servers do
not allow anyxml as data nodes at all.

It is not surprising that the JSON encoding would be problematic,
since we never had agreement on the XML encoding.

I really do not like anyxml instead of real data nodes.
I don't want to encourage the practice in YANG 1.1 by
adding anydata.  I think it is step in the wrong direction.

Maybe we need to be thinking about standardizing the
implementation magic that picks the correct media-type
template for the anyxml node. E.g., for YANG Patch
"application/yang.patch+xml" or "text/html" for your web-banner.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 6 Feb 2015 16:25:41 -0500

>not allow anyxml as data nodes at all.

That sounds more like an issue of incomplete implementations
than an explanation of why anyxml isn't a proper means of
modeling xml data.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Feb 2015 13:57:17 -0800

> than an explanation of why anyxml isn't a proper means of

Why do you implement web-banner with a string instead of anyxml?
Maybe the need for purely abstract or HTML data nodes is so rare that the
significant resources needed to support it are not available.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 6 Feb 2015 17:26:13 -0500

>Why do you implement web-banner with a string instead of anyxml?

Because that's what anyxml does.

>significant resources needed to support it are not available.

Rare?  Yes.  Useful?  Definitely.   I can certainly see your desire
to not waste your resources implementing it until one of your
customers needs it, but that doesn't mean it's not a valid part of
the YANG spec.

I have similar feelings for the notification mechanism, which is
far more ugly.  I'll implement it when customer demand (current
zero) exceeds my distaste (more than zero).  That's my choice, but
it doesn't effect the status of the notifications rfc.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Feb 2015 14:54:21 -0800

> customers needs it, but that doesn't mean it's not a valid part of

It is more than that.
I want to be very careful about the mandatory to implement standards.
If supporting a 1% use-case has a significant impact on footprint,
complexity, development costs, support costs, etc., then it won't
get implemented. That seems to be what already happened with anyxml.

> it doesn't effect the status of the notifications rfc.

But this is optional to implement. Big difference.

We actually support anyxml data nodes in the config or operational data,
but the implementation does not support mixed mode XML.
Internally, anyxml looks more like a leaf than anything else.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 08 Feb 2015 10:44:47 +0100

> for banner are stuffed into the database.

I don't think I am missing anything, actually I used pretty much the
same example previously:

http://www.ietf.org/mail-archive/web/netmod/current/msg11700.html

What you put to a database is one thing and what's presented to NETCONF
clients is another. If you decide to store HTML internally, you'd need to
translate input/output from/to JSON clients to markdown. But you can
also do it the other way around: store markdown and perform the
translations for XML clients.

I am not saying this is the only or best way for implementing this
particular use case, I just don't think that XML-in-JSON-string is the
only option because it has its share of problems, too.

For the record, I am not in favor of removing anyxml in its current
form. The only problem I have with it is the name. I think it can be
useful to have a node in YANG that allows for exchanging schema-less
chunks in *any* encoding.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Sun, 8 Feb 2015 08:37:31 -0800

> Phil Shafer <[email-masked]> writes:
......
> chunks in *any* encoding.

I agree.
So here is solution proposal Y34-06.
(BTW, Y34-05 was never added to the issue list).

Solution Y34-06
    - do not deprecate anyxml
    - do not add anydata (no agreement on rules)
    - implementations MAY restrict the XML accepted in anyxml
       - MAY ignore processing instructions
       - MAY reject mixed mode input
    - document in YANG 1.1 that anyxml is not considered interoperable
      if PIs and mixed mode XML are used
    - The guidelines document should say that YANG Doctors will review
      each use of anyxml in IETF modules

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sun, 8 Feb 2015 18:03:38 -0500

>translations for XML clients.

If my data model says it's a chunk of XHTML and your server gives me
markdown, someone's going to be very unhappy.

>chunks in *any* encoding.

anyxml isn't encoding agnostic.  It specifies a chunk of XML data.
The spec's fairly clear about that:

   The "anyxml" statement is used to represent an unknown chunk of XML.
   No restrictions are placed on the XML.  This

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sun, 8 Feb 2015 15:34:32 -0800

>    No restrictions are placed on the XML.  This

I agree RFC 6020 and 6241 do not prohibit mixed XML context,
except in get, get-config filtering.

Since very few implementations of anyxml-as-data-node exist in the wild,
it is a non-problem I guess.  If we cared about advancing YANG
to be a full standard, then it would matter.

However, it is hard to ignore the problem that we claim anyxml-as-data-node
is mandatory to implement in all servers, now that RESTCONF (and CoMI)
are being added to the mix.  Clearly we cannot have encoding-specific data nodes
if we want YANG to be encoding-independent. Vendors will want to support
a unified data node implementation somehow, no matter what the standard says.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 8 Feb 2015 16:08:26 -0800

> a unified data node implementation somehow, no matter what the standard says.

I do not think processing instructions are a problem.
XML parsers handle them.

RFC 6241, sec. 3.2 says:

   Document type declarations (see Section 2.8 of
   [W3C.REC-xml-20001006]) MUST NOT appear in NETCONF content.

The only problem seems to be mixed mode because it is ordered,
so JSON objects need to be encoded as arrays instead.

An XML parser will treat a mixed text node as an unnamed string node,
and JSON allows zero-length identifier names:

    <web-banner>

(Not sure if the JSON is right ;-))

  { "web-banner" : [
       "p" : [
          "": "This is",
          "em": "very",
          "": "sensitive data"
       ],
       "img": [null],
       "@img": {
           "src":"mister-yuk.png"
       },
       "p": "I'm serious, dud"
    ]
 }

I think even mixed XML can be encoded in JSON in a standard way.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sun, 8 Feb 2015 20:28:12 -0500

>      if PIs and mixed mode XML are used

This is essenially "be aware that server implementations might not
implement all of YANG".

>      each use of anyxml in IETF modules

This part I completely agree with.

Here's my proposal:

Solution Y34-07
  - do not change YANG
  - Change the JSON encoding rules to encode anyxml nodes as strings
  - The guidelines document should say that YANG Doctors will review
    each use of anyxml in IETF modules (lifted from Y34-06)

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Sun, 8 Feb 2015 20:34:08 -0500

>a unified data node implementation somehow, no matter what the standard says.

anyxml is not "encoding-specific data".  The data is a chunk of
XML.  When you go to encode it in XML, the encoding is trivial,
basically something simple like:

   encoded = data;

When you go to encode it in JSON, it's also trivial if you do it
as a string.  All you need to do is escape any quotes to satisfy
JSON:

    encoded = json_string_escape(data);

The data itself is not tied to the encoding.  It's a chunk of XML.
There's nothing magic going on that ties "the data is XML" to "the
encoding is XML", except that the encoding is slightly more trivial.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Sun, 8 Feb 2015 20:38:01 -0500

>I think even mixed XML can be encoded in JSON in a standard way.

I picked this example because this encoding doesn't work.  JSON
allows but doesn't like multiple instances of the same name.  I-JSON
makes it invalid.  The second "p" breaks this encoding.

On the other hand:

   "web-banner": '<p>This is <em>very</em> sensitive data </p>
        <img src="mister-yuk.png"/>
        <p>I'm serious, dude</p>'

works fine and doesn't mix layering, require AI-based conversions,
or tax the implementor's brains.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Feb 2015 09:18:38 +0100 (CET)

>     each use of anyxml in IETF modules (lifted from Y34-06)

This is fine (*) as one part of the solution, but by itself it isn't
sufficient.

The problem is illustrated in YANG PATCH, which is supposed to work
for both XML and JSON.  If YANG PATCH uses anyxml, it means that the
JSON encoding of a YANG PATCH is pretty much useless (since the edit
would be expressed as XML, but the reast in JSON).

This is why we have suggested to add anydata, which YANG PATCH then
should use instead of anyxml.

(*) Actually it is not trivial to simply encode an anxml element as a
string b/c of the namespace prefix issue (prefixes may have been
declared above the anyxml element, but used in the anyxml).

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 09 Feb 2015 09:20:22 +0100

>     - do not add anydata (no agreement on rules)

In this case I'd suggest to rename anyxml to anydata so as to open the
possibility of sending schema-less chunks in JSON and other encodings -
re-using anyxml for this purpose is possible but the name is misleading.

>        - MAY reject mixed mode input

I think it is a data model, rather than implementation, that could formulate
such restrictions.

>       if PIs and mixed mode XML are used

It depends on the definition of interoperability. In NETCONF, all this
can be perfectly interoperable. It is about interoperability in protocols
that support multiple encodings. I'd say it is the responsibility of a
data modeller to define mappings between whatever formats that need to
be supported.

>       each use of anyxml in IETF modules

It should be sufficient to give guidelines - it then goes without saying
that it should be part of the review by YANG doctors.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Feb 2015 00:59:22 -0800

>> This is essenially "be aware that server implementations might not

Isn't this already the case?
Why is it that not all servers fully support anyxml?

> should use instead of anyxml.

I strongly object to making YANG Patch YANG 1.1 only.
I would rather drop JSON support.

> declared above the anyxml element, but used in the anyxml).

good point

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 9 Feb 2015 09:59:27 +0100

> On 09 Feb 2015, at 09:18, Martin Bjorklund <[email-masked]> wrote:
> 

So how about (i) renaming “anyxml” to “anydata” and extending it to represent schema-less chunks in any encoding with no a priori guarantee of a loss-less mapping, and (ii) introducing “root” for embedded YANG schemas with defined mappings between all supported encodings?

+1

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 9 Feb 2015 11:08:43 +0100

> On 09 Feb 2015, at 09:59, Andy Bierman <[email-masked]> wrote:
> 

I think you can continue using anyxml in YANG PATCH, IMO there is nothing wrong with it. If the module gets upgraded to YANG 1.1, the descriptions could perhaps be made shorter, and that’s all.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Feb 2015 13:56:51 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> I think you can continue using anyxml in YANG PATCH, IMO there is
> nothing wrong with it. If the module gets upgraded to YANG 1.1, the
> descriptions could perhaps be made shorter, and that’s all.

I think you're missing the context.  Phil suggested that anyxml should
be encoded as a string in json, and we're discussing the implications
of that.  In this context, I do not think that anyxml can be used in
YANG PATCH - or we do what Andy suggests, drop json support.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 9 Feb 2015 14:15:03 +0100

> On 09 Feb 2015, at 13:56, Martin Bjorklund <[email-masked]> wrote:
> 

OK. Anyway, I am opposed to that encoding of anyxml in JSON. Apart from the problems you mentioned it is also asymmetric: no equivalent is available for JSON.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Feb 2015 07:44:53 -0800

On Mon, Feb 9, 2015 at 7:33 AM, Martin Bjorklund <[email-masked]> wrote:
>> On Mon, Feb 9, 2015 at 4:56 AM, Martin Bjorklund <[email-masked]> wrote:
>> It would be a shame to drop JSON support, because implementations will
>> ignore the standard and continue to support JSON in proprietary ways.
>>
>> The frustrating part for me is that there is not 1 single implementation
>> that is actually using anyxml as configuration storage for HTML.
>> If this is such a great use-case, then why isn't anybody doing it?
>>
>> OTOH, using anyxml as free-form YANG data nodes is implemented
>> by many vendors, in many forms, and has been working fine for years.
>
> Agreed.  But this is not anyxml, it is anydata.  So if we introduce
> anydata, we're standardizing what people are doing already.
>
> anyxml is still needed in order to correctly define the NETCONF
> protocol.  There are actually quite a few NETCONF implementations that
> still use some proprietary language; i.e., even if we had anydata it
> would be inappropraite to use it in the ietf-netconf.yang model.
>
>> I don't know why we would design for the 0% use-case instead of the
>> 100% use-cases.  The IETF seems to get wrapped around the axle
>> far too easily.
>
> To me it seems the only issue is timing.  If we had YANG 1.1. w/
> anydata today, YANG PATCH would use it, and everyone would be happy.
>

I agree with Lada that YANG Patch can use its current definition.
The 'value' node is not free-form XML. it MUST be a container
which contains 1 YANG data node, which MUST be an instance of
the specified target.

> anydata would have a clear encoding and mapping in JSON, and anyxml
> would not.
>

We can republish YANG Patch if/when anydata is available in the future.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Feb 2015 07:55:22 -0800

....
>...

Of course, if the specified datastore target is anyxml (or contains amyxml),
then all bets are off.  In theory, this could be embedded HTML.

If we add anydata, then IMO anyxml MUST NOT be used as a data node
in a YANG 1.1 module. anyxml can only be used in rpc and notification
in YANG 1.1.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 9 Feb 2015 18:00:40 +0100

> On 09 Feb 2015, at 16:25, Andy Bierman <[email-masked]> wrote:
> 

+1

> If this is such a great use-case, then why isn't anybody doing it?

It not only about HTML - there are many existing XML and JSON formats around and I think it would be good for YANG if it can offer means for passing them in anyxml/anydata, even if processing such data is outside the scope for YANG.

In fact, there are other peculiar features in XML that most likely won’t be needed, such as entities. I think it should be OK for a server to implement only a subset of XML with the caveat that it can only use data models that don’t permit the unimplemented features.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Feb 2015 07:25:06 -0800

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Feb 2015 16:33:04 +0100 (CET)

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 10 Feb 2015 11:30:45 +0100

Hi,

I'll try to summarize this long thread. Please comment.

>    propose the following change to 4th paragraph in sec. 4 (SHOULD NOT

It seems Andy is now the only supporter of this change, and I think
there are strong technical reasons for keeping namespace rules strict,
stable and deterministic. I am therefore inclined to keep "MUST NOT", or
reformulate the text in the same sense without using 2119 keywords.

>    JSON-encoded instances is defined.

Phil proposed to define a universal JSON encoding for anyxml values: a
string containing the serialised XML text. However, there are several
problems with this solution:

- an XML chunk may be well-formed in the XML encoding but not in JSON,
  because in XML it may receive namespaces and entity definitions from
  the outer context.

- "anyxml" cannot be used for defining contents of YANG-PATCH,
  configlets etc.

- it is asymmetric because no equivalent means exist for non-XML
  encodings.

I am therefore proposing a new solution for both YANG 1.1 and YANG-JSON
document that could IMO be a reasonable compromise (I also committed it
to SVN):

** Solution Y34-05 (LL: [2015-02-10 Tue])

   - Define a new data node "anydata". Its value is an arbitrary chunk
     of well-formed data in the current encoding. YANG 1.1 spec will
     also say:

     #+BEGIN_QUOTE
     This document defines no universal mapping between "anydata"
     values in different encodings. However, each definition of an
     "anydata" node MAY specify, in the "description" statement,
     syntactic, semantic and mapping rules for the values of that
     "anydata" node.
     #+END_QUOTE

   - For backward compatibility, allow "anyxml" to be used but make it
     a synonym to "anydata" and label as deprecated.

   - Align the specification for JSON encoding (or any other future
     encoding that will be defined for YANG 1.0) with the first item
     above.

   - Define a new data node "root" as in Y34-04.

   - Include guidelines in 6087bis for the use of "anydata/anyxml" and
     "root".

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Feb 2015 10:22:21 -0800

>>    with namespace identifiers SHOULD NOT be used.

I strongly object to changing the text above back to OLD.
The debate has been over top-level nodes missing the prefix,
not nested nodes that redundantly declare the same module
as the parent node.

We already agreed that the receiver has to parse the module name
every time in case it is different.  It has to remember the parent
module name in case it is missing in the child nodes.  So it is not an
interoperability issue but rather a style issue.  This is not the
same as MUST use on the top-level.

>      of well-formed data in the current encoding. YANG 1.1 spec will

What is "well-formed data"?
E.g., the sender and receiver do not know lists from containers, so encoding
the key leafs first is not possible.  Will servers generate the same results if
retrieval/editing produces round-trip conversions:
   JSON --> XML --> JSON    and   XML --> JSON --> XML

>    - Define a new data node "root" as in Y34-04.

This can only be uses in rpc or notification.
It cannot be nested within another 'root'.

>    - Include guidelines in 6087bis for the use of "anydata/anyxml" and

I am still unclear on the consensus and details for those guidelines.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Feb 2015 20:56:48 +0100 (CET)

> > reformulate the text in the same sense without using 2119 keywords.

I think it would be wise to rewrite the text to explain how the
different nodes (top-level in module, top-level in remote augment and
other) are encoded.  The current 2119 language seems to indicate that
there is some kind of choice involved.

> not nested nodes that redundantly declare the same module

No, the debate has been for all nodes.

> module name in case it is missing in the child nodes.

No, the point is that with deterministic rules, the receiver doesn't
have to do any special parsing at all.  The top-level node
"interfaces" in "ietf-interfaces" is *always* send as
"ietf-interfaces:interfaces", and its child node "interface" is
*always* sent as "interface" and the node "ipv4" that augments the
interface list is *always* sent as "ietf-ip:ipv4".

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Feb 2015 12:09:34 -0800

> interface list is *always* sent as "ietf-ip:ipv4".

But what if there is an "acme:interface" that augments
"ietf-interfaces:interfaces"?
Then the child node will not always be "interface". It might be "acme:interface"
instead.  The server better check, right?

Not checking for a module name means the server might assume
that "junk:interface" is a valid node and child of ietf-interfaces:interfaces.
Seems like the server has to check every node.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Feb 2015 21:29:41 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> instead.

No, in that case there are two separate nodes, one always encoded as
"interface" and one always encoded as "acme:interface", regardless of
how many other augments there are.

> The server better check, right?
> 

No, since with this scheme there is no flexibility, everything is 100%
predictable and stable.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Feb 2015 12:40:33 -0800

> No, since with this scheme there is no flexibility, everything is 100%

You really think it's a good idea to assume the data from the sender
is always valid and doesn't need to be checked?

I don't see how interoperability is increased if the server is
forced to reject input it understands.  I doubt customers will
see this as a feature instead of a bug.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Feb 2015 21:55:50 +0100 (CET)

> is always valid and doesn't need to be checked?

That is a completely separate question.  We're discussing the best way
to encode YANG node names in json.  It is up to us to specify this.
There is no given answer.  With clear and simple rules, chances are
higher that implementations are correct.

> see this as a feature instead of a bug.

I think you are missing the point.  If the rule is that a top-level
node is encoded as <module-name>:<node-name>, why would a server
"understand" just "interfaces"?  Surely a server would also understand
<module-name>-<node-name> or <module-name> <node-name>?

Your code can be as liberal as you program it to be, but the
specification needs to be clear and specify what is *valid*.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Feb 2015 13:11:07 -0800

> specification needs to be clear and specify what is *valid*.

The pattern is <module-name>:<local-name> so why would one
change the delimiter to a character that is invalid within a YANG
identifier?  Or to whitespace?  That doesn't make sense.

Since everything is 100% predictable as you say, the server
knows that "foo" matches the only node with a a local-name of "foo".
It seems to violate the Postel Principle to reject this input.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Feb 2015 22:19:35 +0100 (CET)

> identifier?  Or to whitespace?  That doesn't make sense.

Exactly - the encoding is <module-name>:<local-name>, why would anyone
send <local-name>?  If there is just one node, why would your server
care about the name at all?

> It seems to violate the Postel Principle to reject this input.

The Postel Principle says that an implementation should be liberal in
what it accepts, i.e., accept things that do not follow the
specification.  We are talking about what the *specification* should
be.  If the spec says that two forms are legal, the Postel Principle
doesn't apply to these two forms, since it is not liberal to accept
something that is legal!

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 11 Feb 2015 09:12:42 +0100

> there is some kind of choice involved.

Right. RFC 6020 also doesn't say that the decimal point MUST NOT be present
after an integer value.

> No, the debate has been for all nodes.

Yes, and the difference between OLD and NEW in my original mail is
clearly *only* about redundant namespace IDs.

+1

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 11 Feb 2015 19:16:36 -0800

> doesn't apply to these two forms, since it is not liberal to accept

So the standard will specify what the server MUST do if a client deviates
from the mandatory encoding?

I guess you can write MUST in the standard and I will add yet another
config parameter to our server to allow more lax parsing.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 12 Feb 2015 09:36:53 +0100

> specification.  We are talking about what the *specification* should

Exactly. RFC 1122 describes the Robustness (Postel) Principle as the
ability "to deal with every conceivable error, no matter how unlikely;".
It has thus nothing to do with protocol design.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 12 Feb 2015 09:47:26 +0100

> from the mandatory encoding?

If a client deviates from the spec, it is an error. A server implementor
can follow Postel Principle and make the software tolerant to that
error, but it is an error nonetheless.

Along the same lines, server software can tolerate that a client send an
uint8 value as "42." (ending with a dot), which is not permitted by RFC
6020.

Lada