Re: WGLC: p1 MUSTs

Roy T. Fielding <fielding@gbiv.com> Wed, 31 July 2013 17:50 UTC

Return-Path: <ietf-http-wg-request@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 27A1C11E819F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 31 Jul 2013 10:50:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.901
X-Spam-Level:
X-Spam-Status: No, score=-9.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfn1r8HgcgA8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 31 Jul 2013 10:50:42 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5287721E80F5 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 31 Jul 2013 10:50:23 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1V4aWJ-0006uM-88 for ietf-http-wg-dist@listhub.w3.org; Wed, 31 Jul 2013 17:49:07 +0000
Resent-Date: Wed, 31 Jul 2013 17:49:07 +0000
Resent-Message-Id: <E1V4aWJ-0006uM-88@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <fielding@gbiv.com>) id 1V4aW9-0006tc-WA for ietf-http-wg@listhub.w3.org; Wed, 31 Jul 2013 17:48:58 +0000
Received: from caiajhbdcahe.dreamhost.com ([208.97.132.74] helo=homiemail-a87.g.dreamhost.com) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <fielding@gbiv.com>) id 1V4aW8-0007e0-L5 for ietf-http-wg@w3.org; Wed, 31 Jul 2013 17:48:57 +0000
Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 4991B26C05B; Wed, 31 Jul 2013 10:48:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=zImwpf/3Hyw7xpQSNZeewBl8SiA=; b=xJ9lfuW/apRvhZyC7W0Wtg7rl21A DWG3d+IjjYMOJbevWsvzx95Tl5CkjZoveiydnVkLSCLz/e186w6T+RELppakhjze 0l0tvXBDmRj9OsIcArGFyQF0nddzx2LltyBh7m73zQTHopmm34ZHu40U1I5CrnuA XHYQdGeqxK7I6aA=
Received: from [192.168.1.84] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 307BB26C057; Wed, 31 Jul 2013 10:48:34 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Roy T. Fielding <fielding@gbiv.com>
In-Reply-To: <5180137E.2040603@measurement-factory.com>
Date: Wed, 31 Jul 2013 10:48:33 -0700
Cc: IETF HTTP WG <ietf-http-wg@w3.org>
Content-Transfer-Encoding: 7bit
Message-Id: <25F6A64B-AD84-41CA-8D91-A1D3C575CCEE@gbiv.com>
References: <D69329FD-7456-46C5-BE24-6E7EE7E48C39@mnot.net> <5180137E.2040603@measurement-factory.com>
To: Alex Rousskov <rousskov@measurement-factory.com>
X-Mailer: Apple Mail (2.1283)
Received-SPF: none client-ip=208.97.132.74; envelope-from=fielding@gbiv.com; helo=homiemail-a87.g.dreamhost.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-3.437, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001
X-W3C-Scan-Sig: maggie.w3.org 1V4aW8-0007e0-L5 ca1fbcc7de8f870adf62a7d5aa526f0a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: WGLC: p1 MUSTs
Archived-At: <http://www.w3.org/mid/25F6A64B-AD84-41CA-8D91-A1D3C575CCEE@gbiv.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/19018
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: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Apr 30, 2013, at 11:54 AM, Alex Rousskov wrote:

>> A sender MUST NOT generate protocol elements that do not match the
>> grammar defined by the ABNF rules for those protocol elements that
>> are applicable to the sender's role.
> 
> The "for those protocol elements..." part should be dropped IMO. A
> sender MUST NOT generate invalid protocol elements even if they are not
> applicable to the sender's role. Note that we are talking about
> _generation_ and not forwarding here.

That isn't why it is being described. There are ABNF rules that define
various alternative syntax to be generated based on the role of the
sender (and, in some cases, based on the role of the recipient).
It is hard to capture in a small number of words.

>> If a received protocol element is processed, the recipient MUST be
>> able to parse any value that would match the ABNF rules
> 
> "processed" seems too broad because simply buffering a header may be
> called "processing". "Interpreted" may be better. Or did I miss the
> definition of "process" that clarifies this?

Actually, no, simply buffering a header is not called processing.
"Movement of data or material towards a known goal or end result,
by passing it through a series of stages or a sequence of actions."
However, I can rephrase it.

>> If a received protocol element is processed, the recipient MUST be
>> able to parse any value that would match the ABNF rules for that
>> protocol element, excluding only those rules not applicable to the
>> recipient's role.
> 
> The "excluding only those rules not applicable..." part seems to
> contradict the "processed" verb. Why would a recipient want to process
> something inapplicable? Perhaps this is related to the "process" versus
> "interpreted" issue mentioned above.

A client does not need to parse syntax that is only sent to servers.
An origin server does not need to parse syntax that is only sent by
a server. ...

> the recipient MUST be
>> able to parse any value that would match the ABNF rules for that
>> protocol element, excluding only those rules not applicable to the
>> recipient's role.
> 
> Please rephrase to avoid double negation in "excluding not applicable".
> For example: "the recipient MUST be able to parse any value matching the
> corresponding ABNF protocol element rules applicable to the recipient's
> role"

Okay.

One more attempt at describing the overall conformance requirements
has been committed to address this part of #484 (and related concerns).

http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2332

....Roy