Skip to main content

Liaison statement
Response to "Ecma TC39 Comments on RFC 4727bis" from 2013-11-25

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2013-12-10
From Group json
From Contact Paul E. Hoffman
To Group ECMA-TC39
To Contacts
Cc Matthew Miller <>
Pete Resnick <>
Barry Leiba <>
Purpose In response
Attachments (None)
Thank you for your statement of concern about draft-ietf-json-rfc4627bis. The
chairs of the IETF's JSON Working Group were not aware of any serious concerns
that TC39 had with the update process. Over the past many months, we repeatedly
contacted ECMA and TC39 members about the JSON WG and
draft-ietf-json-rfc4627bis, but never received any significant reply. We know
that some TC39 members joined the JSON WG mailing list but did not voice any
process concerns in the WG -- or privately to the WG Chairs -- before or during
either of the Last Calls on the document.

In the future, it would probably be useful for Ecma and the IETF to have a
formal liaison relationship. We have heard that there were preliminary
discussions several months ago, but stopped short of a formal relationship
before the JSON Working Group was formed. Formalizing the liaison relationship
will help both SDOs communicate with each other and thus avoid late surprises.

As to your specific requests:

- In IETF Last Call, there was consensus to change the definition of "JSON
text" in draft-ietf-json-rfc4627bis to match the one in ECMA-404. The latest
draft reflects that change. At this point, we believe that there are no
syntactic differences between the two specifications.

- The JSON WG decided to change the title of the document to better reflect its
content. The current document is much more than a media type registration: it
repeats the JSON syntax originally documented in RFC 4627, and has been stable
for many years, it is a discussion of the JSON semantics important to
freestanding encoders and parsers, it is a discussion of interoperability
issues that have been encountered since RFC 4627 and ECMA-262 5th Edition were
published, and it is a media type registration. Having a more accurate title on
the document will help readers understand its contents and the difference
between it and ECMA-404.

- After Ecma published ECMA-404, the JSON WG discussed whether to remove the
ABNF version of the JSON syntax that was established in RFC 4627 from
draft-ietf-json-rfc4627bis; it was decided not to do so. One reason is that
ECMA-404 uses "racetrack pictures" to define the syntax, whereas IETF documents
have traditionally used ABNF, and many developers have expressed a strong
preference for the ABNF. This might be considered simply a matter of style, but
it was deemed important by many WG members. We intend to keep the discussion
and reference to ECMA-404 in draft-ietf-json-rfc4627bis, even if Ecma continues
to choose not to reciprocate in ECMA-262 6th Edition, because developers
reading draft-ietf-json-rfc4627bis might indeed prefer the racetrack pictures.

- A normative reference to ECMA-404 would be premature without a clear and
well-understood document management process. Historically, when someone reading
an RFC sees a normative reference to one version of another SDO's standards,
they tend to think the reference will apply to future versions of that external
standard as well. Given the closed process that resulted in ECMA-404, it seems
quite possible that Ecma could later make changes to ECMA-404 that would have a
negative effect on interoperability from the Internet perspective. When the
IETF normatively refers to other standards, it tries to do so to standards that
were developed with processes that are open to discussion and contribution by

One of the positive products of a formal liaison relationship between the IETF
and Ecma would be better coordination of development of each other's standards,
which in turn could lead to more use of normative references in future versions
of documents.