Re: empty lists?, was: Last Call: <draft-ietf-httpbis-header-structure-18.txt> (Structured Field Values for HTTP) to Proposed Standard

Benjamin Kaduk <bkaduk@akamai.com> Mon, 18 May 2020 23:38 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CE23A0BD7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 18 May 2020 16:38:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.85
X-Spam-Level:
X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 HpnBSU7klBU6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 18 May 2020 16:38:02 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06233A0BA8 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 18 May 2020 16:38:02 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1japIH-0006ZQ-QV for ietf-http-wg-dist@listhub.w3.org; Mon, 18 May 2020 23:35:37 +0000
Resent-Date: Mon, 18 May 2020 23:35:37 +0000
Resent-Message-Id: <E1japIH-0006ZQ-QV@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <bkaduk@akamai.com>) id 1japIG-0006Yf-Oa for ietf-http-wg@listhub.w3.org; Mon, 18 May 2020 23:35:36 +0000
Received: from mx0b-00190b01.pphosted.com ([2620:100:9005:57f::1]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <bkaduk@akamai.com>) id 1japIF-0003aY-6m for ietf-http-wg@w3.org; Mon, 18 May 2020 23:35:36 +0000
Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 04INZ041012569; Tue, 19 May 2020 00:35:16 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=2DdtdnG6i2jv+Ho0amggri3RPuGX2hRDN6cJJbPRA24=; b=Em9iY4KBdpdo85oOB55XmhMl/d6uZGJjV/hVav1ad4k4KDX9oq/jynCsW8snYbdFYrz+ aisYybU/RvG+IILF4RivKp0w7EIS5TnE3ASZuswHjrFTmbVcOpW5kpvtDaqCE3WYts9O OaKyQ3iTFQtafTQFcn7RVLY+RJviHopQy+p5Le1QuzdccnPE80F7C9g6yGc/TBjIcGwE 0pGNFj1PHq2VVROcdkXtDAfSMpwe8AsF5HhkG6sK+/3LnpYRjqhOojJLSzKs0iPSz9aM 5vUUVC8AbRZd0RZOJ2IxTl3XNsVxA7PKyM0HLv1aIngyqbl+6rZBjgtCJNx+Lui7Rfek YA==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 31252028ap-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 May 2020 00:35:16 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 04INWYdK029873; Mon, 18 May 2020 19:35:15 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 312bgv5skc-1; Mon, 18 May 2020 19:35:15 -0400
Received: from akamai.com (sea-lp9yo.kendall.corp.akamai.com [172.19.16.134]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 6AD603484F; Mon, 18 May 2020 23:35:14 +0000 (GMT)
Date: Mon, 18 May 2020 16:35:13 -0700
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: "Julian F. Reschke" <julian.reschke@gmx.de>, last-call@ietf.org, httpbis-chairs@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>, Barry Leiba <barryleiba@gmail.com>, draft-ietf-httpbis-header-structure@ietf.org
Message-ID: <20200518233513.GE3811@akamai.com>
References: <158740521959.1174.9556681562748997101@ietfa.amsl.com> <bb3a29ff-1a0f-964d-c764-4d4819d338da@gmx.de> <1d494d71-b837-729a-62f3-5ba8ca6549cb@gmx.de> <20200518182746.GC3811@akamai.com> <45ec9bc0-2a81-edf1-6054-7c5bb3cb8140@gmx.de> <20200518212334.GD3811@akamai.com> <721A2334-D1C9-4A34-BE4C-0FA540B4E9D4@mnot.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <721A2334-D1C9-4A34-BE4C-0FA540B4E9D4@mnot.net>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.676 definitions=2020-05-18_06:2020-05-15,2020-05-18 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=862 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2004280000 definitions=main-2005180200
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.676 definitions=2020-05-18_06:2020-05-15,2020-05-18 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 adultscore=0 priorityscore=1501 malwarescore=0 suspectscore=0 spamscore=0 cotscore=-2147483648 lowpriorityscore=0 clxscore=1011 mlxlogscore=901 phishscore=0 bulkscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005180200
Received-SPF: pass client-ip=2620:100:9005:57f::1; envelope-from=bkaduk@akamai.com; helo=mx0b-00190b01.pphosted.com
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1japIF-0003aY-6m 0df35da9aed8dc4aceb879f97a5c3aac
X-Original-To: ietf-http-wg@w3.org
Subject: Re: empty lists?, was: Last Call: <draft-ietf-httpbis-header-structure-18.txt> (Structured Field Values for HTTP) to Proposed Standard
Archived-At: <https://www.w3.org/mid/20200518233513.GE3811@akamai.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37657
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Tue, May 19, 2020 at 09:20:57AM +1000, Mark Nottingham wrote:
> 
> 
> > On 19 May 2020, at 7:23 am, Benjamin Kaduk <bkaduk@akamai.com> wrote:
> > 
> >>> You saw
> >>> 
> >>>    An empty List is denoted by not serializing the field at all.
> >>> 
> >>> right?
> >> 
> >> That's about serialization.
> >> 
> >> 4.2.1 seems to parse an empty string into an empty list.
> >> 
> >> AFAICT, that's in conflict with the ABNF.
> > 
> > Thanks for clarifying.
> 
> As per S 1.2 [1], the ABNF is not for parsing; it's for 'illustrat[ing] the range of acceptable wire representations.'
> 
> The ABNF requires at least one member because sending an empty field value is not good practice; it's not something we encourage.
> 
> 
> > FWIW I already have a comment staged about how we seem to make the
> > ABNF normative for serialization but the prose normative for parsing,
> > which seems like a weird mismatch that requires justification.
> 
> ABNF isn't normative for serialisation; what led you to that conclusion? 
> 
> 
> 
> 1. https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#notational-conventions

Well, we are very explicit that "when parsing [...], implementations MUST
follow the algorithms. [...] If there is a disagreement between the parsing
algorithms and the ABNF, the specified algorithms take precedence".  We lack
such strong language for the serialization process, and in fact say that
"[i]mplementations MAY vary from the specified behavior so long as the output
still matches the ABNF", with the algorithms merely being the "recommended way
to produce them".  To me, that implies that the ABNF is controlling, as any
variance in serialization procedure is contingent on the output matching the
ABNF.  If that's not the intended reading, I suggest making the language more
parallel to the parsing case.

-Ben