Subject: [Json] Support for "\/" in ECMA versus I-JSON?

From: Anders Rundgren <[email-masked]>
Date: Sat, 18 Nov 2017 16:54:18 +0100

It is [quite] possible that I got lost in ECMA's gigantic spec but I can't find any support for the "\/" escape in there but it surely is in I-JSON.

WDYT?

Anders

---

From: Tim Bray <[email-masked]>
Date: Sat, 18 Nov 2017 23:03:29 +0000

I can't imagine why you’d ever need \/ but it's blessed by RFC7159 - if
there's an inconsistency we should get it sorted out.

On Sat, Nov 18, 2017 at 3:54 PM, Anders Rundgren <
[email-masked]> wrote:

> It is [quite] possible that I got lost in ECMA's gigantic spec but I can't
> find any support for the "\/" escape in there but it surely is in I-JSON.
>
> WDYT?
>
> Anders
>
> _______________________________________________
> 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: "Paul Hoffman" <[email-masked]>
Date: Sat, 18 Nov 2017 15:23:58 -0800

On 18 Nov 2017, at 7:54, Anders Rundgren wrote:

> It is [quite] possible that I got lost in ECMA's gigantic spec but I 
> can't find any support for the "\/" escape in there but it surely is 
> in I-JSON.
>
> WDYT?

You may be viewing the wrong spec. 
http://www.ecma-international.org/publications/standards/Ecma-404.htm is 
only 14 pages. The escape you are looking for is in Section 9, on page 
4.

--Paul Hoffman

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 19 Nov 2017 06:54:35 +0100

> You may be viewing the wrong spec.

Indeed I was. Pardon.

> only 14 pages. The escape you are looking for is in Section 9, on page

As noted by Tim the \/ escape is just a relic and not used in JSON serializations
https://www.ecma-international.org/ecma-262/8.0/index.html#sec-quotejsonstring
which got me to (incorrectly) believe it had been removed for parsing as well.

BTW, this document (Ecma-262) is actually quite interesting from an "JSON-I"
point of view since you by adhering to it for JSON parsing and serialization,
without any additional work, get a "normalized" JSON representation fully
usable for digitally signatures.  The current signature standard (JWS) has
unfortunately prompted a flurry of "DIY standards" to overcome the need for
dressing signed JSON messages in Base64Url.

Anders