Subject: Re: [netmod] I-JSON

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 1 Sep 2014 23:50:21 +0200

On Wed, Aug 27, 2014 at 03:30:19PM +0200, Ladislav Lhotka wrote:
> Hi,
> 
> I-JSON spec (draft-ietf-json-i-json-03) defines a restricted profile of
> JSON that guarantees maximum interoperability for protocols that use
> JSON in their messages, no matter what JSON encoders/decoders are used
> in protocol implementations. This is exactly what e.g. RESTCONF needs,
> so it would be useful to make JSON defined in the yang-json document
> I-JSON compliant.
> 
> A far as I can tell, these are the problematic parts:
> 
> Encoding and Characters
> =======================
> 
> - I-JSON requires UTF-8 encoding. Yang-json should do the same, which
>   may need recoding on the sender side.

NETCONF also requires UTF-8 (2nd paragraph in section 3 of RFC 6241).
 
> - I-JSON forbids Unicode surrogates or noncharacters. YANG "string" and
>   other types inherit XML character set which excludes surrogates but
>   not all noncharacters (for example, #xFDDO is allowed). The only
>   robust solution I can see is to ban noncharacters in YANG 1.1 -
>   yang-json cannot do it unilaterally.

Hm. Feels somewhat bad to change YANG because a new encoding has some
problems. I am not enough an expert in character sets to know what
would be the 'right' thing to do.

> Numbers
> =======
> 
> - I-JSON messages SHOULD NOT include numbers which express greater
>   magnitude or precision than an IEEE 754 double precision number. This
>   affects YANG int64, uint64 and decimal64 types. Proposal: encode
>   values of these types as strings.

Yep. I see no alternative.

> Binary Data
> ===========
> 
> - In I-JSON, it is RECOMMENDED that this data be encoded in a string
>   value in base64url. YANG's binary type requires base64. I raised this
>   issue twice in the JSON WG mailing list
>   (http://www.ietf.org/mail-archive/web/json/current/msg03129.html,
>   http://www.ietf.org/mail-archive/web/json/current/msg03192.html). Nobody
>   offered any arguments why base64url should be better than base64 for
>   encoding field values, but I also found no support for changing the
>   current text. So the only option seems to be not to follow this I-JSON
>   recommendation (and provide reasoning). 

Carsten Bormann was strongly advocating base64url but he did not
provide any clear reasons. Since we do not intend to send JSON as
part of URLs, I think we are fine with using base64.

It would be good to keep a list of open issues. Also add to it the
encoding of unions and the handling of anyxml. Do we need a specific
virtual interim meeting to close these open issues? I would like to
get this document complete and into WG last call...

/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: Ladislav Lhotka <[email-masked]>
Date: Tue, 02 Sep 2014 11:19:55 +0200

> NETCONF also requires UTF-8 (2nd paragraph in section 3 of RFC 6241).

So does RESTCONF, but we are talking about data without referring to
a particular protocol. XML defines a way for specifying character
encoding but JSON doesn't. If the intention is that UTF-8 be always used
even in XML, then YANG spec should probably say so.

> would be the 'right' thing to do.

Neither am I but my understanding is that it is more of an omission on
the XML side. If interoperability is our primary interest, I think
noncharacters should be banned in XML, too.

> part of URLs, I think we are fine with using base64.

Right, but if our goal is to be able to say that JSON encoding of
YANG-based instances is I-JSON, then I don't know whether we can do so
if we ignore RECOMMENDED encoding just for legacy reasons.

> get this document complete and into WG last call...

I hope we can decide the open issues in the mailing list, that's why I
opened them there.

BTW, speaking about virtual interims, I will be travelling again
tomorrow afternoon, but I hope I will miss only first twenty minutes or
so.

Lada

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Sep 2014 08:44:48 +0200

> even in XML, then YANG spec should probably say so.

YANG has a type system. RFC 6020 says what YANG strings are (in terms
of the character set, not its encoding) and may other types are
restricted by nature. The only type where things may be unclear is
anyxml.

RFC 6241 section 3 says that all NETCONF must be encoded in UTF-8. As
such, even anyxml must be encoded in UTF-8 when used with NETCONF. I
think the JSON I-D can easily require the same.

> noncharacters should be banned in XML, too.

So you are suggesting to change section 9.4. of RFC 6020 to exclude
noncharacters. Which other types do you think are affected? I think
the other types do not have an issue. 

I assume you also suggest that the anyxml statement gets text added
that the XML character set is restricted to a subset of what XML
allows?

> if we ignore RECOMMENDED encoding just for legacy reasons.

RFC 2119:

  3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
     may exist valid reasons in particular circumstances to ignore a
     particular item, but the full implications must be understood and
     carefully weighed before choosing a different course. 

I think this may be defendable. We likely should have a section
discussing I-JSON compliance and explain the reasoning where we depart
from the recommendations.

/js