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

Vijay Gurbani <vijay.gurbani@gmail.com> Thu, 31 January 2019 19:40 UTC

Return-Path: <vijay.gurbani@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BD590130E9F for <alto@ietfa.amsl.com>; Thu, 31 Jan 2019 11:40:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 26qOyYUy6QTR for <alto@ietfa.amsl.com>; Thu, 31 Jan 2019 11:40:29 -0800 (PST)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECBE3130EA3 for <alto@ietf.org>; Thu, 31 Jan 2019 11:40:28 -0800 (PST)
Received: by mail-ed1-x52f.google.com with SMTP id g22so3556640edr.7 for <alto@ietf.org>; Thu, 31 Jan 2019 11:40:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xy8u8i8Oz5p612N3TVWPKh2ZBc5ldq4R86ctyIUC7h4=; b=MvoeVfFwh9SsK7IT/f7Ith55lG5utT36+SVTSr7mAx11Ls32GvmIHFO2kFArfpDQoG p4B6QzUy6GHFn0EEhyw+bxxjUH8MG5Qdacnef4S2en8YuEGi2DHLLcVFMgNllomiWIS/ RmBXtdanias3gs/yShEq+9iDopY83YwdnbbhZ1AIEbLBs9omvgNyy7AITmVjBLW71P8G d/KHdtiK8zvBSBYuTS4DpRvHq2XD6LOVlxcYDvpnlzKq2/NYIfxAmf0P0DHretKluwnU OCAYdi0cmZex48uYnWqEvjEtuAaFzepCBlbO/hMfnavguNsSh44nHWANWfTKemH/VOp2 9isQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xy8u8i8Oz5p612N3TVWPKh2ZBc5ldq4R86ctyIUC7h4=; b=Em0upE+jddR4rDkMITbEDrh3I9d20JlKmMkjhB89lW5wXMHK+j3mBUyn+bAPMUWdVe MabuVMe/Vwo5OirBIN/CLowcKluGyjK2WjK056CMf8KoCsU6ILGryiek8E6vDqInqP0v HXHdQCp85kANOGOQ+ygJSCw0hrV+5CJZQAUAiNKELXsfaOaZLuMJx3PYpslgsCsbpYFp P54i148htxGkkqhppYp6nP3jT7jXiEcppJYyaF6yT6iC58TuWDbuLx9dWF+1k2scQgv0 ElCLtdhSzlQFxLXf5po2QuwpAblaRx5mV1flERKnmw75DsTX9hY+csAhvBGzL/VCuK4r aD/Q==
X-Gm-Message-State: AJcUukfevEEoPLLTKzK+dZKZf4LNKXJSv1hBri9LA3cug0OIpQwqeNac TPaZ3OPk6bZClQs9gMItrRkj2lg914EyTGJr35DEogDRrAg=
X-Google-Smtp-Source: ALg8bN4DpamtGs4+OimHeTu251NOtuFw9c+vlrBCfQhzvyU9rYOVCsgLcnr5XWyNo2goiGZhofdmjSkeEFviTbu4Zv8=
X-Received: by 2002:a17:906:791:: with SMTP id l17mr30805679ejc.76.1548963627009; Thu, 31 Jan 2019 11:40:27 -0800 (PST)
MIME-Version: 1.0
From: Vijay Gurbani <vijay.gurbani@gmail.com>
Date: Thu, 31 Jan 2019 13:40:10 -0600
Message-ID: <CAMMTW_+4L9E6vkweqBpnEK8b5QnkLniNqE2uapVNnE-TiVMLZQ@mail.gmail.com>
To: alto@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c210860580c6320b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/EGuPfDqoYBv7H8grPXE0qtjQsGc>
Subject: [alto] ALTO and UTF-8 as the mandatory encoding in RFC 8259
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Jan 2019 19:40:31 -0000

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

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

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