From nobody Fri Aug 2 11:55:23 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C261207CA for ; Fri, 2 Aug 2019 11:55:22 -0700 (PDT) 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=AouKm3Cb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=juVBsT+3 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 2yMSnFanMjV5 for ; Fri, 2 Aug 2019 11:55:19 -0700 (PDT) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACA71120278 for ; Fri, 2 Aug 2019 11:55:19 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id AAA5D1B95; Fri, 2 Aug 2019 14:55:17 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 02 Aug 2019 14:55:17 -0400 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=fm3; bh=C WqRSDRvZUbgZOTyhhYCzn0wtfnIi5n2zyHIHf2lolo=; b=AouKm3Cbl1iSodLBb ru+oazosI/EQFIirTvPhWOZW/GGC2XOTGpJcCISzwXBTgUpUWrDDlwLpMEo+EE25 zs/PBy3UZeFIWwjw9Pgg9OMWs/HVJDPLeZdtfjDVh8K1hH3aCOQ+UdUHWDMS1Mb+ J+gI8Sss/1+qVsZquO7P1lS0DDDMna6XurD5VzDxQ2lbvQOlFKV1ij1fxaJo7S/J OzEzhAEHvrcSGCZIXoHqgyt5HDlGhj+8hCm6fgl6o0Y6+qms0IkIdVU8Nrewo69Y zAoZjsGjLnNhPMAn6R63aiZQmtLAKa4DGB81F2pohoYS4saVC80jQwFxk1jBGcXg BfvzQ== 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=fm3; bh=CWqRSDRvZUbgZOTyhhYCzn0wtfnIi5n2zyHIHf2lo lo=; b=juVBsT+3a5VlziDo2hLsQscko1IlF/8J0aZ5WSzBi1VWPA3OXQSObDoF8 kqg+FvPhOBckNH5840L+2aGYQ4//jHbCVZR1/xv8wYf18JGnBqeQDi2IuKAMzb9Z Ion1exbMSBNG3pAXYIc9gqFwf9duLE6UebagPuKhhjNc+fU3ujR9YfncrDjrLnCs L/gJ1zRUFanSyjDrC9iCGb8fvThjKvEzRqdLzJ9E/BvNpxtmRnwgi1bZkJGWoCcZ nLqPiXvg7YraNJCi0mEHv7mChnB/tqADPeezd6MCcJTxQ9cACGDp1Fm/7DZiYpTv jZ/xy/H6UaAABv1gnzlR3z0KMZASQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrleelgddutdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne goufhushhpvggtthffohhmrghinhculdegledmnecujfgurheptggguffhjgffgffkfhfv ofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnh hothesmhhnohhtrdhnvghtqeenucffohhmrghinhepsghlohhgshhpohhtrdgtohhmpdhm nhhothdrnhgvthenucfkphepkedrudekrddvudejrddvtddvnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [10.100.20.67] (unknown [8.18.217.202]) by mail.messagingengine.com (Postfix) with ESMTPA id BFF9680060; Fri, 2 Aug 2019 14:55:15 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mark Nottingham In-Reply-To: Date: Fri, 2 Aug 2019 11:55:14 -0700 Cc: ART Area , Devon O'Brien Content-Transfer-Encoding: quoted-printable Message-Id: References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> To: Jacob Hoffman-Andrews X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [art] On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 18:55:22 -0000 It sounds like you (collectively) want an exception in BCP190 still, = correct? If so, I think we just need to craft some language about that for = inclusion in the spec; I'd imagine it need only be a sentence or two = about it. Then the AD(s) need to convince themselves that it reflects = consensus. The underlying issue is the text in 2.3 of BCP190; I think the emerging = consensus is that it's too strict, in that it can be read to preclude = using a prefix approach with a MUST NOT, when in fact the potential harm = to other applications / the Web overall is pretty small. Does anyone disagree with that? Cheers, > On 31 Jul 2019, at 2:10 pm, Jacob Hoffman-Andrews = wrote: >=20 > On Sat, Jul 27, 2019 at 11:26 PM Larry Masinter wrote: > The use of / in the path of URLs was supposed to >=20 > be restricted to hierarchical data, and yet CT doesn=E2=80=99t > do that. >=20 > = http://masinter.blogspot.com/2019/05/on-nature-of-hierarchical-urls.html >=20 >=20 > CT and all prefix-using APIs do that, with a single level hierarchy. = The domain owner specifies a prefix, ending with a "/". All of the URLs = that are part of the API follow that prefix - they are subordinate in = the hierarchy. >=20 > Coming back to the main point: What remains in order to find consensus = on this issue? >=20 > Thanks, > Jacob -- Mark Nottingham https://www.mnot.net/ From nobody Fri Aug 2 13:15:27 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A449120059 for ; Fri, 2 Aug 2019 13:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 wzYSwG27Vg4g for ; Fri, 2 Aug 2019 13:15:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 4B5201200E9 for ; Fri, 2 Aug 2019 13:15:24 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x72KFJFa080690 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 2 Aug 2019 15:15:21 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1564776922; bh=GVKwsQjdcbkfe5QfIeJRuW9USwMFNaBOvyXwi70lPMA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=KdfqZAi1wirsGbpz/pQrUsxerdhmhwk6APUajzzlVEeA3mpG3SNSzOc0oF9QuT6SI 2AmBRRy6gUCOHH/CvX+lya82DAU7r6pu+KXocp5cHi7rRLZbZmK6EDscWEldJ17N4g h+8xkLJFIdMroiGrMnzKSTooMaMydduNIWUcqpNI= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Mark Nottingham , Jacob Hoffman-Andrews Cc: ART Area , "Devon O'Brien" References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> From: Adam Roach Message-ID: <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> Date: Fri, 2 Aug 2019 15:15:14 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 20:15:26 -0000 For the purposes of clearing my discuss, I intend to read the responses to Mark's message below as a reflection of consensus from the community. If you have thoughts on the topic, please weigh in on the ART-area mailing list no later than Friday, August 16th. People who have participated in the discussion in TRANS are very much welcome to re-express their opinions in this thread. I'm also hoping that we get some input from other participants -- even if it's something as simple as "this sounds good to me" -- to make sure all relevant perspectives are taken into account. Thanks! /a On 8/2/19 1:55 PM, Mark Nottingham wrote: > It sounds like you (collectively) want an exception in BCP190 still, correct? > > If so, I think we just need to craft some language about that for inclusion in the spec; I'd imagine it need only be a sentence or two about it. Then the AD(s) need to convince themselves that it reflects consensus. > > The underlying issue is the text in 2.3 of BCP190; I think the emerging consensus is that it's too strict, in that it can be read to preclude using a prefix approach with a MUST NOT, when in fact the potential harm to other applications / the Web overall is pretty small. > > Does anyone disagree with that? > > Cheers, > > >> On 31 Jul 2019, at 2:10 pm, Jacob Hoffman-Andrews wrote: >> >> On Sat, Jul 27, 2019 at 11:26 PM Larry Masinter wrote: >> The use of / in the path of URLs was supposed to >> >> be restricted to hierarchical data, and yet CT doesn’t >> do that. >> >> http://masinter.blogspot.com/2019/05/on-nature-of-hierarchical-urls.html >> >> >> CT and all prefix-using APIs do that, with a single level hierarchy. The domain owner specifies a prefix, ending with a "/". All of the URLs that are part of the API follow that prefix - they are subordinate in the hierarchy. >> >> Coming back to the main point: What remains in order to find consensus on this issue? >> >> Thanks, >> Jacob > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art From nobody Fri Aug 2 13:16:45 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07BF120059 for ; Fri, 2 Aug 2019 13:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 7tFihyn6bGZP for ; Fri, 2 Aug 2019 13:16:42 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (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 DC8D61200E9 for ; Fri, 2 Aug 2019 13:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=tcMiHDtD4C11ldAXoRn4ZbhIk1swpNJ7nChehYbV2Hk=; b=KD4yVPZCVtbgXY4v9psveCq05T OXCsR/sfuuNXPmnjlphvBtsozTPqTMdA5qFMxYWLwvY9A9VOQ55PmDasnV0SxhvB2azo2ylbaAnyz QMUbwu8uMDypYRseawFQus6tCcWE2O5PXPcDV6UH78igT1mFNuibBGb5jaagYBKhkaFg=; Received: ; Fri, 02 Aug 2019 13:16:42 -0700 To: Mark Nottingham , Jacob Hoffman-Andrews Cc: ART Area , Devon O'Brien References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> From: Jacob Hoffman-Andrews Message-ID: <074c176a-432a-a5e4-2deb-bd7c87d956bc@eff.org> Date: Fri, 2 Aug 2019 13:16:42 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [art] On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 20:16:44 -0000 On 8/2/19 11:55 AM, Mark Nottingham wrote: > The underlying issue is the text in 2.3 of BCP190; I think the emerging consensus is that it's too strict, in that it can be read to preclude using a prefix approach with a MUST NOT, when in fact the potential harm to other applications / the Web overall is pretty small. This sounds good to me, thanks. From nobody Fri Aug 2 13:52:05 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB04812013D for ; Fri, 2 Aug 2019 13:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham 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 oqQpOYyU7JSa for ; Fri, 2 Aug 2019 13:52:00 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3DB1120134 for ; Fri, 2 Aug 2019 13:51:59 -0700 (PDT) Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 460fV62DljzyQ4; Fri, 2 Aug 2019 22:51:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> Date: Fri, 2 Aug 2019 22:51:57 +0200 Cc: Mark Nottingham , Jacob Hoffman-Andrews , ART Area , Devon O'Brien X-Mao-Original-Outgoing-Id: 586471915.917899-82afa68027196b9b6faba4fa6af80bf2 Content-Transfer-Encoding: quoted-printable Message-Id: References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 20:52:03 -0000 > On Aug 2, 2019, at 22:15, Adam Roach wrote: >=20 > For the purposes of clearing my discuss, I intend to read the = responses to Mark's message below as a reflection of consensus from the = community. If you have thoughts on the topic, please weigh in on the = ART-area mailing list no later than Friday, August 16th. >=20 > People who have participated in the discussion in TRANS are very much = welcome to re-express their opinions in this thread. I'm also hoping = that we get some input from other participants -- even if it's something = as simple as "this sounds good to me" -- to make sure all relevant = perspectives are taken into account. >=20 > Thanks! >=20 > /a >=20 > On 8/2/19 1:55 PM, Mark Nottingham wrote: >> It sounds like you (collectively) want an exception in BCP190 still, = correct? >>=20 >> If so, I think we just need to craft some language about that for = inclusion in the spec; I'd imagine it need only be a sentence or two = about it. Then the AD(s) need to convince themselves that it reflects = consensus. >>=20 >> The underlying issue is the text in 2.3 of BCP190; I think the = emerging consensus is that it's too strict, in that it can be read to = preclude using a prefix approach with a MUST NOT, when in fact the = potential harm to other applications / the Web overall is pretty small. >>=20 >> Does anyone disagree with that? This does sound good to me. I hope we don=E2=80=99t put the topic back on the shelves with that = specific decision for TRANS; we still need to have a feeling of the = general shape of that exception as it will apply for other web-based = protocols we define. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 2 13:53:17 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CDE120807 for ; Fri, 2 Aug 2019 13:53:11 -0700 (PDT) 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=B1IB9TnC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=C6chVSyu 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 ts8B8t0paVdT for ; Fri, 2 Aug 2019 13:53:08 -0700 (PDT) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B7B31201EC for ; Fri, 2 Aug 2019 13:53:08 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 4BBBD2821; Fri, 2 Aug 2019 16:53:07 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 02 Aug 2019 16:53:07 -0400 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=fm3; bh=u mxhR6pt5MQjzSBPyoGyMygDd24Uck3rMOFHfOJdAHo=; b=B1IB9TnCUOKDLCTEh UDD62uy5aChXnVuUBMj5hw5LnjqR4v9222LIp6YtqAkPz5cacRChLXpMg13th2IW 5hBUuwxYl2fV30fao4/y2ntE2NgtQF2XV5ARoEVABgcDXhY6NctHVXk2njcvPoFv iUp1dDJ5KEIxrofptUkOajyyjb6nKQ8EDwWvdHaYDgp9PgFRuYotuKg/2SUmnxcr vaRWBwDRFz+PrvYGIAU51k22lmqynOTCWirD+SdQmykfNUk9WuBXV5+E1Q34oGGJ UDyJz5TUZaDSR5oxGRzYKa5eKae2kqirJ6ZqI+uoYgh7270BNAWtL6Zf/0ApGR18 uWgAA== 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=fm3; bh=umxhR6pt5MQjzSBPyoGyMygDd24Uck3rMOFHfOJdA Ho=; b=C6chVSyuiaNcpQy0D0hySQNgPIrqyE1wHJKYdewbVZKsXy1X7m7n8gSnQ FpVA/2LM/iHUl3ufOvZRmrJc/hJYBFQ66TMDw+JZeY0+2XtgjgglgCYAiKisZMlX s2k4H9JvcIqSd0WjPOFauBsFlXI8g3JD9usil7x9VQgpjUvp4QpyaH8oZeCD0FMX Z9tibM69jQfkbCw7SQV4wypiofq8B4kNSUwhJf8h33GCkaWsxLkS3XvwNqhsmMxi 3vVFa15rDuDUhmmtW2E876aHlFlCW9X324yx/snWAFGRoTr0IY0w04ZmADOKGYiw g+gnJF8Zin6745M0DICSJ98vZceIA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrleelgdduvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epmhhnohhtrdhnvghtnecukfhppeekrddukedrvddujedrvddtvdenucfrrghrrghmpehm rghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpe dt X-ME-Proxy: Received: from [10.100.20.67] (unknown [8.18.217.202]) by mail.messagingengine.com (Postfix) with ESMTPA id 2E39E80061; Fri, 2 Aug 2019 16:53:06 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mark Nottingham In-Reply-To: Date: Fri, 2 Aug 2019 13:53:05 -0700 Cc: Adam Roach , Jacob Hoffman-Andrews , ART Area , Devon O'Brien Content-Transfer-Encoding: quoted-printable Message-Id: <912F860C-17AE-41D6-BAD1-B8C50D5CE337@mnot.net> References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 20:53:14 -0000 Agreed; I'm planning an -00 of a bis for discussion. Cheers, > On 2 Aug 2019, at 1:51 pm, Carsten Bormann wrote: >=20 >=20 >=20 >> On Aug 2, 2019, at 22:15, Adam Roach wrote: >>=20 >> For the purposes of clearing my discuss, I intend to read the = responses to Mark's message below as a reflection of consensus from the = community. If you have thoughts on the topic, please weigh in on the = ART-area mailing list no later than Friday, August 16th. >>=20 >> People who have participated in the discussion in TRANS are very much = welcome to re-express their opinions in this thread. I'm also hoping = that we get some input from other participants -- even if it's something = as simple as "this sounds good to me" -- to make sure all relevant = perspectives are taken into account. >>=20 >> Thanks! >>=20 >> /a >>=20 >> On 8/2/19 1:55 PM, Mark Nottingham wrote: >>> It sounds like you (collectively) want an exception in BCP190 still, = correct? >>>=20 >>> If so, I think we just need to craft some language about that for = inclusion in the spec; I'd imagine it need only be a sentence or two = about it. Then the AD(s) need to convince themselves that it reflects = consensus. >>>=20 >>> The underlying issue is the text in 2.3 of BCP190; I think the = emerging consensus is that it's too strict, in that it can be read to = preclude using a prefix approach with a MUST NOT, when in fact the = potential harm to other applications / the Web overall is pretty small. >>>=20 >>> Does anyone disagree with that? >=20 > This does sound good to me. >=20 > I hope we don=E2=80=99t put the topic back on the shelves with that = specific decision for TRANS; we still need to have a feeling of the = general shape of that exception as it will apply for other web-based = protocols we define. >=20 > Gr=C3=BC=C3=9Fe, Carsten -- Mark Nottingham https://www.mnot.net/ From nobody Fri Aug 2 16:27:29 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135FA120024 for ; Fri, 2 Aug 2019 16:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 DevJEoNf4CaH for ; Fri, 2 Aug 2019 16:27:26 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCCB1120018 for ; Fri, 2 Aug 2019 16:27:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 83C6FBE50; Sat, 3 Aug 2019 00:27:23 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgKYZB4brlZC; Sat, 3 Aug 2019 00:27:22 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0D5E1BE47; Sat, 3 Aug 2019 00:27:22 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1564788442; bh=ONe+XRldmRQBn9fLmkxpcx2joih9hpQ3PiLI8JHWjuc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=grCVy+F5pe9bKPvwPiZNZNZXyWiTlPyCxdpIEuVDeQ59F3XsBLdtbD1TB0mCk+TAk XU6I8X0aYi4HyWD6DoFgldQjscHDxt2Ne9qsE+26s2mzK6ECETaYgVO+ajoWkgu0Ae BWwIY7CBYtF9Zl1fAdwG9jGhAyGlLtYybFfJkrys= To: Mark Nottingham , Jacob Hoffman-Andrews Cc: ART Area , Devon O'Brien References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Sat, 3 Aug 2019 00:27:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tvxqdDRc6NLTEvgnYjZFVHtbjiBH4nCLW" Archived-At: Subject: Re: [art] On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 23:27:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tvxqdDRc6NLTEvgnYjZFVHtbjiBH4nCLW Content-Type: multipart/mixed; boundary="lR2BGs6nfX9M9k2105EnLDAnj2J8oRrYA"; protected-headers="v1" From: Stephen Farrell To: Mark Nottingham , Jacob Hoffman-Andrews Cc: ART Area , Devon O'Brien Message-ID: Subject: Re: [art] On BCP 190 References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> In-Reply-To: --lR2BGs6nfX9M9k2105EnLDAnj2J8oRrYA Content-Type: multipart/mixed; boundary="------------2B28864591F3EBE3166E5675" Content-Language: en-GB This is a multi-part message in MIME format. --------------2B28864591F3EBE3166E5675 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/08/2019 19:55, Mark Nottingham wrote: > The underlying issue is the text in 2.3 of BCP190; I think the > emerging consensus is that it's too strict, in that it can be read to > preclude using a prefix approach with a MUST NOT, when in fact the > potential harm to other applications / the Web overall is pretty > small. >=20 > Does anyone disagree with that? No, I agree that's a good description of the situation. S. --------------2B28864591F3EBE3166E5675 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------2B28864591F3EBE3166E5675-- --lR2BGs6nfX9M9k2105EnLDAnj2J8oRrYA-- --tvxqdDRc6NLTEvgnYjZFVHtbjiBH4nCLW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl1ExtQACgkQWrL68XsX K+rMGBAAorP6flJejtj5G5I1CS/6wNRpmqL5kgl+UsO8jtIIH4VmPidNLUtDj7xu NRR9hC/lYDf1/9sEHZpJgZrGMdhD+WXQE4aCiuMsc7UFBu05ru1Bsn6DsLvywwSt JglZCEZGA39GRiLvh6RGGcArFkRTP2/tRZyRTXIXlL+5R4tILn4+l+x0c9t9ujuB RsWCnxcBqb58wqzSwIsQIJsO451jFOMI2atb5lHuG9Y11zlKFgVIBL0rEnqLU7Ok OO9VOysfLj2i+f89p0tzPvaNVVc5wTCW57e4WNLdC9aaFvWHHIrKHF+yTrPzjfYj AmuNE4j5/0fvNfqS555ruUOCDgdz8gvI5fMOYbsB2WRtaRb6FfirIs8aB5CiQn7D x+xF0IAbocbE4FuFY6/2at4agumr71BrzYdAov3+kBchsdr2iLsF5nHMyyG07BPL fM9CrE02JGcFcLusM0+PeWO3+PHIDH97INfPImzwbkMaRRNHg5QMAG03SdkdpVwi KXd35yHXgLkSWvJ2a4kMxOMoz9VtsCSUSq5xa2s+3gvLNhqqZo5pq8c3DXzTO82k aInvZ1SCinXus8rW6m6wIdnjW5msLBvc/Cxpo0MlhxhTKyW0lYmQvS55GvAHozCq 9gv+rA1Yt6MDI/fiOEb18x5lDCPaAzGo5OubPJbY2KL+RjQRNd4= =qLsh -----END PGP SIGNATURE----- --tvxqdDRc6NLTEvgnYjZFVHtbjiBH4nCLW-- From nobody Fri Aug 2 16:33:36 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A0E12002F for ; Fri, 2 Aug 2019 16:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 qMhDLWYNQHst for ; Fri, 2 Aug 2019 16:33:33 -0700 (PDT) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (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 0A451120018 for ; Fri, 2 Aug 2019 16:33:33 -0700 (PDT) Received: by mail-io1-xd44.google.com with SMTP id g20so155733908ioc.12 for ; Fri, 02 Aug 2019 16:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gG8BS96FKJKLVuLQvsmPLUOElHRGoSUcbHUVq3OTGxc=; b=nKzA+KV0k9JtjHNs1KwXmWqDJ1CbJV0YhOngnOj1h7/AfdhNoUCOcrjNe08p57/mrB N14sm/FJ9UFAhd2HocxBs/lqyg6MdH0iMvaT3mFhIu4gZhsZuEXyRSRWCwLDInMc7hO/ mnXRMrRoykMiiIcWBVNruz8RrIqUTVBkcXVEkDfTdNnx5f4WLxDu0BTpV4GVbsRURrmY emJMmuWkQMBZp+3h6B95JyZtGy49jWJZRr4PxxYzL1KcooWNtb0EFRSs4i2n6S6BGhjn oGfq4yTqBA5Lo5sABlTeaatoiy5IFLCxG7waXIkNIHvfrNfo03hLyUSDCWw6gHSi7wsL ksZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gG8BS96FKJKLVuLQvsmPLUOElHRGoSUcbHUVq3OTGxc=; b=ZxYoiEvHVZ2H+ieKOerCbkg4EV1rP8JhrO8RlkJDdLVqggNLpr2gsHbYxmEV/QvsB2 y3MXQ0HZ4wR8n4gOIXdHQ10/PpnVzTSWDt3mnZfOrOGKZFJS2q8uEQze8JcvVx1MUT34 rBS37w5vjeu7UHGcRfPvMb/C0Wy9I4ija+mCY/rwIsthBz4EQ16ZgZn8onXJ6zaDCMeL Ha4iuX4quT7uHcJIwN5U+ZA+ndtBHZ2CJETCSKNeB7A/JgPfYfw6hFhmFRkim+UU0Nly 5JvgWvT9XJ+H7FKG2TS/nTB+l828daAliiIfjvzy40U72LN8FX/1NMWGtb3P+eXs5vSc KTcA== X-Gm-Message-State: APjAAAUCnOAvuiX4Yt8EJFzWOWQ5CIF9zBGe0UmlteMJHydZW7SvRPpX agFue3x0MKRHrpj/lE50Zkx28Ff23n0hgSc8t+c= X-Google-Smtp-Source: APXvYqzAx3N6/tXt2Cma04Cbx9S+ZKbNdHaul/R0nbljXKfJbznoL7r+SvTfNUKxs3BeK4MUT2Y6WU/syNZ4RDl/py0= X-Received: by 2002:a5e:9515:: with SMTP id r21mr85307ioj.257.1564788812229; Fri, 02 Aug 2019 16:33:32 -0700 (PDT) MIME-Version: 1.0 References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> In-Reply-To: <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> From: Rob Sayre Date: Fri, 2 Aug 2019 16:33:21 -0700 Message-ID: To: Adam Roach Cc: ART Area , "Devon O'Brien" , Jacob Hoffman-Andrews , Mark Nottingham Content-Type: multipart/alternative; boundary="0000000000004d305f058f2ac971" Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 23:33:35 -0000 --0000000000004d305f058f2ac971 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This sounds good to me. thanks, Rob On Fri, Aug 2, 2019 at 1:15 PM Adam Roach wrote: > For the purposes of clearing my discuss, I intend to read the responses > to Mark's message below as a reflection of consensus from the community. > If you have thoughts on the topic, please weigh in on the ART-area > mailing list no later than Friday, August 16th. > > People who have participated in the discussion in TRANS are very much > welcome to re-express their opinions in this thread. I'm also hoping > that we get some input from other participants -- even if it's something > as simple as "this sounds good to me" -- to make sure all relevant > perspectives are taken into account. > > Thanks! > > /a > > On 8/2/19 1:55 PM, Mark Nottingham wrote: > > It sounds like you (collectively) want an exception in BCP190 still, > correct? > > > > If so, I think we just need to craft some language about that for > inclusion in the spec; I'd imagine it need only be a sentence or two abou= t > it. Then the AD(s) need to convince themselves that it reflects consensus= . > > > > The underlying issue is the text in 2.3 of BCP190; I think the emerging > consensus is that it's too strict, in that it can be read to preclude usi= ng > a prefix approach with a MUST NOT, when in fact the potential harm to oth= er > applications / the Web overall is pretty small. > > > > Does anyone disagree with that? > > > > Cheers, > > > > > >> On 31 Jul 2019, at 2:10 pm, Jacob Hoffman-Andrews > wrote: > >> > >> On Sat, Jul 27, 2019 at 11:26 PM Larry Masinter wrote: > >> The use of / in the path of URLs was supposed to > >> > >> be restricted to hierarchical data, and yet CT doesn=E2=80=99t > >> do that. > >> > >> > http://masinter.blogspot.com/2019/05/on-nature-of-hierarchical-urls.html > >> > >> > >> CT and all prefix-using APIs do that, with a single level hierarchy. > The domain owner specifies a prefix, ending with a "/". All of the URLs > that are part of the API follow that prefix - they are subordinate in the > hierarchy. > >> > >> Coming back to the main point: What remains in order to find consensus > on this issue? > >> > >> Thanks, > >> Jacob > > -- > > Mark Nottingham https://www.mnot.net/ > > > > _______________________________________________ > > art mailing list > > art@ietf.org > > https://www.ietf.org/mailman/listinfo/art > > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --0000000000004d305f058f2ac971 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This sounds=C2=A0good to me.

thanks,
Rob
<= div>
On= Fri, Aug 2, 2019 at 1:15 PM Adam Roach <adam@nostrum.com> wrote:
jsha@letsencrypt.org> = wrote:
>>
>> On Sat, Jul 27, 2019 at 11:26 PM Larry Masinter <LMM@acm.org> wrote:
>> The use of / in the path of URLs was supposed to
>>
>> be restricted to hierarchical data, and yet CT doesn=E2=80=99t
>> do that.
>>
>> http://masinter.blo= gspot.com/2019/05/on-nature-of-hierarchical-urls.html
>>
>>
>> CT and all prefix-using APIs do that, with a single level hierarch= y. The domain owner specifies a prefix, ending with a "/". All of= the URLs that are part of the API follow that prefix - they are subordinat= e in the hierarchy.
>>
>> Coming back to the main point: What remains in order to find conse= nsus on this issue?
>>
>> Thanks,
>> Jacob
> --
> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art


_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art
--0000000000004d305f058f2ac971-- From nobody Sat Aug 3 05:05:48 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE291201BC for ; Sat, 3 Aug 2019 05:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=0.5] autolearn=ham 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 tFLoaOnuzGxQ for ; Sat, 3 Aug 2019 05:05:44 -0700 (PDT) Received: from webmail.multi.fi (webmail.multi.fi [85.134.37.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFEEA120096 for ; Sat, 3 Aug 2019 05:05:44 -0700 (PDT) Received: from webmail.multi.fi (localhost [IPv6:::1]) by webmail.multi.fi (Postfix) with ESMTPS id 8A5D7180009F for ; Sat, 3 Aug 2019 15:05:41 +0300 (EEST) Received: from [109.240.90.225] ([109.240.90.225]) by webmail.multi.fi (Horde Framework) with HTTPS; Sat, 03 Aug 2019 15:05:41 +0300 Date: Sat, 03 Aug 2019 15:05:41 +0300 Message-ID: <20190803150541.Horde.UvFGBjPHJRjKztlR8THZtGw@webmail.multi.fi> From: Ggh To: art@ietf.org User-Agent: Horde Application Framework 5 Content-Type: multipart/mixed; boundary="=_Z5ihyIs7JMji96DUIxbiGrk" MIME-Version: 1.0 Archived-At: Subject: [art] Fwd: RSS1/RSS2/ATOM/ P2P X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2019 12:05:46 -0000 This message is in MIME format. --=_Z5ihyIs7JMji96DUIxbiGrk Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Tell me, and I forget. Ask me, and I discover... --=_Z5ihyIs7JMji96DUIxbiGrk Content-Type: message/rfc822; name="Forwarded Message" Date: Tue, 23 Jul 2019 15:54:39 +0300 Message-ID: <20190723155439.Horde.dHbtgz6i3J9XENDISknqEq_@webmail.multi.fi> From: Ggh To: art@ietf.org Subject: RSS1/RSS2/ATOM/ P2P Received: from [109.240.234.13] ([109.240.234.13]) by webmail.multi.fi (Horde Framework) with HTTPS; Tue, 23 Jul 2019 15:54:39 +0300 User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Dear All, My name is Greg, and I am new to this list. I have spent some time (a few years) using RSS on the client side, and also server side. I would like to invite all of you to have a constructive critisized discussion regarding RSS1/Atom/RSS2+ and the concept of P2P(Peer to Peer) using them. RSS is not new as such, however the idea of linking RSS-nodes/clients together, the p2p way handling RSS items and feeds, is perhaps. The word is free, lets bounce some ideas forth and back. Thank you, br, Greg Tell me, and I forget. Ask me, and I discover... --=_Z5ihyIs7JMji96DUIxbiGrk-- From nobody Mon Aug 5 08:26:03 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20340120261 for ; Mon, 5 Aug 2019 08:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 YrvRBvVIhAeL for ; Mon, 5 Aug 2019 08:25:49 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 EC9A8120242 for ; Mon, 5 Aug 2019 08:25:48 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:41584) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1huerp-000yqw-dd (Exim 4.92.1) (return-path ); Mon, 05 Aug 2019 16:25:45 +0100 Date: Mon, 5 Aug 2019 16:25:45 +0100 From: Tony Finch To: Mark Nottingham cc: Jacob Hoffman-Andrews , ART Area , Devon O'Brien In-Reply-To: Message-ID: References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [art] On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 15:26:01 -0000 Mark Nottingham wrote: > > The underlying issue is the text in 2.3 of BCP190; I think the emerging > consensus is that it's too strict, in that it can be read to preclude > using a prefix approach with a MUST NOT, when in fact the potential harm > to other applications / the Web overall is pretty small. Yes. Tony. -- f.anthony.n.finch http://dotat.at/ Faeroes, Southeast Iceland: Easterly or northeasterly 4 to 6. Slight or moderate, occasionally rough later. Rain in Faeroes, but mainly fair in Southeast Iceland. Moderate or good, occasionally poor in Faeroes. From nobody Thu Aug 8 15:28:53 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706A512003F for ; Thu, 8 Aug 2019 15:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=comodoca.onmicrosoft.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 7SaFhAMkiemO for ; Thu, 8 Aug 2019 15:28:49 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750072.outbound.protection.outlook.com [40.107.75.72]) (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 8F3C112003E for ; Thu, 8 Aug 2019 15:28:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AuE4Cx1948KGaOCAexfWB6eSZZg68VRn8dzsOk1qgKsBZTii6Hy+Q2MD6uJ0HJKRe6UgcaAjmofEOA7W8kG5vOaKVZ5Unfm36+uRSI+H1MNaB4wn71ucJwaF62lU8TAAyR7HSEUH3xibbnYbPk3jeDfSsPlR57ZEWkgpvKgo7f7D+jYHxS89O2AA9DpteVEImrFEc6v3ELwoWwAoXBxzGytDWI81yB7FDlcuBo+vbZ00E1Ka+pJzZzUaQ3mhOgw7gGTlQGn99LZi8eikgH1PfvsnsrYYCV7xjEEAH47E9l7d4Ez+U3pKqecsvYMeBH5Ix2gJ3n6iRGnFdWc00Y2QZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8seaHjouMUIIvgVybUeM+w9yz3Xx8RvZg4geXJaNHs4=; b=ZXd9lfoD+e1VvJbQlXX5+xmBt0iiOSY9GyBWAaH7ITj2QwyBqDWFNEmUhSIE9HKuF+27bJ+qyWNBhqN7NdqNC1zrXtvos7iR2r85Nxbkzb5gEAOLZKo6OLXTtau/mEebmM/RwnIeF9fdvZLra9N8aJLQuUsFR7v0JbRb9xR5EtV3tb1oCl9h5bpB3t3oQdnEfFYEyVlDFCIbsMGXW09AjhdD9Y9t8DxS6GAk+n6V85pZOAFtDkrPMyxQR8FSfQIijQ4p9jVXRdz2JUwWY+uf7edeTXoAhesa2RXb76Ks0Sw1qaRsboDXjTRmzwgEeIA7ISg+45+C+nRWWZX6TyrsCw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=sectigo.com;dmarc=pass action=none header.from=sectigo.com;dkim=pass header.d=sectigo.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector2-comodoca-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8seaHjouMUIIvgVybUeM+w9yz3Xx8RvZg4geXJaNHs4=; b=Y24QAwFcol6Ig1/EZyA90p/jfDBl52i0mFoq5meSXEwWHxkH0P5CaVai3jgodBauEeE8Q3x2slQnSQtD9DOlQGSi8vcpofITttkcDrLnOgfMIgOWi9Sawao6FWvd1f1SeN+Nro3wdeiCQrP2VP3gTT2LoAyQFZkIjEmAXVeokY0= Received: from DM5PR17MB1211.namprd17.prod.outlook.com (10.173.132.148) by DM5PR17MB0969.namprd17.prod.outlook.com (10.168.115.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Thu, 8 Aug 2019 22:28:46 +0000 Received: from DM5PR17MB1211.namprd17.prod.outlook.com ([fe80::9079:2b0e:ecba:6663]) by DM5PR17MB1211.namprd17.prod.outlook.com ([fe80::9079:2b0e:ecba:6663%9]) with mapi id 15.20.2136.022; Thu, 8 Aug 2019 22:28:46 +0000 From: Rob Stradling To: "art@ietf.org" Thread-Topic: [art] Call for Consensus: Re: On BCP 190 Thread-Index: AQHVTjik4dsE07TQqk2OfPNvmbHpsA== Date: Thu, 8 Aug 2019 22:28:46 +0000 Message-ID: <3b160971-f616-ec5d-e8fd-62c7a034770d@sectigo.com> References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> In-Reply-To: <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P123CA0018.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:a6::30) To DM5PR17MB1211.namprd17.prod.outlook.com (2603:10b6:3:8b::20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rob@sectigo.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2a0e:ac00:25d:300:f68e:38ff:fe7a:a226] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ba242ac9-118d-4226-5c6a-08d71c4fc69b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR17MB0969; x-ms-traffictypediagnostic: DM5PR17MB0969: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 012349AD1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(136003)(39860400002)(366004)(376002)(199004)(189003)(66446008)(5660300002)(446003)(2351001)(46003)(66556008)(476003)(966005)(14454004)(66946007)(186003)(7736002)(11346002)(6512007)(486006)(478600001)(81156014)(8936002)(31686004)(2501003)(305945005)(2616005)(53936002)(8676002)(6246003)(6486002)(1730700003)(25786009)(81166006)(99286004)(36756003)(52116002)(5640700003)(6506007)(53546011)(386003)(31696002)(66476007)(71200400001)(76176011)(6436002)(229853002)(71190400001)(86362001)(102836004)(6116002)(6916009)(2906002)(64756008)(6306002)(14444005)(316002)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR17MB0969; H:DM5PR17MB1211.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: sectigo.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: pS6f1LI9QwxvLXJkGwlZA87qMDsdzprk0fUJdDODk2GsYKodsGGUBF6nWvFP9qh5QI4qEfMefo6d+SYOeMRkhGczTqFjSbYNlhijs1QAm3jmSQQ+Dlz0h2B4VzubHeksoCT3NB7PO76ZKjezapLBD3LagATHDw+3/epF+MAB79uwtVsFlAGitIIKVlm+5Hy6ARDKXGHLNBZqas/r6jrrGskU9jS330SXtboDsWPsytpKophKdfTCftC26J7sHAcQOZZG99D8Ik34TpyIRvDHLQaacBblF4L7svwRWhEwLD9G0o/Nbr3yA51udJu8l6AQO/RrCP9+yXeS07Q5eb+7+NxsdsWvuaCOkCqGNTMuRlZer4jaDcYmT3sXelbrkUm0jPg4zOMXFGXotolADSU2HSZkxvuPrUl8jYWLi33R6QY= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba242ac9-118d-4226-5c6a-08d71c4fc69b X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2019 22:28:46.4065 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0e9c4894-6caa-465d-9660-4b6968b49fb7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: robs@comodoca.net X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR17MB0969 Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 22:28:53 -0000 VGhpcyBzb3VuZHMgZ29vZCB0byBtZS4NCg0KT24gMDIvMDgvMjAxOSAyMToxNSwgQWRhbSBSb2Fj aCB3cm90ZToNCj4gRm9yIHRoZSBwdXJwb3NlcyBvZiBjbGVhcmluZyBteSBkaXNjdXNzLCBJIGlu dGVuZCB0byByZWFkIHRoZSByZXNwb25zZXMgDQo+IHRvIE1hcmsncyBtZXNzYWdlIGJlbG93IGFz IGEgcmVmbGVjdGlvbiBvZiBjb25zZW5zdXMgZnJvbSB0aGUgY29tbXVuaXR5LiANCj4gSWYgeW91 IGhhdmUgdGhvdWdodHMgb24gdGhlIHRvcGljLCBwbGVhc2Ugd2VpZ2ggaW4gb24gdGhlIEFSVC1h cmVhIA0KPiBtYWlsaW5nIGxpc3Qgbm8gbGF0ZXIgdGhhbiBGcmlkYXksIEF1Z3VzdCAxNnRoLg0K PiANCj4gUGVvcGxlIHdobyBoYXZlIHBhcnRpY2lwYXRlZCBpbiB0aGUgZGlzY3Vzc2lvbiBpbiBU UkFOUyBhcmUgdmVyeSBtdWNoIA0KPiB3ZWxjb21lIHRvIHJlLWV4cHJlc3MgdGhlaXIgb3Bpbmlv bnMgaW4gdGhpcyB0aHJlYWQuIEknbSBhbHNvIGhvcGluZyANCj4gdGhhdCB3ZSBnZXQgc29tZSBp bnB1dCBmcm9tIG90aGVyIHBhcnRpY2lwYW50cyAtLSBldmVuIGlmIGl0J3Mgc29tZXRoaW5nIA0K PiBhcyBzaW1wbGUgYXMgInRoaXMgc291bmRzIGdvb2QgdG8gbWUiIC0tIHRvIG1ha2Ugc3VyZSBh bGwgcmVsZXZhbnQgDQo+IHBlcnNwZWN0aXZlcyBhcmUgdGFrZW4gaW50byBhY2NvdW50Lg0KPiAN Cj4gVGhhbmtzIQ0KPiANCj4gL2ENCj4gDQo+IE9uIDgvMi8xOSAxOjU1IFBNLCBNYXJrIE5vdHRp bmdoYW0gd3JvdGU6DQo+PiBJdCBzb3VuZHMgbGlrZSB5b3UgKGNvbGxlY3RpdmVseSkgd2FudCBh biBleGNlcHRpb24gaW4gQkNQMTkwIHN0aWxsLCANCj4+IGNvcnJlY3Q/DQo+Pg0KPj4gSWYgc28s IEkgdGhpbmsgd2UganVzdCBuZWVkIHRvIGNyYWZ0IHNvbWUgbGFuZ3VhZ2UgYWJvdXQgdGhhdCBm b3IgDQo+PiBpbmNsdXNpb24gaW4gdGhlIHNwZWM7IEknZCBpbWFnaW5lIGl0IG5lZWQgb25seSBi ZSBhIHNlbnRlbmNlIG9yIHR3byANCj4+IGFib3V0IGl0LiBUaGVuIHRoZSBBRChzKSBuZWVkIHRv IGNvbnZpbmNlIHRoZW1zZWx2ZXMgdGhhdCBpdCByZWZsZWN0cyANCj4+IGNvbnNlbnN1cy4NCj4+ DQo+PiBUaGUgdW5kZXJseWluZyBpc3N1ZSBpcyB0aGUgdGV4dCBpbiAyLjMgb2YgQkNQMTkwOyBJ IHRoaW5rIHRoZSANCj4+IGVtZXJnaW5nIGNvbnNlbnN1cyBpcyB0aGF0IGl0J3MgdG9vIHN0cmlj dCwgaW4gdGhhdCBpdCBjYW4gYmUgcmVhZCB0byANCj4+IHByZWNsdWRlIHVzaW5nIGEgcHJlZml4 IGFwcHJvYWNoIHdpdGggYSBNVVNUIE5PVCwgd2hlbiBpbiBmYWN0IHRoZSANCj4+IHBvdGVudGlh bCBoYXJtIHRvIG90aGVyIGFwcGxpY2F0aW9ucyAvIHRoZSBXZWIgb3ZlcmFsbCBpcyBwcmV0dHkg c21hbGwuDQo+Pg0KPj4gRG9lcyBhbnlvbmUgZGlzYWdyZWUgd2l0aCB0aGF0Pw0KPj4NCj4+IENo ZWVycywNCj4+DQo+Pg0KPj4+IE9uIDMxIEp1bCAyMDE5LCBhdCAyOjEwIHBtLCBKYWNvYiBIb2Zm bWFuLUFuZHJld3MgDQo+Pj4gPGpzaGFAbGV0c2VuY3J5cHQub3JnPiB3cm90ZToNCj4+Pg0KPj4+ IE9uIFNhdCwgSnVsIDI3LCAyMDE5IGF0IDExOjI2IFBNIExhcnJ5IE1hc2ludGVyIDxMTU1AYWNt Lm9yZz4gd3JvdGU6DQo+Pj4gVGhlIHVzZSBvZiAvIGluIHRoZSBwYXRoIG9mIFVSTHMgd2FzIHN1 cHBvc2VkIHRvDQo+Pj4NCj4+PiBiZSByZXN0cmljdGVkIHRvIGhpZXJhcmNoaWNhbCBkYXRhLCBh bmQgeWV0IENUIGRvZXNu4oCZdA0KPj4+IGRvIHRoYXQuDQo+Pj4NCj4+PiBodHRwOi8vbWFzaW50 ZXIuYmxvZ3Nwb3QuY29tLzIwMTkvMDUvb24tbmF0dXJlLW9mLWhpZXJhcmNoaWNhbC11cmxzLmh0 bWwNCj4+Pg0KPj4+DQo+Pj4gQ1QgYW5kIGFsbCBwcmVmaXgtdXNpbmcgQVBJcyBkbyB0aGF0LCB3 aXRoIGEgc2luZ2xlIGxldmVsIGhpZXJhcmNoeS4gDQo+Pj4gVGhlIGRvbWFpbiBvd25lciBzcGVj aWZpZXMgYSBwcmVmaXgsIGVuZGluZyB3aXRoIGEgIi8iLiBBbGwgb2YgdGhlIA0KPj4+IFVSTHMg dGhhdCBhcmUgcGFydCBvZiB0aGUgQVBJIGZvbGxvdyB0aGF0IHByZWZpeCAtIHRoZXkgYXJlIA0K Pj4+IHN1Ym9yZGluYXRlIGluIHRoZSBoaWVyYXJjaHkuDQo+Pj4NCj4+PiBDb21pbmcgYmFjayB0 byB0aGUgbWFpbiBwb2ludDogV2hhdCByZW1haW5zIGluIG9yZGVyIHRvIGZpbmQgDQo+Pj4gY29u c2Vuc3VzIG9uIHRoaXMgaXNzdWU/DQo+Pj4NCj4+PiBUaGFua3MsDQo+Pj4gSmFjb2INCj4+IC0t IA0KPj4gTWFyayBOb3R0aW5naGFtwqDCoCBodHRwczovL3d3dy5tbm90Lm5ldC8NCg0KLS0gDQpS b2IgU3RyYWRsaW5nDQpTZW5pb3IgUmVzZWFyY2ggJiBEZXZlbG9wbWVudCBTY2llbnRpc3QNClNl Y3RpZ28gTGltaXRlZA0K From nobody Sat Aug 10 21:48:29 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2615912086B; Sat, 10 Aug 2019 21:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 uUvxX_4t5xWg; Sat, 10 Aug 2019 21:47:21 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 1DE78120963; Sat, 10 Aug 2019 18:47:03 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id f17so11677400otq.4; Sat, 10 Aug 2019 18:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wm1pxdiIamoK8SmG37h3KjseWrN4IqXZiAEjZ/8hNPg=; b=YgfNP5QYQiq+q8COAsWTLu6MAv2b+XVFujOdWrmUb4IeBoT4kGUuevXvSBlYVZLud9 Vc8/QBkzo2Rzyo1AQYiDhEgazuO9XKOOn+6RmU00Drkkq5bpdczmq6Sz7b0zSQPWt69i TKIIM9T7XnqOnyrjHOhHQmk+x6VHrV8H2emXyMsrGL7b4htaRJVOXY2b/n1vdymDf5Z4 /gT0z7fRR7opoC6+nZPdhutsnSPh4qEpd6gSbkCG57bbpcYIAdbzcytcyn9qzrXkewGY 6ojqiKEo50t5JHkjodV6H5q6Y3U30jZwxXBf1DuZmszWF7RxTAYiMW4OLQMNhRv2SUma pdaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wm1pxdiIamoK8SmG37h3KjseWrN4IqXZiAEjZ/8hNPg=; b=aQpKSvl5IPJGehg358It+gwaqq0KMGFpWiYKA+UNHqOP1duqgXf2UAJyeN84ENkWgW aVfa3n80aDNUh72vl8s5R1c/PqxikryhoERwAX50jcOQMUuyf1aF9XkcNjNGs75o2aWv 14jg97Cn+iAWZBBNCBv+oQh7gkxuObqhNduGg9uQvKsYbvfisF94jrbXXMTj/BZn8egn cDEOU60xzBvdSIZB16Xov0N/rLGnB9AS2DbJK2bxdZsgF026oBb6RJWtM3bQYGDOLk// y+zSGpiJQZ1s1TyETdyFM1y9ASp33CGLzEK1BfEKezN2Z9mmz8U8Hf8PDDwDaXONB2po mXnA== X-Gm-Message-State: APjAAAWM/BDn8dc8VFTJf/TXnX1BnKw08vuR+EULp9LiuIKBNo/te7lb 3+qRYxaMsN+ltZJO6/JWkjRW0hhrR/hqWTSTUUw= X-Google-Smtp-Source: APXvYqyMz+5iIeR6Vkv6+ZMq4pcs1F+N0ggZFr6AgsL7J3JS5vE9r3r6dr8RmbiojHzzYQ7T7UEHVqo+iQC5F4Y1pZI= X-Received: by 2002:a54:4703:: with SMTP id k3mr10379358oik.143.1565488021266; Sat, 10 Aug 2019 18:47:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:4b14:0:0:0:0:0 with HTTP; Sat, 10 Aug 2019 18:47:00 -0700 (PDT) In-Reply-To: References: <791b33b8-4696-f69c-aca3-8838b2caafd8@sectigo.com> <77F8C1C2AAB5AE251285436F@172.20.2.211> <30deb3a8-c24f-1f38-2701-aa1d68b6adba@nostrum.com> From: Guntur Wiseno Putra Date: Sun, 11 Aug 2019 08:47:00 +0700 Message-ID: To: Adam Roach Cc: John C Klensin , "art@ietf.org" , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006865d9058fcd95e4" Archived-At: Subject: [art] [arch-d] BCP 190, draft-nottingham-for-the-users, and a generalization X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2019 04:48:16 -0000 --0000000000006865d9058fcd95e4 Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss, Such co-presences of which architecture is part of: if we attempt to think of its relation with other human experiences on poetry, on poetics, on a spirit invoked to make comprehensible a poetic fact, to get toward an understanding of cyberspace architecture, of "Liquid Architecture in Cyberspace" (Marcos Novak, 1991) I suggested as a reading to public-informationarchitecture@w3.org at which there is the web-address to the Novak's work (posted at 12 May 2019): http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0ZyT5em5Tg9gBMJh0Aiw@mail.gmail.com;list=public-informationarchitecture Regard, Guntur Wiseno Putra Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra menulis: > Dear architecture-discuss, > & John, > > To share what might be inspiring... > > In order to propose what should be understood as "concept", "percept" & > "affect", thus as "philosophy" & "art", Deleuze & Guattari ("What is > Philosophy?") mentioned architecture as the first art as art begins with > house: that of which "the most scientific architecture continually produces > and unifies planes and sections... it could be defined as "frame" with a > connection among various frames oriented differently, applied to other > arts...(There is) a composite system consisting of points and > counterpoints... (there is) a matter of sensations (percepts and affects) > combined... (While) the system still needs a composition plane run > "deframing" opening ways from house territory to city-cosmos, the system in > which there are cosmic forces to create new affects...". > > There is "asthetic composition" as the working of sensation which is, so > they said, the definition of art... > > Regard, > Guntur Wiseno Putra > > Pada Selasa, 23 Juli 2019, Adam Roach menulis: > >> John -- >> >> It's going to take a while for me to formulate my thoughts around what >> you say below. To make sure I understand the class of constraints you're >> concerned about below, can you clarify whether you think they apply to: >> >> - Documents like BCP 200, RFC 2804, and BCP 188? >> - Documents like BCP 9 and BCP 92? >> - Documents like BCP 25, BCP 54, and BCP 83? >> >> You might see an unstated agenda in the categories of documents I list >> above, so I'll state it explicitly: in the general case, one person's >> important protections against a tragedy of the commons is another person's >> annoying impediment to be ignored and defeated. I get that not all of the >> above read on protocol design; but they do share the common feature that >> they've gone through the IETF consensus process (at least to the degree >> that such a process existed at the time of their respective publications). >> If we're going to carefully parse out the meanings of some of them as the >> will of the community while treating others as light guidelines to be >> ignored when they become cumbersome, we're going to need to agree on a >> pretty bright line that divides those categories. >> >> /a >> >> On 7/23/19 08:37, John C Klensin wrote: >> >> (copying architecture-discuss because the comment I'm about to >> make is an architectural issue and because >> draft-nottingham-for-the-users is under discussion there.) >> >> >> A late colleague, much loved by some of us, used to claim (much >> more elegantly than I can manage) that one of the reasons the >> ARPANET and then the Internet protocols had succeeded and much >> of what was seen as competitive alternatives had not, was that >> our efforts focused on pragmatic, working protocols and >> implementations. >> >> The other folks had developed a culture of formalisms, models, >> and stated design principles. They then tried to develop >> protocols that fit into the boxes and categories of those >> formalisms, models, and design principles. When they >> discovered that something didn't fit, they needed to either >> invent kludges or other ways of getting square pegs into round >> holes, go back and revise models and guidance before moving >> forward, or consider and make exceptions (which often required >> first figuring out how to make an exception and developing >> procedures for that). >> >> One difficulty is that the above can waste a lot of time. >> Another is that it can distort protocol design, if only because >> forcing square pegs into round holes tends to be hard on both >> the pegs and the holes. >> >> In many or most fields of application, the nature of engineering >> involves seeing and understanding a range of tradeoffs and then >> doing design work that reflects a carefully-chosen balance among >> them. Give design elegance absolute priority over structural >> issues and buildings and bridges fall down. IMO, we need to >> think, and keep thinking, about systems and tradeoffs. That, in >> turn, means that statements like these that can be interpreted >> in absolute terms, even if we mostly agree with them, should be >> packaged as general guidelines and not BCPs to which everything >> done in the future is required to either conform or to try to >> figure out how to appeal to a higher authority. >> >> I'm not at all convinced that the proposal that was summarized >> an ARTAREA yesterday and that is seen as requiring an exception >> to BCP 190 is a good idea. But I think our time would be better >> spent, and the Internet more efficiently made better, discussing >> the strengths, weaknesses, and alternatives to that idea rather >> than debating the reach and appropriateness of BCP 190 under >> various circumstances. Long term and more generally, I think >> that suggests seeing BCP 190 not as a particular set of >> principles and rules but as an example of something we don't >> want to do to ourselves again as a BCP (or as something that >> gets enough of an IAB stamp of approval that people will later >> argue MUST (or SHOULD) be conformed to. Again, restated as >> general guidance with the assumption that there will be >> exceptions and cases not considered, I don't have much of a >> problem. If that shoe fits draft-nottingham-for-the-users, >> so be it. >> >> john >> >> p.s. I don't mean to pick on Mark here. While these two >> documents coming up at the same time was handy, I think the >> problem is general and that there are far worse examples >> (examples of which he is not an author) than either of them. >> >> _______________________________________________ >> art mailing listart@ietf.orghttps://www.ietf.org/mailman/listinfo/art >> >> >> --0000000000006865d9058fcd95e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,

Such co-presences of which ar= chitecture is part of: if we attempt to think of its relation with other hu= man experiences on poetry, on poetics, on a spirit invoked to make comprehe= nsible a poetic fact, to get toward an understanding of cyberspace architec= ture, of "Liquid Architecture in Cyberspace" (Marcos Novak, 1991)=


Regard,

Guntur Wiseno = Putra

Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis= :
Dear architecture-discuss,
& Jo= hn,

To share what might be inspiring...

In order to propose what should be understood as "con= cept", "percept" & "affect", thus as "phi= losophy" & "art", Deleuze & Guattari ("What is = Philosophy?") mentioned architecture as the first art as art begins wi= th house: that of which "the most scientific architecture continually = produces and unifies planes and sections... it could be defined as "fr= ame" with a connection among various frames oriented differently, appl= ied to other arts...(There is) a composite system consisting of points and = counterpoints... (there is) a matter of sensations (percepts and affects) c= ombined... (While) the system still needs a composition plane run "def= raming" opening ways from house territory to city-cosmos, the system i= n which there are cosmic forces to create new affects...".
<= br>
There is "asthetic composition" as the working of s= ensation which is, so they said, the definition of art...

Regard,
Guntur Wiseno Putra

Pada Selasa, 23 Juli 2= 019, Adam Roach <a= dam@nostrum.com> menulis:
=20 =20 =20
John --

It's going to take a while for me to formulate my thoughts around what you say below. To make sure I understand the class of constraints you're concerned about below, can you clarify whether you think they apply to:
  • Documents like BCP 200, RFC 2804, and BCP 188?
  • Documents like BCP 9 and BCP 92?
  • Documents like BCP 25, BCP 54, and BCP 83?

You might see an unstated agenda in the categories of documents I list above, so I'll state it explicitly: in the general case, one person's important protections against a tragedy of the commons is another person's annoying impediment to be ignored and defeated. I get that not all of the above read on protocol design; but they do share the common feature that they've gone through the IETF consensus process (at least to the degree that such a process existed at the time of their respective publications). If we're going to carefully parse out the meanings of some of them as the will of the community while treating others as light guidelines to be ignored when they become cumbersome, we're going to need to agree on a pretty bright line that divides those categories.

/a


On 7/23/19 08:37, John C Klensin wrote:
(copying architecture-discuss because the comment I'm about =
to
make is an architectural issue and because
draft-nottingham-for-the-users is under discussion there.)


A late colleague, much loved by some of us, used to claim (much
more elegantly than I can manage) that one of the reasons the
ARPANET and then the Internet protocols had succeeded and much
of what was seen as competitive alternatives had not, was that
our efforts focused on pragmatic, working protocols and
implementations. =20

The other folks had developed a culture of formalisms, models,
and stated design principles.  They then tried to develop
protocols that fit into the boxes and categories of those
formalisms, models, and design principles.    When they
discovered that something didn't fit, they needed to either
invent kludges or other ways of getting square pegs into round
holes, go back and revise models and guidance before moving
forward, or consider and make exceptions (which often required
first figuring out how to make an exception and developing
procedures for that).

One difficulty is that the above can waste a lot of time.
Another is that it can distort protocol design, if only because
forcing square pegs into round holes tends to be hard on both
the pegs and the holes.

In many or most fields of application, the nature of engineering
involves seeing and understanding a range of tradeoffs and then
doing design work that reflects a carefully-chosen balance among
them.  Give design elegance absolute priority over structural
issues and buildings and bridges fall down.  IMO, we need to
think, and keep thinking, about systems and tradeoffs.  That, in
turn, means that statements like these that can be interpreted
in absolute terms, even if we mostly agree with them, should be
packaged as general guidelines and not BCPs to which everything
done in the future is required to either conform or to try to
figure out how to appeal to a higher authority.

I'm not at all convinced that the proposal that was summarized
an ARTAREA yesterday and that is seen as requiring an exception
to BCP 190 is a good idea.  But I think our time would be better
spent, and the Internet more efficiently made better, discussing
the strengths, weaknesses, and alternatives to that idea rather
than debating the reach and appropriateness of BCP 190 under
various circumstances.   Long term and more generally, I think
that suggests seeing BCP 190 not as a particular set of
principles and rules but as an example of something we don't
want to do to ourselves again as a BCP (or as something that
gets enough of an IAB stamp of approval that people will later
argue MUST (or SHOULD) be conformed to.  Again, restated as
general guidance with the assumption that there will be
exceptions and cases not considered, I don't have much of a
problem.    If that shoe fits  draft-nottingham-for-the-users,
so be it.

   john

p.s. I don't mean to pick on Mark here.   While these two
documents coming up at the same time was handy, I think the
problem is general and that there are far worse examples
(examples of which he is not an author) than either of them.

_______________________________________________
art mailing list
art@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/art


--0000000000006865d9058fcd95e4-- From nobody Sat Aug 10 23:37:49 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADD412084F; Sat, 10 Aug 2019 23:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 WyqjnJV69LXV; Sat, 10 Aug 2019 23:36:51 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 456FF120895; Sat, 10 Aug 2019 20:06:42 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id f17so11991289otq.4; Sat, 10 Aug 2019 20:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YNi1tLaD+tL97L6kx6ITpUjBB7XP5loFJ/mPxRcIFjg=; b=UVfDQ3ZijbTnsnUDAuywChfm5hTfzvR2+Atc3Kvdx2oCMLGX6+R3rfBOaHtVGzS5BV QW6yt7zF4YRYLQBZ2JCQHAZdUBmbPGx3hQ8JgpQpEr7++deV6+pDRD95SyqUUYAvb6vM VTXv4+XBouhjRmhYqYZ/PljSnUaQzXeKH27aucc76sj8sxvpj9DcA5nAgQ0jW+2mMMqO 27mCdlGnb3xELd4p8ZcT4pDJ6zgOtxZqoERyMTmh4eN55is//iu71SeQQM1lAeOMlVHh xl6EhFzqVaBxpbSAW+cK2n+jyN6udd3WXsu71f7Gefc4NZCJ9ao6xWXsy2gRL21VR/ng XmEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YNi1tLaD+tL97L6kx6ITpUjBB7XP5loFJ/mPxRcIFjg=; b=lD+irMAgXBKqTKRFyI3H6Bx3fmwMf2vp3sXCkaRyVimANZBWkPx63CqWeWLzSqVY2d t+TT71uSrfkI5LjmDueZtJ0A+EOdeYBI1mWLZpd3Yk/L4/NYISPn05S2TRETEEy+nPUn BWr/RQSJ13q2dwRCHgT8+ruWm4cHMjHQ9Gofqct0ZzszcXEdNHWGjug0wIvgtfTw9hLW RoupmfyQPf1YTvNZ2wIpMYfInxJYcsM/vz8oy6q8dcK428hgyG1gF63sCdXf6RFRyS7U 5woDJi2ncHOZq/+Fp797oKydB5xxhfkCzcjx33z8ulj6ryWB+bN2b2XQnLhFq+Y/tcG0 us9w== X-Gm-Message-State: APjAAAXxwfxc90Is3zhjSaB8AkKoMFc0cDo9JqBsj55Cv6XPisLVEAC+ IxrafHXvfxxYRpn9X3hi8Q36w/iyNvFbKcihBvY= X-Google-Smtp-Source: APXvYqye9SrId5sA0I4wgPRn+CjjgyC9hbiTzAQJnYE8dKoNllMIH3p+FhlwZK2DsndYS4VMHkgqo4/JDXezgXUqp5U= X-Received: by 2002:aca:b104:: with SMTP id a4mr10314516oif.90.1565492801328; Sat, 10 Aug 2019 20:06:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:4b14:0:0:0:0:0 with HTTP; Sat, 10 Aug 2019 20:06:40 -0700 (PDT) In-Reply-To: References: <791b33b8-4696-f69c-aca3-8838b2caafd8@sectigo.com> <77F8C1C2AAB5AE251285436F@172.20.2.211> <30deb3a8-c24f-1f38-2701-aa1d68b6adba@nostrum.com> From: Guntur Wiseno Putra Date: Sun, 11 Aug 2019 10:06:40 +0700 Message-ID: To: Adam Roach Cc: John C Klensin , "art@ietf.org" , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000525b10058fceb259" Archived-At: Subject: [art] [arch-d] BCP 190, draft-nottingham-for-the-users, and a generalization X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2019 06:37:48 -0000 --000000000000525b10058fceb259 Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss, An alternative link to the posting on Marcos Nocak'S "Liquid Architecture in Cyberspace" at public@informationarchitecture@w3.org I mentioned earlier is https://lists.w3.org/Archives/Public/public-informationarchitecture/2019May/0000.html (which was "403 Forbidden: Request forbidden by administrative rules" the last time I checked up minutes ago) Or, if going directly toward the text: https:///www.evl.uic.edu/datsoupi/coding/readings/Marcos_Novak_ Liquid.pdf Thank to Martin Dodge for suggesting Marcos Novak's architecture in www.cybergeography.org bringing me to Daria Tsoupukiva's lecture providing the reading... Regard, Gubtur Wiseno Putra Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra menulis: > Dear architecture-discuss, > > Such co-presences of which architecture is part of: if we attempt to think > of its relation with other human experiences on poetry, on poetics, on a > spirit invoked to make comprehensible a poetic fact, to get toward an > understanding of cyberspace architecture, of "Liquid Architecture in > Cyberspace" (Marcos Novak, 1991) > > I suggested as a reading to public-informationarchitecture@w3.org at > which there is the web-address to the Novak's work (posted at 12 May 2019): > > http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0Zy > T5em5Tg9gBMJh0Aiw@mail.gmail.com;list=public-informationarchitecture > Regard, > > Guntur Wiseno Putra > > Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra menulis: > >> Dear architecture-discuss, >> & John, >> >> To share what might be inspiring... >> >> In order to propose what should be understood as "concept", "percept" & >> "affect", thus as "philosophy" & "art", Deleuze & Guattari ("What is >> Philosophy?") mentioned architecture as the first art as art begins with >> house: that of which "the most scientific architecture continually produces >> and unifies planes and sections... it could be defined as "frame" with a >> connection among various frames oriented differently, applied to other >> arts...(There is) a composite system consisting of points and >> counterpoints... (there is) a matter of sensations (percepts and affects) >> combined... (While) the system still needs a composition plane run >> "deframing" opening ways from house territory to city-cosmos, the system in >> which there are cosmic forces to create new affects...". >> >> There is "asthetic composition" as the working of sensation which is, so >> they said, the definition of art... >> >> Regard, >> Guntur Wiseno Putra >> >> Pada Selasa, 23 Juli 2019, Adam Roach menulis: >> >>> John -- >>> >>> It's going to take a while for me to formulate my thoughts around what >>> you say below. To make sure I understand the class of constraints you're >>> concerned about below, can you clarify whether you think they apply to: >>> >>> - Documents like BCP 200, RFC 2804, and BCP 188? >>> - Documents like BCP 9 and BCP 92? >>> - Documents like BCP 25, BCP 54, and BCP 83? >>> >>> You might see an unstated agenda in the categories of documents I list >>> above, so I'll state it explicitly: in the general case, one person's >>> important protections against a tragedy of the commons is another person's >>> annoying impediment to be ignored and defeated. I get that not all of the >>> above read on protocol design; but they do share the common feature that >>> they've gone through the IETF consensus process (at least to the degree >>> that such a process existed at the time of their respective publications). >>> If we're going to carefully parse out the meanings of some of them as the >>> will of the community while treating others as light guidelines to be >>> ignored when they become cumbersome, we're going to need to agree on a >>> pretty bright line that divides those categories. >>> >>> /a >>> >>> On 7/23/19 08:37, John C Klensin wrote: >>> >>> (copying architecture-discuss because the comment I'm about to >>> make is an architectural issue and because >>> draft-nottingham-for-the-users is under discussion there.) >>> >>> >>> A late colleague, much loved by some of us, used to claim (much >>> more elegantly than I can manage) that one of the reasons the >>> ARPANET and then the Internet protocols had succeeded and much >>> of what was seen as competitive alternatives had not, was that >>> our efforts focused on pragmatic, working protocols and >>> implementations. >>> >>> The other folks had developed a culture of formalisms, models, >>> and stated design principles. They then tried to develop >>> protocols that fit into the boxes and categories of those >>> formalisms, models, and design principles. When they >>> discovered that something didn't fit, they needed to either >>> invent kludges or other ways of getting square pegs into round >>> holes, go back and revise models and guidance before moving >>> forward, or consider and make exceptions (which often required >>> first figuring out how to make an exception and developing >>> procedures for that). >>> >>> One difficulty is that the above can waste a lot of time. >>> Another is that it can distort protocol design, if only because >>> forcing square pegs into round holes tends to be hard on both >>> the pegs and the holes. >>> >>> In many or most fields of application, the nature of engineering >>> involves seeing and understanding a range of tradeoffs and then >>> doing design work that reflects a carefully-chosen balance among >>> them. Give design elegance absolute priority over structural >>> issues and buildings and bridges fall down. IMO, we need to >>> think, and keep thinking, about systems and tradeoffs. That, in >>> turn, means that statements like these that can be interpreted >>> in absolute terms, even if we mostly agree with them, should be >>> packaged as general guidelines and not BCPs to which everything >>> done in the future is required to either conform or to try to >>> figure out how to appeal to a higher authority. >>> >>> I'm not at all convinced that the proposal that was summarized >>> an ARTAREA yesterday and that is seen as requiring an exception >>> to BCP 190 is a good idea. But I think our time would be better >>> spent, and the Internet more efficiently made better, discussing >>> the strengths, weaknesses, and alternatives to that idea rather >>> than debating the reach and appropriateness of BCP 190 under >>> various circumstances. Long term and more generally, I think >>> that suggests seeing BCP 190 not as a particular set of >>> principles and rules but as an example of something we don't >>> want to do to ourselves again as a BCP (or as something that >>> gets enough of an IAB stamp of approval that people will later >>> argue MUST (or SHOULD) be conformed to. Again, restated as >>> general guidance with the assumption that there will be >>> exceptions and cases not considered, I don't have much of a >>> problem. If that shoe fits draft-nottingham-for-the-users, >>> so be it. >>> >>> john >>> >>> p.s. I don't mean to pick on Mark here. While these two >>> documents coming up at the same time was handy, I think the >>> problem is general and that there are far worse examples >>> (examples of which he is not an author) than either of them. >>> >>> _______________________________________________ >>> art mailing listart@ietf.orghttps://www.ietf.org/mailman/listinfo/art >>> >>> >>> --000000000000525b10058fceb259 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,

An alternative link to the po= sting on Marcos Nocak'S "Liquid Architecture in Cyberspace" a= t public@informationarchitecture@w3.org=C2=A0 I mentioned earlier is


(which was = "403 Forbidden: Request forbidden by administrative rules" the la= st time I checked up minutes ago)

Or, if going dir= ectly toward the text:


=
Thank to Martin Dodge for suggesting Marcos Novak's architecture i= n www.cybergeography.org brin= ging me to Daria Tsoupukiva's lecture providing the reading...

Regard,
Gubtur Wiseno Putra

Pada Minggu, = 11 Agustus 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,

Such co-presen= ces of which architecture is part of: if we attempt to think of its relatio= n with other human experiences on poetry, on poetics, on a spirit invoked t= o make comprehensible a poetic fact, to get toward an understanding of cybe= rspace architecture, of "Liquid Architecture in Cyberspace" (Marc= os Novak, 1991)

I suggested as a reading to public= -informationarchitecture@w3.org at which there is the web-address = to the Novak's work (posted at 12 May 2019):

<= a href=3D"http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0ZyT5em5= Tg9gBMJh0Aiw@mail.gmail.com;list=3Dpublic-informationarchitecture" target= =3D"_blank">http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0= ZyT5em5Tg9gBMJh0Aiw@mail.gmail.com;list=3Dpublic-informationarchitecture
Regard,

Guntur Wise= no Putra

Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menu= lis:
Dear architecture-discuss,
&= John,

To share what might be inspiring...
=

In order to propose what should be understood as "= concept", "percept" & "affect", thus as "= philosophy" & "art", Deleuze & Guattari ("What = is Philosophy?") mentioned architecture as the first art as art begins= with house: that of which "the most scientific architecture continual= ly produces and unifies planes and sections... it could be defined as "= ;frame" with a connection among various frames oriented differently, a= pplied to other arts...(There is) a composite system consisting of points a= nd counterpoints... (there is) a matter of sensations (percepts and affects= ) combined... (While) the system still needs a composition plane run "= deframing" opening ways from house territory to city-cosmos, the syste= m in which there are cosmic forces to create new affects...".

There is "asthetic composition" as the working o= f sensation which is, so they said, the definition of art...

=
Regard,
Guntur Wiseno Putra

Pada Selasa, 23 Jul= i 2019, Adam Roach <adam@nostrum.com> menulis:
=20 =20 =20
John --

It's going to take a while for me to formulate my thoughts around what you say below. To make sure I understand the class of constraints you're concerned about below, can you clarify whether you think they apply to:
  • Documents like BCP 200, RFC 2804, and BCP 188?
  • Documents like BCP 9 and BCP 92?
  • Documents like BCP 25, BCP 54, and BCP 83?

You might see an unstated agenda in the categories of documents I list above, so I'll state it explicitly: in the general case, one person's important protections against a tragedy of the commons is another person's annoying impediment to be ignored and defeated. I get that not all of the above read on protocol design; but they do share the common feature that they've gone through the IETF consensus process (at least to the degree that such a process existed at the time of their respective publications). If we're going to carefully parse out the meanings of some of them as the will of the community while treating others as light guidelines to be ignored when they become cumbersome, we're going to need to agree on a pretty bright line that divides those categories.

/a


On 7/23/19 08:37, John C Klensin wrote:
(copying architecture-discuss because the comment I'm about =
to
make is an architectural issue and because
draft-nottingham-for-the-users is under discussion there.)


A late colleague, much loved by some of us, used to claim (much
more elegantly than I can manage) that one of the reasons the
ARPANET and then the Internet protocols had succeeded and much
of what was seen as competitive alternatives had not, was that
our efforts focused on pragmatic, working protocols and
implementations. =20

The other folks had developed a culture of formalisms, models,
and stated design principles.  They then tried to develop
protocols that fit into the boxes and categories of those
formalisms, models, and design principles.    When they
discovered that something didn't fit, they needed to either
invent kludges or other ways of getting square pegs into round
holes, go back and revise models and guidance before moving
forward, or consider and make exceptions (which often required
first figuring out how to make an exception and developing
procedures for that).

One difficulty is that the above can waste a lot of time.
Another is that it can distort protocol design, if only because
forcing square pegs into round holes tends to be hard on both
the pegs and the holes.

In many or most fields of application, the nature of engineering
involves seeing and understanding a range of tradeoffs and then
doing design work that reflects a carefully-chosen balance among
them.  Give design elegance absolute priority over structural
issues and buildings and bridges fall down.  IMO, we need to
think, and keep thinking, about systems and tradeoffs.  That, in
turn, means that statements like these that can be interpreted
in absolute terms, even if we mostly agree with them, should be
packaged as general guidelines and not BCPs to which everything
done in the future is required to either conform or to try to
figure out how to appeal to a higher authority.

I'm not at all convinced that the proposal that was summarized
an ARTAREA yesterday and that is seen as requiring an exception
to BCP 190 is a good idea.  But I think our time would be better
spent, and the Internet more efficiently made better, discussing
the strengths, weaknesses, and alternatives to that idea rather
than debating the reach and appropriateness of BCP 190 under
various circumstances.   Long term and more generally, I think
that suggests seeing BCP 190 not as a particular set of
principles and rules but as an example of something we don't
want to do to ourselves again as a BCP (or as something that
gets enough of an IAB stamp of approval that people will later
argue MUST (or SHOULD) be conformed to.  Again, restated as
general guidance with the assumption that there will be
exceptions and cases not considered, I don't have much of a
problem.    If that shoe fits  draft-nottingham-for-the-users,
so be it.

   john

p.s. I don't mean to pick on Mark here.   While these two
documents coming up at the same time was handy, I think the
problem is general and that there are far worse examples
(examples of which he is not an author) than either of them.

_______________________________________________
art mailing list
art@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/art


--000000000000525b10058fceb259-- From nobody Sun Aug 11 00:01:15 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AF9120A88; Sun, 11 Aug 2019 00:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 aJYiJwHr9eqR; Sun, 11 Aug 2019 00:00:00 -0700 (PDT) Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (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 9FA741209A3; Sat, 10 Aug 2019 20:19:34 -0700 (PDT) Received: by mail-ot1-x342.google.com with SMTP id c34so7420708otb.7; Sat, 10 Aug 2019 20:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bjy+NdozKFHqXYH3JVWGJKqHq745Mb2Z37WWFdM9JWI=; b=fTM4bxjkzqOb3nn8WoH5w7adA5W8PZSjF//gYrosGJdmWAguF0uFTE+pAHPQ5hqQ+C 1Bf6dn/p+r7Yb23gji26yeoCz82uvcrEgdmtUJVcL/ZsBmv0wMrJxKnNzDofPs9d6Izq KBjNxsEKYi7Z4pjHHSoj4UhXuUZv7B5wacLYGSGOy1GJofmE88OCu6FANUJqlA+DxreU I+r9s47FvuV5YIvL89Ifspvp0RjZx+W0SjeOOigc3G7txJuse2yDY8WRtGWSVkwzoDBz b+Cr5jS7h0NJ5FR46gcvQaYdwPGtdWnvRzUPbsbunlk6Cb2VDoqMMTBKE4iIS5C4GqVY XgHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bjy+NdozKFHqXYH3JVWGJKqHq745Mb2Z37WWFdM9JWI=; b=CfNB9OkDLtih+sImau5VslSOQeD1FUu91rkYc9NNHYH2n9TGGQD5S58FDUWhHENJJn TtkIqCkNvIcb8n2SYmiGM3uOZD9dAjpM2hAXcD8K0z3J/yq2k17Sq8vYguHxUIortVg8 sbJ23ghpsdS+38gQ109FCjBaOj+7pTBJc72kDOI4c6L+eV+Xabk5PG43bhVvBy1O8Pn+ hp2v6PLWHtTuUj+2/rtWKFn+ckWOkaOwK9E9604FNkeEdLc7HjUTSOxP6wQbEeXMqLw2 96x0EmGPEXY1722M7KFXgVECg0f+z4meAY0D7rXytcTJiYNAsPouP9n+6rbBUhY01f8K Ocdg== X-Gm-Message-State: APjAAAVL6XoJw2jHc3t1nEyGkDgi+VyuwnoRkMoAIdMZ+gvFy2JX//jX lowPusXOgebR98F6JaHXtIDFUVm13XtXJWa2PhY= X-Google-Smtp-Source: APXvYqxAuXt9HYn5pOPVFwvi2Pd+GLSAAYfXOsUQCSVXeeGWKcngPiLyPUMdTidUy+YIP9zIoBBa3LnQhE0+UdFgqHA= X-Received: by 2002:aca:72c7:: with SMTP id p190mr7226909oic.9.1565493573825; Sat, 10 Aug 2019 20:19:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:4b14:0:0:0:0:0 with HTTP; Sat, 10 Aug 2019 20:19:33 -0700 (PDT) In-Reply-To: References: <791b33b8-4696-f69c-aca3-8838b2caafd8@sectigo.com> <77F8C1C2AAB5AE251285436F@172.20.2.211> <30deb3a8-c24f-1f38-2701-aa1d68b6adba@nostrum.com> From: Guntur Wiseno Putra Date: Sun, 11 Aug 2019 10:19:33 +0700 Message-ID: To: Adam Roach Cc: John C Klensin , "art@ietf.org" , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005db9dd058fcee067" Archived-At: Subject: Re: [art] [arch-d] BCP 190, draft-nottingham-for-the-users, and a generalization X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2019 07:01:08 -0000 --0000000000005db9dd058fcee067 Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss, Forgive me for typing errors in previous message... An alternative link to the posting on Marcos Novak's "Liquid Architecture in Cyberspace" at public@informationarchitecture@w3.org I mentioned earlier is https://lists.w3.org/Archives/Public/public-informationarchitecture/ 2019May/0000.html (which was "403 Forbidden: Request forbidden by administrative rules" the last time I checked up minutes ago) Or, if going directly toward the text: https://www.evl.uic.edu/datsoupi/coding/readings/1991_Novak_Liquid.pdf Thank to Martin Dodge for suggesting Marcos Novak's architecture in www.cybergeography.org bringing me to Daria Tsoupukiva's lecture providing the reading... Regard, Guntur Wiseno Putra Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra menulis: > Dear architecture-discuss, > > An alternative link to the posting on Marcos Nocak'S "Liquid Architecture > in Cyberspace" at public@informationarchitecture@w3.org I mentioned > earlier is > > https://lists.w3.org/Archives/Public/public-informationarchitecture/ > 2019May/0000.html > > (which was "403 Forbidden: Request forbidden by administrative rules" the > last time I checked up minutes ago) > > Or, if going directly toward the text: > > https:///www.evl.uic.edu/datsoupi/coding/readings/Marcos_Novak_ Liquid.pdf > > Thank to Martin Dodge for suggesting Marcos Novak's architecture in > www.cybergeography.org bringing me to Daria Tsoupukiva's lecture > providing the reading... > > Regard, > Gubtur Wiseno Putra > > Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra > menulis: > >> Dear architecture-discuss, >> >> Such co-presences of which architecture is part of: if we attempt to >> think of its relation with other human experiences on poetry, on poetics, >> on a spirit invoked to make comprehensible a poetic fact, to get toward an >> understanding of cyberspace architecture, of "Liquid Architecture in >> Cyberspace" (Marcos Novak, 1991) >> >> I suggested as a reading to public-informationarchitecture@w3.org at >> which there is the web-address to the Novak's work (posted at 12 May 2019): >> >> http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0Zy >> T5em5Tg9gBMJh0Aiw@mail.gmail.com;list=public-informationarchitecture >> Regard, >> >> Guntur Wiseno Putra >> >> Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra menulis: >> >>> Dear architecture-discuss, >>> & John, >>> >>> To share what might be inspiring... >>> >>> In order to propose what should be understood as "concept", "percept" & >>> "affect", thus as "philosophy" & "art", Deleuze & Guattari ("What is >>> Philosophy?") mentioned architecture as the first art as art begins with >>> house: that of which "the most scientific architecture continually produces >>> and unifies planes and sections... it could be defined as "frame" with a >>> connection among various frames oriented differently, applied to other >>> arts...(There is) a composite system consisting of points and >>> counterpoints... (there is) a matter of sensations (percepts and affects) >>> combined... (While) the system still needs a composition plane run >>> "deframing" opening ways from house territory to city-cosmos, the system in >>> which there are cosmic forces to create new affects...". >>> >>> There is "asthetic composition" as the working of sensation which is, so >>> they said, the definition of art... >>> >>> Regard, >>> Guntur Wiseno Putra >>> >>> Pada Selasa, 23 Juli 2019, Adam Roach menulis: >>> >>>> John -- >>>> >>>> It's going to take a while for me to formulate my thoughts around what >>>> you say below. To make sure I understand the class of constraints you're >>>> concerned about below, can you clarify whether you think they apply to: >>>> >>>> - Documents like BCP 200, RFC 2804, and BCP 188? >>>> - Documents like BCP 9 and BCP 92? >>>> - Documents like BCP 25, BCP 54, and BCP 83? >>>> >>>> You might see an unstated agenda in the categories of documents I list >>>> above, so I'll state it explicitly: in the general case, one person's >>>> important protections against a tragedy of the commons is another person's >>>> annoying impediment to be ignored and defeated. I get that not all of the >>>> above read on protocol design; but they do share the common feature that >>>> they've gone through the IETF consensus process (at least to the degree >>>> that such a process existed at the time of their respective publications). >>>> If we're going to carefully parse out the meanings of some of them as the >>>> will of the community while treating others as light guidelines to be >>>> ignored when they become cumbersome, we're going to need to agree on a >>>> pretty bright line that divides those categories. >>>> >>>> /a >>>> >>>> On 7/23/19 08:37, John C Klensin wrote: >>>> >>>> (copying architecture-discuss because the comment I'm about to >>>> make is an architectural issue and because >>>> draft-nottingham-for-the-users is under discussion there.) >>>> >>>> >>>> A late colleague, much loved by some of us, used to claim (much >>>> more elegantly than I can manage) that one of the reasons the >>>> ARPANET and then the Internet protocols had succeeded and much >>>> of what was seen as competitive alternatives had not, was that >>>> our efforts focused on pragmatic, working protocols and >>>> implementations. >>>> >>>> The other folks had developed a culture of formalisms, models, >>>> and stated design principles. They then tried to develop >>>> protocols that fit into the boxes and categories of those >>>> formalisms, models, and design principles. When they >>>> discovered that something didn't fit, they needed to either >>>> invent kludges or other ways of getting square pegs into round >>>> holes, go back and revise models and guidance before moving >>>> forward, or consider and make exceptions (which often required >>>> first figuring out how to make an exception and developing >>>> procedures for that). >>>> >>>> One difficulty is that the above can waste a lot of time. >>>> Another is that it can distort protocol design, if only because >>>> forcing square pegs into round holes tends to be hard on both >>>> the pegs and the holes. >>>> >>>> In many or most fields of application, the nature of engineering >>>> involves seeing and understanding a range of tradeoffs and then >>>> doing design work that reflects a carefully-chosen balance among >>>> them. Give design elegance absolute priority over structural >>>> issues and buildings and bridges fall down. IMO, we need to >>>> think, and keep thinking, about systems and tradeoffs. That, in >>>> turn, means that statements like these that can be interpreted >>>> in absolute terms, even if we mostly agree with them, should be >>>> packaged as general guidelines and not BCPs to which everything >>>> done in the future is required to either conform or to try to >>>> figure out how to appeal to a higher authority. >>>> >>>> I'm not at all convinced that the proposal that was summarized >>>> an ARTAREA yesterday and that is seen as requiring an exception >>>> to BCP 190 is a good idea. But I think our time would be better >>>> spent, and the Internet more efficiently made better, discussing >>>> the strengths, weaknesses, and alternatives to that idea rather >>>> than debating the reach and appropriateness of BCP 190 under >>>> various circumstances. Long term and more generally, I think >>>> that suggests seeing BCP 190 not as a particular set of >>>> principles and rules but as an example of something we don't >>>> want to do to ourselves again as a BCP (or as something that >>>> gets enough of an IAB stamp of approval that people will later >>>> argue MUST (or SHOULD) be conformed to. Again, restated as >>>> general guidance with the assumption that there will be >>>> exceptions and cases not considered, I don't have much of a >>>> problem. If that shoe fits draft-nottingham-for-the-users, >>>> so be it. >>>> >>>> john >>>> >>>> p.s. I don't mean to pick on Mark here. While these two >>>> documents coming up at the same time was handy, I think the >>>> problem is general and that there are far worse examples >>>> (examples of which he is not an author) than either of them. >>>> >>>> _______________________________________________ >>>> art mailing listart@ietf.orghttps://www.ietf.org/mailman/listinfo/art >>>> >>>> >>>> --0000000000005db9dd058fcee067 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,

Forgive me for typing = errors in previous message...

An alternative link to the posting on Marcos Novak's "Liqu= id Architecture in Cyberspace" at public@informationarchitecture@w3.org=C2=A0I me= ntioned earlier is


=
(which was "403 Forbidden: Request forbidden by administra= tive rules" the last time I checked up minutes ago)

Or, if going directly toward the text:


=
Thank to Martin Dodge for suggesting Marcos Novak's archite= cture in=C2=A0= www.cybergeography.org=C2=A0bringing me to Daria Tsoupukiva's lectu= re providing the reading...


<= br>
Regard,
Guntur Wiseno Putra

Pada Minggu, 11 = Agustus 2019, Guntur Wiseno Putra <= gsenopu@gmail.com> menulis:
Dear a= rchitecture-discuss,

An alternative link to the posting = on Marcos Nocak'S "Liquid Architecture in Cyberspace" at publ= ic@informationarchitecture@w3.org=C2=A0 I mentioned earlier is


(which was "403 Forbidden: Request forbidden by admi= nistrative rules" the last time I checked up minutes ago)
Or, if going directly toward the text:


Thank to Mart= in Dodge for suggesting Marcos Novak's architecture in www.cybergeography.org brin= ging me to Daria Tsoupukiva's lecture providing the reading...

Regard,
Gubtur Wiseno Putra

Pada Minggu, = 11 Agustus 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,

Such co-presen= ces of which architecture is part of: if we attempt to think of its relatio= n with other human experiences on poetry, on poetics, on a spirit invoked t= o make comprehensible a poetic fact, to get toward an understanding of cybe= rspace architecture, of "Liquid Architecture in Cyberspace" (Marc= os Novak, 1991)

I suggested as a reading to public= -informationarchitecture@w3.org at which there is the web-address = to the Novak's work (posted at 12 May 2019):

<= a href=3D"http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0ZyT5em5= Tg9gBMJh0Aiw@mail.gmail.com;list=3Dpublic-informationarchitecture" target= =3D"_blank">http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0= ZyT5em5Tg9gBMJh0Aiw@mail.gmail.com;list=3Dpublic-informationarch<= wbr>itecture
Regard,

Guntur Wise= no Putra

Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menu= lis:
Dear architecture-discuss,
&= John,

To share what might be inspiring...
=

In order to propose what should be understood as "= concept", "percept" & "affect", thus as "= philosophy" & "art", Deleuze & Guattari ("What = is Philosophy?") mentioned architecture as the first art as art begins= with house: that of which "the most scientific architecture continual= ly produces and unifies planes and sections... it could be defined as "= ;frame" with a connection among various frames oriented differently, a= pplied to other arts...(There is) a composite system consisting of points a= nd counterpoints... (there is) a matter of sensations (percepts and affects= ) combined... (While) the system still needs a composition plane run "= deframing" opening ways from house territory to city-cosmos, the syste= m in which there are cosmic forces to create new affects...".

There is "asthetic composition" as the working o= f sensation which is, so they said, the definition of art...

=
Regard,
Guntur Wiseno Putra

Pada Selasa, 23 Jul= i 2019, Adam Roach <adam@nostrum.com> menulis:
=20 =20 =20
John --

It's going to take a while for me to formulate my thoughts around what you say below. To make sure I understand the class of constraints you're concerned about below, can you clarify whether you think they apply to:
  • Documents like BCP 200, RFC 2804, and BCP 188?
  • Documents like BCP 9 and BCP 92?
  • Documents like BCP 25, BCP 54, and BCP 83?

You might see an unstated agenda in the categories of documents I list above, so I'll state it explicitly: in the general case, one person's important protections against a tragedy of the commons is another person's annoying impediment to be ignored and defeated. I get that not all of the above read on protocol design; but they do share the common feature that they've gone through the IETF consensus process (at least to the degree that such a process existed at the time of their respective publications). If we're going to carefully parse out the meanings of some of them as the will of the community while treating others as light guidelines to be ignored when they become cumbersome, we're going to need to agree on a pretty bright line that divides those categories.

/a


On 7/23/19 08:37, John C Klensin wrote:
(copying architecture-discuss because the comment I'm about =
to
make is an architectural issue and because
draft-nottingham-for-the-users is under discussion there.)


A late colleague, much loved by some of us, used to claim (much
more elegantly than I can manage) that one of the reasons the
ARPANET and then the Internet protocols had succeeded and much
of what was seen as competitive alternatives had not, was that
our efforts focused on pragmatic, working protocols and
implementations. =20

The other folks had developed a culture of formalisms, models,
and stated design principles.  They then tried to develop
protocols that fit into the boxes and categories of those
formalisms, models, and design principles.    When they
discovered that something didn't fit, they needed to either
invent kludges or other ways of getting square pegs into round
holes, go back and revise models and guidance before moving
forward, or consider and make exceptions (which often required
first figuring out how to make an exception and developing
procedures for that).

One difficulty is that the above can waste a lot of time.
Another is that it can distort protocol design, if only because
forcing square pegs into round holes tends to be hard on both
the pegs and the holes.

In many or most fields of application, the nature of engineering
involves seeing and understanding a range of tradeoffs and then
doing design work that reflects a carefully-chosen balance among
them.  Give design elegance absolute priority over structural
issues and buildings and bridges fall down.  IMO, we need to
think, and keep thinking, about systems and tradeoffs.  That, in
turn, means that statements like these that can be interpreted
in absolute terms, even if we mostly agree with them, should be
packaged as general guidelines and not BCPs to which everything
done in the future is required to either conform or to try to
figure out how to appeal to a higher authority.

I'm not at all convinced that the proposal that was summarized
an ARTAREA yesterday and that is seen as requiring an exception
to BCP 190 is a good idea.  But I think our time would be better
spent, and the Internet more efficiently made better, discussing
the strengths, weaknesses, and alternatives to that idea rather
than debating the reach and appropriateness of BCP 190 under
various circumstances.   Long term and more generally, I think
that suggests seeing BCP 190 not as a particular set of
principles and rules but as an example of something we don't
want to do to ourselves again as a BCP (or as something that
gets enough of an IAB stamp of approval that people will later
argue MUST (or SHOULD) be conformed to.  Again, restated as
general guidance with the assumption that there will be
exceptions and cases not considered, I don't have much of a
problem.    If that shoe fits  draft-nottingham-for-the-users,
so be it.

   john

p.s. I don't mean to pick on Mark here.   While these two
documents coming up at the same time was handy, I think the
problem is general and that there are far worse examples
(examples of which he is not an author) than either of them.

_______________________________________________
art mailing list
art@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/art


--0000000000005db9dd058fcee067-- From nobody Sun Aug 11 11:01:51 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16074120E5E; Sun, 11 Aug 2019 11:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Em8iKfh81vYS; Sun, 11 Aug 2019 11:00:40 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 814A0120841; Sun, 11 Aug 2019 03:30:58 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id r21so143163214otq.6; Sun, 11 Aug 2019 03:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MlpopoR+CbVl3zsLx9A/OpcrDljjRFJW7cnPJLuDhZM=; b=kWJ+RuyA6I3958bOr/E8CctersfqB5jGTqPZKuZlnWbtbpkvoy6jOf7YG7daPIlM7C dZ5/toSFYaS9npNUqRsLHdkgiBU5CoewNI8TU/5Aol5S+xl6TWnYtFelIIkGeowFkYNY hwPSCJAllr7y4VMKSbQY2tuR35RTsIE+InMvpuGZvm/G6TPyjin71w1RQ1lRU35iOB4e uaAhOXK+O6ADYNkWRPXEVH49hNw8vPuTROA9c+Y71aC5nH5Ms/Rs0letV8ABq/oHFCuA DYBy7GDsx/mXtFev1rrcBu7LA+f2ze0zcncQGlkvFghQbr4jM1RguMbIA4GI8hQYTHNC 0s8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MlpopoR+CbVl3zsLx9A/OpcrDljjRFJW7cnPJLuDhZM=; b=eE8qLk4Y6+9IUIQwmFCcc887OTK+1K7noqE1jCFKunZVczEsonaAbIgdoEMb6NDtE/ fzTD3CeT7N8vgVh2cLVkyvBpP+nnrOx1FBlyy+WFGOO3WmQF4UP+ZK2+VPxRst1Nm4pE vh7ouUPVbEbh5b9RIb3Q9oT3N1GqEbCJ3coBZbK+RHDR2F42SIxlY7v93rjlbUTaQ4lX TNDPCz/v4RDEpsELkk3Czdr/e9g+f9+SgAcGNoWCGqh3ayFYN/74EpT6t7mm/9keMD97 ylXTkbAvzDeaI1Tu30vYDfr2+4A8F1NMDFM09pfQFZx30Jd4CFOToA0odr5yW640v2KZ BeTA== X-Gm-Message-State: APjAAAUmZ/mPyr4aIXMKBVrrkIcvtW41TYAN+Q9DZJRdMYNCNdLVz7bX If/FpbsTiIfmukLct9b0Xp4cF2waROgZQbHg3tk= X-Google-Smtp-Source: APXvYqxsk8+FEv1uvVaeE/2Wwxbv/Sz45QmiHBxM/3UDTIuRekfLt0vahkBK62XpqzSRqbuEUI2XC03WhUy+eanH//4= X-Received: by 2002:aca:72c7:: with SMTP id p190mr7926189oic.9.1565519457713; Sun, 11 Aug 2019 03:30:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:4b14:0:0:0:0:0 with HTTP; Sun, 11 Aug 2019 03:30:57 -0700 (PDT) In-Reply-To: References: <791b33b8-4696-f69c-aca3-8838b2caafd8@sectigo.com> <77F8C1C2AAB5AE251285436F@172.20.2.211> <30deb3a8-c24f-1f38-2701-aa1d68b6adba@nostrum.com> From: Guntur Wiseno Putra Date: Sun, 11 Aug 2019 17:30:57 +0700 Message-ID: To: Adam Roach Cc: John C Klensin , "art@ietf.org" , "architecture-discuss@ietf.org" , tsoupi@uic.edu Content-Type: multipart/alternative; boundary="0000000000002a82f5058fd4e766" Archived-At: Subject: Re: [art] [arch-d] BCP 190, draft-nottingham-for-the-users, and a generalization X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2019 18:01:43 -0000 --0000000000002a82f5058fd4e766 Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss, To share what I have found out: if such public installations inspire/is about exploring musicality of diferent architectural features --as it was attempted by "Building Music" of Electronic Visual Laboratory UIC: https://www.evl.uic.edu/entry.php?id=1985 *Note: There is a correction for Daria Tsoupikova e-mail address of my previous messages... Regard, Guntur Wiseno Putra Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra menulis: > Dear architecture-discuss, > > Forgive me for typing errors in previous message... > > An alternative link to the posting on Marcos Novak's "Liquid Architecture > in Cyberspace" at public@informationarchitecture@w3.org I mentioned > earlier is > > https://lists.w3.org/Archives/Public/public-informationarchi > tecture/2019May/0000.html > > (which was "403 Forbidden: Request forbidden by administrative rules" the > last time I checked up minutes ago) > > Or, if going directly toward the text: > > https://www.evl.uic.edu/datsoupi/coding/readings/1991_Novak_Liquid.pdf > > Thank to Martin Dodge for suggesting Marcos Novak's architecture in > www.cybergeography.org bringing me to Daria Tsoupukiva's lecture > providing the reading... > > > > Regard, > Guntur Wiseno Putra > > Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra > menulis: > >> Dear architecture-discuss, >> >> An alternative link to the posting on Marcos Nocak'S "Liquid Architecture >> in Cyberspace" at public@informationarchitecture@w3.org I mentioned >> earlier is >> >> https://lists.w3.org/Archives/Public/public-informationarchi >> tecture/2019May/0000.html >> >> (which was "403 Forbidden: Request forbidden by administrative rules" the >> last time I checked up minutes ago) >> >> Or, if going directly toward the text: >> >> https:///www.evl.uic.edu/datsoupi/coding/readings/Marcos_Novak_ >> Liquid.pdf >> >> Thank to Martin Dodge for suggesting Marcos Novak's architecture in >> www.cybergeography.org bringing me to Daria Tsoupukiva's lecture >> providing the reading... >> >> Regard, >> Gubtur Wiseno Putra >> >> Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra >> menulis: >> >>> Dear architecture-discuss, >>> >>> Such co-presences of which architecture is part of: if we attempt to >>> think of its relation with other human experiences on poetry, on poetics, >>> on a spirit invoked to make comprehensible a poetic fact, to get toward an >>> understanding of cyberspace architecture, of "Liquid Architecture in >>> Cyberspace" (Marcos Novak, 1991) >>> >>> I suggested as a reading to public-informationarchitecture@w3.org at >>> which there is the web-address to the Novak's work (posted at 12 May 2019): >>> >>> http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0Zy >>> T5em5Tg9gBMJh0Aiw@mail.gmail.com;list=public-informationarchitecture >>> Regard, >>> >>> Guntur Wiseno Putra >>> >>> Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra >>> menulis: >>> >>>> Dear architecture-discuss, >>>> & John, >>>> >>>> To share what might be inspiring... >>>> >>>> In order to propose what should be understood as "concept", "percept" & >>>> "affect", thus as "philosophy" & "art", Deleuze & Guattari ("What is >>>> Philosophy?") mentioned architecture as the first art as art begins with >>>> house: that of which "the most scientific architecture continually produces >>>> and unifies planes and sections... it could be defined as "frame" with a >>>> connection among various frames oriented differently, applied to other >>>> arts...(There is) a composite system consisting of points and >>>> counterpoints... (there is) a matter of sensations (percepts and affects) >>>> combined... (While) the system still needs a composition plane run >>>> "deframing" opening ways from house territory to city-cosmos, the system in >>>> which there are cosmic forces to create new affects...". >>>> >>>> There is "asthetic composition" as the working of sensation which is, >>>> so they said, the definition of art... >>>> >>>> Regard, >>>> Guntur Wiseno Putra >>>> >>>> Pada Selasa, 23 Juli 2019, Adam Roach menulis: >>>> >>>>> John -- >>>>> >>>>> It's going to take a while for me to formulate my thoughts around what >>>>> you say below. To make sure I understand the class of constraints you're >>>>> concerned about below, can you clarify whether you think they apply to: >>>>> >>>>> - Documents like BCP 200, RFC 2804, and BCP 188? >>>>> - Documents like BCP 9 and BCP 92? >>>>> - Documents like BCP 25, BCP 54, and BCP 83? >>>>> >>>>> You might see an unstated agenda in the categories of documents I list >>>>> above, so I'll state it explicitly: in the general case, one person's >>>>> important protections against a tragedy of the commons is another person's >>>>> annoying impediment to be ignored and defeated. I get that not all of the >>>>> above read on protocol design; but they do share the common feature that >>>>> they've gone through the IETF consensus process (at least to the degree >>>>> that such a process existed at the time of their respective publications). >>>>> If we're going to carefully parse out the meanings of some of them as the >>>>> will of the community while treating others as light guidelines to be >>>>> ignored when they become cumbersome, we're going to need to agree on a >>>>> pretty bright line that divides those categories. >>>>> >>>>> /a >>>>> >>>>> On 7/23/19 08:37, John C Klensin wrote: >>>>> >>>>> (copying architecture-discuss because the comment I'm about to >>>>> make is an architectural issue and because >>>>> draft-nottingham-for-the-users is under discussion there.) >>>>> >>>>> >>>>> A late colleague, much loved by some of us, used to claim (much >>>>> more elegantly than I can manage) that one of the reasons the >>>>> ARPANET and then the Internet protocols had succeeded and much >>>>> of what was seen as competitive alternatives had not, was that >>>>> our efforts focused on pragmatic, working protocols and >>>>> implementations. >>>>> >>>>> The other folks had developed a culture of formalisms, models, >>>>> and stated design principles. They then tried to develop >>>>> protocols that fit into the boxes and categories of those >>>>> formalisms, models, and design principles. When they >>>>> discovered that something didn't fit, they needed to either >>>>> invent kludges or other ways of getting square pegs into round >>>>> holes, go back and revise models and guidance before moving >>>>> forward, or consider and make exceptions (which often required >>>>> first figuring out how to make an exception and developing >>>>> procedures for that). >>>>> >>>>> One difficulty is that the above can waste a lot of time. >>>>> Another is that it can distort protocol design, if only because >>>>> forcing square pegs into round holes tends to be hard on both >>>>> the pegs and the holes. >>>>> >>>>> In many or most fields of application, the nature of engineering >>>>> involves seeing and understanding a range of tradeoffs and then >>>>> doing design work that reflects a carefully-chosen balance among >>>>> them. Give design elegance absolute priority over structural >>>>> issues and buildings and bridges fall down. IMO, we need to >>>>> think, and keep thinking, about systems and tradeoffs. That, in >>>>> turn, means that statements like these that can be interpreted >>>>> in absolute terms, even if we mostly agree with them, should be >>>>> packaged as general guidelines and not BCPs to which everything >>>>> done in the future is required to either conform or to try to >>>>> figure out how to appeal to a higher authority. >>>>> >>>>> I'm not at all convinced that the proposal that was summarized >>>>> an ARTAREA yesterday and that is seen as requiring an exception >>>>> to BCP 190 is a good idea. But I think our time would be better >>>>> spent, and the Internet more efficiently made better, discussing >>>>> the strengths, weaknesses, and alternatives to that idea rather >>>>> than debating the reach and appropriateness of BCP 190 under >>>>> various circumstances. Long term and more generally, I think >>>>> that suggests seeing BCP 190 not as a particular set of >>>>> principles and rules but as an example of something we don't >>>>> want to do to ourselves again as a BCP (or as something that >>>>> gets enough of an IAB stamp of approval that people will later >>>>> argue MUST (or SHOULD) be conformed to. Again, restated as >>>>> general guidance with the assumption that there will be >>>>> exceptions and cases not considered, I don't have much of a >>>>> problem. If that shoe fits draft-nottingham-for-the-users, >>>>> so be it. >>>>> >>>>> john >>>>> >>>>> p.s. I don't mean to pick on Mark here. While these two >>>>> documents coming up at the same time was handy, I think the >>>>> problem is general and that there are far worse examples >>>>> (examples of which he is not an author) than either of them. >>>>> >>>>> _______________________________________________ >>>>> art mailing listart@ietf.orghttps://www.ietf.org/mailman/listinfo/art >>>>> >>>>> >>>>> --0000000000002a82f5058fd4e766 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,



To share what I have found out: if such public installations inspire/is ab= out exploring musicality of diferent architectural features --as it was att= empted by "Building Music" of Electronic Visual Laboratory UIC:


https://www.evl.uic.edu/entry.php?id=3D1985


*Note: There is a correction for Daria= Tsoupikova e-mail address of my previous messages...

<= div>
Regard,
Guntur Wiseno Putra

Pada Minggu= , 11 Agustus 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
D= ear architecture-discuss,

Forgive me for typing e= rrors in previous message...

= An alternative link to the posting on Marcos Novak's "Liqui= d Architecture in Cyberspace" at public@informationarchitecture= @w3.org=C2=A0I ment= ioned earlier is


(which was "403 Forbidden: Request forbidden by administrative rule= s" the last time I checked up minutes ago)

= Or, if going directly toward the text:


Thank to Martin Dodge for suggesting Marcos = Novak's architecture in=C2=A0www.cybergeography.org=C2=A0bringing me to Dari= a Tsoupukiva's lecture providing the reading...



Regard,
Guntur Wiseno Putra=

Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis= :
Dear architecture-discuss,

An alternative link to the posting on Marcos Nocak'S "Liqui= d Architecture in Cyberspace" at public@informationarchitecture@<= a href=3D"http://w3.org" target=3D"_blank">w3.org=C2=A0 I mentioned ear= lier is


(which was "403 F= orbidden: Request forbidden by administrative rules" the last time I c= hecked up minutes ago)

Or, if going directly towar= d the text:

https:///www.evl.= uic.edu/datsoupi/coding/readings/Marcos_Novak_ Liquid.pdf

Thank to Martin Dodge for suggesting Marcos Novak'= ;s architecture in www.cybergeography.org bringing me to Daria Tsoupukiva's lectur= e providing the reading...

Regard,

Regard,

Guntur Wiseno Putra

Pada Rabu, 24 Juli 2019, G= untur Wiseno Putra <gsenopu@gmail.com> menulis:
Dea= r architecture-discuss,
& John,

To sha= re what might be inspiring...

In order to propose wh= at should be understood as "concept", "percept" & &= quot;affect", thus as "philosophy" & "art", De= leuze & Guattari ("What is Philosophy?") mentioned architectu= re as the first art as art begins with house: that of which "the most = scientific architecture continually produces and unifies planes and section= s... it could be defined as "frame" with a connection among vario= us frames oriented differently, applied to other arts...(There is) a compos= ite system consisting of points and counterpoints... (there is) a matter of= sensations (percepts and affects) combined... (While) the system still nee= ds a composition plane run "deframing" opening ways from house te= rritory to city-cosmos, the system in which there are cosmic forces to crea= te new affects...".

There is "asthetic c= omposition" as the working of sensation which is, so they said, the de= finition of art...

Regard,
Guntur Wiseno= Putra

Pada Selasa, 23 Juli 2019, Adam Roach <adam@nostrum.com> menulis:
=20 =20 =20
John --

It's going to take a while for me to formulate my thoughts around what you say below. To make sure I understand the class of constraints you're concerned about below, can you clarify whether you think they apply to:
  • Documents like BCP 200, RFC 2804, and BCP 188?
  • Documents like BCP 9 and BCP 92?
  • Documents like BCP 25, BCP 54, and BCP 83?

You might see an unstated agenda in the categories of documents I list above, so I'll state it explicitly: in the general case, one person's important protections against a tragedy of the commons is another person's annoying impediment to be ignored and defeated. I get that not all of the above read on protocol design; but they do share the common feature that they've gone through the IETF consensus process (at least to the degree that such a process existed at the time of their respective publications). If we're going to carefully parse out the meanings of some of them as the will of the community while treating others as light guidelines to be ignored when they become cumbersome, we're going to need to agree on a pretty bright line that divides those categories.

/a


On 7/23/19 08:37, John C Klensin wrote:
(copying architecture-discuss because the comment I'm about =
to
make is an architectural issue and because
draft-nottingham-for-the-users is under discussion there.)


A late colleague, much loved by some of us, used to claim (much
more elegantly than I can manage) that one of the reasons the
ARPANET and then the Internet protocols had succeeded and much
of what was seen as competitive alternatives had not, was that
our efforts focused on pragmatic, working protocols and
implementations. =20

The other folks had developed a culture of formalisms, models,
and stated design principles.  They then tried to develop
protocols that fit into the boxes and categories of those
formalisms, models, and design principles.    When they
discovered that something didn't fit, they needed to either
invent kludges or other ways of getting square pegs into round
holes, go back and revise models and guidance before moving
forward, or consider and make exceptions (which often required
first figuring out how to make an exception and developing
procedures for that).

One difficulty is that the above can waste a lot of time.
Another is that it can distort protocol design, if only because
forcing square pegs into round holes tends to be hard on both
the pegs and the holes.

In many or most fields of application, the nature of engineering
involves seeing and understanding a range of tradeoffs and then
doing design work that reflects a carefully-chosen balance among
them.  Give design elegance absolute priority over structural
issues and buildings and bridges fall down.  IMO, we need to
think, and keep thinking, about systems and tradeoffs.  That, in
turn, means that statements like these that can be interpreted
in absolute terms, even if we mostly agree with them, should be
packaged as general guidelines and not BCPs to which everything
done in the future is required to either conform or to try to
figure out how to appeal to a higher authority.

I'm not at all convinced that the proposal that was summarized
an ARTAREA yesterday and that is seen as requiring an exception
to BCP 190 is a good idea.  But I think our time would be better
spent, and the Internet more efficiently made better, discussing
the strengths, weaknesses, and alternatives to that idea rather
than debating the reach and appropriateness of BCP 190 under
various circumstances.   Long term and more generally, I think
that suggests seeing BCP 190 not as a particular set of
principles and rules but as an example of something we don't
want to do to ourselves again as a BCP (or as something that
gets enough of an IAB stamp of approval that people will later
argue MUST (or SHOULD) be conformed to.  Again, restated as
general guidance with the assumption that there will be
exceptions and cases not considered, I don't have much of a
problem.    If that shoe fits  draft-nottingham-for-the-users,
so be it.

   john

p.s. I don't mean to pick on Mark here.   While these two
documents coming up at the same time was handy, I think the
problem is general and that there are far worse examples
(examples of which he is not an author) than either of them.

_______________________________________________
art mailing list
art@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/art


--0000000000002a82f5058fd4e766-- From nobody Sun Aug 11 11:18:29 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAB1120988; Sun, 11 Aug 2019 11:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 mhoK6b9V6Eni; Sun, 11 Aug 2019 11:17:28 -0700 (PDT) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 EEF40120A3E; Sun, 11 Aug 2019 03:42:20 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id z17so30693031otk.13; Sun, 11 Aug 2019 03:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lOpkauZtFKIBi1RhE7bb07RqEgTjeh9D87dDZ0vLJ/w=; b=rF3KuE+8bwInATZ6+EC9iuYcl5D3GhZ5Jbq3M7egqDUNkCECjLjayK5HgJmoe5Chze hUeKRLZ/kqtPA9YjOtKUtoi+kJQVgM7PSJ34hr26xILtSmKpx116QUji3kVSaPKeagLM MoNW3HHLOszlLIYtl3k5RFfcGM0lj2Ha3RSzzH8iI7bgQI0pXI1xgEFlvGRU1cCmdDUW zVlNNTjeZQS5h4PXBZqhH8Rt7q3oR5HA8hdDDTavMlUEO2rmKsyt8g+N+BHTmGSLZdkp mEvRj+hd05pidi7uThZNMadLdKrJXg0YjGzC4CATaMGte8L3uhIXtXO7SgiiHfrvKbQp gxlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lOpkauZtFKIBi1RhE7bb07RqEgTjeh9D87dDZ0vLJ/w=; b=YCFnbwCY+q+wNMAvBu0jIi0LyqBuXkaTL5knNCSinmkQEabadfhQ3XSaWnS2ZXM5Xq qlnkK2AXqY2BhdBO3M69xQNlbw59baixmYgvpWSSjXHmMHJr+moPpHHz+AQoznbZy2Rc Zd10h1+0YlMV3lFbeQjYAVgkO4MhtHwvww2suJ1aZZn4r0TVMBrKDBpJ9+R+jfq47c1E Lgy4sxUfFEFSOi9WDPjZqzHSJLoKHO41mVb1zxMuO82gRi5taNkIIYxcdjjzKgmplQFX bUpmUXgFDufgKa7IkL1gN+qD0ot1LHEXDW6kwXUT1nCaTl6f5++J/TJ731Ns4EpSao9X Sxyw== X-Gm-Message-State: APjAAAXf0EJ+EcFNDlgQJd2MoFIG0+sQBXRkXDHjSegGCG4YMqkSwY0o cFivkQLcDEFkzJibzZkq3/lAzmiu1Nm7D6bUP/E= X-Google-Smtp-Source: APXvYqwrYbHxbSfWLt8LVH0ZgNHobTEELJWvUhwBbBUjVjs18Ub/RsiJtEHSjTD+gOwmL66MTPYg49AZqPcuBa8YGpk= X-Received: by 2002:a54:4703:: with SMTP id k3mr11129535oik.143.1565520140145; Sun, 11 Aug 2019 03:42:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:4b14:0:0:0:0:0 with HTTP; Sun, 11 Aug 2019 03:42:19 -0700 (PDT) In-Reply-To: References: <791b33b8-4696-f69c-aca3-8838b2caafd8@sectigo.com> <77F8C1C2AAB5AE251285436F@172.20.2.211> <30deb3a8-c24f-1f38-2701-aa1d68b6adba@nostrum.com> From: Guntur Wiseno Putra Date: Sun, 11 Aug 2019 17:42:19 +0700 Message-ID: To: Adam Roach Cc: John C Klensin , "art@ietf.org" , "architecture-discuss@ietf.org" , "tsoupi@uic.edu" , info@playthemagic.com Content-Type: multipart/alternative; boundary="000000000000d79c57058fd50fd9" Archived-At: Subject: Re: [art] [arch-d] BCP 190, draft-nottingham-for-the-users, and a generalization X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2019 18:18:23 -0000 --000000000000d79c57058fd50fd9 Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss, (There are things need to correct on * Note) To share what I have found out: if such public installations inspire/is about exploring musicality of diferent architectural features --as it was attempted by "Building Music" of Electronic Visual Laboratory UIC: https://www.evl.uic.edu/entry.php?id=1985 *Note: - There is a correction for Daria Tsoupikova e-mail address of my previous messages on Marcos Novak'"Liquid Architecture in Cyberspace" - Should I add CC: info@playthemagic.com as it is of the "Building Music" page which may have importances. Regard, Guntur Wiseno Putra Dear architecture-discuss, To share what I have found out: if such public installations inspire/is about exploring musicality of diferent architectural features --as it was attempted by "Building Music" of Electronic Visual Laboratory UIC: https://www.evl.uic.edu/entry.php?id=1985 *Note: There is a correction for Daria Tsoupikova e-mail address of my previous messages... Regard, Guntur Wiseno Putra Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra menulis: > Dear architecture-discuss, > > > > To share what I have found out: if such public installations inspire/is > about exploring musicality of diferent architectural features --as it was > attempted by "Building Music" of Electronic Visual Laboratory UIC: > > > https://www.evl.uic.edu/entry.php?id=1985 > > > *Note: There is a correction for Daria Tsoupikova e-mail address of my > previous messages... > > > Regard, > Guntur Wiseno Putra > > Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra > menulis: > >> Dear architecture-discuss, >> >> Forgive me for typing errors in previous message... >> >> An alternative link to the posting on Marcos Novak's "Liquid Architecture >> in Cyberspace" at public@informationarchitecture@w3.org I mentioned >> earlier is >> >> https://lists.w3.org/Archives/Public/public-informationarchi >> tecture/2019May/0000.html >> >> (which was "403 Forbidden: Request forbidden by administrative rules" the >> last time I checked up minutes ago) >> >> Or, if going directly toward the text: >> >> https://www.evl.uic.edu/datsoupi/coding/readings/1991_Novak_Liquid.pdf >> >> Thank to Martin Dodge for suggesting Marcos Novak's architecture in >> www.cybergeography.org bringing me to Daria Tsoupukiva's lecture >> providing the reading... >> >> >> >> Regard, >> Guntur Wiseno Putra >> >> Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra >> menulis: >> >>> Dear architecture-discuss, >>> >>> An alternative link to the posting on Marcos Nocak'S "Liquid >>> Architecture in Cyberspace" at public@informationarchitecture@w3.org I >>> mentioned earlier is >>> >>> https://lists.w3.org/Archives/Public/public-informationarchi >>> tecture/2019May/0000.html >>> >>> (which was "403 Forbidden: Request forbidden by administrative rules" >>> the last time I checked up minutes ago) >>> >>> Or, if going directly toward the text: >>> >>> https:///www.evl.uic.edu/datsoupi/coding/readings/Marcos_Novak_ >>> Liquid.pdf >>> >>> Thank to Martin Dodge for suggesting Marcos Novak's architecture in >>> www.cybergeography.org bringing me to Daria Tsoupukiva's lecture >>> providing the reading... >>> >>> Regard, >>> Gubtur Wiseno Putra >>> >>> Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra >>> menulis: >>> >>>> Dear architecture-discuss, >>>> >>>> Such co-presences of which architecture is part of: if we attempt to >>>> think of its relation with other human experiences on poetry, on poetics, >>>> on a spirit invoked to make comprehensible a poetic fact, to get toward an >>>> understanding of cyberspace architecture, of "Liquid Architecture in >>>> Cyberspace" (Marcos Novak, 1991) >>>> >>>> I suggested as a reading to public-informationarchitecture@w3.org at >>>> which there is the web-address to the Novak's work (posted at 12 May 2019): >>>> >>>> http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0Zy >>>> T5em5Tg9gBMJh0Aiw@mail.gmail.com;list=public-informationarchitecture >>>> Regard, >>>> >>>> Guntur Wiseno Putra >>>> >>>> Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra >>>> menulis: >>>> >>>>> Dear architecture-discuss, >>>>> & John, >>>>> >>>>> To share what might be inspiring... >>>>> >>>>> In order to propose what should be understood as "concept", "percept" >>>>> & "affect", thus as "philosophy" & "art", Deleuze & Guattari ("What is >>>>> Philosophy?") mentioned architecture as the first art as art begins with >>>>> house: that of which "the most scientific architecture continually produces >>>>> and unifies planes and sections... it could be defined as "frame" with a >>>>> connection among various frames oriented differently, applied to other >>>>> arts...(There is) a composite system consisting of points and >>>>> counterpoints... (there is) a matter of sensations (percepts and affects) >>>>> combined... (While) the system still needs a composition plane run >>>>> "deframing" opening ways from house territory to city-cosmos, the system in >>>>> which there are cosmic forces to create new affects...". >>>>> >>>>> There is "asthetic composition" as the working of sensation which is, >>>>> so they said, the definition of art... >>>>> >>>>> Regard, >>>>> Guntur Wiseno Putra >>>>> >>>>> Pada Selasa, 23 Juli 2019, Adam Roach menulis: >>>>> >>>>>> John -- >>>>>> >>>>>> It's going to take a while for me to formulate my thoughts around >>>>>> what you say below. To make sure I understand the class of constraints >>>>>> you're concerned about below, can you clarify whether you think they apply >>>>>> to: >>>>>> >>>>>> - Documents like BCP 200, RFC 2804, and BCP 188? >>>>>> - Documents like BCP 9 and BCP 92? >>>>>> - Documents like BCP 25, BCP 54, and BCP 83? >>>>>> >>>>>> You might see an unstated agenda in the categories of documents I >>>>>> list above, so I'll state it explicitly: in the general case, one person's >>>>>> important protections against a tragedy of the commons is another person's >>>>>> annoying impediment to be ignored and defeated. I get that not all of the >>>>>> above read on protocol design; but they do share the common feature that >>>>>> they've gone through the IETF consensus process (at least to the degree >>>>>> that such a process existed at the time of their respective publications). >>>>>> If we're going to carefully parse out the meanings of some of them as the >>>>>> will of the community while treating others as light guidelines to be >>>>>> ignored when they become cumbersome, we're going to need to agree on a >>>>>> pretty bright line that divides those categories. >>>>>> >>>>>> /a >>>>>> >>>>>> On 7/23/19 08:37, John C Klensin wrote: >>>>>> >>>>>> (copying architecture-discuss because the comment I'm about to >>>>>> make is an architectural issue and because >>>>>> draft-nottingham-for-the-users is under discussion there.) >>>>>> >>>>>> >>>>>> A late colleague, much loved by some of us, used to claim (much >>>>>> more elegantly than I can manage) that one of the reasons the >>>>>> ARPANET and then the Internet protocols had succeeded and much >>>>>> of what was seen as competitive alternatives had not, was that >>>>>> our efforts focused on pragmatic, working protocols and >>>>>> implementations. >>>>>> >>>>>> The other folks had developed a culture of formalisms, models, >>>>>> and stated design principles. They then tried to develop >>>>>> protocols that fit into the boxes and categories of those >>>>>> formalisms, models, and design principles. When they >>>>>> discovered that something didn't fit, they needed to either >>>>>> invent kludges or other ways of getting square pegs into round >>>>>> holes, go back and revise models and guidance before moving >>>>>> forward, or consider and make exceptions (which often required >>>>>> first figuring out how to make an exception and developing >>>>>> procedures for that). >>>>>> >>>>>> One difficulty is that the above can waste a lot of time. >>>>>> Another is that it can distort protocol design, if only because >>>>>> forcing square pegs into round holes tends to be hard on both >>>>>> the pegs and the holes. >>>>>> >>>>>> In many or most fields of application, the nature of engineering >>>>>> involves seeing and understanding a range of tradeoffs and then >>>>>> doing design work that reflects a carefully-chosen balance among >>>>>> them. Give design elegance absolute priority over structural >>>>>> issues and buildings and bridges fall down. IMO, we need to >>>>>> think, and keep thinking, about systems and tradeoffs. That, in >>>>>> turn, means that statements like these that can be interpreted >>>>>> in absolute terms, even if we mostly agree with them, should be >>>>>> packaged as general guidelines and not BCPs to which everything >>>>>> done in the future is required to either conform or to try to >>>>>> figure out how to appeal to a higher authority. >>>>>> >>>>>> I'm not at all convinced that the proposal that was summarized >>>>>> an ARTAREA yesterday and that is seen as requiring an exception >>>>>> to BCP 190 is a good idea. But I think our time would be better >>>>>> spent, and the Internet more efficiently made better, discussing >>>>>> the strengths, weaknesses, and alternatives to that idea rather >>>>>> than debating the reach and appropriateness of BCP 190 under >>>>>> various circumstances. Long term and more generally, I think >>>>>> that suggests seeing BCP 190 not as a particular set of >>>>>> principles and rules but as an example of something we don't >>>>>> want to do to ourselves again as a BCP (or as something that >>>>>> gets enough of an IAB stamp of approval that people will later >>>>>> argue MUST (or SHOULD) be conformed to. Again, restated as >>>>>> general guidance with the assumption that there will be >>>>>> exceptions and cases not considered, I don't have much of a >>>>>> problem. If that shoe fits draft-nottingham-for-the-users, >>>>>> so be it. >>>>>> >>>>>> john >>>>>> >>>>>> p.s. I don't mean to pick on Mark here. While these two >>>>>> documents coming up at the same time was handy, I think the >>>>>> problem is general and that there are far worse examples >>>>>> (examples of which he is not an author) than either of them. >>>>>> >>>>>> _______________________________________________ >>>>>> art mailing listart@ietf.orghttps://www.ietf.org/mailman/listinfo/art >>>>>> >>>>>> >>>>>> --000000000000d79c57058fd50fd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear architecture-discuss,

(There ar= e things need to correct on * Note)

To share what = I have found out: if such public installations inspire/is about exploring m= usicality of diferent architectural features --as it was attempted by "= ;Building Music" of Electronic Visual Laboratory UIC:




*Note:=C2=A0
- There= is a correction for Daria Tsoupikova e-mail address of my previous message= s on Marcos Novak'"Liquid Architecture in Cyberspace"
- Should I add CC: info@playthe= magic.com as it is of the "Building Music" page which may hav= e importances.


Regard,
Gu= ntur Wiseno Putra



<= div>

Dear architecture-discuss,

=


To share what I have found out: if such = public installations inspire/is about exploring musicality of diferent arch= itectural features --as it was attempted by "Building Music" of E= lectronic Visual Laboratory UIC:


htt= ps://www.evl.uic.edu/entry.php?id=3D1985

<= div>
*Note: There is a correction for Daria Tsoupikova e-mail= address of my previous messages...


Regard,
Guntur Wiseno Putra



Pa= da Minggu, 11 Agustus 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,



To share what I have found out: if such public installations inspi= re/is about exploring musicality of diferent architectural features --as it= was attempted by "Building Music" of Electronic Visual Laborator= y UIC:




*Note: = There is a correction for Daria Tsoupikova e-mail address of my previous me= ssages...


Regard,
Guntur = Wiseno Putra

Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra <<= a href=3D"mailto:gsenopu@gmail.com" target=3D"_blank">gsenopu@gmail.com= > menulis:
Dear architecture-discuss,<= div>
Forgive me for typing errors in previous message.= ..

An alternative link= to the posting on Marcos Novak's "Liquid Architecture in Cyberspa= ce" at public@informationarchitecture@w3.org=C2=A0I mentioned earlier is


(which was "403 Fo= rbidden: Request forbidden by administrative rules" the last time I ch= ecked up minutes ago)

Or, if going directly towa= rd the text:


=
Thank to Martin Dodge for suggesting Marcos Novak's architecture = in=C2=A0www.cy= bergeography.org=C2=A0bringing me to Daria Tsoupukiva's lectur= e providing the reading...


Regard,
Guntur Wiseno Putra

Pada Minggu, 11 A= gustus 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,

An alternative lin= k to the posting on Marcos Nocak'S "Liquid Architecture in Cybersp= ace" at public@informationarchitecture@w3.org=C2=A0 I mentioned earlier is


(which was "403 Forbidden: Request forbidd= en by administrative rules" the last time I checked up minutes ago)

Or, if going directly toward the text:


Tha= nk to Martin Dodge for suggesting Marcos Novak's architecture in www.cybergeography.or= g bringing me to Daria Tsoupukiva's lecture providing the reading..= .

Regard,
Gubtur Wiseno Putra

Pad= a Minggu, 11 Agustus 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,

Such= co-presences of which architecture is part of: if we attempt to think of i= ts relation with other human experiences on poetry, on poetics, on a spirit= invoked to make comprehensible a poetic fact, to get toward an understandi= ng of cyberspace architecture, of "Liquid Architecture in Cyberspace&q= uot; (Marcos Novak, 1991)

I suggested as a reading= to public-informationarchitecture@w3.org at which there is the we= b-address to the Novak's work (posted at 12 May 2019):

Regard,

Gun= tur Wiseno Putra

Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra <gsenopu@gmail.com&= gt; menulis:
Dear architecture-discuss,& John,

To share what might be inspirin= g...

In order to propose what should be understood a= s "concept", "percept" & "affect", thus a= s "philosophy" & "art", Deleuze & Guattari (&qu= ot;What is Philosophy?") mentioned architecture as the first art as ar= t begins with house: that of which "the most scientific architecture c= ontinually produces and unifies planes and sections... it could be defined = as "frame" with a connection among various frames oriented differ= ently, applied to other arts...(There is) a composite system consisting of = points and counterpoints... (there is) a matter of sensations (percepts and= affects) combined... (While) the system still needs a composition plane ru= n "deframing" opening ways from house territory to city-cosmos, t= he system in which there are cosmic forces to create new affects...".<= /div>

There is "asthetic composition" as the w= orking of sensation which is, so they said, the definition of art...
<= div>
Regard,
Guntur Wiseno Putra

Pada Selasa= , 23 Juli 2019, Adam Roach <adam@nostrum.com> menulis:
=20 =20 =20
John --

It's going to take a while for me to formulate my thoughts around what you say below. To make sure I understand the class of constraints you're concerned about below, can you clarify whether you think they apply to:
  • Documents like BCP 200, RFC 2804, and BCP 188?
  • Documents like BCP 9 and BCP 92?
  • Documents like BCP 25, BCP 54, and BCP 83?

You might see an unstated agenda in the categories of documents I list above, so I'll state it explicitly: in the general case, one person's important protections against a tragedy of the commons is another person's annoying impediment to be ignored and defeated. I get that not all of the above read on protocol design; but they do share the common feature that they've gone through the IETF consensus process (at least to the degree that such a process existed at the time of their respective publications). If we're going to carefully parse out the meanings of some of them as the will of the community while treating others as light guidelines to be ignored when they become cumbersome, we're going to need to agree on a pretty bright line that divides those categories.

/a


On 7/23/19 08:37, John C Klensin wrote:
(copying architecture-discuss because the comment I'm about =
to
make is an architectural issue and because
draft-nottingham-for-the-users is under discussion there.)


A late colleague, much loved by some of us, used to claim (much
more elegantly than I can manage) that one of the reasons the
ARPANET and then the Internet protocols had succeeded and much
of what was seen as competitive alternatives had not, was that
our efforts focused on pragmatic, working protocols and
implementations. =20

The other folks had developed a culture of formalisms, models,
and stated design principles.  They then tried to develop
protocols that fit into the boxes and categories of those
formalisms, models, and design principles.    When they
discovered that something didn't fit, they needed to either
invent kludges or other ways of getting square pegs into round
holes, go back and revise models and guidance before moving
forward, or consider and make exceptions (which often required
first figuring out how to make an exception and developing
procedures for that).

One difficulty is that the above can waste a lot of time.
Another is that it can distort protocol design, if only because
forcing square pegs into round holes tends to be hard on both
the pegs and the holes.

In many or most fields of application, the nature of engineering
involves seeing and understanding a range of tradeoffs and then
doing design work that reflects a carefully-chosen balance among
them.  Give design elegance absolute priority over structural
issues and buildings and bridges fall down.  IMO, we need to
think, and keep thinking, about systems and tradeoffs.  That, in
turn, means that statements like these that can be interpreted
in absolute terms, even if we mostly agree with them, should be
packaged as general guidelines and not BCPs to which everything
done in the future is required to either conform or to try to
figure out how to appeal to a higher authority.

I'm not at all convinced that the proposal that was summarized
an ARTAREA yesterday and that is seen as requiring an exception
to BCP 190 is a good idea.  But I think our time would be better
spent, and the Internet more efficiently made better, discussing
the strengths, weaknesses, and alternatives to that idea rather
than debating the reach and appropriateness of BCP 190 under
various circumstances.   Long term and more generally, I think
that suggests seeing BCP 190 not as a particular set of
principles and rules but as an example of something we don't
want to do to ourselves again as a BCP (or as something that
gets enough of an IAB stamp of approval that people will later
argue MUST (or SHOULD) be conformed to.  Again, restated as
general guidance with the assumption that there will be
exceptions and cases not considered, I don't have much of a
problem.    If that shoe fits  draft-nottingham-for-the-users,
so be it.

   john

p.s. I don't mean to pick on Mark here.   While these two
documents coming up at the same time was handy, I think the
problem is general and that there are far worse examples
(examples of which he is not an author) than either of them.

_______________________________________________
art mailing list
art@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/art


--000000000000d79c57058fd50fd9-- From nobody Wed Aug 14 08:05:50 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A09120883 for ; Wed, 14 Aug 2019 08:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 K_Qfv4ygka8C for ; Wed, 14 Aug 2019 08:05:46 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 E72CF12023E for ; Wed, 14 Aug 2019 08:05:45 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id l14so15166344lje.2 for ; Wed, 14 Aug 2019 08:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=e0sepdeJ+lkwf7ITmijbUFg7+0Xl3D0LZY3JMl/llqo=; b=e3XgZ6YzOdrSZpWe4s25YYEXmT7EEHJFqHu/L2XIVUv6bcrpeJzDjfghyHUOh9ijvv 09fPQ+3BGanC+2jpM+oFnbC4WEzJcE25jfUl3IlrgDf3NPt+S839iopo5mVh2TbUGx8I WLb2n9ZXUjMALmFuVHoUP0YNbnHuoo6GdTuub5h6PMphuIMzmKQBzE8J8ve5Zdr0BKtR 4ela+E6MnF/jF8zbV2CDT3AH6VcfmQ7slCDhxJTfTLoRrVQWJsMAUDa5QfFmZVBPtI/H XbJmP/6A0wr8+9LsFtURr1FiKbqcdkKuFoKOCyG5IEF7Rjza2d5D9cDYcfNKzN73d9fZ f8lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=e0sepdeJ+lkwf7ITmijbUFg7+0Xl3D0LZY3JMl/llqo=; b=sVf2IGyK9EwN8c8JI6/Goifq72cVtmkbmCc7fLbl16wZs9/J8f9n0cfD35zc3gHhqm DKDRbNWSD6+DlwUArMmc1ozbLKy0Kh9DBB6aWiouNBLpk80UgYGYhYDaw/Ijd9GXtMZU waf+IU9NcD+SBt88olEFWBnLsKdd+TwwrCQ9TcGW19yBhwy5CQGp+Xp4841DC3tKYBW2 O9VkcGtqigouabjx0HiRXaPznc3eUAKgTb1JHzZRCBnVgwe8k11H7Pn8t0AYRKM+LgZX wwnSB1L/RPI0h6m9t92rlxcFzDYlkWmS4syO7LTKYfw4q6OwrgKFvx30DSiDj2z5j/w7 Df/A== X-Gm-Message-State: APjAAAW2P9K1ul2tlaT/RK1E8w2b5wrXiyw/NYPYkm6SQJXkleqqcPxP Rqz62Yx5OCyX71yLW/DFX8I5PvblAJSJ1JAu/2ITQZ+H X-Google-Smtp-Source: APXvYqxEhnSh0L3N1q+kezQ2tnurtyS+hpXVjVDde7bwfKFO9IwWvFtSIaCq7wIdfYDvr1q25ru1lkD/lFhQv+9pMFg= X-Received: by 2002:a2e:85d4:: with SMTP id h20mr145787ljj.142.1565795143846; Wed, 14 Aug 2019 08:05:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mary Barnes Date: Wed, 14 Aug 2019 11:05:45 -0400 Message-ID: To: IETF ART Mailing List Content-Type: multipart/alternative; boundary="0000000000005710b205901517c4" Archived-At: Subject: [art] Fwd: DISPATCH WG deadlines for IETF-106 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 15:05:49 -0000 --0000000000005710b205901517c4 Content-Type: text/plain; charset="UTF-8" Since I don't think everyone on the ART list is on the DISPATCH WG mailing list, I'm forwarding this as an FYI. Regards, Mary. ---------- Forwarded message --------- From: Mary Barnes Date: Wed, Aug 14, 2019 at 10:49 AM Subject: DISPATCH WG deadlines for IETF-106 To: DISPATCH Cc: dispatch chairs , ART ADs Hi all, While IETF-106 seems a long ways out, it is less than 2 months before the IETF-106 BoF deadline. If you have a potential topic and are not sure if it might require an official BoF as opposed to a DISPATCH WG slot, please contact the ADs and DISPATCH WG chairs (aliases cc'ed above). As a reminder, these dates are always available on the DISPATCH WG wiki: https://trac.ietf.org/trac/dispatch/wiki - Oct 4, 2019. Cutoff date for IETF BoF submissions. - Oct 7, 2019. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal/topic. - Oct 14, 2019. Cutoff for proposals (i.e., problem statement and proposed deliverables) for topics posted to the DISPATCH WG mailing list. - Oct 21, 2019. Announcement of topics that have been dispatched for IETF-105. - Nov 4, 2019. Draft submission deadline. Note, that while these dates are specific to DISPATCH WG, since we share our slot with ART area, it would be helpful to know about potential ART area topics sooner rather than later, so we don't get into the situation like we did at IETF-105 and have to cutoff important ART discussions. Regards, Mary DISPATCH WG co-chair --0000000000005710b205901517c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Since I don't think everyone on the ART list is on the= DISPATCH WG mailing list, I'm forwarding this as an FYI.=C2=A0=C2=A0
Regards,
Mary.=C2=A0

---------- Forwarded message = ---------
From: Mary Bar= nes <mary.ietf.barnes@gmail.com>
Date: Wed, Aug 14, 2019= at 10:49 AM
Subject: DISPATCH WG deadlines for IETF-106
To: DISPATCH= <dispatch@ietf.org>
Cc: = dispatch chairs <dispatch-ch= airs@ietf.org>, ART ADs <art-= ads@ietf.org>


Hi all,

While IETF-106 seems a long ways out, it is less than 2 months befor= e the IETF-106 BoF deadline.=C2=A0 If you have a potential topic and are no= t sure if it might require an official BoF as opposed to a DISPATCH WG slot= , please contact the ADs and DISPATCH WG chairs (aliases cc'ed above).= =C2=A0=C2=A0

As a reminder, these dates are always= available on the DISPATCH WG wiki:
    Oct 4, 2019. Cutoff date for IETF BoF submissions.
  • Oct 7, 2019. Cutoff date to notify = the chairs/DISPATCH WG of plans to submit a proposal/topic.
  • Oct 14, 2019. Cutoff for pr= oposals (i.e., problem statement and proposed deliverables) for topics post= ed to the DISPATCH WG mailing list.
  • Oct 21, 2019. Announcement of topics that have been= dispatched for IETF-105.
  • Nov 4, 2019. Draft submission deadline.
N= ote, that while these dates are specific to DISPATCH WG, since we share our= slot with ART area, it would be helpful to know about potential ART area t= opics sooner rather than later, so we don't get into the situation like= we did at IETF-105 and have to cutoff important ART discussions.=C2=A0=C2= =A0

Regards,
Mary
DISPATCH WG = co-chair
--0000000000005710b205901517c4-- From nobody Mon Aug 19 14:48:23 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C036812087A for ; Mon, 19 Aug 2019 14:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 mfpqDf55bHeK for ; Mon, 19 Aug 2019 14:48:07 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 18D3C1200FF for ; Mon, 19 Aug 2019 14:48:07 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x7JLm2pD017187 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 19 Aug 2019 16:48:04 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1566251285; bh=UzU+fhKlFDpIf9M3U1gssn/VMinx58fySItSR626tXA=; h=Subject:From:To:Cc:References:Date:In-Reply-To; b=MCY05HBoQ+88pwV1STYyHYZXjh6K94RUGnjd5tXg4XcIJ+pjFFYuCkTjGFvsYDybQ nP+TUG6NcTr/Ti4NKVt3D2Fr4sZWvq1YjbboAUWywTLPQWc1jtX8zobX5Imwy6TOCs drXkElEXCLgm36mp4LpA2B9oaOJ5PFtbXnLfLTIk= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at From: Adam Roach To: Mark Nottingham , Jacob Hoffman-Andrews Cc: ART Area , "Devon O'Brien" References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> Message-ID: Date: Mon, 19 Aug 2019 16:47:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 21:48:13 -0000 I've seen precious little response to this (two messages in two weeks), and conclude that people either do not care; or, the people who do care can't reasonably be reached to weigh in on the topic. That said, I think that these responses combined with the input received during IETF 105 are a weak signal that that there is support for adjusting BCP 190 at least to the extent necessary to allow the "provisioned directory prefix" approach used by CT. So I'm going to clear my DISCUSS under the assumption that Mark will be putting forth a proposed amendment to BCP 190 in the near future. I'm happy to AD sponsor publication of such a change, assuming we can get a more vigorous level of participation than we did on this thread. /a On 8/2/19 3:15 PM, Adam Roach wrote: > For the purposes of clearing my discuss, I intend to read the > responses to Mark's message below as a reflection of consensus from > the community. If you have thoughts on the topic, please weigh in on > the ART-area mailing list no later than Friday, August 16th. > > People who have participated in the discussion in TRANS are very much > welcome to re-express their opinions in this thread. I'm also hoping > that we get some input from other participants -- even if it's > something as simple as "this sounds good to me" -- to make sure all > relevant perspectives are taken into account. > > Thanks! > > /a > > On 8/2/19 1:55 PM, Mark Nottingham wrote: >> It sounds like you (collectively) want an exception in BCP190 still, >> correct? >> >> If so, I think we just need to craft some language about that for >> inclusion in the spec; I'd imagine it need only be a sentence or two >> about it. Then the AD(s) need to convince themselves that it reflects >> consensus. >> >> The underlying issue is the text in 2.3 of BCP190; I think the >> emerging consensus is that it's too strict, in that it can be read to >> preclude using a prefix approach with a MUST NOT, when in fact the >> potential harm to other applications / the Web overall is pretty small. >> >> Does anyone disagree with that? >> >> Cheers, >> >> >>> On 31 Jul 2019, at 2:10 pm, Jacob Hoffman-Andrews >>> wrote: >>> >>> On Sat, Jul 27, 2019 at 11:26 PM Larry Masinter wrote: >>> The use of / in the path of URLs was supposed to >>> >>> be restricted to hierarchical data, and yet CT doesn’t >>> do that. >>> >>> http://masinter.blogspot.com/2019/05/on-nature-of-hierarchical-urls.html >>> >>> >>> >>> CT and all prefix-using APIs do that, with a single level hierarchy. >>> The domain owner specifies a prefix, ending with a "/". All of the >>> URLs that are part of the API follow that prefix - they are >>> subordinate in the hierarchy. >>> >>> Coming back to the main point: What remains in order to find >>> consensus on this issue? >>> >>> Thanks, >>> Jacob >> -- >> Mark Nottingham   https://www.mnot.net/ >> >> _______________________________________________ >> art mailing list >> art@ietf.org >> https://www.ietf.org/mailman/listinfo/art > > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art From nobody Mon Aug 19 23:06:42 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2166F120815 for ; Mon, 19 Aug 2019 23:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 xOOKaQg4hArz for ; Mon, 19 Aug 2019 23:06:36 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326871200CC for ; Mon, 19 Aug 2019 23:06:36 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1hzxHq-000JTo-Su; Tue, 20 Aug 2019 02:06:30 -0400 Date: Tue, 20 Aug 2019 02:06:24 -0400 From: John C Klensin To: Adam Roach , Mark Nottingham , Jacob Hoffman-Andrews cc: ART Area , Devon O'Brien Message-ID: <301DF34E4C5601BCA4D2BCBF@PSB> In-Reply-To: References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 06:06:40 -0000 Adam, I think you should consider an alternate hypothesis to "no one cares" and/or people "who do or might care cannot be reached". It is that the amount of traffic on a small number of subjects on the ART, architecture-discuss, and IETF lists has just been too great for those of us who have other responsibilities (inside or outside the IETF) to keep up on. A quick check of my "I need to find time to read this stuff" mail queue shows over sixty unread messages with "BCP 190" in the subject line and I've read a good many other messages. I don't track the TRANS list; I assume that, if I did, the count would be even higher. =20 Of course, the BCP 190 threads have not been the only ones. We have, or recently have had, a number of other discussion threads going on about such topics of clearly earth-shaking importance as whether 128 is a sufficiently auspicious number, to say nothing of whether and how much we can overspecify the IETF-ISOC relationship. I appreciate your good intentions in asking that people summarize or reprise remarks on the previous BCP 190-related threads but many of us, perhaps especially those of us who have been beaten up multiple times for repeating ourselves, just don't have time and/or consider it to be not in the best interests of the Internet to give this topic priority over everything else. And I suggest that, with the amount of traffic on the general subject of BCP 190 and its relationship to other work and the health of the Internet, the conclusion from two messages on this particular thread in two weeks should be "good try, but people were already worn out on this topic or the experiment of asking for summaries on a specific thread failed" rather than "no one cares or those who do are hiding somewhere". That said, let me try for a quick and inadequate summary of what I tried to say nearly a month ago in https://mailarchive.ietf.org/arch/msg/art/Ef09SVAnIMfGfkHSbEni9iC= YRas and to which you responded that same day. =20 I think "should we allow an exception to BCP 190 for CT" and "should we soften the language of BCP 190 a bit" (both very crude summaries) are answers to the wrong question and that the right question is very important to the future of the Internet or at least the relevance of IETF going forward. =20 Apologies to those who came along too late to be familiar with the battles of the 1980s and 1990s and to those who were closer to the details than I was an might summarize this differently. But the Internet technology "won" the so-called OSI wars and became the dominant networking and internetworking technology in large measure because the the Internet's design, and the ARPANET design before it, were pragmatic to an extreme. We made decisions for individual applications based on the actual functions that application was intended to support and for protocols based on whether they worked well enough, and were described well enough, to interoperate and determined success the same way. What we didn't do was to build elaborate models or norms about how protocols should behave and then treat those models and norms as a sort of Procrustean bed, evaluating protocol quality based on conformance to the model or deciding whether something was or was not legitimate based on how it fit the bed or whether it should be stretched or chopped off if it didn't. =20 >From that historical point of view, the problem is that BCP 190 was approved at all and the only surprise is that it took this long for it to become clear that it over-constrained real-world applications. To be clear and respond directly to your note of 23 July, in which you wrote: > It's going to take a while for me to formulate my thoughts > around what you say below. To make sure I understand the class > of constraints you're concerned about below, can you clarify > whether you think they apply to: >=20 > * Documents like BCP 200, RFC 2804, and BCP 188? I see those three as being at least a little bit different, essentially problem identification and policy statements rather than constraints on protocol design. I would see them as problems the moment a piece of work came around and someone said "you can't do that work in the IETF, or you cannot design a protocol in such-and-such a way because one of those documents says you can't" and was taken seriously. I do see a separate problem with how they, and other privacy-oriented documents and statements have been used, but that is part of a separate rant. > * Documents like BCP 9 and BCP 92? Also a completely different set of issues. These documents are essentially IESG statements, albeit with the claim of sufficient community approval to justify BCP status, about how the IESG intends to do business. They do not constrain the design of particular protocols (or even, in the case of BCP 92, the content of particular documents). > * Documents like BCP 25, BCP 54, and BCP 83? I wonder why you didn't add BCP 9 to that list. These are IETF procedural documents, differing from the previous group in that they specify how the IETF works, not how the IESG operates. They again do not constrain particular protocols. If I wanted to pick other documents that concern me the way BCP 190 does, I'd start with draft-thomson-postel-was-wrong/draft-iab-protocol-maintenance but with the qualification that the IAB is entitled to its opinion and presumably can't publish it as a BCP and insist that new protocols conform to its suggestions. =20 The thing I find objectionable about BCP 190 is that it specifies a design model for URIs generally and then tries to insist that new work conform to it. It changes a full Internet Standard (RFC3986) by using the BCP mechanism, something that, for many years at least, we would not allow. It arguably does not so much update 3986 as it reinterprets some of its provisions. While objectionable, that would be ok in a BCP if "BCP" were taken seriously as a general statement of preferred practices, not a "you can't do this in the future, no matter what the circumstances, because we said so" protocol constraint. =20 > You might see an unstated agenda in the categories of > documents I list above, so I'll state it explicitly: in the > general case, one person's important protections against a > tragedy of the commons is another person's annoying impediment > to be ignored and defeated. I get that not all of the above > read on protocol design; actually none of them do in the sense that BCP 190 does. > but they do share the common feature > that they've gone through the IETF consensus process (at least > to the degree that such a process existed at the time of their > respective publications). If we're going to carefully parse > out the meanings of some of them as the will of the community > while treating others as light guidelines to be ignored when > they become cumbersome, we're going to need to agree on a > pretty bright line that divides those categories. First of all, if you review RFC 2026 and understand it as I always have, BCPs (other than those that specify IETF or IESG procedures and the like) do not represent "the will of the community" at all. They represent community consensus about desirable (or "best") contemporary practices. They are not protocol specifications ("Technical Specifications" in 2026-speak) and they are not Applicability Statements either. Both types of traditional standards track documents (Section 3 or 2026)-- TS and AS -- presumably represent that will of the community about what should be done and how. From that standpoint, a BCP is just commentary. Section 5 of 2026 does say "...best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function" but I don't think that contradicts what I'm saying because best current thinking can change. So, if RFC 7320 represents best current thinking as of July 2014 and some document comes along that represents newer thinking, potentially involving conditions that 7320 did not consider, it is probably entirely reasonable to insist that the authors of the new document explain those conditions and resulting thinking. It is closer to that Procrustean bed if those authors have to apply for an exception to BCP 190 or relitigate it as a condition for moving forward. I think that is at least close to your bright line. best,=20 john --On Monday, August 19, 2019 16:47 -0500 Adam Roach wrote: > I've seen precious little response to this (two messages in > two weeks), and conclude that people either do not care; or, > the people who do care can't reasonably be reached to weigh in > on the topic. That said, I think that these responses combined > with the input received during IETF 105 are a weak signal that > that there is support for adjusting BCP 190 at least to the > extent necessary to allow the "provisioned directory prefix" > approach used by CT. >=20 > So I'm going to clear my DISCUSS under the assumption that > Mark will be putting forth a proposed amendment to BCP 190 in > the near future. I'm happy to AD sponsor publication of such a > change, assuming we can get a more vigorous level of > participation than we did on this thread. >=20 > /a >=20 > On 8/2/19 3:15 PM, Adam Roach wrote: >> For the purposes of clearing my discuss, I intend to read the = >> responses to Mark's message below as a reflection of >> consensus from the community. If you have thoughts on the >> topic, please weigh in on the ART-area mailing list no later >> than Friday, August 16th. >>=20 >> People who have participated in the discussion in TRANS are >> very much welcome to re-express their opinions in this >> thread. I'm also hoping that we get some input from other >> participants -- even if it's something as simple as "this >> sounds good to me" -- to make sure all relevant perspectives >> are taken into account. >>=20 >> Thanks! >>=20 >> /a >>=20 >> On 8/2/19 1:55 PM, Mark Nottingham wrote: >>> It sounds like you (collectively) want an exception in >>> BCP190 still, correct? >>>=20 >>> If so, I think we just need to craft some language about >>> that for inclusion in the spec; I'd imagine it need only be >>> a sentence or two about it. Then the AD(s) need to convince >>> themselves that it reflects consensus. >>>=20 >>> The underlying issue is the text in 2.3 of BCP190; I think >>> the emerging consensus is that it's too strict, in that it >>> can be read to preclude using a prefix approach with a MUST >>> NOT, when in fact the potential harm to other applications >>> / the Web overall is pretty small. >>>=20 >>> Does anyone disagree with that? >>>=20 >>> Cheers, >>>=20 >>>=20 >>>> On 31 Jul 2019, at 2:10 pm, Jacob Hoffman-Andrews=20 >>>> wrote: >>>>=20 >>>> On Sat, Jul 27, 2019 at 11:26 PM Larry Masinter >>>> wrote: The use of / in the path of URLs was >>>> supposed to >>>>=20 >>>> be restricted to hierarchical data, and yet CT doesn't >>>> do that. >>>>=20 >>>> http://masinter.blogspot.com/2019/05/on-nature-of-hierarchi >>>> cal-urls.html=20 >>>>=20 >>>>=20 >>>>=20 >>>> CT and all prefix-using APIs do that, with a single level >>>> hierarchy. The domain owner specifies a prefix, ending >>>> with a "/". All of the URLs that are part of the API >>>> follow that prefix - they are subordinate in the = hierarchy. >>>>=20 >>>> Coming back to the main point: What remains in order to >>>> find consensus on this issue? >>>>=20 >>>> Thanks, >>>> Jacob >>> --=20 >>> Mark Nottingham=C2=A0=C2=A0 https://www.mnot.net/ >>>=20 >>> _______________________________________________ >>> art mailing list >>> art@ietf.org >>> https://www.ietf.org/mailman/listinfo/art >>=20 >>=20 >> _______________________________________________ >> art mailing list >> art@ietf.org >> https://www.ietf.org/mailman/listinfo/art >=20 >=20 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art From nobody Tue Aug 20 00:05:02 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1F5120870 for ; Tue, 20 Aug 2019 00:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=nomountain-net.20150623.gappssmtp.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 MG7Ra7IzLpvj for ; Tue, 20 Aug 2019 00:04:58 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 3AC0D1200B3 for ; Tue, 20 Aug 2019 00:04:58 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id w16so2801912pfn.7 for ; Tue, 20 Aug 2019 00:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=qmmBrocnbtuU6RYv7zkOosEQvJwqEUGgCI/gW8+pG30=; b=CtTDPINCGdCT//vGDvf6xuf3FqoZ477aRV0aAzoHI4kZv2jf8sjQy7+KnJ37gbNzkq 6FOHqOlaalc/ofjQgOgasVHE4tTtIBCDELtPe/pwKJtvlza6B6X+zTw7w4aFkraowCV9 FVzPDxw00EOAkhusNjlqQKEffEqo/VzIbPLnLqKda4Js3GUGz9kvPvvA5NpdiJojASMh LAZNqRJHOJBJ/UkoFH+3jWq5IchsssYRGaf0uhVP+8XpRftm67eFpwUmsMtJNiOlLyo2 7iPxP8CARWhCKiX/ojodgDnv68PV664BKapzTS0clAkRAkLDOsUX1XvvZ4yOYHHZWv52 I0cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=qmmBrocnbtuU6RYv7zkOosEQvJwqEUGgCI/gW8+pG30=; b=YweqxOEKpdYEwIjI4N4rtXHPTR1XYgqODb4uIiHoW3a2mteqmiyj2I4wzPqMBQI7H0 sgNacoPUV9UnHs0pZ6KwEXJBs/ZXo7f/OSa+APFAhW4ycoH1if3AbCOtkiHp3adAlt6p r5Rqz86Id+ZAyKgNFFbv3KoKDiwnP1yRUV4kjQG6mLkUouQYPLNtLzdztjBpfaf8Mf6j b0IeBHkL3CU9KIe8/dHmp/kdYWpEr66nQi5sfSBZ9bzQM/5pgxF7aJYqIToXvB1Wb7gi L8HwbP0hz/pOPkoYKYNrrGvU3myRGb9LDoUEqJNZmJw5I+nycZouKpTqGNnBcY1YSljm 9m7A== X-Gm-Message-State: APjAAAWRpdEBbd2XByCZ3VRIhGrEcShq9aiUKl617DDkLI9VzzP3brrz HtBQTAaJmwPt+7DNCdsJfv5qif1MNg== X-Google-Smtp-Source: APXvYqwdDY6KUkO6zl5LX+MDkVmoXbvV3wb+XiGDJm9+EZ55EkoL2N+ioflyllh9+iiYWFEuqURcug== X-Received: by 2002:a63:e20a:: with SMTP id q10mr22926963pgh.24.1566284697323; Tue, 20 Aug 2019 00:04:57 -0700 (PDT) Received: from aspen.local (63-140-73-7-rb1.jnu.dsl.dynamic.acsalaska.net. [63.140.73.7]) by smtp.gmail.com with ESMTPSA id ck8sm15155015pjb.25.2019.08.20.00.04.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Aug 2019 00:04:56 -0700 (PDT) To: art@ietf.org References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> From: Melinda Shore Openpgp: preference=signencrypt Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= mQINBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABtCxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PokCVAQTAQoAPgIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaXRaAAoJ EN+4kXKadtuPVioP/3nVzx33yjiEtqLKTEHwofnLT15CV5wAcGa0DTbqgiomVKzSRkkhbF3Z KIHYrnjVpTcYJuW+PmFSIjNizNVr+vvjNP6ptRqx5orWmK4EBe/B9mrpmIshxUwkYr46uwN4 h06xJS3KCzhfhSsnesH5vlGBkUod0+nQhbSLyLRpxmaKaeAl4dxFSBLU0vUJMLH8PXTZVNof 5Yo+ThqCzu1pwOkBQ8gST2J6zdy4PjU9ENQ9RLAamlAG/6rGHEKLFcnUpEg7Tcu1hSzAsqR8 kjX2Prpu4A9DyLCjTOvfOPQa8WjZy18ZdYOxuPxdrTazeCRVJIvYRflhBCZb744jhMyfAiSW eckwRBVSCnBuvWBJl9Ua1wp8SOUXXhgGI8WGvSkvul6kKSkHQKDggd4cojAhxWLfvmjxn5pz 0BNbvrEBGqgWwO1ZMuJpmv3P8YK5Aytsl85NZoMMUJIDxEQhBUgYz5QTQANBKPi8RsfOntho rhzXLqnPPQcE4Xf9O9XIyy077F0JoyiPx74Zsl1dTxmT73pezpfhKUQR7/QlmJ/FAADpb6SO V0tlgBtR6FAZToBYPDiss57AcKM1zzyJ7sHIZkxQelykYSet6hp2WGcwMXQveWqFMQ4fiGQx XNEPO+KZKNj+0sfINzSLP88O5TniM/l/JrjZZNT/lVAQDTdkCBGyuQINBFppZ0gBEACgZuM1 8ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1YZ0O pQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR35FAg SnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fEZHM6 6phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQV0yB gc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4cztv gmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRHRvQs 0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBjLtx1 tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI7qDH FxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnYjMJo dU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABiQI8BBgBCgAmFiEET2gtkyoXlvgg8jTA37iR cpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ75iY5 pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiFPjkr QIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/JYK75 BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApMLL0R /qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV5abZ +iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJRi+cH 7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7Vz9F +6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloSbbMv P9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjxuLzd LY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+31fk1 HKwqd9xRxC8= Message-ID: Date: Mon, 19 Aug 2019 23:04:53 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bPMYE2elzzYK0U6ubv2uFmDvpLAwsA68c" Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 07:05:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bPMYE2elzzYK0U6ubv2uFmDvpLAwsA68c Content-Type: multipart/mixed; boundary="JAab73RpEud3nP7V5M5Z91IG2dWFnMuAp"; protected-headers="v1" From: Melinda Shore To: art@ietf.org Message-ID: Subject: Re: [art] Call for Consensus: Re: On BCP 190 References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> In-Reply-To: --JAab73RpEud3nP7V5M5Z91IG2dWFnMuAp Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 8/19/19 1:47 PM, Adam Roach wrote: > I've seen precious little response to this (two messages in two weeks),= > and conclude that people either do not care; or, the people who do care= > can't reasonably be reached to weigh in on the topic.=20 It's August and an awful lot of people are on holiday. I'm still digging through my email after two weeks away. I've sent a nudge to the trans mailing list in the interest of getting more input on this, but discussion in Montreal and afterwards suggested that the interest in finding some reasonable compromise is broader than in just trans. > So I'm going to clear my DISCUSS under the assumption that Mark will be= > putting forth a proposed amendment to BCP 190 in the near future. I'm > happy to AD sponsor publication of such a change, assuming we can get a= > more vigorous level of participation than we did on this thread. Thanks very much - this sounds like a reasonable way forward. We'll make sure to get more participation from the CT community, since we're the ones with the most pressing use case, from what I can see. Melinda --=20 Melinda Shore melinda.shore@nomountain.net Software longa, hardware brevis --JAab73RpEud3nP7V5M5Z91IG2dWFnMuAp-- --bPMYE2elzzYK0U6ubv2uFmDvpLAwsA68c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEET2gtkyoXlvgg8jTA37iRcpp2248FAl1bm5YACgkQ37iRcpp2 24/ZcA/+NqvcCQ2A2bt0+CaoLKzY6ONH4LEvwRLE8+UT/0E6hMRM2eU0W96uPXhA o6yRPL8B8eZH3+IFnzK3fw2h8/NASXwF4epeHHYJVHIV535+Kx/HUu5WUxKybZyV Pel/UaRYpVuGsVEx0Kmmhd70EQGLDmtBhHt7gJcbAR1Xvo3DMMycuFK0DyN+iCNt 9BzvFs5qYg4k15F3eRxFJl8l/TyIA1VG63lf6iphHHnAjZbu3xcTPKPte6F3OusI SbyQn0GE9jhJXCezcmMJSaHJVQSbxeMjnLrPxVmACaZYXRYLUDGIs2TuAtTH91gM q0jBwBkrAf/ukuP/ZCbUIo1J9HN2gUfaL1WehuB8YrWWP++hpP0H+gZBpUVCMPmf mQiUtTaKTGLucfMp4emE7Zyj47rUFfFpEl40vzcq4uvFx37sZUkXI23dWDYVxBsZ xK2YWOHXTVB6IS/QVGzss7RQI0dodM1TpF5GkKSzavHZmjBl74X/O+jmOERL+CX7 KGgs9o40rlD/e/R3hCcGEs/HzpKeJs7Bv9QVPIt6T0zOqoymr9YlEs1SZ4PZvpC7 hMcYEzIHCGj97EiUYKBW+CIlQLgrf+FxDTUhGczDSWt69pUk6Drmn+Q7CyWzrLpC zCK955dR+3B3WBqK56ymFZ0T9fpBhguMPAzVP7xB4vE10p+4Czg= =lqZh -----END PGP SIGNATURE----- --bPMYE2elzzYK0U6ubv2uFmDvpLAwsA68c-- From nobody Tue Aug 20 00:34:29 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24285120878 for ; Tue, 20 Aug 2019 00:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=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=tCnqnk43; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GoMPmlBc 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 HAFrTW2SXp6m for ; Tue, 20 Aug 2019 00:34:23 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAD1812013A for ; Tue, 20 Aug 2019 00:34:23 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id F11E822087; Tue, 20 Aug 2019 03:34:22 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 20 Aug 2019 03:34:22 -0400 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=fm3; bh=D i6y55xAIO/8NaDLshmRaQAD8IyF5DHBJJHLMiWY9UE=; b=tCnqnk43enHrBac8T dPpjx8XZmRfPwkJGPb0sxx/1Dyo48I+ZKGUI4T0OVkDrxXW6mw8RXOVbNLBArnIr hRL3vD5m91yd44ZVJ8vuYBYwNHft6pCEJsgqfiTznQSmMQcoiujat3jebWtKYYzg xbiumi05VT0aPskfDK96GEucGt9RvWJtzv4L36ImCzIuebE9bzX0WYKfOKG5PG4n LT5WoIPKcvSXsZEo6lx734SIBeOiBnmCgGFjtvAyMhVlrq3OoM7sdxeM9y6/l3wW wsXeWGi6dvSm4K6uGTDMClHCglwT/70ab7OI2STt+CIuV453UkCOlu4CbS1vYXYn mGh6g== 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=fm3; bh=Di6y55xAIO/8NaDLshmRaQAD8IyF5DHBJJHLMiWY9 UE=; b=GoMPmlBc813GvFZQGXPU/HVXN8CeiFNkk5cwWMnTKJ9B3oKesXCrSW6rw I9G1CaJFMIeOoynnEEzrKuk+Y6n8fII53wrnC8Z0UGaIHRGH7FB3Lln/zTk84Jxx YKeQ4ZCJfzYr72Xyqg10WY+nQOstabOaVZpOxbXGWf+6+8VyCl+zZJ6k7Zqr8ZaA /idBRJkDeYxPiymb+nM7sfQcB5IXHjX6br6gLTbCG+FyrC2P/HP7J6vtiJ8lxMux shA7a1FDPhBOFTLrGyoZC+HNHweUqz4qq3j7i1FBjN0txhEoox/IlpOgeJV0T8BH Q7P3ySLgoCxEwJBR68/AqkbBHV0qA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudegtddguddvgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfjughrpegtggfuhfgjfffgkfhf vffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomh hnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrihhopdhmnhho thdrnhgvthenucfkphepudeggedrudefiedrudejhedrvdeknecurfgrrhgrmhepmhgrih hlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 5D29180059; Tue, 20 Aug 2019 03:34:19 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mark Nottingham In-Reply-To: <301DF34E4C5601BCA4D2BCBF@PSB> Date: Tue, 20 Aug 2019 17:34:14 +1000 Cc: Adam Roach , Jacob Hoffman-Andrews , ART Area , Devon O'Brien Content-Transfer-Encoding: quoted-printable Message-Id: References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> <301DF34E4C5601BCA4D2BCBF@PSB> To: John C Klensin X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 07:34:27 -0000 John, > On 20 Aug 2019, at 4:06 pm, John C Klensin wrote: [ many words elided ] > The thing I find objectionable about BCP 190 is that it > specifies a design model for URIs generally and then tries to > insist that new work conform to it. [...] > It arguably does not so much update 3986 as it reinterprets some of = its > provisions. While objectionable, that would be ok in a BCP if > "BCP" were taken seriously as a general statement of preferred > practices, not a "you can't do this in the future, no matter > what the circumstances, because we said so" protocol constraint. [...] > So, > if RFC 7320 represents best current thinking as of July 2014 > and some document comes along that represents newer thinking, > potentially involving conditions that 7320 did not consider, it > is probably entirely reasonable to insist that the authors of > the new document explain those conditions and resulting > thinking. It is closer to that Procrustean bed if those > authors have to apply for an exception to BCP 190 or relitigate > it as a condition for moving forward. As has been said, I think that we failed to distinguish between = practices that could be harmful to other uses -- and therefore should be = prohibited -- and those that are just ones you want to think about = before engaging in. I committed to performing an update to reflect this, = so before we spill too many bits on this topic, perhaps it would be good = to look at that and then discuss. To that end, I've just published a -00 [1] that's just a copy of the = BCP; I'll do some refinement along the lines above and then see where = we're at. Cheers, 1. draft-nottingham-rfc7320bis, although = might be easier on the eyes. -- Mark Nottingham https://www.mnot.net/ From nobody Tue Aug 20 03:56:11 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95BCA1200DE for ; Tue, 20 Aug 2019 03:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 uFq2JUyA5wtd for ; Tue, 20 Aug 2019 03:56:07 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B38112001A for ; Tue, 20 Aug 2019 03:56:07 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1i01o1-000KMi-MK; Tue, 20 Aug 2019 06:56:01 -0400 Date: Tue, 20 Aug 2019 06:55:55 -0400 From: John C Klensin To: Mark Nottingham cc: Adam Roach , Jacob Hoffman-Andrews , ART Area , Devon O'Brien Message-ID: In-Reply-To: References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> <301DF34E4C5601BCA4D2BCBF@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 10:56:10 -0000 Mark, Happy to wait, but a few comments going forward: * For Adam, there is some question in my mind about whether it is desirable to clear a Discuss based on a plan about a document that has not been written yet, that has no firm schedule, etc. * It seems to me that your "for the users" draft suffers from some of the same issues as 7320. It might be worth having a look at that concurrently and in the same light. * If you/we are going to do a 7320bis, a careful examination of whether it should really be handled as a BCP or whether it is an A/S or actual substantive update to 3986 would be in order. In addition, several of the comments in 7320 seem far more relevant to locator-type URIs rather than name-type ones. The revision should probably be scrutinized to be sure that it doesn't say things that does not invite a tangle or other awkwardness for URNs or, even in theory, other name-type URI. I guess the good news is that a 7320bis is likely to get much closer examination in the community than it now appears that 7320 received. best, john --On Tuesday, August 20, 2019 17:34 +1000 Mark Nottingham wrote: > John, > >> On 20 Aug 2019, at 4:06 pm, John C Klensin >> wrote: > > [ many words elided ] > >> The thing I find objectionable about BCP 190 is that it >> specifies a design model for URIs generally and then tries to >> insist that new work conform to it. > > [...] > >> It arguably does not so much update 3986 as it reinterprets >> some of its provisions. While objectionable, that would be >> ok in a BCP if "BCP" were taken seriously as a general >> statement of preferred practices, not a "you can't do this in >> the future, no matter what the circumstances, because we said >> so" protocol constraint. > > [...] > >> So, >> if RFC 7320 represents best current thinking as of July 2014 >> and some document comes along that represents newer thinking, >> potentially involving conditions that 7320 did not consider, >> it is probably entirely reasonable to insist that the authors >> of the new document explain those conditions and resulting >> thinking. It is closer to that Procrustean bed if those >> authors have to apply for an exception to BCP 190 or >> relitigate it as a condition for moving forward. > > As has been said, I think that we failed to distinguish > between practices that could be harmful to other uses -- and > therefore should be prohibited -- and those that are just ones > you want to think about before engaging in. I committed to > performing an update to reflect this, so before we spill too > many bits on this topic, perhaps it would be good to look at > that and then discuss. > > To that end, I've just published a -00 [1] that's just a copy > of the BCP; I'll do some refinement along the lines above and > then see where we're at. > > Cheers, > > 1. draft-nottingham-rfc7320bis, although > might be easier on > the eyes. > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Tue Aug 20 08:30:27 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088AD120960 for ; Tue, 20 Aug 2019 08:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 yuBb9TIu2pWG for ; Tue, 20 Aug 2019 08:30:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B38C9120104 for ; Tue, 20 Aug 2019 08:30:24 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x7KFUJZb043362 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Aug 2019 10:30:20 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1566315021; bh=/k43Lz9n5G29+kzu3rTaqEw4dyhgr2xcMr6nRQS5OHk=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=cxG0LixXPYvIKUqD/AoZn6Ss8x8tEEmjNFsKvApK9gGtUjmClqSbAqoGs958w6uvl IKqHM89XamwGbdxm9XxsjAT+5UnQmjDNosUTDsVdejng22jV/NkcK//cZPDMpX/wWE /Jy9QHXKfqbI1nTGQnElRoqIgzR0j+bOxLthm2O0= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: <52942FE2-6C74-4E45-A077-B3004A3FC6D3@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_676E4210-2FE5-4514-8B77-55FED77EF131"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 20 Aug 2019 10:30:12 -0500 In-Reply-To: Cc: Mark Nottingham , Jacob Hoffman-Andrews , Adam Roach , "Devon O'Brien" , ART Area To: John C Klensin References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> <301DF34E4C5601BCA4D2BCBF@PSB> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 15:30:26 -0000 --Apple-Mail=_676E4210-2FE5-4514-8B77-55FED77EF131 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Commenting on just one point (I am agnostic on the others): > On Aug 20, 2019, at 5:55 AM, John C Klensin wrote: >=20 > Mark, >=20 > Happy to wait, but a few comments going forward: >=20 > * For Adam, there is some question in my mind about whether it > is desirable to clear a Discuss based on a plan about a document > that has not been written yet, that has no firm schedule, etc. In this case, I think Adam is saying that we don=E2=80=99t have = consensus that the draft in question is really wrong. It could take months to years to figure out what we really want BCP190 = to say. I agree with Adam that we should not hold current work hostage = to that. Holding up work due to non-critical externalities is a very = good way to kill momentum. [=E2=80=A6] Thanks! Ben. --Apple-Mail=_676E4210-2FE5-4514-8B77-55FED77EF131 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAl1cEgQACgkQgFZKbJXz 1A1qsg/+Muf3BKSCTE2AuCzyuNR9uMq4KosdUjs/xG6h+oxM8XGOqjA4j+MMI0S4 R6uKmud5IKGdi7hP8KZjxym/veXuzxjfhI4LnsBtPuJaIZuB5h47IrbtkE8g+aqt HG4SjoPNugfUdoe1aPAE+b72NyjJ8FxAgTLYCjgE52Md7DB4tV5w9aWyKHPkgTSA +N3KOu6JWjgQN3MPAelRxSCpee9Tj1wB0eA6sIsMXyfwsTTXBQZAIWUpV3KKgiNs fCb8Y1mZmzIl/+2xl6GPcjDSz051haQU40z3dR3Fu6r/YuKN7qUpIuRDFzn+NEhZ mxcaP3S3Bk5WobnEQcDBOh0AG+KZcUknbeHYejDB5+QLYBfRx05q+djQ9z3HQ7qu GWFyPtQkkeUU6FaJyXD/j9uHqfcIM6yWfTwmI7laeom44dfOTCX2Ftb6KrEMvFBo BdrqeV8zhk/P19Yce049RPkCt3brGOZQO08wugMQs+zZCS31PoyLNze4CtG40hmZ uncmFX8DdbBsyvfZ1v3O7Bwe/4ivrfoqSo30daV5IvdLnN5YGO9Ugkp9s06318JL WvcieiTd0+LCWPX6JIpHigHpDA/SpXfCv3nzi5UWQoVCmBm8KRyychDv1yJRZvEY pqoOtBiKQuPO6qkFmQSBkLXZ8CAQFCYJvS5yOFyDy07FWbHDblk= =fqIV -----END PGP SIGNATURE----- --Apple-Mail=_676E4210-2FE5-4514-8B77-55FED77EF131-- From nobody Tue Aug 20 09:38:07 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256E212096D for ; Tue, 20 Aug 2019 09:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 CsRcei0rlgQH for ; Tue, 20 Aug 2019 09:38:04 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A533120106 for ; Tue, 20 Aug 2019 09:38:04 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1i078w-000L1J-UX; Tue, 20 Aug 2019 12:37:58 -0400 Date: Tue, 20 Aug 2019 12:37:52 -0400 From: John C Klensin To: Ben Campbell cc: Mark Nottingham , Jacob Hoffman-Andrews , Adam Roach , Devon O'Brien , ART Area Message-ID: In-Reply-To: <52942FE2-6C74-4E45-A077-B3004A3FC6D3@nostrum.com> References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> <301DF34E4C5601BCA4D2BCBF@PSB> <52942FE2-6C74-4E45-A077-B3004A3FC6D3@nostrum.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 16:38:06 -0000 --On Tuesday, August 20, 2019 10:30 -0500 Ben Campbell wrote: > Commenting on just one point (I am agnostic on the others): >=20 >> On Aug 20, 2019, at 5:55 AM, John C Klensin >> wrote: >>=20 >> Mark, >>=20 >> Happy to wait, but a few comments going forward: >>=20 >> * For Adam, there is some question in my mind about whether = it >> is desirable to clear a Discuss based on a plan about a >> document that has not been written yet, that has no firm >> schedule, etc. >=20 > In this case, I think Adam is saying that we don't have > consensus that the draft in question is really wrong. >=20 > It could take months to years to figure out what we really > want BCP190 to say. I agree with Adam that we should not hold > current work hostage to that. Holding up work due to > non-critical externalities is a very good way to kill = momentum. >=20 > [=E2=80=A6] Then we are very much in agreement. A different way of expressing the concern about protocol-restricting documents that are treated as requirements is that other work gets held up while we try to converge on protocol models, philosophy of protocols, or other externalities that become critical only if we make them critical... and doing that is generally a bad idea. Holding up work that way not only kills momentum, but may cause critical people to simply give up and go away while others debate the angel population of the heads of various pins. best, john From nobody Tue Aug 20 10:03:42 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AEF12011F for ; Tue, 20 Aug 2019 10:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 bhsdp-cXZsWI for ; Tue, 20 Aug 2019 10:03:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 F019A1200EB for ; Tue, 20 Aug 2019 10:03:38 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x7KH3XBO059846 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Aug 2019 12:03:35 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1566320616; bh=xTwd04/QyPX7YA7PTFGgqs/wq1FW9xehTXMfXEDee+c=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=btERK/nXVJbXxVsCcvWz2qqbEq5qCixRYOA7H6oabTm/H1AuL9niy6LoRdV+Hw8ql EpywKypFfPvNq8K10Y2vmPCE/jIlrQJypvHznXjc63Eox3viMauYuRx7SbcD6q/5p1 Q8SOdGG7UaFlL4GVsIGY8ZsJ7VfKhke9faKWnhxo= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: John C Klensin , Mark Nottingham , Jacob Hoffman-Andrews Cc: ART Area , "Devon O'Brien" References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> <301DF34E4C5601BCA4D2BCBF@PSB> From: Adam Roach Message-ID: Date: Tue, 20 Aug 2019 12:03:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <301DF34E4C5601BCA4D2BCBF@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 17:03:40 -0000 On 8/20/19 1:06 AM, John C Klensin wrote: > So, > if RFC 7320 represents best current thinking as of July 2014 > and some document comes along that represents newer thinking, > potentially involving conditions that 7320 did not consider, it > is probably entirely reasonable to insist that the authors of > the new document explain those conditions and resulting > thinking. Certainly; and if the thinking had come out of, say, a working group whose charter dealt primarily with URIs or with HTTP, then it would be somewhat more plausible that people with an appropriate depth of domain knowledge had been involved in that process. I suspect that part of the problem is that you're too close to ART technologies to see the forest for the trees, and so assume a level of expertise in ART technologies across the entirety of the IETF that is somewhat higher than actually exists. This might become clearer if we hypothesize an identical situation with the players reversed: if an ART working group had specified the population of an initialization vector for an encryption algorithm in a way that had been documented by the SEC area as problematic, I would hope that the SEC ADs wouldn't write that off as simply representing "newer thinking" about cryptography, and that they would insist that the document conform to documented security practices; or, failing that, at least involve the SEC community in a discussion about whether the specific use of security technology was, in fact, problematic. If you think that would be the wrong outcome, then I believe we simply have an irreconcilable difference of opinion. I will, of course, consider input from the community on this topic and act accordingly, but I suspect that most people will, after careful consideration, agree that these kinds of backstops are actually useful. /a From nobody Tue Aug 20 10:15:01 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CBF120232 for ; Tue, 20 Aug 2019 10:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 iHjISv4rUb5E for ; Tue, 20 Aug 2019 10:14:59 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 804FF12018D for ; Tue, 20 Aug 2019 10:14:59 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x7KHEt9G061665 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Aug 2019 12:14:57 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1566321298; bh=qST6w+gl5nhdorAipjGlCaam7pXo5WNpcNb9xUVc5pg=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Lc8pUOcoOR1JhjN2rfEbzR02gsL6cKCyPw2AkNudTJREdAECxL1nnqWiE+X1Qyqez HveoS4AYZgc/YcMqSp1hRluHGjQtsR3bbWuB/m+xLBJmCT53+cUCir9TI8loW43scT jVDrGGynx2GkLk/RvQxF1O+K2K9GM1E1Y8j+p62Y= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: John C Klensin , Mark Nottingham Cc: Jacob Hoffman-Andrews , ART Area , "Devon O'Brien" References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> <301DF34E4C5601BCA4D2BCBF@PSB> From: Adam Roach Message-ID: <80bb60b7-cdc7-0df8-6a33-726839b15dfe@nostrum.com> Date: Tue, 20 Aug 2019 12:14:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 17:15:00 -0000 On 8/20/19 5:55 AM, John C Klensin wrote: > * For Adam, there is some question in my mind about whether it > is desirable to clear a Discuss based on a plan about a document > that has not been written yet, that has no firm schedule, etc. I agree that it's not ideal. I'm having to balance the possibility that the end result of community discussion will result in not removing this restriction against delaying the TRANS document until we're 100% certain. Given that we've done a reasonable shaking of the trees over the past month, and no one has dropped out to strongly defend the specific provision in question, it appears likely that the end result will work out. Is this perfect? No. Is it pragmatic? Yes; and you've been championing pragmatism in this thread, so I would expect you to be on board. /a From nobody Tue Aug 20 11:34:04 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9C21207FE for ; Tue, 20 Aug 2019 11:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 c0TYkpE2PGhX for ; Tue, 20 Aug 2019 11:34:02 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7DBD120046 for ; Tue, 20 Aug 2019 11:34:01 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1i08xA-000LE3-A4; Tue, 20 Aug 2019 14:33:56 -0400 Date: Tue, 20 Aug 2019 14:33:49 -0400 From: John C Klensin To: Adam Roach , Mark Nottingham cc: Jacob Hoffman-Andrews , ART Area , Devon O'Brien Message-ID: In-Reply-To: <80bb60b7-cdc7-0df8-6a33-726839b15dfe@nostrum.com> References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> <301DF34E4C5601BCA4D2BCBF@PSB> <80bb60b7-cdc7-0df8-6a33-726839b15dfe@nostrum.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 18:34:04 -0000 --On Tuesday, August 20, 2019 12:14 -0500 Adam Roach wrote: > On 8/20/19 5:55 AM, John C Klensin wrote: >> * For Adam, there is some question in my mind about whether it >> is desirable to clear a Discuss based on a plan about a >> document that has not been written yet, that has no firm >> schedule, etc. > > > I agree that it's not ideal. I'm having to balance the > possibility that the end result of community discussion will > result in not removing this restriction against delaying the > TRANS document until we're 100% certain. Given that we've done > a reasonable shaking of the trees over the past month, and no > one has dropped out to strongly defend the specific provision > in question, it appears likely that the end result will work > out. Is this perfect? No. Is it pragmatic? Yes; and you've > been championing pragmatism in this thread, so I would expect > you to be on board. I am on board (a bit more explanation in my response to Ben). I don't think we are far apart, so let me try saying this in a different way. I think there is at least rough consensus that parts of RFC 7320 were a mistake, whether because their were overly prescriptive or for some other reason. I don't think there is consensus about which parts or what the right remedy for them is. The best way to deal with that problem is exactly what you and Mark have proposed -- get a new, replacement, I-D up and focus on it rather than on picking 7320 apart. In a more perfect world, I'd like to see 7320 deprecated, with the focus on that new document and no actual or apparent conflict between CT and anything. If that were proposed now, I'd oppose it because it would hold the other work up by at least four weeks to no good purpose. On the other hand, while I don't think it is important enough to hold things up either, I'd be happier with a statement from you that, instead of saying that you are clearing the Discuss because Mark is working on a revision, said something closer to that you are clearing the Discuss because there is a plan about a revision but, if that doesn't happen, you will open a discussion about deprecating 7320. Don't waste time with it now, but I believe that thinking about the difference might inform future actions and might better explain what I'm objecting to. Also... >... > I suspect that part of the problem is that you're too close to > ART technologies to see the forest for the trees, and so > assume a level of expertise in ART technologies across the > entirety of the IETF that is somewhat higher than actually > exists. I actually don't think so in this case. FWIW, remember that I'm spending most of my IETF time these days on Internationalization, a topic area that has been rooted in Apps and now ART but that his implications in many IETF areas. It would it would be quite difficult to underestimate the level of expertise across the entirety IETF or even in ART as a whole. So I am reasonably familiar with that problem. > This might become clearer if we hypothesize an identical > situation with the players reversed: if an ART working group > had specified the population of an initialization vector for > an encryption algorithm in a way that had been documented by > the SEC area as problematic, I would hope that the SEC ADs > wouldn't write that off as simply representing "newer > thinking" about cryptography, and that they would insist that > the document conform to documented security practices; or, > failing that, at least involve the SEC community in a > discussion about whether the specific use of security > technology was, in fact, problematic. Agreed. But not quite an identical problem. If this had been about, e.g., an issue with calendaring, I'd say "nearly identical problem". If there were reasonably high confidence that the active participants in the WG understood the issues (and, btw, there were more than three or four of them), I would also expect that most of us would be comfortable going forward within in-depth review from elsewhere in the IETF. However, that is much less true of things like URIs or some other web-associated technologies, especially when the IETF is considering foo-over-HTTP protocols and XML and JSON as general, and perhaps mandatory, data representation structures. Similar comments can be made about i18n because, while much of the action is in ART, there are issues about identifiers and other issues in multiple areas --Security and Internet being obvious examples-- that the IETF is in trouble if all of the expertise is in ART and others become inclined to just let things go (especially given how little expertise there actually appears to be in ART). There is another difference. In the example you used, it would be reasonable to assume that the documentation in the SEC area actually represented consensus in the area and among experts (I think, at least historically, almost the same thing in SEC, although not quite) about the problems. I don't believe that is the case about 7320 across the ART area, as some of the discussion _among active participants in ART_ in the various recent threads about BCP 190 illustrates. I don't believe it was the case five years ago either, but that would be hard to prove at the time. That suggests an intra-ART problem and is closely connected to why I've felt from the beginning of this discussion that the IETF had a BCP 190 problem and not a problem with the CT work. So, should ART have flagged this? Absolutely. But then I think we should have figured out, much more quickly than we have, that there are fundamental problems with BCP 190, started addressing those problems a month or two ago, and figured out how to Do the Right Thing and move on -- both to clear the CT work to progress and to start cleaning up 7320. > If you think that would be the wrong outcome, then I believe > we simply have an irreconcilable difference of opinion. I > will, of course, consider input from the community on this > topic and act accordingly, but I suspect that most people > will, after careful consideration, agree that these kinds of > backstops are actually useful. I think that is the right outcome. I also think that at least part of that outcome is tied up with what we (at least used to) call cross-area review. I don't think the IETF is doing nearly as well about that as we used to. That is mostly a separate topic, but I think it calls for extra caution. best, john From nobody Tue Aug 20 12:22:27 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D831B120A16 for ; Tue, 20 Aug 2019 12:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 4n6TgRQk-WNC for ; Tue, 20 Aug 2019 12:22:25 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A5CAE120A05 for ; Tue, 20 Aug 2019 12:22:23 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x7KJMHAw084589 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Aug 2019 14:22:19 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1566328940; bh=EIsQKQpSM8DBA/SAR2iGCLTDuITxHsW1lnddXMOhe1I=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=OP87WxZSidlSTZVuy94A7O+2PnX4bxmjJ1Ie1kYVFgd3/DPHAIC+6T90Yj8cFHsDu EZx0iyjqrnTXEUZfVkDt/wBzK04ruQIi0DrMSnPzheLG2Cu/B7V9pt4XR+g6rHeKeF IjXmkczdEhdMhnM8Eyy1PgZWNvGVcfLefiiH4mO8= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: John C Klensin , Mark Nottingham Cc: Jacob Hoffman-Andrews , ART Area , "Devon O'Brien" References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> <301DF34E4C5601BCA4D2BCBF@PSB> <80bb60b7-cdc7-0df8-6a33-726839b15dfe@nostrum.com> From: Adam Roach Message-ID: Date: Tue, 20 Aug 2019 14:22:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 19:22:26 -0000 On 8/20/19 1:33 PM, John C Klensin wrote: > I'd > be happier with a statement from you that, instead of saying > that you are clearing the Discuss because Mark is working on a > revision Thanks for giving me a chance to clear this up, since it's not what I meant, although I can see how the structure of my email may inadvertently give that impression. The rationale for clearing my DISCUSS is: > I think that these responses combined with the input received during > IETF 105 are a weak signal that that there is support for adjusting > BCP 190 at least to the extent necessary to allow the "provisioned > directory prefix" approach used by CT. The mention of updating the document is a follow-on from this observation, but not at all the rationale for clearing the discuss. /a From nobody Tue Aug 20 13:35:26 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70921200A1 for ; Tue, 20 Aug 2019 13:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 p-dUchn-8WYC for ; Tue, 20 Aug 2019 13:35:23 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA493120090 for ; Tue, 20 Aug 2019 13:35:22 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1i0Aqb-000LR0-EL; Tue, 20 Aug 2019 16:35:17 -0400 Date: Tue, 20 Aug 2019 16:35:10 -0400 From: John C Klensin To: Adam Roach , Mark Nottingham cc: Jacob Hoffman-Andrews , ART Area , Devon O'Brien Message-ID: <4FA97CBBC395799300730D88@PSB> In-Reply-To: References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> <301DF34E4C5601BCA4D2BCBF@PSB> <80bb60b7-cdc7-0df8-6a33-726839b15dfe@nostrum.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 20:35:25 -0000 --On Tuesday, August 20, 2019 14:22 -0500 Adam Roach wrote: > On 8/20/19 1:33 PM, John C Klensin wrote: >> I'd >> be happier with a statement from you that, instead of saying >> that you are clearing the Discuss because Mark is working on a >> revision > > > Thanks for giving me a chance to clear this up, since it's not > what I meant, although I can see how the structure of my email > may inadvertently give that impression. > > The rationale for clearing my DISCUSS is: > >> I think that these responses combined with the input received >> during IETF 105 are a weak signal that that there is support >> for adjusting BCP 190 at least to the extent necessary to >> allow the "provisioned directory prefix" approach used by CT. > > > The mention of updating the document is a follow-on from this > observation, but not at all the rationale for clearing the > discuss. That helps. But it also takes us full circle because: * RFC 7320 is either normative, and the 2119 language in it lays out firm requirements, or it isn't. It reads as it it is normative, it contains MUST statements, and it cites 2119 normatively. Both that, and the discussions of the last few weeks, strongly imply that the community thinks it is normative and its author thought it was normative at the time it was approved. * Nothing in that document, or in any more general IETF procedural specification I can find, gives either a single AD or the IESG the authority to waive a normative requirement of a standards-track document without at least an IETF Last Call that addresses the specific issue and, normally, a Last Call on a new document that waives or eliminates the requirement in question. * Independent of how you interpret the discussions of the last few weeks (we agree that there is at least weak consensus within the ART Area that 7320 needs some adjustment), there is, AFAIK, no posted document that makes those adjustments or allows the IESG to make exceptions, much less an IETF Last Call on such a document. * Given that, whatever agreement you see (and cite) does not justify your taking a position that sounds a lot like "well, BCP 190 prohibits this but there is a 'weak signal that that there is support for adjusting BCP 190' and therefore never mind what it actually says". The IESG does not have the authority and withdrawing the Discuss and having the IESG let this go through has the appearance of the IESG thinking that whatever it wants to do supercedes most or all of the IETF's procedural rules about document approval. Because I'd rather have a discussion than have this note interpreted as a thread, I promise to not appeal should the IESG follow that course, but I suggest it would set a precedent about claims of IESG authority independent of even a pretense of IETF consensus that the IETF would probably come to regret. So, it would seem to me that, without violating any fundamental procedures and in the interest of Doing the Right Thing and unblocking the CT document, you (and the IESG) could do any of the following. The first would involve a certain amount of nose-holding, but, IMO, that is far less objectionable than simply kissing off our procedures. (1) Go back to what I thought you said and approve this with a clear understanding that either a replacement for 7320 or an action to deprecate it, killing its advice until a more temperate replacement was approved. (2) Put normative language into the CT document pointing to Mark's draft. That would allow the IESG to approve it but would introduce an RFC Editor normative reference hold on publication. I don't know whether that would block important work or not. (3) Have someone write a document that either deprecates 7320 or updates it sufficiently to turn it into general guidance, not a collection of normative requirements. Push that document through the system (presumably requiring a four-week LC). (4) Have someone write a document that adds language to 7320 to update it to allow the IESG to make exceptions on its own judgment and without community consensus. Same comment about pushing that document through and four-week Last Calls. (5) Section 6.4 of 2026 has been widely interpreted as not requiring a replacement document to change the classification of a standard. So, presumably the IESG could reclassify 7320 to Informational or Historic on the basis of a Statement. I'd hope that would involve an IETF Last Call too, but I'm not sure that is a firm requirement (remember that, once upon a time, the RFC Editor could reclassify documents on his own initiative). I'm open to other ideas if you have them, but I think that going down the path toward a "never mind what BCP 190 says, do what seems sensible on the IESG's say-so" decision would be a really bad idea for the future of the IETF. Because I really do want to see progress here, if you conclude that (3) or (4) above is the right course of action and you can't find a volunteer, I'll try to push everything else in my queue aside and do some writing. Again, from my perspective, the problem here is RFC 7320, not the new work. And, if there is a lesson here, it is either "no more documents like that, especially as normative Standards Track documents disguised as BCPs" or "if we are going to have one, even as an Applicability Statement, it MUST (sic) include a clear exception procedure. Sorry about this, but I've very concerned about the precedents this would set. best, john From nobody Tue Aug 20 13:36:17 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FBA120090 for ; Tue, 20 Aug 2019 13:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 QvPGVhOSHjiD for ; Tue, 20 Aug 2019 13:36:15 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 19C32120086 for ; Tue, 20 Aug 2019 13:36:15 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x7KKa83E097175 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Aug 2019 15:36:10 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1566333373; bh=B6Vz2SogfhriQDl3/T7Sk37r1Ujm72sxbq9UhuU+GVY=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=tTHi61wGOapD4GUTSsumOY3r1EoUYOuAuD1VZ0R3xAoDsRltFlcLtCZqylfmTPh0Y gUY2WjUUEC0j+nhkGweEQmTgB3HuvmopxkJnRhrOtjZiDUO0OjoIu62L8j5dq9KvFJ cbMZRHpl/Q2sDLN3Zodk7cyXGiKNhcvPX1qA8Kwc= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: John C Klensin , Mark Nottingham Cc: Jacob Hoffman-Andrews , ART Area , "Devon O'Brien" References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> <301DF34E4C5601BCA4D2BCBF@PSB> <80bb60b7-cdc7-0df8-6a33-726839b15dfe@nostrum.com> From: Adam Roach Message-ID: <6fc41d0c-6fb2-9470-4e5a-baf6760ba79a@nostrum.com> Date: Tue, 20 Aug 2019 15:36:03 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 20:36:16 -0000 On 8/20/19 1:33 PM, John C Klensin wrote: > So, should ART have flagged this? Absolutely. But then I think > we should have figured out, much more quickly than we have, that > there are fundamental problems with BCP 190, started addressing > those problems a month or two ago, and figured out how to Do the > Right Thing and move on -- both to clear the CT work to progress > and to start cleaning up 7320. You are, of course, entitled to a differing opinion; but I find your characterization of the speed with which I've moved on this topic to be either misinformed or misleading, and I'm troubled by the implications of either case. To be clear about the timeline: although the document was reviewed by the IESG in March, the first hint from its authors or any of the working group participants indicating that the provisions of BCP 190 might be considered a serious obstacle was on June 26th [1], and even that message was rather circumspect, indicating that the working group was positing "alternate means of satisfying BCP 190." It wasn't until the second week of July that it became completely clear that the WG believed that none of the alternate approaches offered by BCP 190 were acceptable to them. Given the, as you've pointed out, summer vacation schedule that many people have, I believe that taking on the order of one to two months to gather input on this topic and come to a conclusion that allows them to move forward is eminently reasonable (especially given the level of urgency implied by the three months they took to provide initial responses to any of their several IESG review comments). /a ____ [1] https://mailarchive.ietf.org/arch/msg/trans/aq9Ojwqw8cPtXsUsofJhE_YO4Q0 From nobody Tue Aug 20 14:20:17 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D532B120110 for ; Tue, 20 Aug 2019 14:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 Lj2Jyu6IOIBw for ; Tue, 20 Aug 2019 14:20:15 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E7B711200B8 for ; Tue, 20 Aug 2019 14:20:14 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x7KLK9XP004875 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Aug 2019 16:20:11 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1566336012; bh=yH3rHFhxymlTSMur0aQUS+G/alHHTR5z+Ni8+qGxANA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=vX5ACsZQSplmy5Q/YQLfr/U11sCwaWZdRXxY9rjvYET974lumjprFjjzRhc1/gf2S mwxHIQt3v7o0awxDAR9k5RfGNVV3RzLefG07A8nX+4yJvqniMf0nLgJ2bHwCweK0/y cHRfYW5OdYNRHubJRm+F1k2A4D0LPxQRjVt8J0fY= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: John C Klensin , Mark Nottingham Cc: Jacob Hoffman-Andrews , ART Area , "Devon O'Brien" References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> <301DF34E4C5601BCA4D2BCBF@PSB> <80bb60b7-cdc7-0df8-6a33-726839b15dfe@nostrum.com> <4FA97CBBC395799300730D88@PSB> From: Adam Roach Message-ID: <1e9aa7ef-56ae-9227-0445-881a577ed5e4@nostrum.com> Date: Tue, 20 Aug 2019 16:20:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <4FA97CBBC395799300730D88@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 21:20:16 -0000 On 8/20/19 3:35 PM, John C Klensin wrote: > So, it would seem to me that, without violating any fundamental > procedures and in the interest of Doing the Right Thing and > unblocking the CT document, you (and the IESG) could do any of > the following. The first would involve a certain amount of > nose-holding, but, IMO, that is far less objectionable than > simply kissing off our procedures. > > (1) Go back to what I thought you said and approve this with a > clear understanding that either a replacement for 7320 or an > action to deprecate it, killing its advice until a more > temperate replacement was approved. The understanding that Mark will produce such a document definitely exists; and if there were no clear path to getting a such revision in place, the plan would would look different. If that document doesn't materialize and progress, we'll have to consult the community to determine support for alternate solutions (of which deprecation would be an option); but I don't see value in churning mailing list traffic coming to consensus on the course of action for every potential failure case. I do want to thank you for standing ready to contribute to the effort if such a failure does occur. /a From nobody Tue Aug 20 14:31:44 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8431012013C for ; Tue, 20 Aug 2019 14:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 xvjWMQpKqN5F for ; Tue, 20 Aug 2019 14:31:41 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10BF91200A3 for ; Tue, 20 Aug 2019 14:31:41 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1i0Bj6-000LXV-3L; Tue, 20 Aug 2019 17:31:36 -0400 Date: Tue, 20 Aug 2019 17:31:31 -0400 From: John C Klensin To: Adam Roach , Mark Nottingham cc: Jacob Hoffman-Andrews , ART Area , Devon O'Brien Message-ID: In-Reply-To: <6fc41d0c-6fb2-9470-4e5a-baf6760ba79a@nostrum.com> References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> <301DF34E4C5601BCA4D2BCBF@PSB> <80bb60b7-cdc7-0df8-6a33-726839b15dfe@nostrum.com> <6fc41d0c-6fb2-9470-4e5a-baf6760ba79a@nostrum.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 21:31:43 -0000 --On Tuesday, August 20, 2019 15:36 -0500 Adam Roach wrote: > On 8/20/19 1:33 PM, John C Klensin wrote: >> So, should ART have flagged this? Absolutely. But then I >> think we should have figured out, much more quickly than we >> have, that there are fundamental problems with BCP 190, >> started addressing those problems a month or two ago, and >> figured out how to Do the Right Thing and move on -- both to >> clear the CT work to progress and to start cleaning up 7320. > You are, of course, entitled to a differing opinion; but I > find your characterization of the speed with which I've moved > on this topic to be either misinformed or misleading, and I'm > troubled by the implications of either case. Adam, no personal criticism intended. And I was looking at a different timeframe, specifically... > To be clear about the timeline: although the document was > reviewed by the IESG in March, the first hint from its authors > or any of the working group participants indicating that the > provisions of BCP 190 might be considered a serious obstacle > was on June 26th [1], and even that message was rather > circumspect, indicating that the working group was positing > "alternate means of satisfying BCP 190." It wasn't until the > second week of July that it became completely clear that the > WG believed that none of the alternate approaches offered by > BCP 190 were acceptable to them. And I was counting from March. If the first hint of an issue was in late June, that certainly isn't an ART problem although, by your argument about cross-area reviews, one might have hoped that some ARTarea reviewer would have caught it. Note "hoped" -- no blame either way. > Given the, as you've pointed out, summer vacation schedule > that many people have, I believe that taking on the order of > one to two months to gather input on this topic and come to a > conclusion that allows them to move forward is eminently > reasonable (especially given the level of urgency implied by > the three months they took to provide initial responses to any > of their several IESG review comments). That sounds completely reasonable. But, IMO, it also eliminates most of the arguments against simply taking the time now to patch RFC 7320 as suggested in my options (3) or (4) and doing the one month Last Call. I was trying to figure out a way to speed things up because of the time since March (again, not in any way your fault) but, if you and/or the WG believe that the relevant date is sometime in June or July, then the right answer, IMO, is to do this right. Again, I'm not blaming anyone, least of all you. I'm just trying to find a way to get this done that doesn't violate our procedures for approving or modifying/updating standards track documents. best, john From nobody Wed Aug 21 07:50:25 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C950912007C for ; Wed, 21 Aug 2019 07:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 LPldnOfOaf3s for ; Wed, 21 Aug 2019 07:50:22 -0700 (PDT) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 7603412006B for ; Wed, 21 Aug 2019 07:50:22 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id t14so1444674plr.11 for ; Wed, 21 Aug 2019 07:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=/Ri8eYKILqRt6Ot0yQI5pmin6o3ZrILC1MevLvS6A3k=; b=d7aKhx9ZVg7rrT3kGTNOH8kZoRcS9OrU7WlnzYyA9vrcLirjW6S219iIcRv91laUJh Yid9UNCgM8Hh71WI+nPS2oI33VKZslmziW6rFEIIW4sYrvF3bqsizcG/E2UFWr2OuqJV zSRo+b24xXXBB9+rVN/3r+0QDFmmigY1NIhw3GyqrzBSp+riWiytUy3KDmXfD22YdZUL aIO3iplJ01Pa+D6hmu37/IgGyneOGCn1Asz6aQWZjqTVi/9Us/A+zp5uSgc2bI8k7YLX ee7I4dqrJN2uCmCQXikvJFBbBE5wl9db7RP7cgjANUlbJqVo7ZVVeDN5SWq02uB8vnYC 7zkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=/Ri8eYKILqRt6Ot0yQI5pmin6o3ZrILC1MevLvS6A3k=; b=AZMrN9A3X/dXy10flXR3zad8MTGkLvYo7Q3cnh/6bceQiFw5gfcSVq94GABOJn8jpg fQClqIb2+07ekpY25IZw5Dh57OCGQ90ldryiO3jj3C/J3/TOQzf7hJMMrZ7LIpGYkeB4 pRiqMoPXgIgDTEYM1FLfsFibGr2ls6HZPDMAMT6+HQH9NPN4E0s6GkbB5dOV8RSNpnJl k3IXBHKVSZJkHE26SYMl+a6gchN97trVlTy+a4HzG1Ku5s2HU6e9mVpGLsp1XZonj/KY nRRIA8lJKaOtR9jf9ywByfC4xDkTDaD/QhPIa7Hms2lgiylT9bLA0iYPK2QLy44bHhTF oDSg== X-Gm-Message-State: APjAAAV0VyUkbPPeZoqLWWkdVRr51EC1sq/92gic4F0U2uLABIV/Fdw5 0aI6pkGvXH14bJ+0V7c0yLg= X-Google-Smtp-Source: APXvYqxgraMxUyz50HIPVhNm9aw//mNqicHUvF6Qs4em2Qmejg9YI7bEBARYzSr7S+m0/9QEgeP/eg== X-Received: by 2002:a17:902:461:: with SMTP id 88mr32398304ple.296.1566399021804; Wed, 21 Aug 2019 07:50:21 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id l31sm24345351pgm.63.2019.08.21.07.50.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Aug 2019 07:50:20 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Adam Roach'" , "'John C Klensin'" , "'Mark Nottingham'" Cc: "'Jacob Hoffman-Andrews'" , "'Devon O'Brien'" , "'ART Area'" References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <004601d5450d$62b33220$28199660$@acm.org> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> <301DF34E4C5601BCA4D2BCBF@PSB> <80bb60b7-cdc7-0df8-6a33-726839b15dfe@nostrum.com> <4FA97CBBC395799300730D88@PSB> <1e9aa7ef-56ae-9227-0445-881a577ed5e4@nostrum.com> In-Reply-To: <1e9aa7ef-56ae-9227-0445-881a577ed5e4@nostrum.com> Date: Wed, 21 Aug 2019 07:50:19 -0700 Message-ID: <015601d5582f$c1430600$43c91200$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQFxlPSiwrtxymI7oXhTAVMNSh8OAAJO5FUZAjbPnJ4BYG1OMgJuSbHFAri/BdoBfw7fJAKoBNagAcnBZW8B3sNK5wEwO4m0Alt285sCGTW4wwNM0pu/Al7Mp8sCJAo4xQK6yICqprTL0jA= Archived-At: Subject: Re: [art] Call for Consensus: Re: On BCP 190 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 14:50:24 -0000 Just back from an August vacation, apologies for brevity IMHO An update to BCP 190 should take into account the fact that there is not a consensus for the "best" of various "current practice" for avoiding the URL squatting identified (namely using a hypermedia format to let the server control the URL format completely rather than the API control the URL syntax and making the client do string processing. As far as process goes, I think it's ok to drop the DISCUSS in question because it is Experimental and not Standards track. As Carsten Bormann wrote Sunday, July 28, 2019 1:43 AM Re: [art] On BCP 190 > > On Jul 28, 2019, at 08:26, Larry Masinter wrote: > > > > Now, why JSON-HAL is still an expired Internet Draft is a puzzle. > > (Slightly, but not completely off-topic:) > > Probably because there are multiple ways to skin this cat and we never > tried to converge on one. > > As a data point, for the applications in the CoRE working group, we > have mostly been able to avoid BCP190-style arguments by using > /.well-known, mainly because simple devices only tend to have one > service offered directly under / and because IoT device platforms tend > to provide the application developer full control over the URI space. > /.well-known/core provides a discovery mechanism for the entry point URIs actually offered by a server. > > For where this is not enough, the WG has just last week adopted CoRAL > (not yet resubmitted as draft-ietf, so you can find it at > draft-hartke-t2trg-coral) as our idea of a hypermedia format like HAL. > Up to now, we tried to make everything work with RFC 6690 link format, > but that has too many idiosyncrasies that started to get in the way of a long-term way forward. From nobody Tue Aug 27 17:45:48 2019 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D23E12080F for ; Tue, 27 Aug 2019 17:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=mnot.net header.b=bCxbqAXs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=poj+3Ihi 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 tPqzglg0edKY for ; Tue, 27 Aug 2019 17:45:44 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AC0120013 for ; Tue, 27 Aug 2019 17:45:44 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 867AA42D for ; Tue, 27 Aug 2019 20:45:43 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 27 Aug 2019 20:45:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:mime-version:subject:message-id:references:to :date; s=fm3; bh=G/oQF/Dv8uuQZxcdWy/YA/h7pB5i32aoRnzCiZVstxE=; b= bCxbqAXs/J4yPwqQI5ItlIhfanSbfgxw61rkCoN+nEYTFbQnaUneSaACRCdDs3DY 4uULJF/lu9/YABvwmhZxMKMNAds1ZrFsMZro95HMLhBp4IOLUgHz4yH2Tx0R/SoN KEuh3wd0uS7emPxTaJ/1lkYFkMlmcbUuXOhXeZ+LzdCYP0ar2P6acCW/eBZHJFHX xE6/IQmbe2S0z2J9nFIy8bJ2AF2AyKgN52R1WMgTSvniR6SYNDmqVK3UNYMEc2Tm JnldDYGuxP5djTcO7dSnXFlwd67HHo0IZTU13o3G16l/KyvmupAMJOuZ6cEH5GEb 8UcLNM2yqTi4XHNMWF0Erg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=G/oQF/Dv8uuQZxcdW y/YA/h7pB5i32aoRnzCiZVstxE=; b=poj+3IhiYobsebi8vdIK7heU30NwoQb7C FuyhBAW6rjmHjHNtUJXMGE+XoXk2/V0cGf+ultuGnqptfW6fGnY6q8qRU7nH6Jam bFOX1m92Y6e47fHxaS4r7a66D3g4K2o8hlMpXXuVmd1Gim7twJNU1LHxnfjSJfWC l10+LFlptxZ1gMcmjf7fHIDyL302XC05LYqB+8icn0GFi425c1po/AGj6bHNcEwF HfNCmH2aeo2GFv37W1sX7zsl2g1lJothC46Nn2adeiVo9VbQdt3GQz/cb2OX+Z3R m9YwzqDNWAA/6pwhjWCf/fZBw/4RlL9QEc+f4TFHJISVkIoVgvehg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudehledgfeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhtggguffkfhfvfffosegrtdhmre hhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhho thdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghdpmhhnohhtrdhnvghtnecukf hppeegledrvdehhedrudelledrudehtdenucfrrghrrghmpehmrghilhhfrhhomhepmhhn ohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [172.16.8.215] (unknown [49.255.199.150]) by mail.messagingengine.com (Postfix) with ESMTPA id 619A9D6005B for ; Tue, 27 Aug 2019 20:45:40 -0400 (EDT) From: Mark Nottingham Content-Type: multipart/alternative; boundary="Apple-Mail=_6A552E21-AA2A-4B6B-979E-0EF6CFAD9F01" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <6CACB9C1-265A-450E-A5CF-A47F38682E6B@mnot.net> References: <156685932063.2566.4065147273562437244.idtracker@ietfa.amsl.com> To: ART Area Date: Wed, 28 Aug 2019 10:45:37 +1000 X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [art] Fwd: New Version Notification for draft-nottingham-rfc7320bis-01.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 00:45:48 -0000 --Apple-Mail=_6A552E21-AA2A-4B6B-979E-0EF6CFAD9F01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI; this is a proposed revision of RFC7320 / BCP190, as discussed. -00 was a copy of 7320; -01 proposes the revision (so the diff is = probably a good place to start). Cheers, > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nottingham-rfc7320bis-01.txt > Date: 27 August 2019 at 8:42:00 am AEST > To: "Mark Nottingham" >=20 >=20 > A new version of I-D, draft-nottingham-rfc7320bis-01.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Name: draft-nottingham-rfc7320bis > Revision: 01 > Title: URI Design and Ownership > Document date: 2019-08-27 > Group: Individual Submission > Pages: 10 > URL: = https://www.ietf.org/internet-drafts/draft-nottingham-rfc7320bis-01.txt > Status: = https://datatracker.ietf.org/doc/draft-nottingham-rfc7320bis/ > Htmlized: = https://tools.ietf.org/html/draft-nottingham-rfc7320bis-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-nottingham-rfc7320bis > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-rfc7320bis-01 >=20 > Abstract: > Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and > extensible naming system wherein each scheme's specification may > further restrict the syntax and semantics of identifiers using that > scheme." In other words, the structure of a URI is defined by its > scheme. While it is common for schemes to further delegate their > substructure to the URI's owner, publishing independent standards > that mandate particular forms of substructure in URIs is often > problematic. >=20 > This document provides guidance on the specification of URI > substructure in standards. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 -- Mark Nottingham https://www.mnot.net/ --Apple-Mail=_6A552E21-AA2A-4B6B-979E-0EF6CFAD9F01 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI; = this is a proposed revision of RFC7320 / BCP190, as discussed.

-00 was a copy of 7320; = -01 proposes the revision (so the diff is probably a good place to = start).

Cheers,



Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-nottingham-rfc7320bis-01.txt
Date: = 27 August 2019 at 8:42:00 am = AEST
To: = "Mark Nottingham" <mnot@mnot.net>

A new version of I-D, draft-nottingham-rfc7320bis-01.txt
has been successfully submitted by Mark Nottingham and posted = to the
IETF repository.

Name: = = draft-nottingham-rfc7320bis
Revision: 01
Title:= = URI Design and Ownership
Document date: = 2019-08-27
Group: Individual Submission
Pages:= = 10
URL: =            https://www.ietf.org/internet-drafts/draft-nottingham-rfc7320bi= s-01.txt
Status: =         https://datatracker.ietf.org/doc/draft-nottingham-rfc7320bis/
Htmlized:       https://tools.ietf.org/html/draft-nottingham-rfc7320bis-01<= br class=3D"">Htmlized:       https://datatracker.ietf.org/doc/html/draft-nottingham-rfc7320b= is
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-rfc7320bis= -01

Abstract:
=   Section 1.1.1 of RFC 3986 defines URI syntax as "a federated = and
  extensible naming system wherein each = scheme's specification may
  further restrict = the syntax and semantics of identifiers using that
=   scheme."  In other words, the structure of a URI is = defined by its
  scheme.  While it is = common for schemes to further delegate their
=   substructure to the URI's owner, publishing independent = standards
  that mandate particular forms of = substructure in URIs is often
  problematic.

  This document provides guidance = on the specification of URI
  substructure in = standards.




Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF = Secretariat


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

= --Apple-Mail=_6A552E21-AA2A-4B6B-979E-0EF6CFAD9F01--