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

Kai GAO <> Wed, 30 January 2019 21:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F1FE131008; Wed, 30 Jan 2019 13:29:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oliYjER5FJKi; Wed, 30 Jan 2019 13:29:35 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 55B0A130FF4; Wed, 30 Jan 2019 13:29:35 -0800 (PST)
Received: by with SMTP id n13so694019vsk.4; Wed, 30 Jan 2019 13:29:35 -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=wRxAvw3zcMRVD1PAXDqQLcQBKsnQZbPn48/RwQgidl4=; b=Dx3p0s6H1kn+nP7BBjMsDxpd3QKQjdVIy6rsK939owO6+DDZ8tTfFIRabxuyyfC30c l/nUDAdwbM92aCPC2+oIMmwfiBolkkNp5isTSUa1SQpphcy9FgZcaQtBtvmYu76yMJd5 FF5gFyG5X5KuCOI3VUJxYOWHbbTKskWtdv7qBLtV9M9EO7gRBx6rYD1Ba4RPugPtJNRj 0p9B52YN4MdP+51gEAqZv0rlqVkjJDpinQSLNUkSSPmsFKVA/4GvdHYzzFEQqjoQ0sTt nqWsGbzsTk48y8jsLo6BX0h7/e3zk5mO0dQBBeh0xYsoqwBfz3Gft8zrW9HMcQez02L2 VpqQ==
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=wRxAvw3zcMRVD1PAXDqQLcQBKsnQZbPn48/RwQgidl4=; b=QUHuiemtTmwqNb4DFebyW7003TCTsI1YZ2mgerr/5Hwsuui0R/FtWRPOcyBiqDMkMC 3yRBlyw+HKZ3us2arreNgzzKfsxlOguqQdWapMN6QzxavMryhekNbPPWbMRag11hTQ2A EGy0YfIrQsbpdYv1q4z3uvyZStFisx2vWhk7nK+d/HYBfAvpaZAynpZRX4s25Z0jNbwE u8P7KbtJHldfYdZDCvycm3wX/j3qIHT5MksTXXNeb4dGa7IgprwZ747lPWwoAsRk21Bx ehrKJaruvK09qGDdED7rI9PmNDCM19HDDNLEHJqg6+RPw43BOug84GEtogu2TMMw9fr3 3K9A==
X-Gm-Message-State: AJcUukdqYxIm0MZzHCikNwZSj89mrR5k8D+6yx/qYMEn7lxV/pMNpXV0 z9pdFIcGOSrFgentDXhuN0MXTZaYZKcr3jHEMw4=
X-Google-Smtp-Source: ALg8bN6fSrsh69tQHwxizgqZF8jq+qi+Hljl7lpRXsB71OdU80XzDan1xk2kzwkHDGtY8pY92EU/lJnIKYhrjiA776Y=
X-Received: by 2002:a67:f9d7:: with SMTP id c23mr13391682vsq.24.1548883774431; Wed, 30 Jan 2019 13:29:34 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Kai GAO <>
Date: Thu, 31 Jan 2019 05:29:22 +0800
Message-ID: <>
To: Benjamin Kaduk <>
Cc: Adam Roach <>, "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <>, The IESG <>, "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000002c68a90580b39b39"
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 21:29:37 -0000

Hi Benjamin,

Thanks for the reply.

DISCLAIMER: I'm only speaking on behalf of myself.

Well, the situation is that we don't know the answer to the key question at
the moment and probably also in the near future.
Thus, the problem at hand is "how do we proceed if we don't know the
My personal opinion is that ALTO should be self-contained so the principle
is that extensions should not conflict with the base protocol.
So instead of patching every draft, why don't we just patch the root cause
(RFC 7285)?

However, I don't really know if this is the best practice in IETF.
Since you and Adam are the experts here, we would like very much to
leverage your expertise a bit and hear your opinions on this procedural
(I imagine the implication is that we should not proceed until we find out
the answer?)

Back to the encoding. If UTF-8 is the de facto JSON encoding in JSON
libraries, as Adam pointed out, I don't see why it would not be for ALTO
I don't truly believe there would be a nontrivial amount of developers who
use an 18-century JSON library or reinvent the wheel just to be
interoperable with ALTO.

Just my 2 cents.


On Thu, Jan 31, 2019 at 12:13 AM Benjamin Kaduk <>; wrote:

> On Wed, Jan 30, 2019 at 12:44:43PM +0800, Kai GAO wrote:
> > 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?
> This seems to be sidestepping the key question, of whether UTF-8 is
> actually the de facto interoperable JSON encoding for ALTO usage, or
> whether there is nontrivial usage of other encodings.  It seems a little
> odd to consider procedural options without knowing what the right answer
> is.
> -Benjamin