[alto] ALTO and UTF-8 as the mandatory encoding in RFC 8259

[Vijay Gurbani <[e-mail]>]

Folks: From the cost-calendar IESG review, it has become sufficiently
clear that there is some confusion around RFC 7285 and RFC 7159 (JSON
standard) and its successor, RFC 8259 that now mandates UTF-8.  As I
have been able to understand it, the basic issue is as follows.

When ALTO WG standardized the protocol in RFC 7285, the JSON standard
in force was RFC 7159.  RFC 7159 specified that JSON text SHALL be
encoded in UTF-{8,16,32} with the default encoding being UTF-8.  RFC
8259 obsoleted RFC 7159 and mandated that UTF-8 encoding is now a
MUST.

So the issue now is whether we need to update RFC 7285 to explicitly
support RFC 8259.  I do not think we do, and I lay out my reasoning
below.

I am not aware of RFC 7285 (ALTO Protocol) specifying explicitly the
use of UTF-{16,32} encoding, thus this whole incident may be moot.
Since RFC 8259 obsoleted RFC 7159, it is implicitly understood that
RFC 7285 now depends on the latest JSON standard as specified in RFC
8259.  We do not need to do anything special here with respect to RFC
7285.  This is the normal attrition method in IETF whereby if RFC Z
obsoletes RFC Y, it is now understood that all previous RFCs that
depended on RFC Y now depend on RFC Z.  If previous RFCs had normative
language in them causing them to be tied closely to RFC Y, then it
seems appropriate that the previous RFCs be updated or obsoleted to
conform to RFC Z through the normal IETF change process.  I see no
such dependency in RFC 7285 tying it normatively to RFC 7159, nor do I
see any of the extensions the ALTO WG has standardized thus far or is
in progress towards standardization that have normative language tying
them to RFC 7159.  Yes, we must be aware that RFC 7159 is now obsolete
and succeeded by RFC 8259, thus when we add a reference to JSON in our
standards under development, we should use RFC 8259.

To be complete, perhaps some of the WG members are of the opinion that
ALTO extensions have been using UTF-{16,32}.  If so, we need to
identify these extensions as soon as possible and determine what to do
with them.

To that end, please reply to this thread if you are aware of an
extension that has normative language in it tying the JSON object in
that extension to UTF-{16,32} encodings or encoding not supported by
RFC 8259.

If not, then there is nothing special to do here except --- as I note
above ---
we must be aware that RFC 7159 is now obsolete and succeeded by RFC
8259, thus when we add a reference to JSON in our standards under
development, we should use RFC 8259 as a reference.

Thank you.

- vijay