Randy Presuhn <[email protected]> writes: > Hi - > >>From: Juergen Schoenwaelder <[email protected]> >>Sent: Nov 11, 2015 5:44 AM >>To: Ladislav Lhotka <[email protected]> >>Cc: [email protected] >>Subject: Re: [netmod] JSON encoding of anyxml > ... >>Observations: >> >> - Except b), none of the options is interoperable. Option d) is >> interoperable for the anydata subset of anyxml. >> - It seems a) is simplest to implement, b) might be expensive to >> implement and use. >> - Some implementations use internal data stores that can only deal >> with data that can be modelled with YANG and for those implementations >> anyxml is effectively the same as anydata and d) migth be close to >> a) in terms of implementation costs. >> >>Any other observations missing? > > The problem is similar to the ones that show up with ASN.1 "ANY" > (but *not* "ANY DEFINED BY") in environments supporting multiple > encoding rules / transfer syntaxes. > > For a recipient to *fully* decode something in such an environment, > either the encoding has unambiguously identify the grammar of the > bits in question, or the recipient has to have complete a priori > knowledge of everything that could possibly be encountered in that > context, along with any disambiguation logic. > > The "ANY DEFINED BY" construct meets that requirement, as long as > each set of encoding rules properly supports the abstract syntax. > ASN.1 "ANY" doesn't meet that requirement as soon as things like, > for example, IMPLICIT tagging come into play. > > Netmod and netconf have painted themselves into a corner here: > (1) the grammar can't be deduced from an encoding > (2) the information identifying the grammar of the payload > is not present on the wire, nor is it available in > machine-readable form in the data model. At best it'll > be handled on an ad hoc basis if a developer gets around > to it for a given leaf.
Right, that's exactly how I see it. Even if anyxml is deprecated in standard modules, I believe it may be useful if an implementation has the possibility to send some non-YANG data, for one reason or another. The vendor can then write a one-off module for this purpose and that's all. Lada > > This means that, as a practical matter, it's not going to be > practical or interoperable to treat the payloads of these types > as anything other than (octet) strings for transport. Attempts > to convert a value based on the (wrapping) transfer syntax will > only work for senders that know the payload's grammar. Generic > recipients and particularly relays would be Simply Out of Luck. > > Randy > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
