From nobody Wed Apr 11 00:33:55 2018 Return-Path: X-Original-To: morg@ietfa.amsl.com Delivered-To: morg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A851242EA for ; Wed, 11 Apr 2018 00:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 RXJRcxUrJUIc for ; Wed, 11 Apr 2018 00:33:52 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC54124235 for ; Wed, 11 Apr 2018 00:33:51 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5E397FA0084; Wed, 11 Apr 2018 07:33:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1523432029; bh=Otbg/CdyY+m377gY54p5fIEbhn23vUJORnvTiHgK9B4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XFmCnumHygroyB8sdHSc29xQ3miTs600etbkWNo7ufC7fDDfso+kMF85pVSqadQVH gqvMSPpWgvzkzOAGkRXbuLAcEjwWX7kstUC95tAbJyZnHDWl5+lfn5g7tde664V/4d oqNOTacLjNQFLfKZbDVHp9Uqd1fQRwiM0r/tHWv0= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1523432028-16144-31493/11/23; Wed, 11 Apr 2018 07:33:48 +0000 From: Arnt Gulbrandsen To: Randall Gellens Cc: morg@ietf.org Date: Wed, 11 Apr 2018 08:33:47 +0100 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: <243b4d3d-b6e6-477c-a436-232a4ef838a6@gulbrandsen.priv.no> In-Reply-To: <492D42AA-73E5-401D-866F-F6D7AFC2CA31@randy.pensive.org> References: <20180225161655.11CA8B80C6A@rfc-editor.org> <492D42AA-73E5-401D-866F-F6D7AFC2CA31@randy.pensive.org> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [MORG] [Technical Errata Reported] RFC6154 (5265) X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 07:33:55 -0000 I'm saying that specification writers should make up their minds: Either a particular feature is case-sensitive or it isn't. "Every implementer should treat foo as case insensitive, but I myself am going to treat it as case sensitive" is ungood. When a writer does that it's a sign that he/she doesn't actually like that aspect of his/her own spec. A lot of RFCs get it right. Take line wrapping in line-oriented protocols: Just next to the first example there's often a a sentence such as "lines are wrapped for editorial clarity only". And a lot get it wrong. Take RFC 3501. There are examples on about 45 different pages, all of them use upper case for all keywords, and none of those 45 pages mention that this consistency is no rule, and none of the neighbouring pages do, either. The rule is clear once you do find it. It's like some of those privacy settings on Facebook: Clear once you find them, not at all findable. The target audience for that writing is the kind of implementer who will read an entire 108-page document before writing any code. Which I suppose mrc would consider a laudable incentive, not bad writing. Arnt From nobody Thu Apr 19 15:36:39 2018 Return-Path: X-Original-To: morg@ietfa.amsl.com Delivered-To: morg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DDF12D882 for ; Thu, 19 Apr 2018 15:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 9bgfwekWrwEt for ; Thu, 19 Apr 2018 15:36:35 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 BA773126CF6 for ; Thu, 19 Apr 2018 15:36:35 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id s78so7050757qkl.8 for ; Thu, 19 Apr 2018 15:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=tLClmaHl4AdkUykGNgYPRDnGM6tNMMByo9dnCdDqap4=; b=HoZfL5so/fZVDRlU365657EGFEaaVdhPDtD/dTkkxeA9GAKOb2u6u602uZrpVYPKJD H5mpojIUwe7gkDu78Py8AniYkb2nuiDDMefhD8QzCVt3XcbeWLxQOyqOGmku3g39LCAI uFcs5BNGVkl+z5UF4Ac04M7JWDWmaXk1Xe4LMyEgXSPc4BCpMO19SLrpQWw11iSYwDXI B3/Wz1OfLGtFdJIGmA5WILXISGbWULdGMrx3oH7RKAP1hc4LNfD/DLjFPTeZXSpajkKu 8lg5ftsemmX6ydcQLNySVc8EP94Pp9nAD2cx/EuQbhp5pv3T8NCkOQiHJpVhSva0va9c jEBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=tLClmaHl4AdkUykGNgYPRDnGM6tNMMByo9dnCdDqap4=; b=Q/k9PNA+KT2UATU6YQ7ygFt44aX9SrUUmvE1dywWtOqRjwcve+piAV3LLYobQLotpY TVzChmD354uyQAzvpITjR31sA8LYf+OtTmKwvzeNHyWtVgcVxgjbrOzFORT298GLW0Cz pev0TF0Jgzbb5FDUN1o8+xGtyN7ndEG4DdoydQAPWNn572OKqOjMd4t12DXVtIqTU/ax zxVpyWf3ywCL3VMKF6qC2bJ8X3LnK5yjxROhAmq1ldqyqMZgtJHDiGJtUWzGmcEqJkxm /bWDm1mcvpeDLeUHaX060ohT995PbII6MWpQUEDclGpBEA6RdEnClnHpUn0Nw4qwMaGz xatw== X-Gm-Message-State: ALQs6tAJouBp5DLaRI8BDN3KR9aFL/AnfdFDEI7v92InyZPff4TGh0qs lxBlfLEjcbi6GC9wEcj7GF8OigPV50mewabV3Sk= X-Google-Smtp-Source: AB8JxZqARMWEnznxSsiV7yJvulOcS8wrS1jl6iC6/pi87cvgcAJLJv4i4np+8m5/rvkK/DN0EtXnv3gX+c7+juaY+gI= X-Received: by 10.55.187.3 with SMTP id l3mr7751279qkf.32.1524177394791; Thu, 19 Apr 2018 15:36:34 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.237.51.162 with HTTP; Thu, 19 Apr 2018 15:36:34 -0700 (PDT) In-Reply-To: <243b4d3d-b6e6-477c-a436-232a4ef838a6@gulbrandsen.priv.no> References: <20180225161655.11CA8B80C6A@rfc-editor.org> <492D42AA-73E5-401D-866F-F6D7AFC2CA31@randy.pensive.org> <243b4d3d-b6e6-477c-a436-232a4ef838a6@gulbrandsen.priv.no> From: Barry Leiba Date: Thu, 19 Apr 2018 18:36:34 -0400 X-Google-Sender-Auth: 5p1xb_k5muRmHklnt-Jmwm3ArAo Message-ID: To: Arnt Gulbrandsen Cc: Randall Gellens , morg Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [MORG] [Technical Errata Reported] RFC6154 (5265) X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 22:36:38 -0000 Arnt, I agree with you, but... The problem is deciding how many times (and where) to say it. We often have a "terminology" section at the beginning, which has things like the 2119 boilerplate, explanations of "C:" and "S:" in examples, and such. I figure that's a good place to put a notation about case-sensitivity. But that still leaves the issue that it's specified in one place in a large document, and we still expect the reader to read that particular bit out of the large document. It's easy to say that one gets it right and another doesn't, but when they both essentially have the rule in one place... what makes the one right and the other not. Barry On Wed, Apr 11, 2018 at 3:33 AM, Arnt Gulbrandsen wrote: > I'm saying that specification writers should make up their minds: Either a > particular feature is case-sensitive or it isn't. "Every implementer should > treat foo as case insensitive, but I myself am going to treat it as case > sensitive" is ungood. When a writer does that it's a sign that he/she > doesn't actually like that aspect of his/her own spec. > > A lot of RFCs get it right. Take line wrapping in line-oriented protocols: > Just next to the first example there's often a a sentence such as "lines are > wrapped for editorial clarity only". > > And a lot get it wrong. Take RFC 3501. There are examples on about 45 > different pages, all of them use upper case for all keywords, and none of > those 45 pages mention that this consistency is no rule, and none of the > neighbouring pages do, either. > > The rule is clear once you do find it. It's like some of those privacy > settings on Facebook: Clear once you find them, not at all findable. > > The target audience for that writing is the kind of implementer who will > read an entire 108-page document before writing any code. Which I suppose > mrc would consider a laudable incentive, not bad writing. > > Arnt > > > _______________________________________________ > MORG mailing list > MORG@ietf.org > https://www.ietf.org/mailman/listinfo/morg > Note Well: http://www.ietf.org/maillist.html