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

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

Return-Path: <vijay.gurbani@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 7A4B1129C6A; Thu, 31 Jan 2019 07:18:09 -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 2iRSbtm8EHXy; Thu, 31 Jan 2019 07:18:07 -0800 (PST)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 010D21286D9; Thu, 31 Jan 2019 07:18:07 -0800 (PST)
Received: by mail-ed1-x52c.google.com with SMTP id o10so2836562edt.13; Thu, 31 Jan 2019 07:18:06 -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=qFczdC+mGtYKJCkQhLZcLb7+wbY3dTq7uUJDRdDoqNY=; b=otSdjVajrq4mI8ydMJ44BQw5F1o7bEjwwCrD5cIGxmEwKyeoSrXXi0JLHPEJ6qX4CW qGtRoqOLVzc3CF5gI3RFQtUqQw8560JaJ1NgtLTl/7UXTSEbAwN8QVZHql3d2Ni+x/sG aK3BqM8AtxyX/Vl1ERPV2FkW/56UlQBgrkyQoC9kDCG1pciqz4at8qVxrfy/3vo4FhBT k7jogqSipNAiloLGtyU4wJUJYZdiNRPd6tA0uyJlXVaPCmD9drvCW8NE+bMFT1kvqMYk AO+aZ3YxWRvIP+xsgByZ5IcyJiqLoHnD8K1h/vYpoTfeMhOtvU0YFeno4/pB855tY/69 BKTQ==
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=qFczdC+mGtYKJCkQhLZcLb7+wbY3dTq7uUJDRdDoqNY=; b=uZkTBG9h0nSP+GUDFzPJvvFAFt33e/BaBP54j3YnjMKBv8St9bkhcrzMyssuGN5+px 5WxehHeEzVMNnV8l73A87R7PVEc0JOW1sQIjmYfYa5Vjcme/3wPUqsFKh5ETWg5yFF9J mVD759QrMKoUxqvWypIyho/S+u/D5yUnOO3Qf8EFizJ9idX6yx2OLo8Qqcg3C5EEvg9C JcqGB1Rsva2UfJgXlIm5dhk6Zt2kSPiDjqgYt/P0JhwYsCMqWmDpxH12FxRDKyZ6mDm1 CarlhDbifgTdSCLTgJs9DaFkrBMYZAWQVoSIrnPIusieBKzfZATXiw4lsoIwtN22tzBC HiMA==
X-Gm-Message-State: AJcUukf8jkXcLrtds6Ezt47IEt5vt4jSWeOI9nq98fSgfOPbjqZ2R06v T31Xe7ISwip7V1DFXk4/q0H7W+lX7U/ZGbk4LPO8CmEM
X-Google-Smtp-Source: ALg8bN5DCI73CBgpdy+EQyX3EfVpzhu8bFRarH3oadI2Cg0hAGDzrMgbq092j78uxNefPt/x5NqpWAhcv2jyOEilCrQ=
X-Received: by 2002:a50:9784:: with SMTP id e4mr34533403edb.165.1548947885242; Thu, 31 Jan 2019 07:18:05 -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> <CAOELiNNUUMJCDWoCAUhpwscV3R9VocjPCE6a+icSuVf3DNmyzQ@mail.gmail.com> <022cc047-a7aa-e087-8638-8f9798e4ea91@nostrum.com> <CAOELiNPU-vdOSEWbs4eJyUAqiactSSM7Y3K7GMndNE7St-Ju-w@mail.gmail.com> <20190130161322.GA49072@kduck.mit.edu> <CAOELiNP96Lzn3Ba9vksDe5xWT-OCRD=+2HTcRxLcq4HvpJ19RQ@mail.gmail.com> <CAMMTW_LjfmmPq4GfFUdfT5a-PTtjRXaj2_57DcUmZkrrpRTiDA@mail.gmail.com> <d63e67fe-f5c9-9a38-5a37-e7eff834c157@nostrum.com> <AM4PR07MB3236F5F7F2828D9E643F493595910@AM4PR07MB3236.eurprd07.prod.outlook.com>
In-Reply-To: <AM4PR07MB3236F5F7F2828D9E643F493595910@AM4PR07MB3236.eurprd07.prod.outlook.com>
From: Vijay Gurbani <vijay.gurbani@gmail.com>
Date: Thu, 31 Jan 2019 09:17:47 -0600
Message-ID: <CAMMTW_LawTQyxCxCct=A62x4qcN_6gea6ubG_93mR6OnfvjngQ@mail.gmail.com>
To: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <sabine.randriamasy@nokia-bell-labs.com>
Cc: Adam Roach <adam@nostrum.com>, Kai GAO <godrickk@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>, "alto-chairs@ietf.org" <alto-chairs@ietf.org>, "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="00000000000079c6fc0580c28884"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/QAQz0TLePy9tmjyc5n6cqFyIA60>
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: Thu, 31 Jan 2019 15:18:09 -0000

Adam, thanks for confirming.

Sabine, very well.  The IESG can look at your suggested changes and proceed
accordingly.

In the meantime, I think we should open up a thread in the ALTO WG (so we
don't disturb the IESG further with this issue) and reach consensus how to
proceed forward.  I will do so later today.

Thank you, all.

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

> Hello,
>
> I would personally opt for a Clarification draft for implementing RFC 7285
> with RFC 8259.
> Before we get there, the calendar specification may pave the way by making
> the use of UTF-8 to encode text sent by Calendar-aware Clients and Servers
> a MUST,  rather than a SHOULD as the proposed text in my previous e-mail
> suggested. Please see below the new text proposed for the backwards
> compatibility section. The MUST rule on UTF8 encoding will be distributed
> in the spec sections.
>
> We may add this to the operation considerations as well, and mention the
> possibility of a future clarification on RFC 7285 to make compliance with
> RFC 8259 mandatory.
>
> 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 MUST 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: Thursday, January 31, 2019 12:38 AM
> To: Vijay Gurbani <vijay.gurbani@gmail.com>;; Kai GAO <godrickk@gmail.com>;
> Cc: Benjamin Kaduk <kaduk@mit.edu>;; Randriamasy, Sabine (Nokia -
> FR/Paris-Saclay) <sabine.randriamasy@nokia-bell-labs.com>;; The IESG <
> iesg@ietf.org>;; alto-chairs@ietf.org;
> draft-ietf-alto-cost-calendar@ietf.org; alto@ietf.org
> Subject: Re: [alto] Adam Roach's No Objection on
> draft-ietf-alto-cost-calendar-09: (with COMMENT)
>
> On 1/30/19 4:26 PM, Vijay Gurbani wrote:
> > Do I get the sense that the WG thinks that this is the best course of
> > action?  (I must apologize as I am coming up to speed on this issue.
> > If I was to produce a 1 sentence summary of the issue here, it is that
> > RFC 8259 normatively requires UTF-8 encoding and that there are
> > existing ALTO implementations conformant to RFC 7285 that use
> > encodings other than UTF-8.  Is that accurate?).
>
>
> That's my understanding, modulo any other JSON changes you might want to
> highlight. Again, I think RFC 7647 provides a good example of how this kind
> of thing can be clarified.
>
> /a
>
>