Re: [stir] Review of: draft-ietf-stir-rfc4474bis-10

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 19 August 2016 16:13 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEEC12D09B for <stir@ietfa.amsl.com>; Fri, 19 Aug 2016 09:13:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
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 HdQE6wGVja7w for <stir@ietfa.amsl.com>; Fri, 19 Aug 2016 09:13:09 -0700 (PDT)
Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 60C5A12B04C for <stir@ietf.org>; Fri, 19 Aug 2016 09:13:09 -0700 (PDT)
Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-06v.sys.comcast.net with SMTP id amPsbT4352NhqamPsbuHJN; Fri, 19 Aug 2016 16:13:08 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-19v.sys.comcast.net with SMTP id amPrbSSaKvDp9amPsbxHPe; Fri, 19 Aug 2016 16:13:08 +0000
To: stir@ietf.org
References: <c3a85ffc-8340-ac54-4d8e-21a16fefd032@dcrocker.net> <D3D41210.1A72E4%jon.peterson@neustar.biz> <CAHBDyN7W8zkgGjeUqzGaxLfRD-nFDgD9R3kxioQ47Kbp4_B8EA@mail.gmail.com> <D3DB2F21.1A7B5F%jon.peterson@neustar.biz> <7594FB04B1934943A5C02806D1A2204B4BC231EA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC2338A@ESESSMB209.ericsson.se>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <58d5ff69-8135-69f6-4191-52f33c6029d5@alum.mit.edu>
Date: Fri, 19 Aug 2016 12:13:06 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC2338A@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfH11AUDEqqhE3s5/9rwBa75mPgNTiuYBmwDqBupDihZTlhwC68VoVHc5G3C5sgRENlOQhUZrhDf4zL+Z4lAF+eDG1l95CE0kM8z1A6Jle/uY7NY53Z2O +hUdkfTnFZ+UQ/eLg1Vq3tEKlCwu+o0WJJ4p+5ZjpV+hjHYVOVydOHXk2b3GriHO18CHYcPyKa9QGA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/-rc5__zP9iFAxhi3ay-4ZKmq3k4>
Subject: Re: [stir] Review of: draft-ietf-stir-rfc4474bis-10
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Aug 2016 16:13:10 -0000

On 8/18/16 2:19 PM, Christer Holmberg wrote:
>
>
>>From my experience as GenART reviewer, I can say that usage of consistent >terminology is something that the whole IETF suffers from. But, it’s getting better :)
>
> The usage of inconsistent terminology, that is.

+1

For the specific case of header vs. header field vs. header field 
parameter, these have long been used in a sloppy way. (And I admit to 
being a frequent offender.)

Also note that while "header field" is used widely in 3261 it is never 
defined. By context it is clear that it means the same as the abnf rule 
"message-header".

Nor is there any definition of "header" in an unqualified form in 3261, 
nor (afaik) any use of that.

In informal conversation it is common to use "header" in lieu of 
"message-header"/"header field", and I would be shocked if its use ever 
causes any confusion.

I am in favor of cleaning up usage for consistency, using "header field" 
or "header field parameter" when appropriate. But I consider this an 
editorial issue, not a semantic issue.

	Thanks,
	Paul