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

Kai GAO <godrickk@gmail.com> Tue, 29 January 2019 18:52 UTC

Return-Path: <godrickk@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2821C130FBE; Tue, 29 Jan 2019 10:52:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyfUm8UGKwW5; Tue, 29 Jan 2019 10:52:45 -0800 (PST)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 F0DEB130FBB; Tue, 29 Jan 2019 10:52:44 -0800 (PST)
Received: by mail-vs1-xe31.google.com with SMTP id t17so12586333vsc.8; Tue, 29 Jan 2019 10:52:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RQI6oSVaazZaaOjtxMjd0v/ph6hd69PzU8Z4dAcc4yY=; b=dtEBccD6XRFjMxlISc9Vtjso0bo59HUr8fUSaBKxyqAMWAKpl/7/lTutGozbeO5YZS 2Me35ws4xuBNLiP/jZesQVvMrJbTDjq16Jh3AaubS16DKK0S7+44GE9M6i7SUImBQsJ6 CzO7xuyWN0GzLF7R4ZEQ45275nJabJfokKHDZ5H+dRErbS7ZsKAkIg0iT4Ur4PLx9Nob ytWZIqu8O/g9sm8z92CvZrMpqvhszXkN1zSaDbBz6aLZyCagW9YXzxr3ovGIYTQ1XtIx 2sn33pJlqym4MimcTmW7XDuEwtTsw50hLuiHQWC8R83Cq6G0WP3TTX4w4SjFNiQH+yIu qmkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RQI6oSVaazZaaOjtxMjd0v/ph6hd69PzU8Z4dAcc4yY=; b=e7O1YBEsigvL9PUBtMpGYsCw3o8KF5YkfM1ft1VCKA4HEUfQwxzjfubt8W2CU/nNJl cZP7CtcxdsEIgxeVc+Db269ACd/LWCXpuv/CFLmD3hv/flWi/DqZMpInxxEl3QVZ23kg oq7umn+gwCeYYaSh4RaniKhYHNvIycnQIBm+H8hccTS0ARXWv0wBR1EKX/amunaIjl7B qqO/LoZl/uCkuCrxABZ5K0SUFIKM6vmBy4kh+usz8kjcxFM2l0WJk97mDyQnmjfBg8ga /hnY91kymdlCMGVYNmH/jNbI2TqZTjd1v87QL0ENJzjT6plTLsG77UJR1ssYsHoMIzPb UMOw==
X-Gm-Message-State: AJcUukevl4/2NIKhJZ63wQLdnJrqFQ4fiCraVI/OblTaUYHZo7eNnx0+ AM8XPHqqMqayh32Xl8fCm2tjnQofcSztN8SWgSc=
X-Google-Smtp-Source: ALg8bN4dJmjBUtWbytJLVkTgnDCaYha+dK4xtinkPilIIVgpzt+Ph1b2lTNL3bDttCwMPN7MR5mlf/Ec+n0eGHtPMk4=
X-Received: by 2002:a67:7106:: with SMTP id m6mr11786744vsc.67.1548787964097; Tue, 29 Jan 2019 10:52:44 -0800 (PST)
MIME-Version: 1.0
References: <154345970393.13521.17177728478340801020.idtracker@ietfa.amsl.com> <AM4PR07MB3236DD059F50035D0F5C8F21959B0@AM4PR07MB3236.eurprd07.prod.outlook.com> <1497dbf3-d057-160b-f81a-bbf6b496d81b@nostrum.com> <AM4PR07MB32366E0069BFE9CD455D012095970@AM4PR07MB3236.eurprd07.prod.outlook.com>
In-Reply-To: <AM4PR07MB32366E0069BFE9CD455D012095970@AM4PR07MB3236.eurprd07.prod.outlook.com>
From: Kai GAO <godrickk@gmail.com>
Date: Wed, 30 Jan 2019 02:52:32 +0800
Message-ID: <CAOELiNNUUMJCDWoCAUhpwscV3R9VocjPCE6a+icSuVf3DNmyzQ@mail.gmail.com>
To: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <sabine.randriamasy@nokia-bell-labs.com>
Cc: Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, "alto-chairs@ietf.org" <alto-chairs@ietf.org>, "Gurbani, Vijay (Nokia - US/Naperville)" <vijay.gurbani@nokia.onmicrosoft.com>, "draft-ietf-alto-cost-calendar@ietf.org" <draft-ietf-alto-cost-calendar@ietf.org>, "alto@ietf.org" <alto@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006eba4205809d4cad"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/tsc_0i3FUhtGkHhdjBHJD7xPuic>
Subject: Re: [alto] Adam Roach's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT)
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: Tue, 29 Jan 2019 18:52:48 -0000

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?

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.

Many thanks!

Best,
Kai


On Wed, Jan 30, 2019 at 1:53 AM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay) <sabine.randriamasy@nokia-bell-labs.com>; wrote:

> Hi Adam and Benjamin,
>
> Regarding the citation of RFC 8259, in the Introduction, using the JSON
> format as specified in RFC 8259 may actually cause backwards compatibility
> issues with RFC7285 that uses the JSON format specified in RFC7159. Would
> it be OK to cite 7159 in the Introduction and add the paragraph below in
> section 2.2.2 “Compatibility with legacy ALTO Clients" ?
>
> Thanks,
> Sabine
>
> <t>Last, for backwards compatibility with <xref target="RFC7285"/>,
>           this extension encodes its requests and responses using the JSON
>           Data Interchange Format specified in <xref target="RFC7159"/>.
>           The latter has been obsoleted by <xref target="RFC8259"/>,
>           that among others makes UTF-8 mandatory for text encoding to
>           improve interoperability. Therefore, Clients and Servers
> supporting
>           ALTO Calendars SHOULD use UTF-8 for text encoding while still
> being able to
>           successfully read texts in other encodings such as UTF-16 and
> UTF-32.</t>
>
> -----Original Message-----
> From: Adam Roach <adam@nostrum.com>;
> Sent: Friday, January 25, 2019 10:25 PM
> To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <
> sabine.randriamasy@nokia-bell-labs.com>;; The IESG <iesg@ietf.org>;
> Cc: draft-ietf-alto-cost-calendar@ietf.org; Gurbani, Vijay (Nokia -
> US/Naperville) <vijay.gurbani@nokia.onmicrosoft.com>;; alto-chairs@ietf.org;
> alto@ietf.org
> Subject: Re: Adam Roach's No Objection on
> draft-ietf-alto-cost-calendar-09: (with COMMENT)
>
> On 1/25/19 10:06 AM, Randriamasy, Sabine (Nokia - FR/Paris-Saclay) wrote:
> > [[SR]] The purpose is actually to lighten the reading. Would the
> following addition to paragraph 3 of section 4.1.3 be OK ?
> > "The Server returns Calendars with arrays of 12 numbers. To lighten the
> text, the arrays in the provided example are symbolized by expression
> "[v1,v2, ... v12]" that is otherwise not valid in JSON. The same type of
> symbolization is used in the example Server responses."
>
>
> That seems a reasonable approach. Thanks!
>
> /a
>
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>