Re: [Gen-art] [Last-Call] [art] Genart last call review of draft-nottingham-rfc7320bis-02

Mark Nottingham <mnot@mnot.net> Wed, 27 November 2019 02:32 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32ACF120116; Tue, 26 Nov 2019 18:32:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=DQVXa4J8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=k7be1H5t
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 gVGE2OYoZLsG; Tue, 26 Nov 2019 18:32:16 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A46012006F; Tue, 26 Nov 2019 18:32:16 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id DD4292260C; Tue, 26 Nov 2019 21:32:15 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 26 Nov 2019 21:32:15 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=U 3JVEvzZS8+tJHKdbg9ikUXBem+1p/TlS1YgzUWA/Xg=; b=DQVXa4J8jFgNVzwQt sjVuLdBIkJePe8Y1v2J8K4gCPkuH4D4ENZ9SCSAx/IZYYMWmNU46iM0CAQPolq0q vS1Iz0U+7Nt25XNA3XZmoVZToPZhEo0r5oBwRngwLYfh4eibByb9WtYElEKQGWtf AK3gXOK1wlRHBvxfHZjRm1/+jwcUJ9ZRdpbMO9VO4WVZizSrCqiR9ogdVeZI50Gf auEyWyVGs6NOXydpGWxcQV4+r3pW30n5kP1l6VEEl6nys9609IqRDgFlqkzQddjM /ZM5Hv14kc/89eVIJ0xQhEWaKp37IoOnOewhv/COsL6quwx/iv7nsoAV7YmjIoKq KS82g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=U3JVEvzZS8+tJHKdbg9ikUXBem+1p/TlS1YgzUWA/ Xg=; b=k7be1H5tUAj0Jo5Uj6qWKbiL0N7cb1RU83oyZJ39ruPiRXJkPfK4D6n8i 5tlg7Wses1yi7qsR/IQzR708O8fMSyrXG8nDDm4aHCq2duVvpuk1Th9Fj6JdEs5C 2vCD9GtbbBemVIpRk7/1rCg5/9wcsdXYvpTnP8yvDnLKVAWFqjGJoKK4ss8eYn5K I79AFMHlbbvck7YzBjGr8n9Mt+uGWzfJp2sehn8nzgAZ4o1FNkrhBBMTcmBupzmB rQ7uRV6KF4nR7Fb0YBAjbEwi0yrYbVAh+a5VeKZfU40PjhtqwVM34wn6Vrs/JcVJ J7KDUM7qW0c3HEptBnwjgjF8VKp2A==
X-ME-Sender: <xms:LuDdXVSoaO9p1vAoK-nVrYLGjIPdqSmORSH8JmwkJLj8f3q_Zzn4dw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeigedggeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucfrrghrrghm pehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiii gvpedt
X-ME-Proxy: <xmx:LuDdXTAZYJ1QzIRW8N3_SN48NfgC7n5gRRCCije-4_PRK2ismqrohQ> <xmx:LuDdXV3GdvLrbInEJ1G616-Wos_T9f_hsBrkMEwFqq0lqyATqd_8-w> <xmx:LuDdXRUNhYXfMXq2feItaQ1Agwatidh5DCDgkZKi3zsLVaofd7ouAA> <xmx:L-DdXSbAkXif3AgNRdZt7W6hlsZdANqIcr0bHN_WiSo8phZmQMXlgg>
Received: from attitudadjuster.mnot.net (unknown [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 93F683060057; Tue, 26 Nov 2019 21:32:12 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <23E269D1-06A1-4EE6-B886-5E5B3824C27E@tzi.org>
Date: Wed, 27 Nov 2019 13:32:09 +1100
Cc: last-call@ietf.org, gen-art@ietf.org, draft-nottingham-rfc7320bis.all@ietf.org, Martin Thomson <mt@lowentropy.net>, Robert Sparks <rjsparks@nostrum.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C01295C-6EDA-4C32-8BA3-BD8DA3B9C9A2@mnot.net>
References: <3a7db097-84c0-4c44-aed0-51196a6a16b6@www.fastmail.com> <9F9A2298-0088-40B2-A69C-7F63D17EB8E3@nostrum.com> <A88B004F-6426-41BF-9711-4071A63637B5@mnot.net> <23E269D1-06A1-4EE6-B886-5E5B3824C27E@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/qNvtALhRXOocSsZToanyKAJKOXs>
Subject: Re: [Gen-art] [Last-Call] [art] Genart last call review of draft-nottingham-rfc7320bis-02
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Nov 2019 02:32:18 -0000


> On 27 Nov 2019, at 1:13 pm, Carsten Bormann <cabo@tzi.org> wrote:
> 
> On Nov 27, 2019, at 02:56, Mark Nottingham <mnot@mnot.net> wrote:
>> 
>> Do we expect most readers to be comparing the documents so closely? This is an 'obsoletes', not an 'updates'.
> 
> Speaking for myself as a reader only: Yes.

My concern is that every time we add text to a document, we increase the cognitive load for readers; adding the reasoning for *every* decision and change expands a page of text into 2 to 3 (or more), so we need to impose a filter of some sort.

The requirement in question is:

 "Media type definitions (as per [RFC6838]) SHOULD specify the fragment identifier syntax(es) to be used with them"

It was removed because it was misleading (6838 doesn't make such a requirement a SHOULD), and the focus of this update was to reduce the number of unnecessary requirements. 3986 isn't replacing that reference; it's providing a grounding for what fragment identifiers are.

IME this information doesn't help the reader understand the document any better unless they're closely comparing the two documents (as reviewers are now doing, and thanks to them). If folks disagree, that's fine, but I'd like to understand why they think this information is worthy of documenting in-spec.

Cheers,

--
Mark Nottingham   https://www.mnot.net/