Subject: [Json] Conclusions for Working Group Last Call of draft-ietf-json-i-json-02

From: Matt Miller <[email-masked]>
Date: Tue, 5 Aug 2014 11:29:39 -0600

The Working Group Last Call on draft-ietf-json-i-json-02 ended a
couple of weeks ago.  Other than an incorrect reference (RFC 7149
versus RFC 7159), two other concerns were raised:

* Whether binary data should be encoded as base64 or as base64url
* Defining an RFC 6906 profile URI

With regards to base64 vs. base64url: The Chairs do not see any
consensus from the Working Group on which choice is better, which
means the draft's current text (recommending base64url) remains.

With regards to a RFC 6906 profile URI: The Chairs do not see any
consensus to define such a profile.

The Chairs ask the editor to produce a new draft that corrects the
reference to RFC 7149 with a reference to 7159.  Once published, this
new draft will be submitted to the Area Director with a request to
send it to the IESG for publication.

Thank you,

- - Matt Miller and Paul Hoffman

---

From: Tim Bray <[email-masked]>
Date: Tue, 5 Aug 2014 10:37:08 -0700

I actually disagree slightly.  I thought there were a few voices in favor
of switching from base64url to just base64 - for maximal compatibility -
and I don’t recall a single person actually being against that.

On Tue, Aug 5, 2014 at 10:29 AM, Matt Miller <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBCgAGBQJT4RSDAAoJEDWi+S0W7cO19FsH/j3n/RdjFZijC5ts8H13J0kq
> 9X2jEmJJtYkUVWb9etKMZ1/KHk8AIzIYwHCsBgqkfaCyl4HHnfhqQB/INqmC/DJl
> Yz7boqjsbYnJBwdDUlhKUmszzzYXMoomRK5gSRpIEYfh6Hr2Sc2rhKgxPdJelVcL
> CHVOWOnlpJHX0M06qZgF0Yuw0j6jOWukURp3d/PZl6CSbbuENfSDZlAmkwx/BEpV
> s9XjqEMGba+VvkfihsSLaJ+s5xPerBXfBLka3xPM00gFKpjTSuGrtxODeWjEmZ4P
> En0MdhorU1jlhxljkHVdCwVV9JUf9U0o9z46S+PFCLfIyUhzBXo21s/f6lc28Pg=
> =S68M
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 5 Aug 2014 20:33:06 +0200

> and I don’t recall a single person actually being against that.

I had hoped I was clear enough about being strongly against that regression.

Nothing new should use legacy base64.

(“base64url” actually stands for RFC 4648 base64url without the equals signs for padding and without whitespace.
See draft-ietf-jose-json-web-signature-31.txt, Section 2 and Appendix C.)

Grüße, Carsten

---

From: Tim Bray <[email-masked]>
Date: Tue, 5 Aug 2014 11:38:13 -0700

Hm, a reminder of Ladislav Lhotka’s original report at
http://www.ietf.org/mail-archive/web/json/current/msg03129.html

Are there any cases in which I-JSON being base64url going to cause problems
like this for other IETF work?  If the answer is “no” I’ll shut up.

On Tue, Aug 5, 2014 at 11:33 AM, Carsten Bormann <[email-masked]> wrote:

> (“base64url” actually stands for RFC 4648 base64url without the equals
> signs for padding and without whitespace.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 5 Aug 2014 20:50:46 +0200

On 05 Aug 2014, at 20:38, Tim Bray <[email-masked]> wrote:

> Hm, a reminder of Ladislav Lhotka’s original report at http://www.ietf.org/mail-archive/web/json/current/msg03129.html

Yang-JSON has another interesting issue:

3.3.1.  Numeric Datatypes

   A value of one of the YANG numeric datatypes ("int8", "int16",
   "int32", "int64", "uint8", "uint16", "uint32", "uint64" and
   "decimal64") is mapped to a JSON number using the same lexical
   representation.

I think there would need to be a decision whether yang-JSON is more like I-JSON or more like yang-XML.
(And I would guess yang-JSON is always going to prioritize being like yang-XML.)

I-JSON is more about capturing where the JSON puck is now, and is likely to be for a while, not about compatibility with every legacy.

Grüße, Carsten

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 5 Aug 2014 19:04:56 +0000

>See draft-ietf-jose-json-web-signature-31.txt, Section 2 and Appendix C.)

Nitpicking.

My reading of 4648, section 3.1 says that whitespace is the same for
either:

"Implementations MUST NOT add line feeds to base-encoded data unless
   the specification referring to this document explicitly directs base
   encoders to add line feeds after a specific number of characters."

Mostly, base64url changes to +/ to -_ and omits the padding "if the data
length is known implicitly".  I think "implicitly" here means we know the
length of the base64-encoded data, so I can't think of a case where it's
not true.

I believe there were a couple of JOSE use cases for which base64url was
preferable.

-- 
Joe Hildebrand

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 5 Aug 2014 21:22:57 +0200

On 05 Aug 2014, at 20:38, Tim Bray <[email-masked]> wrote:

> base64url going to cause problems like this for other IETF work

jCal uses base64 (RFC 7265).

3.6.1.  Binary (RFC 5545, Section 3.3.1)

   Description:  iCalendar "BINARY" property values are represented by a
      property with the type identifier "binary".  The value element is
      a JSON string, encoded with base64 encoding as specified in
      Section 4 of [RFC4648].

   Example:

   ["attach", {}, "binary", "SGVsbG8gV29ybGQh”]

jCal doesn’t seem to have a number problem with INTEGER (a 32-bit signed).
I have no idea what precision FLOAT is supposed to have (RFC 5545 only seems to use it for geographic positions, where 53 bits should be enough unless you need picometer accuracy):

3.3.7.  Float

   Value Name:  FLOAT

   Purpose:  This value type is used to identify properties that contain
      a real-number value.

   Format Definition:  This value type is defined by the following
      notation:

       float      = (["+"] / "-") 1*DIGIT ["." 1*DIGIT]

   Description:  If the property permits, multiple "float" values are
      specified by a COMMA-separated list of values.

      No additional content value encoding (i.e., BACKSLASH character
      encoding, see Section 3.3.11) is defined for this value type.

   Example:

       1000000.0000001
       1.333
       -3.14

Grüße, Carsten

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 5 Aug 2014 19:52:21 +0000

I don't have a strong opinion, and would be fine with either as long as we
pick exactly one.

On 8/5/14, 1:22 PM, "Carsten Bormann" <[email-masked]> wrote:

>I have no idea what precision FLOAT is supposed to have (RFC 5545 only
>seems to use it for geographic positions, where 53 bits should be enough
>unless you need picometer accuracy):
>
>3.3.7.  Float
>
>   Value Name:  FLOAT
>

-- 
Joe Hildebrand

---

From: Larry Masinter <[email-masked]>
Date: Thu, 7 Aug 2014 07:25:24 +0000

> * Defining an RFC 6906 profile URI

For the record, I don't agree with this summary. I raised a concern
http://www.ietf.org/mail-archive/web/json/current/msg03102.html
during the last call.

There was an extensive discussion of my concerns, which I elaborated
and expanded, and I didn't see a lot of support for my position.
Perhaps the rough consensus is that those concerns have been
addressed (although I personally don't think they have adequately.)
But don't leave it out of the last call summary.

Larry
--
http://larry.masinter.net