Re: [alto] Adam Roach's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT)

Kai GAO <> Wed, 30 January 2019 04:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A796B127B4C; Tue, 29 Jan 2019 20:44:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MbvBNgBj4Yst; Tue, 29 Jan 2019 20:44:57 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EEA41124BF6; Tue, 29 Jan 2019 20:44:56 -0800 (PST)
Received: by with SMTP id v205so13479357vsc.3; Tue, 29 Jan 2019 20:44:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ENdPRiOcI0DLxS3ktsQVlq47ysK125m2x7Bgz4t5kck=; b=ez9B+FK5lO+G/YUpDoiDb2TijHnhdKP1UKqpqTzt1fJCM+RhsjWTu/+06gPjpbKHqa tyjqB7zYNqKFsDcoux0yMKvBYZ640QV7iJtSu2mi9Mrxxz5pSbNjolZ9WUaFvlJI5Kyu O/0/LVL4HGSBOwYBvRhm2zBWNE4YGBMUMLitWZ+3cc+wF0PSwvtTHykV8FaXtlCmyEhR 5HW/ZsVA02NodgPemuuw2J2ab/kj5hVr43i92Qj/ozE24BxhpP5kjP5npOpi0HtUdvBq ZFAaE1x3OZN9SkiYKCqqUbOnfaPK4v2NWPihdWGzf5XgJxV1qiMsYoC0eu85skEo7872 J/jA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ENdPRiOcI0DLxS3ktsQVlq47ysK125m2x7Bgz4t5kck=; b=HPHCGceHeO7oMXZkXfM+v9RfGCZ56MBrtghv9MNFfhqxuxO/ZI41NWUycwCKL1+Gug rV0otXdwDf5PmQFqn1l0Au5Rwel3lt+5cNkwcjN2e9fWhCnXBicqV6LwEDX4wZIQmvvX im5vmx/dPDLkdSw64j0kRNchDTs/3KQUhSz9cVixBcb1HkfTw9JHTKLRrDS+tqsCqjhc WlRQLgjZw+XC5X7c7XIObp9CphdBN3oXHdBQ1rDz68t2TCcz6zsS0WaFIEAxNfRR/T12 /kNzIKTtiYNpPNa3+vTrgCm3eWZ61cswMxhtyifMkpGPgytCndQfbwJyeNEJzbkKHHxy oTUg==
X-Gm-Message-State: AJcUukfkXL6S5AsOPOeEGvkjvzcpBfP+KqXgQUmJQ5rCU3/QRi8M9euD AYZKLJRGGt5akMS0LKh5vfdUI41WPzi5P7TACfI=
X-Google-Smtp-Source: ALg8bN4K581DHiTtsOHPblCna4KQP4kKByRQedeFDjzIl9QocNI1kOaCJE8TdjuLl7GVoMyuOuJr2NTjNgb9gLjnWB4=
X-Received: by 2002:a67:7106:: with SMTP id m6mr12552716vsc.67.1548823495744; Tue, 29 Jan 2019 20:44:55 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Kai GAO <>
Date: Wed, 30 Jan 2019 12:44:43 +0800
Message-ID: <>
To: Adam Roach <>
Cc: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <>, The IESG <>, Benjamin Kaduk <>, "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000048a4660580a59258"
Archived-At: <>
Subject: Re: [alto] Adam Roach's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Jan 2019 04:45:00 -0000

Hi Adam,

Thanks for the clarification. Regarding the situation, I wonder if the
following procedure makes sense:

1. Extensions of the ALTO protocol should not explicitly cite a specific
(especially the obsoleted) JSON RFC but "follow the same JSON format as in
the base protocol (RFC 7285)".
2. Charter a draft to clarify the impacts of new JSON (and probably TLS
too) standards on all ALTO-related RFCs.

Or maybe we should have a standard paragraph stating the situation and put
it in every ALTO extension?

What do you think?


On Wed, Jan 30, 2019 at 3:30 AM Adam Roach <>; wrote:

> On 1/29/19 12:52 PM, Kai GAO wrote:
> Hi Adam and Benjamin,
> It appears to me that the JSON format is not specific to the cost calendar
> but a general problem with all ALTO extensions (or even all protocols
> encoded in JSON).
> I wonder if we have some kind of "best practice" in situations like this.
> For example, how do other protocols handle this if they originally cited
> RFC 7159?
> I can't offhand think of a protocol in a similar situation regarding JSON.
> In other similar cases, the course of action has been somewhat dependent on
> the nature of the changes between an older draft and a draft that obsoletes
> it. In many cases, changes are backwards-compatible, and I think there's an
> implicit assumption that new implementations will automatically make use of
> the newer document.
> In other cases where there have been breaking changes, I've seen working
> groups issue new clarification documents to "clean up" the discrepancy. For
> example, when RFC 6665 replaced RFC 3265, the SIPCORE working group created
> RFC 7647 to clarify the impact of those changes on RFC 3515. It wouldn't be
> unreasonable for ALTO to do something similar.
> Since you guys are more senior in the IETF, do you happen to know any RFC
> in a similar situation? I think that would be extremely helpful so we don't
> have to get into this fight for other on-going ALTO drafts.
> The decision made by the JSON working group when creating RFC 8259 was
> that the practice of trying to deal with multiple encodings was problematic
> from an interoperability perspective, and that practical interoperability
> is best achieved by always using UTF-8. The RFC itself attempts to capture
> this rationale:
>    Previous specifications of JSON have not required the use of UTF-8
>    when transmitting JSON text.  However, the vast majority of JSON-
>    based software implementations have chosen to use the UTF-8 encoding,
>    to the extent that it is the only encoding that achieves
>    interoperability.
> A decision by the ALTO working group to intentionally use an obsoleted
> version of JSON puts it in the position of reverting consensus established
> by the JSON working group. While this kind of consensus revision is
> possible in the IETF, it needs to be part of the charter of the working
> group that is doing it. Given that ALTO is not chartered to revise JSON
> procedures, this isn't allowable.
> If you wanted to normatively cite RFC 8259 and then include non-normative
> text indicating that it is possible that older data might be written in
> UTF-16 or UTF-32, and that implementations might want a configuration
> option that allows reading such formats, I think that would be keeping in
> the spirit of the "part of a closed ecosystem" language in RFC 8259.
> /a