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

Adam Roach <> Tue, 29 January 2019 19:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A87C130FD9; Tue, 29 Jan 2019 11:30:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d4NB-Py9sgS9; Tue, 29 Jan 2019 11:30:36 -0800 (PST)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6208C130FE9; Tue, 29 Jan 2019 11:30:36 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x0TJUToY065041 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 29 Jan 2019 13:30:31 -0600 (CST) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1548790233; bh=nUEujgX4i42JjHOyTpdouJoV+Kb6wqPGD4r8gF2NwRc=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=XmLaEndkR0aZ/yo9BXcmTuKYH9FuwYLgwfQTC82je5jTrwJ+gLUQJgpbXMlCmUTQj 93mFDLqDEgstX9lY17JQj5o4XE0GasMc3DhXR+PMNT03uVr9Gm9qCPR0fkvi3oL7dv MakeD8j+gCJRkb7fniyZJyd2Sm6pi1sJo5mKh+kc=
X-Authentication-Warning: Host [] claimed to be
To: Kai GAO <>, "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <>
Cc: The IESG <>, Benjamin Kaduk <>, "" <>, "Gurbani, Vijay (Nokia - US/Naperville)" <>, "" <>, "" <>
References: <> <> <> <> <>
From: Adam Roach <>
Message-ID: <>
Date: Tue, 29 Jan 2019 13:30:24 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------A728AF7FF31879B2825E2B03"
Content-Language: en-US
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: Tue, 29 Jan 2019 19:30:38 -0000

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.