Balázs Lengyel <[email protected]> writes: > Hello, > > Recently we came up against a problem where a certain implementation did not > accept the > following: > > <with-defaults xmlns="..."> > report-all > </with-defaults> > > while it did accept > > <with-defaults xmlns="...">report-all</with-defaults>
The "with-defaults" leaf is modelled as an enumeration in RFC 6243 (sec. 5), so the lexical representation is the assigned name, i.e. "report-all". So the behaviour above is correct according to the spec. On the other hand, this looks like a good place for applying the Postel principle because enum names must not have any leading or trailing whitespace, so no confusion can ever arise if this whitespace is stripped. Lada > > I am unsure whether YANG's XML encoding allows whitespace before and after a > leaf's value? In > RFC7950 it does not say yes or no. I have found the following examples that > seem to allow > preceding/following whitespace: > > https://tools.ietf.org/html/rfc7950#section-4.2.9 > > <status xmlns="http://example.com/system";> > The image example-fw-2.3 is being installed. > </status> > > https://tools.ietf.org/html/rfc7950#section-7.16.3 > > <reporting-entity> > /ex:interface[ex:name='Ethernet0'] > </reporting-entity> > > https://tools.ietf.org/html/rfc6243#appendix-A.3.1 > > <with-defaults > xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults"> > report-all > </with-defaults> > > It is problematic that this is not clarified. IMHO this should be clarified > in an errata to rfc7950. > Chose one: > > 1 It is not allowed to add preceding or following whitespace after the value > of a leaf/leaf-list. > Note that some text documents may add whitespace to Netconf examples to > avoid long > lines, > however this extra whitespace MUST NOT be present in the actual Netconf > encoding. > 2 It is not allowed to add preceding or following whitespace after the value > of a leaf/leaf-list. > 3 It is allowed to add preceding or following whitespace after the value of a > leaf/leaf-list except > for string based types, where the whitespace could be part of the leaf's > value itself.. > > What do you think? > > regards Balazs > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: [email protected] > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
