From nobody Mon Sep 7 06:24:54 2020 Return-Path: X-Original-To: httpapi@ietf.org Delivered-To: httpapi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A31D3A0C2E; Mon, 7 Sep 2020 06:24:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: httpapi-chairs@ietf.org, httpapi@ietf.org, httpapi@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.15.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <159948508855.23108.4995171934432420015@ietfa.amsl.com> Date: Mon, 07 Sep 2020 06:24:49 -0700 Archived-At: Subject: [httpapi] Magnus Westerlund's No Objection on charter-ietf-httpapi-00-00: (with COMMENT) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2020 13:24:49 -0000 Magnus Westerlund has entered the following ballot position for charter-ietf-httpapi-00-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-httpapi/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I find this bullet creating some questions: • Proposals for new HTTP status codes, methods, or other generic extensions, to be considered by the HTTP Working Group As this is output. So this is basically a WG consensus proposal (Internet Draft) in HTTPAPI that is then thrown over the fence to the HTTPbis WG for consideration? In this consideration then it is up to the HTTPbis WG to do what ever they feel about this proposal? And the status in HTTPbis will basically that this is from the HTTPAPI WG and have the level of consensus it had. Is there a need to actually move this bullet from the output list to instead detail how the HTTPAPI WG can propose chagnes in HTTPbis WG scope and establish its WG consensus prior to handing it over? Also are this expected to be technical solutions or primarily an problem solving idea for further development with solid use case(s) and requirements from HTTPAPI? From nobody Tue Sep 8 07:21:53 2020 Return-Path: X-Original-To: httpapi@ietf.org Delivered-To: httpapi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D763A13D5; Tue, 8 Sep 2020 07:21:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: httpapi-chairs@ietf.org, httpapi@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.15.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <159957490828.12351.9225317829844364255@ietfa.amsl.com> Date: Tue, 08 Sep 2020 07:21:48 -0700 Archived-At: Subject: [httpapi] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_charter?= =?utf-8?q?-ietf-httpapi-00-00=3A_=28with_COMMENT=29?= X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2020 14:21:49 -0000 Éric Vyncke has entered the following ballot position for charter-ietf-httpapi-00-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-httpapi/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Should there also be a link with the CoRE WG ? From nobody Tue Sep 8 07:50:42 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136553A0D68; Tue, 8 Sep 2020 07:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5mou4-h2iXW; Tue, 8 Sep 2020 07:50:40 -0700 (PDT) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (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 52E983A0D64; Tue, 8 Sep 2020 07:50:05 -0700 (PDT) Received: by mail-io1-f43.google.com with SMTP id h4so17381200ioe.5; Tue, 08 Sep 2020 07:50:05 -0700 (PDT) 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=t2zfZW6XHTqBSQ04O5RAtV/LqJStvsbhMEdZOlBEXIY=; b=Qqv1JEI94naNNGpQynlNeJWBurwvvotvht/5N7KbRxdR/D9IuZ6QgvN0plSO/IEQ0U MuyIJFs3HYUgsewWhixA3Flxqr+0SurWnK9MYBwDaf/JEs8FMC/DF7/5NJP7x9t7WYcU w9j+8raecMuvE8i043uTn7MPtCusmEId2+5ZhXjzgZojLEj/U6XJSRuAgLKGRI5N2zgE lYVq6Vin/DPDyUk5D7K2Fqh4Gfc7hliLQG5QUb04hUN6PbtKHRgqYAu9pwwGs2y1N0IG NRCsYByznso9mWaLUHtoKxk+8knzHZNK39kobh26ob9lr/TysUj9FqQM7ElJUZPRPkKJ etKQ== X-Gm-Message-State: AOAM533knPmmYtaomB+SexHcgNsHk/aePr+34y6AH+OCxmzjFBYF5bRq nqU362U2az9S+QE4Z3wlw8/9wrK7O8ElfF4rbrg= X-Google-Smtp-Source: ABdhPJwYsuXYgIRFRwdZwwg1Crcs9c8dOTGZGfnXTOuIfJ+YYUQ+MCNgr7ZR9/0peNRskousdkqZY+vpShMoKTa07T0= X-Received: by 2002:a6b:bf44:: with SMTP id p65mr5145490iof.126.1599576604397; Tue, 08 Sep 2020 07:50:04 -0700 (PDT) MIME-Version: 1.0 References: <159957490828.12351.9225317829844364255@ietfa.amsl.com> In-Reply-To: <159957490828.12351.9225317829844364255@ietfa.amsl.com> From: Barry Leiba Date: Tue, 8 Sep 2020 10:49:53 -0400 Message-ID: To: =?UTF-8?B?w4lyaWMgVnluY2tl?= Cc: The IESG , httpapi@ietf.org, httpapi-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [httpapi] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_charter?= =?utf-8?q?-ietf-httpapi-00-00=3A_=28with_COMMENT=29?= X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2020 14:50:41 -0000 > Should there also be a link with the CoRE WG ? Not that specifically needs to be in the charter. Barry From nobody Tue Sep 8 08:59:20 2020 Return-Path: X-Original-To: httpapi@ietf.org Delivered-To: httpapi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A64943A0E96; Tue, 8 Sep 2020 08:59:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Duke via Datatracker To: "The IESG" Cc: httpapi-chairs@ietf.org, httpapi@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.15.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <159958075822.806.6403222206022210649@ietfa.amsl.com> Date: Tue, 08 Sep 2020 08:59:18 -0700 Archived-At: Subject: [httpapi] Martin Duke's Block on charter-ietf-httpapi-00-00: (with BLOCK) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2020 15:59:19 -0000 Martin Duke has entered the following ballot position for charter-ietf-httpapi-00-00: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-httpapi/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- I certainly support creation of a working group of this nature; however, from the charter I have no idea what portion of this large problem space constitutes the short-term objectives of this group. From nobody Wed Sep 9 07:54:01 2020 Return-Path: X-Original-To: httpapi@ietf.org Delivered-To: httpapi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 108453A0E4A; Wed, 9 Sep 2020 07:53:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: httpapi-chairs@ietf.org, httpapi@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.16.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <159966323879.8094.15005725001447785927@ietfa.amsl.com> Date: Wed, 09 Sep 2020 07:53:59 -0700 Archived-At: Subject: [httpapi] Alissa Cooper's Block on charter-ietf-httpapi-00-00: (with BLOCK and COMMENT) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 14:53:59 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-httpapi-00-00: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-httpapi/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- I agree with Martin. In particular, I am wondering how the WG will define "specific use cases or applications" as referred to where the text says, "this WG will not take on work items for APIs for specific use cases or applications." ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Magnus that it is unclear whether the third bullet encompasses work that the WG will do or not. The first sentence is clunky. I would suggest "In addition to its use for web browsing, HTTP is often used for machine-to-machine communication, facilitated by HTTP APIs." From nobody Wed Sep 9 11:51:21 2020 Return-Path: X-Original-To: httpapi@ietf.org Delivered-To: httpapi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF733A0C99; Wed, 9 Sep 2020 11:51:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: httpapi-chairs@ietf.org, httpapi@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.16.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <159967746837.8437.7601380417417968185@ietfa.amsl.com> Date: Wed, 09 Sep 2020 11:51:08 -0700 Archived-At: Subject: [httpapi] Roman Danyliw's No Objection on charter-ietf-httpapi-00-00: (with COMMENT) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 18:51:09 -0000 Roman Danyliw has entered the following ballot position for charter-ietf-httpapi-00-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-httpapi/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** (Like Martin and Alissa) I’m having trouble discriminating what work comes to HTTPbis as opposed to this proposed WG. As written, does all HTTP for web browser go to HTTPbis; and machine-to-machine comes here? ** Per “Proposals for new HTTP status codes, methods, or other generic extensions, to be considered by the HTTP Working Group”, why would this WG propose new work for HTTPbis, instead of doing it? ** How do when know when this WG is done? ** Can the initial milestones please be added From nobody Wed Sep 9 11:56:18 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B22D3A0CCB; Wed, 9 Sep 2020 11:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QclqW2SpsGTn; Wed, 9 Sep 2020 11:56:07 -0700 (PDT) Received: from mail-il1-f178.google.com (mail-il1-f178.google.com [209.85.166.178]) (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 C514D3A0CB3; Wed, 9 Sep 2020 11:56:07 -0700 (PDT) Received: by mail-il1-f178.google.com with SMTP id t18so2733312ilp.5; Wed, 09 Sep 2020 11:56:07 -0700 (PDT) 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:content-transfer-encoding; bh=g40Zzl64+6JpYKuewn4s9UWxIFRS/Ao0C9mizgi+Vsg=; b=lwHOo4ggM4SIF54H5HX7Xegq/dRRE0NwNq18OnL3MF+nWFxgNbriA60Daji68KYVKE Wjs+rEpbP8ubDKNv9LWffCBYhzb56XX9TJKLGdEYCWRPJDo+CN9QfgiZ7TIzCQVYllCh ExjFzs9B5FQYswK4wikujsWPBtBtVDQN1UHnhmhI/JwM+871UrIy4VhQ0qDKSR7KzUNX L+iPitRvGyE4/prlovkjWZal0XZsBlPQkM/zvPVK2saKza++aAIAKBvZgRJKNgC7PhEx Cgvmm0fupuomaz2zvC5yL9d6Gb4yR8Xzzqi1dHlU0wBMaZ5b7rynZvzkZM1eSDJr5F/K 8Yaw== X-Gm-Message-State: AOAM532fgU37Qm2Ob5BsDUbAjQIE568xRJVYaB4zpbL0t9a/Tl/dRCEG xk+9+8QAEafY975bHQ7iVIj8rYZ/OkK+HIYCLBCoseEuyibxYA== X-Google-Smtp-Source: ABdhPJxpo1A4wQV9DQoj5AvENNb4tGpqSQw+we6ficamLQZ3D0BK8gF94c0snl4R4rpcSZUYXqib5mT5HUj/UexJqGI= X-Received: by 2002:a92:d906:: with SMTP id s6mr4693300iln.152.1599677767009; Wed, 09 Sep 2020 11:56:07 -0700 (PDT) MIME-Version: 1.0 References: <159967746837.8437.7601380417417968185@ietfa.amsl.com> In-Reply-To: <159967746837.8437.7601380417417968185@ietfa.amsl.com> From: Barry Leiba Date: Wed, 9 Sep 2020 14:55:56 -0400 Message-ID: To: Roman Danyliw , Mark Nottingham Cc: The IESG , httpapi@ietf.org, httpapi-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [httpapi] Roman Danyliw's No Objection on charter-ietf-httpapi-00-00: (with COMMENT) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 18:56:10 -0000 > ** (Like Martin and Alissa) I=E2=80=99m having trouble discriminating wha= t work comes > to HTTPbis as opposed to this proposed WG. As written, does all HTTP for= web > browser go to HTTPbis; and machine-to-machine comes here? Indeed; I've heard this clearly, and I'm putting Mark specifically on the "to" line to ask for some edits to clarify this, especially, along with other questions that have been raised. Thanks, all, Barry From nobody Wed Sep 9 15:35:45 2020 Return-Path: X-Original-To: httpapi@ietf.org Delivered-To: httpapi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2E43A0F76; Wed, 9 Sep 2020 15:35:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: httpapi-chairs@ietf.org, httpapi@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.16.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <159969093993.15400.2758336106235985465@ietfa.amsl.com> Date: Wed, 09 Sep 2020 15:35:40 -0700 Archived-At: Subject: [httpapi] Benjamin Kaduk's No Objection on charter-ietf-httpapi-00-00: (with COMMENT) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 22:35:40 -0000 Benjamin Kaduk has entered the following ballot position for charter-ietf-httpapi-00-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-httpapi/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Not much to add that hasn't already been covered by my fellow ADs. It's particularly hard to gauge the expected scope with no milestones listed. One point, though: machine-to-machine API usage is likely to make heavy use of (TLS) mutual authentication, and the stalwart documentation for authenticating TLS servers (RFC 6125) explicitly disclaims coverage of authentication of TLS clients. There may be a gap in this area that could use filling and I wonder if the right people would be here to work on plugging it. From nobody Wed Sep 9 18:15:57 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7B43A09E9; Wed, 9 Sep 2020 18:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=fiJSO5iK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Jg6dVzCy 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 njDzSpNREUot; Wed, 9 Sep 2020 18:15:48 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0741D3A09E8; Wed, 9 Sep 2020 18:15:48 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 579CEC02; Wed, 9 Sep 2020 21:15:47 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 09 Sep 2020 21:15:47 -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 7K/+Nw3AZbnqP3HYOa649vxDAZHDxw25cNmBxB+NTk=; b=fiJSO5iK0a9TJbf/w b4AoMFkL6RDEEDKZ/VQ5paWAAqiy6s4McnziTligJkKlqYaOOzml82/GJQekss1K fiYTT+IiEjE1fJWUptRbAbRqhwf8dZlBaXllONdWCEUCQ+rXM3jpwNvHAoa8geZq 4QCz6pcDcQu8z241sdXtlPef6N9fhH1JyXghWSu+8AGaBgCE0XFecR9aLp23HCmr m/fLLQIXKJg/eoqjGh7PQ6OzyKvM7YPk8e4vJYNzX+rGBcHJEP/gCeqFW0yR+Xf7 BqBUx3WjBzMosdNs/DP8q2yo3nwd+P2GSDcKNUyDYTqTlefzaw8RPqKrKTb345n9 HFKKA== 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=D7K/+Nw3AZbnqP3HYOa649vxDAZHDxw25cNmBxB+N Tk=; b=Jg6dVzCytupeiRVMp82Fi1DuioRR6ribq4U2MEA0G7m6GKU/RiG00Xna8 kHAGAtSTEuQA7eKwFbYo1Tc7rnp8sdTc7Ir67xJ56gsH+lLkAZ1N/ba+kGdoHJ7F oQs/V5G0ga445zRtrUJkc744Yd1kzE8j2COdabyqbzBG4Wd0fBI25dc1tmAi85Y3 uFZYfLocYQC5mncaXPGq/R9dnmwwlZInL2PvQpOIEaA1bktlxdnK0aMaNKCdQ7xb jQY4ZR8G4aDft3gEkek+mWSIgtuxzVuXCdQe0UTwX2uC+VFG+3G2NOiBMopFdVth +0P+nV9mfvv7jKW+0O5jvf1bkycgg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehiedggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeefgedvgfejgedvteeuudekveefhfehleeiveejjeekhfffheekjeeikeejtdeh jeenucffohhmrghinhepihgvthhfrdhorhhgpdhmnhhothdrnhgvthenucfkphepuddule drudejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id A1FA03280060; Wed, 9 Sep 2020 21:15:44 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <159966323879.8094.15005725001447785927@ietfa.amsl.com> Date: Thu, 10 Sep 2020 11:15:42 +1000 Cc: The IESG , httpapi@ietf.org, httpapi-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <159966323879.8094.15005725001447785927@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [httpapi] Alissa Cooper's Block on charter-ietf-httpapi-00-00: (with BLOCK and COMMENT) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 01:15:52 -0000 Hi Alissa (et al), Apologies, I missed many of the previous charter comments (there was = some confusion about list creation -- it seems not many people were = told), so I'll respond to some previous ones here. (For folks who have just joined the list: this is the IESG's discussion = of whether to adopt the WG charter; see = and feel = free to chime in). > On 10 Sep 2020, at 12:53 am, Alissa Cooper via Datatracker = wrote: >=20 > I agree with Martin. Martin's comment was: > from the charter I have no idea what portion of this large problem = space constitutes the short-term objectives of this group. As discussed in DISPATCH, this is purposefully not proposed with = immediate milestones. To date, we've done some API-related work in the = HTTP WG (e.g., Signatures), and in many ways this proposal is simply = splitting that work out into a separate group to make it more accessible = to its target community. So, to Murray and Roman's comments, yes this is intended to be a = standing group -- *if* it is healthy. I would consider it on probation = for at least 6-9 months, to see if it's able to have good interaction = with the rest of the API community and be productive; if not, as I've = said many times I'll be the one most loudly calling for it to be shut = down. There are a number of potential drafts out there that the group could = adopt, but I'd rather see a CfAs happen in the group, rather than as = part of the chartering process; that will help form the community and = give it ownership over what's going on (and will give it some experience = running the CfA process). I gave a talk about API standards and linked = to the mailing list last night, and so far the mailing list has almost = 20 new members -- many who AFAICT are new to the IETF and also actively = practicing in this area. So if the IESG insists, we can add a few initial drafts as milestones, = but for the reasons above I have a fairly strong preference not to. > In particular, I am wondering how the WG will define "specific use = cases or applications" as referred to where the text says, "this WG will = not take on work items for APIs for specific use cases or applications." It says the WG will *not* do those things. That text is intended to prevent the WG from defining specific APIs. For = example, if someone wants to create a HTTP API for DNS (to use a recent = example), this group wouldn't be an appropriate place to do that. > I agree with Magnus that it is unclear whether the third bullet = encompasses work that the WG will do or not. The intent there was that the group could talk about proposals for new = status codes, but would need to defer their actual standardisation to = the HTTP WG (since in HTTP status codes, like methods, are generic and = not supposed to be specific to any application or even type of = application). I'm open to figuring out another way to do this -- and maybe the charter = doesn't need to be so specific (or maybe it needs to be more?). But I = think it's generally safer for restricted items like status codes and = methods to go through the HTTP WG; we've been burned before on this = (e.g., see WEBDAV). > The first sentence is clunky. I would suggest "In addition to its use = for web browsing, HTTP is often used for machine-to-machine = communication, facilitated by HTTP APIs." Fine by me. Some other responses -- Erik K said 'I still think the working group name might be shortened by = removing "ttp".' I don't think that would be wise; not only would it remove the = reinforcement of the term 'HTTP API' (terminology has been a problem for = a while in this area), but it would also conflict with Eran Hammer = Lahev's HAPI framework for building HTTP services. I also find that the = IETF's penchant for cute names can be confusing and off-putting to = outsiders. =C3=89ric asks 'Should there also be a link with the CoRE WG?'=20 Definitely not. CORE is not HTTP, and requiring coordination there would = be burdensome to both communities. If the IESG is going to insist on = coordination between HTTP and CORE, we have a *much* bigger discussion = at our feet. Ben wonders about TLS mutual authentication. I suspect that TLS = extensions are out of scope for this community, but gauging interest in = / requirements for doing it from HTTP APIs here could be useful.=20 Roman asks 'As written, does all HTTP for web browser go to HTTPbis; and = machine-to-machine comes here?' That's a rough yardstick; I expect there to be fairly close = communication and coordination between the groups about potential work. = This isn't that unusual in the IETF; e.g., I've seen work items go from = SECDISPATCH to DISPATCH and then to the HTTP WG, with a fair amount of = back-channel coordination between the relevant WG chairs and ADs. I'd also observe that from discussions I've had, this split makes sense = to HTTP folks; it might not from a greater distance, but I do think = it'll work. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Sep 9 18:31:36 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9133A0A04; Wed, 9 Sep 2020 18:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=J5meac34; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=A9bKvM3/ 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 v8E8Dn79UgIl; Wed, 9 Sep 2020 18:31:28 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E31D3A0A06; Wed, 9 Sep 2020 18:31:28 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 574A3C41; Wed, 9 Sep 2020 21:31:27 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 09 Sep 2020 21:31:27 -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=6 VCSNBfdFH5ktpphPMZPqbBc6tP24wUDgNr1dPNC58g=; b=J5meac34qdhLYMcMD dY5PVEbTb+WsxJVDRJcMCND/56bUrZ3KO1/wCVSoCjMmIPvadlZJMWaSSNniSaYh DD2oWyvuo8va+11vVm7+0nFrylHdPcKbcyPnTiuVuocykZsjltx3CsfWx52jckAr ZDMhdP/Br/322Tpklt/u4eN4qDxwz6hDziCTTYzdiqep5WYhGpl0GSdUUohokFDN 1ILTtGXtcWbCVG26ZpHbZ56yk4EeRgc0MdgBM4zuckbulUmArgeunOIFeo8Xhe/q rbNXW1+eDrf27OvgJN6JIjRgjgj+wyNMGWnXi52OagvlPN4+z2HS9PVbuT6ZNs0m nUuSA== 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=6VCSNBfdFH5ktpphPMZPqbBc6tP24wUDgNr1dPNC5 8g=; b=A9bKvM3/lWE3Tcp/hGbAtMEQ65grJUWOMLjSzQ4os/VKDoLDFnXnYdAb2 nx3LNyqlBdczoplIcrYW8EhBmG3lYPqx+VqNRImjmurqODUm+JO53GT5OmGul9dO 6CCSZIPoflV1vNzOXlNBzlrrqoLwF2fsi6fA5XyIjdThdVKqKGgq9sZpJngFpgDE riaexsd1/KWH0T9HWxnHgSAht2DzCQZx5d7SfgsjCi17Q8Nqegmgud5jOp7F6Yit 7rpu/Mwam1Y/xcUUKdy8yjH/X9iIooeMPvYOP+xjUdc9Y9bUIjZqoTuXSIWJuhNZ JyZoyao/PfCoTlySr8HkQOGAKjlGw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehiedggeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeehheduhefgheehfeehvedvhfekfedvhfevkeefvedvteelgefhudefhffhvdel geenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhhthhtphgsihhsrghsohhpphhosh gvughtohhthhhishhprhhophhoshgvugifghdrrghspdhmnhhothdrnhgvthenucfkphep udduledrudejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 6B2CF3068C6A; Wed, 9 Sep 2020 21:31:24 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: Date: Thu, 10 Sep 2020 11:31:21 +1000 Cc: Roman Danyliw , The IESG , httpapi@ietf.org, httpapi-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <19F553C2-00FE-495F-BC59-32B4FFCC09B4@mnot.net> References: <159967746837.8437.7601380417417968185@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [httpapi] Roman Danyliw's No Objection on charter-ietf-httpapi-00-00: (with COMMENT) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 01:31:31 -0000 Hi Barry, I've updated my copy at: https://gist.github.com/mnot/8a29455df65df33d92902a1ecc3e7e68 Tell me what you think. Cheers, > On 10 Sep 2020, at 4:55 am, Barry Leiba = wrote: >=20 >> ** (Like Martin and Alissa) I=E2=80=99m having trouble discriminating = what work comes >> to HTTPbis as opposed to this proposed WG. As written, does all HTTP = for web >> browser go to HTTPbis; and machine-to-machine comes here? >=20 > Indeed; I've heard this clearly, and I'm putting Mark specifically on > the "to" line to ask for some edits to clarify this, especially, along > with other questions that have been raised. >=20 > Thanks, all, > Barry -- Mark Nottingham https://www.mnot.net/ From nobody Thu Sep 10 01:01:15 2020 Return-Path: X-Original-To: httpapi@ietf.org Delivered-To: httpapi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D02813A11DB; Thu, 10 Sep 2020 01:01:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Vigoureux via Datatracker To: "The IESG" Cc: httpapi-chairs@ietf.org, httpapi@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.16.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Vigoureux Message-ID: <159972486733.10192.6682792123036811993@ietfa.amsl.com> Date: Thu, 10 Sep 2020 01:01:07 -0700 Archived-At: Subject: [httpapi] Martin Vigoureux's No Objection on charter-ietf-httpapi-00-00: (with COMMENT) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 08:01:08 -0000 Martin Vigoureux has entered the following ballot position for charter-ietf-httpapi-00-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-httpapi/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, New work items can be added after a Call for Adoption on the working group mailing list and consultation with the Area Director. It is unclear to me whether those new work items are items in scope of the current charter or out of the current scope. In the latter case I would tend to think that a rechartering process is the way to handle that. Thank you From nobody Thu Sep 10 05:44:08 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4933A0853; Thu, 10 Sep 2020 05:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=cooperw.in header.b=SHEcl6/g; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KmssQFRi 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 IutA6KSgt3nR; Thu, 10 Sep 2020 05:44:05 -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 131873A0991; Thu, 10 Sep 2020 05:43:43 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0E8FB5C005D; Thu, 10 Sep 2020 08:43:42 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 10 Sep 2020 08:43:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=U rP5aRGLvmCEDFnJqSOwmC4NEDlkbH4rMmgkVhKryHY=; b=SHEcl6/gxKBwfhYSS YJGBCL4rqnY7R3AKmG2g7zJOdBYp5aNokuwAV3Voxt7CNSm3VfNwtNf7Q6BxzrZq dEDPZw/3cO5PVIIO0vCp3z9LMLKujbkNpPhNlJmsOS7PmRDxxJZ99Dk69vho3G38 Qi9u0Qu28uf3bs0cU+onGR/T/Bb2L58tiQ8/lwV3s725jr2kelRAFowopeM+DmYi s3md3Kzm7JFUb7Tcz9F1BViYGJrT0HELW5j5QfbF6Lrx/r7CTpeV8Oyc+V4KTDPf vzNN097wK/wItOrRoBV9ld7gzJLSFTOOMg+F2jYLAfSnqI5cAvdlA7gZKyLVvERN pp6ow== 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=UrP5aRGLvmCEDFnJqSOwmC4NEDlkbH4rMmgkVhKry HY=; b=KmssQFRivRtkNJGG5/omq4IG+Phn2N9Dlax875FHvHjY2bX9nFS3XoPsh E4mn4VkQGX1TRp/2IjAUZNhFbYoV/E4bnOaUdfqwDU+h15TG9EDJp4KFudLPDqE4 8jzwae32oijbdKMd/FE0/JAKQXb1drBgveiZC/NjpFxqReL2FFqXmhe/w9TahhxI Zn7OFQTePjrwjfSH4oBwF8FsfBlFZvgHC7E9Nvjy1W6j7HogIMEQT5gg/q2C4N0N QYqu1B5FExM/XCylgZ/yuQd770fHvl+K5F+JgRmoHTQKJvpFS8A0ULCmt/U1M2xk zYaD+t/045UnrfMLxmlWp0U0e+WIA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehjedggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucggtffrrg htthgvrhhnpeelveekieeuleegvdfhtddvtedvkeffieetkeetffevhedtteevieefvdet leetkeenucffohhmrghinhepihgvthhfrdhorhhgpdhmnhhothdrnhgvthenucfkphepud ejfedrfeekrdduudejrdekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhep mhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhn X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.84]) by mail.messagingengine.com (Postfix) with ESMTPA id 96898328005E; Thu, 10 Sep 2020 08:43:41 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Alissa Cooper In-Reply-To: Date: Thu, 10 Sep 2020 08:43:40 -0400 Cc: IESG , httpapi@ietf.org, httpapi-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <752C5863-F10A-44A4-8459-CBF7529C14CC@cooperw.in> References: <159966323879.8094.15005725001447785927@ietfa.amsl.com> To: Mark Nottingham X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [httpapi] Alissa Cooper's Block on charter-ietf-httpapi-00-00: (with BLOCK and COMMENT) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 12:44:07 -0000 Hi Mark, > On Sep 9, 2020, at 9:15 PM, Mark Nottingham wrote: >=20 > Hi Alissa (et al), >=20 > Apologies, I missed many of the previous charter comments (there was = some confusion about list creation -- it seems not many people were = told), so I'll respond to some previous ones here. >=20 > (For folks who have just joined the list: this is the IESG's = discussion of whether to adopt the WG charter; see = and feel = free to chime in). >=20 >> On 10 Sep 2020, at 12:53 am, Alissa Cooper via Datatracker = wrote: >>=20 >> I agree with Martin. >=20 > Martin's comment was: >=20 >> from the charter I have no idea what portion of this large problem = space constitutes the short-term objectives of this group. >=20 > As discussed in DISPATCH, this is purposefully not proposed with = immediate milestones. To date, we've done some API-related work in the = HTTP WG (e.g., Signatures), and in many ways this proposal is simply = splitting that work out into a separate group to make it more accessible = to its target community. >=20 > So, to Murray and Roman's comments, yes this is intended to be a = standing group -- *if* it is healthy. I would consider it on probation = for at least 6-9 months, to see if it's able to have good interaction = with the rest of the API community and be productive; if not, as I've = said many times I'll be the one most loudly calling for it to be shut = down. I would say we put that in the charter then, so everyone agrees to = revisit on the same time frame. >=20 > There are a number of potential drafts out there that the group could = adopt, but I'd rather see a CfAs happen in the group, rather than as = part of the chartering process; that will help form the community and = give it ownership over what's going on (and will give it some experience = running the CfA process). I gave a talk about API standards and linked = to the mailing list last night, and so far the mailing list has almost = 20 new members -- many who AFAICT are new to the IETF and also actively = practicing in this area. >=20 > So if the IESG insists, we can add a few initial drafts as milestones, = but for the reasons above I have a fairly strong preference not to. >=20 >> In particular, I am wondering how the WG will define "specific use = cases or applications" as referred to where the text says, "this WG will = not take on work items for APIs for specific use cases or applications." >=20 > It says the WG will *not* do those things. Right, my question is how do you know which things you won=E2=80=99t do?=20= >=20 > That text is intended to prevent the WG from defining specific APIs. = For example, if someone wants to create a HTTP API for DNS (to use a = recent example), this group wouldn't be an appropriate place to do that. I think for applications it=E2=80=99s clearer, but what is a =E2=80=9Cspec= ific use case=E2=80=9D? To use your example above, let=E2=80=99s say my = use case is that I want to be able to digitally sign the contents of = HTTP messages. Since that is apparently in scope for the WG, why does it = not count as a =E2=80=9Cspecific use case=E2=80=9D? I=E2=80=99m not = arguing with the limitation, I=E2=80=99m just hoping to have the charter = be more expressive in describing the boundary. >=20 >> I agree with Magnus that it is unclear whether the third bullet = encompasses work that the WG will do or not. >=20 > The intent there was that the group could talk about proposals for new = status codes, but would need to defer their actual standardisation to = the HTTP WG (since in HTTP status codes, like methods, are generic and = not supposed to be specific to any application or even type of = application). Ok. It shouldn=E2=80=99t be in a bulleted list of what the WG=E2=80=99s = outputs will be, but maybe can be described in its own paragraph. Alissa >=20 > I'm open to figuring out another way to do this -- and maybe the = charter doesn't need to be so specific (or maybe it needs to be more?). = But I think it's generally safer for restricted items like status codes = and methods to go through the HTTP WG; we've been burned before on this = (e.g., see WEBDAV). >=20 >> The first sentence is clunky. I would suggest "In addition to its use = for web browsing, HTTP is often used for machine-to-machine = communication, facilitated by HTTP APIs." >=20 > Fine by me. >=20 > Some other responses -- >=20 > Erik K said 'I still think the working group name might be shortened = by removing "ttp".' >=20 > I don't think that would be wise; not only would it remove the = reinforcement of the term 'HTTP API' (terminology has been a problem for = a while in this area), but it would also conflict with Eran Hammer = Lahev's HAPI framework for building HTTP services. I also find that the = IETF's penchant for cute names can be confusing and off-putting to = outsiders. >=20 > =C3=89ric asks 'Should there also be a link with the CoRE WG?'=20 >=20 > Definitely not. CORE is not HTTP, and requiring coordination there = would be burdensome to both communities. If the IESG is going to insist = on coordination between HTTP and CORE, we have a *much* bigger = discussion at our feet. >=20 > Ben wonders about TLS mutual authentication. I suspect that TLS = extensions are out of scope for this community, but gauging interest in = / requirements for doing it from HTTP APIs here could be useful.=20 >=20 > Roman asks 'As written, does all HTTP for web browser go to HTTPbis; = and machine-to-machine comes here?' >=20 > That's a rough yardstick; I expect there to be fairly close = communication and coordination between the groups about potential work. = This isn't that unusual in the IETF; e.g., I've seen work items go from = SECDISPATCH to DISPATCH and then to the HTTP WG, with a fair amount of = back-channel coordination between the relevant WG chairs and ADs. >=20 > I'd also observe that from discussions I've had, this split makes = sense to HTTP folks; it might not from a greater distance, but I do = think it'll work. >=20 > Cheers, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 From nobody Thu Sep 10 09:31:27 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C503A0E0B; Thu, 10 Sep 2020 09:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUaB0Zy1HS8w; Thu, 10 Sep 2020 09:31:13 -0700 (PDT) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) (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 A63F33A0DA1; Thu, 10 Sep 2020 09:31:13 -0700 (PDT) Received: by mail-io1-f47.google.com with SMTP id b6so7749207iof.6; Thu, 10 Sep 2020 09:31:13 -0700 (PDT) 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:content-transfer-encoding; bh=xw707rscEbmTNnyYmIqptcP8VrrHCap9GWQ7BrRyJ6w=; b=E32uu+U/wFNkY867wSsZPidlzaL2DukA1Z4QhEZVJCxDDbWWVb2CNS7MNAbaM1V3sP oBsdOlkzSXBdIfbcf6lJtuuwvVOjvAuV+znzGNi7DSX4BbLDcfeKHjh4G5bRWFJ1XeDW Q+ggS0ZKI6ZJkQmNg6gTqRLNB6tOwQ2ryTgnxIP3iMHmH/mG1TPFo6lr056Edr9LwXPi jdmx1wCDun0jMxF+4eLfkNej83Z77WB/Ok7tuH3lCvRfGgNCnM+meumAT+MVGMhh3gI+ gD9J8GsnGw/l5Mizboz/5dSuqfMaLaZ3DPnNSIgdKK2VGJVjjH5XEHOWiXP7RPY9y3HW OvwA== X-Gm-Message-State: AOAM533iC3EPjxSbRQulqKQD+Aom+KO87HmKvQPNzPKWqDu8Rj6NsCT4 PazwU8lh/SOueAM+yfzH0BeUWgznpSvqvq1iFF+uONSzRzE= X-Google-Smtp-Source: ABdhPJyVurPPthrhYP+PogVuvgWZiPT0qWc9xRtHgPsZLlFGeQRRaUJOW6tIvyDYw3Ww/16d3HHC6Sh+bjtWxOjkEyc= X-Received: by 2002:a6b:e718:: with SMTP id b24mr8501855ioh.9.1599755472655; Thu, 10 Sep 2020 09:31:12 -0700 (PDT) MIME-Version: 1.0 References: <159966323879.8094.15005725001447785927@ietfa.amsl.com> <752C5863-F10A-44A4-8459-CBF7529C14CC@cooperw.in> In-Reply-To: <752C5863-F10A-44A4-8459-CBF7529C14CC@cooperw.in> From: Barry Leiba Date: Thu, 10 Sep 2020 12:31:01 -0400 Message-ID: To: Alissa Cooper Cc: Mark Nottingham , httpapi@ietf.org, IESG , httpapi-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [httpapi] Alissa Cooper's Block on charter-ietf-httpapi-00-00: (with BLOCK and COMMENT) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 16:31:26 -0000 The -00-01 version of the proposed charter includes Mark's latest edits. Alissa, will you check it and let us know what you think? Thanks, Barry On Thu, Sep 10, 2020 at 8:44 AM Alissa Cooper wrote: > > Hi Mark, > > > On Sep 9, 2020, at 9:15 PM, Mark Nottingham wrote: > > > > Hi Alissa (et al), > > > > Apologies, I missed many of the previous charter comments (there was so= me confusion about list creation -- it seems not many people were told), so= I'll respond to some previous ones here. > > > > (For folks who have just joined the list: this is the IESG's discussion= of whether to adopt the WG charter; see and feel free to chime in). > > > >> On 10 Sep 2020, at 12:53 am, Alissa Cooper via Datatracker wrote: > >> > >> I agree with Martin. > > > > Martin's comment was: > > > >> from the charter I have no idea what portion of this large problem spa= ce constitutes the short-term objectives of this group. > > > > As discussed in DISPATCH, this is purposefully not proposed with immedi= ate milestones. To date, we've done some API-related work in the HTTP WG (e= .g., Signatures), and in many ways this proposal is simply splitting that w= ork out into a separate group to make it more accessible to its target comm= unity. > > > > So, to Murray and Roman's comments, yes this is intended to be a standi= ng group -- *if* it is healthy. I would consider it on probation for at lea= st 6-9 months, to see if it's able to have good interaction with the rest o= f the API community and be productive; if not, as I've said many times I'll= be the one most loudly calling for it to be shut down. > > I would say we put that in the charter then, so everyone agrees to revisi= t on the same time frame. > > > > > There are a number of potential drafts out there that the group could a= dopt, but I'd rather see a CfAs happen in the group, rather than as part of= the chartering process; that will help form the community and give it owne= rship over what's going on (and will give it some experience running the Cf= A process). I gave a talk about API standards and linked to the mailing lis= t last night, and so far the mailing list has almost 20 new members -- many= who AFAICT are new to the IETF and also actively practicing in this area. > > > > So if the IESG insists, we can add a few initial drafts as milestones, = but for the reasons above I have a fairly strong preference not to. > > > >> In particular, I am wondering how the WG will define "specific use cas= es or applications" as referred to where the text says, "this WG will not t= ake on work items for APIs for specific use cases or applications." > > > > It says the WG will *not* do those things. > > Right, my question is how do you know which things you won=E2=80=99t do? > > > > > That text is intended to prevent the WG from defining specific APIs. Fo= r example, if someone wants to create a HTTP API for DNS (to use a recent e= xample), this group wouldn't be an appropriate place to do that. > > I think for applications it=E2=80=99s clearer, but what is a =E2=80=9Cspe= cific use case=E2=80=9D? To use your example above, let=E2=80=99s say my us= e case is that I want to be able to digitally sign the contents of HTTP mes= sages. Since that is apparently in scope for the WG, why does it not count = as a =E2=80=9Cspecific use case=E2=80=9D? I=E2=80=99m not arguing with the = limitation, I=E2=80=99m just hoping to have the charter be more expressive = in describing the boundary. > > > > >> I agree with Magnus that it is unclear whether the third bullet encomp= asses work that the WG will do or not. > > > > The intent there was that the group could talk about proposals for new = status codes, but would need to defer their actual standardisation to the H= TTP WG (since in HTTP status codes, like methods, are generic and not suppo= sed to be specific to any application or even type of application). > > Ok. It shouldn=E2=80=99t be in a bulleted list of what the WG=E2=80=99s o= utputs will be, but maybe can be described in its own paragraph. > > Alissa > > > > > I'm open to figuring out another way to do this -- and maybe the charte= r doesn't need to be so specific (or maybe it needs to be more?). But I thi= nk it's generally safer for restricted items like status codes and methods = to go through the HTTP WG; we've been burned before on this (e.g., see WEBD= AV). > > > >> The first sentence is clunky. I would suggest "In addition to its use = for web browsing, HTTP is often used for machine-to-machine communication, = facilitated by HTTP APIs." > > > > Fine by me. > > > > Some other responses -- > > > > Erik K said 'I still think the working group name might be shortened by= removing "ttp".' > > > > I don't think that would be wise; not only would it remove the reinforc= ement of the term 'HTTP API' (terminology has been a problem for a while in= this area), but it would also conflict with Eran Hammer Lahev's HAPI frame= work for building HTTP services. I also find that the IETF's penchant for c= ute names can be confusing and off-putting to outsiders. > > > > =C3=89ric asks 'Should there also be a link with the CoRE WG?' > > > > Definitely not. CORE is not HTTP, and requiring coordination there woul= d be burdensome to both communities. If the IESG is going to insist on coor= dination between HTTP and CORE, we have a *much* bigger discussion at our f= eet. > > > > Ben wonders about TLS mutual authentication. I suspect that TLS extensi= ons are out of scope for this community, but gauging interest in / requirem= ents for doing it from HTTP APIs here could be useful. > > > > Roman asks 'As written, does all HTTP for web browser go to HTTPbis; an= d machine-to-machine comes here?' > > > > That's a rough yardstick; I expect there to be fairly close communicat= ion and coordination between the groups about potential work. This isn't th= at unusual in the IETF; e.g., I've seen work items go from SECDISPATCH to D= ISPATCH and then to the HTTP WG, with a fair amount of back-channel coordin= ation between the relevant WG chairs and ADs. > > > > I'd also observe that from discussions I've had, this split makes sense= to HTTP folks; it might not from a greater distance, but I do think it'll = work. > > > > Cheers, > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > From nobody Thu Sep 10 09:31:50 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2B03A0DDD; Thu, 10 Sep 2020 09:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mH0vGalq7wO9; Thu, 10 Sep 2020 09:31:34 -0700 (PDT) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (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 864D23A0DDC; Thu, 10 Sep 2020 09:31:34 -0700 (PDT) Received: by mail-io1-f54.google.com with SMTP id d18so7732913iop.13; Thu, 10 Sep 2020 09:31:34 -0700 (PDT) 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=QriBx6WZQVxPWsN99OffHueBRVh2+SvAbZXMHiqiEXs=; b=O7a2LgW+JtthNUyfjnp3tHrdHrNpiVXAv29OAVnLC377dg5qhC1Ep7sPJzW6So+JGC sw+VYgpBzo7fd1udyjhVOQo3EFQl6Uc5UWMLD79eGrPoTXB/6lm3UEHSsralnoxKU0tg 0qIvky2tEBraCE+DqaoCLUvbPJTl2soEhMNFB72o7fxLAnPi+ffmgivLDO1Xfict8yz/ PfhJaueqhMsER8QCS57EnDyxwWcDGcMPy3RI7yP6St/EA3hbo1LW/fBUluW86Xvyq0b1 NemEy4VigKw1yq+fhVGeQw1K78VgLyP+DY5Zs0FYIsnj1PCvLnKKEDN1MKnEXnzvNkvj JIog== X-Gm-Message-State: AOAM532n4rbehdbwEadKRusMbN20ok4D5eaHgE4HCnNZyPl6STmJLbiA JFK5O9mHOemdIvGa17QljWd3AbIUWlFUvY5g4eA= X-Google-Smtp-Source: ABdhPJxK8hpm5AFavGhFMQNMphVh3vPOpDhKFL7hj/5WKID3iwEXt+t3f+MebV3OuKUEF9Sqpv8FPNI0XJU9eMAqxV4= X-Received: by 2002:a05:6638:14c8:: with SMTP id l8mr9502016jak.136.1599755493734; Thu, 10 Sep 2020 09:31:33 -0700 (PDT) MIME-Version: 1.0 References: <159958075822.806.6403222206022210649@ietfa.amsl.com> In-Reply-To: <159958075822.806.6403222206022210649@ietfa.amsl.com> From: Barry Leiba Date: Thu, 10 Sep 2020 12:31:22 -0400 Message-ID: To: Martin Duke Cc: The IESG , httpapi@ietf.org, httpapi-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [httpapi] Martin Duke's Block on charter-ietf-httpapi-00-00: (with BLOCK) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 16:31:47 -0000 The -00-01 version of the proposed charter includes Mark's latest edits. Martin, will you check it and let us know what you think? On Tue, Sep 8, 2020 at 11:59 AM Martin Duke via Datatracker wrote: > > Martin Duke has entered the following ballot position for > charter-ietf-httpapi-00-00: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-httpapi/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > I certainly support creation of a working group of this nature; however, from > the charter I have no idea what portion of this large problem space constitutes > the short-term objectives of this group. > > > > > From nobody Thu Sep 10 09:32:34 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D65D3A0DEE; Thu, 10 Sep 2020 09:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3bgEieHqdS0; Thu, 10 Sep 2020 09:32:15 -0700 (PDT) Received: from mail-il1-f179.google.com (mail-il1-f179.google.com [209.85.166.179]) (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 8C81C3A0E02; Thu, 10 Sep 2020 09:32:14 -0700 (PDT) Received: by mail-il1-f179.google.com with SMTP id l4so6267304ilq.2; Thu, 10 Sep 2020 09:32:14 -0700 (PDT) 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:content-transfer-encoding; bh=pfYLb4GTSP41pO1jAJp7IFh9kt/26lbaZzQCn5qPcvg=; b=tjOyp0Bx4rfeO9Ign9RBPHLRrrkbl6ryb61peQSUR19It6Rj7BGQUMx8WIGCDpnTH2 owXPeglTUo+lo970aGrwx+EiIME81YYQSOtEyf8ObgNdD9zh6cABb1SbEfADSWfA9ErE 8VWXKnbTBSq5OKRqAhpB0LPYarf8SPXQKKENEuhpdOTa8r02MEOBffxm+b9ZPt5xGdek hNMZF9y10VqQ64LOqlNCc9gD5mBkJy+oPF5P2Kf1fB4FUrf3x/UoDhNL97fLe7KanIB2 HofjT5m311YjNHJLwWSFRYD1YltnhJHXZ0OVOHRjphjxGoBFF4qYXPDLjZs5Ub8MhGu2 1V9g== X-Gm-Message-State: AOAM5329jOsyXyqcWjuY+ib7X4+pThKultMQd1RpbWJlKLPghcvKNwdI CoJLe4iSLjcHDZCQ2VSk0e7PlaYsFXBQJDXKZAM= X-Google-Smtp-Source: ABdhPJz460OeUR2zZBlm5SYJkTvuVHcCVLkkwFlvCtBVxItB7qsoIySE5pVUfOv4PVNsGiBf0SSMUPj3erwmkhbxHMo= X-Received: by 2002:a92:d482:: with SMTP id p2mr8998587ilg.9.1599755533676; Thu, 10 Sep 2020 09:32:13 -0700 (PDT) MIME-Version: 1.0 References: <159967746837.8437.7601380417417968185@ietfa.amsl.com> In-Reply-To: <159967746837.8437.7601380417417968185@ietfa.amsl.com> From: Barry Leiba Date: Thu, 10 Sep 2020 12:32:02 -0400 Message-ID: To: Roman Danyliw Cc: The IESG , httpapi@ietf.org, httpapi-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [httpapi] Roman Danyliw's No Objection on charter-ietf-httpapi-00-00: (with COMMENT) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 16:32:30 -0000 The -00-01 version of the proposed charter includes Mark's latest edits. Roman, will you check it and let us know what you think? On Wed, Sep 9, 2020 at 2:51 PM Roman Danyliw via Datatracker wrote: > > Roman Danyliw has entered the following ballot position for > charter-ietf-httpapi-00-00: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-httpapi/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ** (Like Martin and Alissa) I=E2=80=99m having trouble discriminating wha= t work comes > to HTTPbis as opposed to this proposed WG. As written, does all HTTP for= web > browser go to HTTPbis; and machine-to-machine comes here? > > ** Per =E2=80=9CProposals for new HTTP status codes, methods, or other ge= neric > extensions, to be considered by the HTTP Working Group=E2=80=9D, why woul= d this WG > propose new work for HTTPbis, instead of doing it? > > ** How do when know when this WG is done? > > ** Can the initial milestones please be added > > > From nobody Thu Sep 10 09:59:42 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134F23A0E41; Thu, 10 Sep 2020 09:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=cooperw.in header.b=MHKxekeL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YsD7Z7fz 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 4zlo3VXUxK8F; Thu, 10 Sep 2020 09:59:39 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF223A0E31; Thu, 10 Sep 2020 09:59:38 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9348A5C010D; Thu, 10 Sep 2020 12:59:37 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 10 Sep 2020 12:59:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=r YBcNv2P9G78mUQSH1oVEvYpg0cV4Vks08+Enyat3Fs=; b=MHKxekeLUqLlbiZWY 9wdhTh6l54FHyhLi5ddB8q+7vdhPLVypcV13yEZ9QESUNRbGK8hhv+ElwdoqhFOl 4S+41LLnZXg8Ff31B6uF1/lVADhSbecXdkI9z8Ga3hRdyxczrSPrKwI0PH9hUKVP W6g1smeRHyuEbEa1puGxK37oPiiTloJZA0ggUR77z63Kezm851ROiSKhw3Qx0V+z JxOZt+QWgq9Ba4UCst/6P03mxuXxeOlZpDbIk3JtdYDVtYiX5XlyAdH9T4swyjmX 13ulHxYNzGrafP9YIBy4ptpSRjgkwAwXyAiy61NIM9QngEaCBwXeuqJU0eZGrnUy Hy7sQ== 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=rYBcNv2P9G78mUQSH1oVEvYpg0cV4Vks08+Enyat3 Fs=; b=YsD7Z7fzm3/q91zC9mGLyIr4RKRIGJQxtOc+faZ3n+Vc25ENvmeBtxVDC /C76hBNPSlHR281yKPUqTVt9Z4NsVIceu3gFpYgahnCim2VB0e/8gUhWMMjDUsCR /qIlxExOpea8nOCq5QrEiAHEkScM/CSNYVcz3X83+B4wTLQ1vlGK4O3BQUQq3KEK O/GgzlTLDClKjxp8FQGgap5/U0YhVqVmZVjpGHVgu/H5O7+zU1SF0oQ9LrnXP7Ij O3Urn6DXQDrOXwFWBzgFpJWUnVC+HPE7vaUOu96/NLTTA2dJZsojaX5vQHXP6rBf oUlHQuJdyiBRfXkX6lCwJHa/IlN7w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehjedguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhi shhsrgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuggftrf grthhtvghrnhepleevkeeiueelgedvhfdtvdetvdekffeiteekteffveehtdetveeifedv teelteeknecuffhomhgrihhnpehivghtfhdrohhrghdpmhhnohhtrdhnvghtnecukfhppe dujeefrdefkedruddujedrkeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinh X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.84]) by mail.messagingengine.com (Postfix) with ESMTPA id F059E3064683; Thu, 10 Sep 2020 12:59:36 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Alissa Cooper In-Reply-To: Date: Thu, 10 Sep 2020 12:59:36 -0400 Cc: Mark Nottingham , httpapi@ietf.org, IESG , httpapi-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <515FE00E-9542-46F3-8666-9D4ADC7B4C65@cooperw.in> References: <159966323879.8094.15005725001447785927@ietfa.amsl.com> <752C5863-F10A-44A4-8459-CBF7529C14CC@cooperw.in> To: Barry Leiba X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [httpapi] Alissa Cooper's Block on charter-ietf-httpapi-00-00: (with BLOCK and COMMENT) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 16:59:41 -0000 > On Sep 10, 2020, at 12:31 PM, Barry Leiba = wrote: >=20 > The -00-01 version of the proposed charter includes Mark's latest > edits. Alissa, will you check it and let us know what you think? It does not address the points below about reviewing the productivity of = the group after 6-9 months or about =E2=80=9Cspecific use cases.=E2=80=9D = Otherwis it looks fine to me. Thanks, Alissa >=20 > Thanks, > Barry >=20 > On Thu, Sep 10, 2020 at 8:44 AM Alissa Cooper = wrote: >>=20 >> Hi Mark, >>=20 >>> On Sep 9, 2020, at 9:15 PM, Mark Nottingham wrote: >>>=20 >>> Hi Alissa (et al), >>>=20 >>> Apologies, I missed many of the previous charter comments (there was = some confusion about list creation -- it seems not many people were = told), so I'll respond to some previous ones here. >>>=20 >>> (For folks who have just joined the list: this is the IESG's = discussion of whether to adopt the WG charter; see = and feel = free to chime in). >>>=20 >>>> On 10 Sep 2020, at 12:53 am, Alissa Cooper via Datatracker = wrote: >>>>=20 >>>> I agree with Martin. >>>=20 >>> Martin's comment was: >>>=20 >>>> from the charter I have no idea what portion of this large problem = space constitutes the short-term objectives of this group. >>>=20 >>> As discussed in DISPATCH, this is purposefully not proposed with = immediate milestones. To date, we've done some API-related work in the = HTTP WG (e.g., Signatures), and in many ways this proposal is simply = splitting that work out into a separate group to make it more accessible = to its target community. >>>=20 >>> So, to Murray and Roman's comments, yes this is intended to be a = standing group -- *if* it is healthy. I would consider it on probation = for at least 6-9 months, to see if it's able to have good interaction = with the rest of the API community and be productive; if not, as I've = said many times I'll be the one most loudly calling for it to be shut = down. >>=20 >> I would say we put that in the charter then, so everyone agrees to = revisit on the same time frame. >>=20 >>>=20 >>> There are a number of potential drafts out there that the group = could adopt, but I'd rather see a CfAs happen in the group, rather than = as part of the chartering process; that will help form the community and = give it ownership over what's going on (and will give it some experience = running the CfA process). I gave a talk about API standards and linked = to the mailing list last night, and so far the mailing list has almost = 20 new members -- many who AFAICT are new to the IETF and also actively = practicing in this area. >>>=20 >>> So if the IESG insists, we can add a few initial drafts as = milestones, but for the reasons above I have a fairly strong preference = not to. >>>=20 >>>> In particular, I am wondering how the WG will define "specific use = cases or applications" as referred to where the text says, "this WG will = not take on work items for APIs for specific use cases or applications." >>>=20 >>> It says the WG will *not* do those things. >>=20 >> Right, my question is how do you know which things you won=E2=80=99t = do? >>=20 >>>=20 >>> That text is intended to prevent the WG from defining specific APIs. = For example, if someone wants to create a HTTP API for DNS (to use a = recent example), this group wouldn't be an appropriate place to do that. >>=20 >> I think for applications it=E2=80=99s clearer, but what is a = =E2=80=9Cspecific use case=E2=80=9D? To use your example above, let=E2=80=99= s say my use case is that I want to be able to digitally sign the = contents of HTTP messages. Since that is apparently in scope for the WG, = why does it not count as a =E2=80=9Cspecific use case=E2=80=9D? I=E2=80=99= m not arguing with the limitation, I=E2=80=99m just hoping to have the = charter be more expressive in describing the boundary. >>=20 >>>=20 >>>> I agree with Magnus that it is unclear whether the third bullet = encompasses work that the WG will do or not. >>>=20 >>> The intent there was that the group could talk about proposals for = new status codes, but would need to defer their actual standardisation = to the HTTP WG (since in HTTP status codes, like methods, are generic = and not supposed to be specific to any application or even type of = application). >>=20 >> Ok. It shouldn=E2=80=99t be in a bulleted list of what the WG=E2=80=99s= outputs will be, but maybe can be described in its own paragraph. >>=20 >> Alissa >>=20 >>>=20 >>> I'm open to figuring out another way to do this -- and maybe the = charter doesn't need to be so specific (or maybe it needs to be more?). = But I think it's generally safer for restricted items like status codes = and methods to go through the HTTP WG; we've been burned before on this = (e.g., see WEBDAV). >>>=20 >>>> The first sentence is clunky. I would suggest "In addition to its = use for web browsing, HTTP is often used for machine-to-machine = communication, facilitated by HTTP APIs." >>>=20 >>> Fine by me. >>>=20 >>> Some other responses -- >>>=20 >>> Erik K said 'I still think the working group name might be shortened = by removing "ttp".' >>>=20 >>> I don't think that would be wise; not only would it remove the = reinforcement of the term 'HTTP API' (terminology has been a problem for = a while in this area), but it would also conflict with Eran Hammer = Lahev's HAPI framework for building HTTP services. I also find that the = IETF's penchant for cute names can be confusing and off-putting to = outsiders. >>>=20 >>> =C3=89ric asks 'Should there also be a link with the CoRE WG?' >>>=20 >>> Definitely not. CORE is not HTTP, and requiring coordination there = would be burdensome to both communities. If the IESG is going to insist = on coordination between HTTP and CORE, we have a *much* bigger = discussion at our feet. >>>=20 >>> Ben wonders about TLS mutual authentication. I suspect that TLS = extensions are out of scope for this community, but gauging interest in = / requirements for doing it from HTTP APIs here could be useful. >>>=20 >>> Roman asks 'As written, does all HTTP for web browser go to HTTPbis; = and machine-to-machine comes here?' >>>=20 >>> That's a rough yardstick; I expect there to be fairly close = communication and coordination between the groups about potential work. = This isn't that unusual in the IETF; e.g., I've seen work items go from = SECDISPATCH to DISPATCH and then to the HTTP WG, with a fair amount of = back-channel coordination between the relevant WG chairs and ADs. >>>=20 >>> I'd also observe that from discussions I've had, this split makes = sense to HTTP folks; it might not from a greater distance, but I do = think it'll work. >>>=20 >>> Cheers, >>>=20 >>> -- >>> Mark Nottingham https://www.mnot.net/ >>>=20 >>=20 From nobody Thu Sep 10 10:05:03 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54053A0E98; Thu, 10 Sep 2020 10:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqO27J-1_GCX; Thu, 10 Sep 2020 10:04:56 -0700 (PDT) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) (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 4DA733A0E97; Thu, 10 Sep 2020 10:04:56 -0700 (PDT) Received: by mail-io1-f53.google.com with SMTP id m17so7932990ioo.1; Thu, 10 Sep 2020 10:04:56 -0700 (PDT) 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:content-transfer-encoding; bh=s5Lzd5Jqr3bVjO0dpxFfpVlpTeoyQP0mRKtBq2+sPwI=; b=tDNv3fZnzVCodwf8cq5FA3wWoUEuEyeq1YrbsBEfHZPbHpYjVWgMltXCXcGntO9WpS EKBWT5tpX6qInSQHHu70rWEF7F7dTb7OUcpHCtK/XLtZy/49uxy9eG9B11JTRoZI8R0/ GVq4jS48hTYostg+OCMOn/HHBT+6jZZaPZc8ync+xwL/vTA64w1hfzqDL+/LH7Ga65xO f2MnuiIk7USB5OQprGiKlULbyY5ma9NJSKDgavd6YrK+ngiYSm3XkLISt3+QHvoH3YJ2 UCBb5gUBZ4FD2/gY+IZWD7l4Yok8QR1Z7ShAKX9nhuQa14pWqqNZ179f19KHaDEgI3+H +x9w== X-Gm-Message-State: AOAM5303qO+xJUQ4nu7/kp8opLWpX4GBzHwg5tZVC6A2+hscgEjjlH6+ +d38eUipJ/FOCwlKDUFJShkNI2Q4Y9vXRVuYPT4= X-Google-Smtp-Source: ABdhPJxws2riUUxh3RCGgKv2FKmTpZbRAZ3BKbrvV/MX2hyjR5xL5lZUzY2PQUqjDkwJHmbxr1iJno5WpR52V+nk0TU= X-Received: by 2002:a6b:e718:: with SMTP id b24mr8631702ioh.9.1599757495190; Thu, 10 Sep 2020 10:04:55 -0700 (PDT) MIME-Version: 1.0 References: <159966323879.8094.15005725001447785927@ietfa.amsl.com> <752C5863-F10A-44A4-8459-CBF7529C14CC@cooperw.in> <515FE00E-9542-46F3-8666-9D4ADC7B4C65@cooperw.in> In-Reply-To: <515FE00E-9542-46F3-8666-9D4ADC7B4C65@cooperw.in> From: Barry Leiba Date: Thu, 10 Sep 2020 13:04:44 -0400 Message-ID: To: Alissa Cooper Cc: Mark Nottingham , httpapi@ietf.org, IESG , httpapi-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [httpapi] Alissa Cooper's Block on charter-ietf-httpapi-00-00: (with BLOCK and COMMENT) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 17:04:58 -0000 Mark, for "In particular, this WG will not take on work items for APIs for specific use cases or applications," are we looking, perhaps for something like, "In particular, this WG will not take on work items for APIs for narrow use cases or specific applications"? Barry On Thu, Sep 10, 2020 at 12:59 PM Alissa Cooper wrote: > > > > On Sep 10, 2020, at 12:31 PM, Barry Leiba wro= te: > > > > The -00-01 version of the proposed charter includes Mark's latest > > edits. Alissa, will you check it and let us know what you think? > > It does not address the points below about reviewing the productivity of = the group after 6-9 months or about =E2=80=9Cspecific use cases.=E2=80=9D O= therwis it looks fine to me. > > Thanks, > Alissa > > > > > Thanks, > > Barry > > > > On Thu, Sep 10, 2020 at 8:44 AM Alissa Cooper wrote= : > >> > >> Hi Mark, > >> > >>> On Sep 9, 2020, at 9:15 PM, Mark Nottingham wrote: > >>> > >>> Hi Alissa (et al), > >>> > >>> Apologies, I missed many of the previous charter comments (there was = some confusion about list creation -- it seems not many people were told), = so I'll respond to some previous ones here. > >>> > >>> (For folks who have just joined the list: this is the IESG's discussi= on of whether to adopt the WG charter; see and feel free to chime in). > >>> > >>>> On 10 Sep 2020, at 12:53 am, Alissa Cooper via Datatracker wrote: > >>>> > >>>> I agree with Martin. > >>> > >>> Martin's comment was: > >>> > >>>> from the charter I have no idea what portion of this large problem s= pace constitutes the short-term objectives of this group. > >>> > >>> As discussed in DISPATCH, this is purposefully not proposed with imme= diate milestones. To date, we've done some API-related work in the HTTP WG = (e.g., Signatures), and in many ways this proposal is simply splitting that= work out into a separate group to make it more accessible to its target co= mmunity. > >>> > >>> So, to Murray and Roman's comments, yes this is intended to be a stan= ding group -- *if* it is healthy. I would consider it on probation for at l= east 6-9 months, to see if it's able to have good interaction with the rest= of the API community and be productive; if not, as I've said many times I'= ll be the one most loudly calling for it to be shut down. > >> > >> I would say we put that in the charter then, so everyone agrees to rev= isit on the same time frame. > >> > >>> > >>> There are a number of potential drafts out there that the group could= adopt, but I'd rather see a CfAs happen in the group, rather than as part = of the chartering process; that will help form the community and give it ow= nership over what's going on (and will give it some experience running the = CfA process). I gave a talk about API standards and linked to the mailing l= ist last night, and so far the mailing list has almost 20 new members -- ma= ny who AFAICT are new to the IETF and also actively practicing in this area= . > >>> > >>> So if the IESG insists, we can add a few initial drafts as milestones= , but for the reasons above I have a fairly strong preference not to. > >>> > >>>> In particular, I am wondering how the WG will define "specific use c= ases or applications" as referred to where the text says, "this WG will not= take on work items for APIs for specific use cases or applications." > >>> > >>> It says the WG will *not* do those things. > >> > >> Right, my question is how do you know which things you won=E2=80=99t d= o? > >> > >>> > >>> That text is intended to prevent the WG from defining specific APIs. = For example, if someone wants to create a HTTP API for DNS (to use a recent= example), this group wouldn't be an appropriate place to do that. > >> > >> I think for applications it=E2=80=99s clearer, but what is a =E2=80=9C= specific use case=E2=80=9D? To use your example above, let=E2=80=99s say my= use case is that I want to be able to digitally sign the contents of HTTP = messages. Since that is apparently in scope for the WG, why does it not cou= nt as a =E2=80=9Cspecific use case=E2=80=9D? I=E2=80=99m not arguing with t= he limitation, I=E2=80=99m just hoping to have the charter be more expressi= ve in describing the boundary. > >> > >>> > >>>> I agree with Magnus that it is unclear whether the third bullet enco= mpasses work that the WG will do or not. > >>> > >>> The intent there was that the group could talk about proposals for ne= w status codes, but would need to defer their actual standardisation to the= HTTP WG (since in HTTP status codes, like methods, are generic and not sup= posed to be specific to any application or even type of application). > >> > >> Ok. It shouldn=E2=80=99t be in a bulleted list of what the WG=E2=80=99= s outputs will be, but maybe can be described in its own paragraph. > >> > >> Alissa > >> > >>> > >>> I'm open to figuring out another way to do this -- and maybe the char= ter doesn't need to be so specific (or maybe it needs to be more?). But I t= hink it's generally safer for restricted items like status codes and method= s to go through the HTTP WG; we've been burned before on this (e.g., see WE= BDAV). > >>> > >>>> The first sentence is clunky. I would suggest "In addition to its us= e for web browsing, HTTP is often used for machine-to-machine communication= , facilitated by HTTP APIs." > >>> > >>> Fine by me. > >>> > >>> Some other responses -- > >>> > >>> Erik K said 'I still think the working group name might be shortened = by removing "ttp".' > >>> > >>> I don't think that would be wise; not only would it remove the reinfo= rcement of the term 'HTTP API' (terminology has been a problem for a while = in this area), but it would also conflict with Eran Hammer Lahev's HAPI fra= mework for building HTTP services. I also find that the IETF's penchant for= cute names can be confusing and off-putting to outsiders. > >>> > >>> =C3=89ric asks 'Should there also be a link with the CoRE WG?' > >>> > >>> Definitely not. CORE is not HTTP, and requiring coordination there wo= uld be burdensome to both communities. If the IESG is going to insist on co= ordination between HTTP and CORE, we have a *much* bigger discussion at our= feet. > >>> > >>> Ben wonders about TLS mutual authentication. I suspect that TLS exten= sions are out of scope for this community, but gauging interest in / requir= ements for doing it from HTTP APIs here could be useful. > >>> > >>> Roman asks 'As written, does all HTTP for web browser go to HTTPbis; = and machine-to-machine comes here?' > >>> > >>> That's a rough yardstick; I expect there to be fairly close communic= ation and coordination between the groups about potential work. This isn't = that unusual in the IETF; e.g., I've seen work items go from SECDISPATCH to= DISPATCH and then to the HTTP WG, with a fair amount of back-channel coord= ination between the relevant WG chairs and ADs. > >>> > >>> I'd also observe that from discussions I've had, this split makes sen= se to HTTP folks; it might not from a greater distance, but I do think it'l= l work. > >>> > >>> Cheers, > >>> > >>> -- > >>> Mark Nottingham https://www.mnot.net/ > >>> > >> > From nobody Thu Sep 10 10:25:58 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271BC3A0E29; Thu, 10 Sep 2020 10:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 YbEn1PPAlIsf; Thu, 10 Sep 2020 10:25:53 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 B2C3D3A0BEA; Thu, 10 Sep 2020 10:25:53 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id d190so7998305iof.3; Thu, 10 Sep 2020 10:25:53 -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=aGooy6gho/6p5iqvKOspbqTOwhLc3RUyu3m83dsShBw=; b=iv0MGzhfxvm43KHX8wPr4Kv6sYBylH5LsTf9F9VyXHLu9kA5NfzNKVhAiQUstXKDjl 1/u4tkkdIuj8pW++8BMDqoJoa3it6x49gf9luPm+jiWg9drOJ2OCGhBwfpkd1XTDBrcY HCjK5XEl3cMv4eLTMbr0fgxoTeco+OfSCcZg7YeHawr0jwcmRbuRGu/P0xqBGrKlTWzN wzmF6FZMBbA3U86QIAX4I0xCS4/1H/Umpg2GLVXE+mkJajKOSZSZGLEI8SiVyqpOsTgh 9F3leWfl4/N+vmjuLJ8kJU+0A13vvd6u5Rr/4+lZDd/W8/e+1qFCjImefou5Ppq2PF8A py+A== 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=aGooy6gho/6p5iqvKOspbqTOwhLc3RUyu3m83dsShBw=; b=dbwDLLUhkECBem8RC3InxcNTAIheW7U+WWy+4mrzKhh8v85hm69zNMV4Zd5SQDzIFB WWfDCL/QK8hvwAud+MAiPFVC1DiFhPVqoeejD22nlVVcpxMUvg3hIBW1nbOXZ8N8uyS2 Dc3fpC0lmWI3y5Szkf3/v2ixaGAnKiJowAANnTUh9rXXX9TcdhBr29/FIzFFKY9B6FoW HR63P9J8QsSjuLuFe+Blw9L7WS6ja1qLz7XhhriKM6DvW+HX0o2dZSxQuTbFopBjLAHD ymC9o9Kp/kACPMzp3qYrtFVmPvua52gN7oAQc5tJ958hO7j/IyrspdQNPviJLpwmiuZW mjeg== X-Gm-Message-State: AOAM533qxHu/y8GRdveglAygOqOjzZ5C494aiGpd/NURj8apCTZl8Lz0 GyGSxhtnJZMOlHdqySE9er3iZaf88rjwY/QKfzgU6tft X-Google-Smtp-Source: ABdhPJyLs9EhVRyGB/mregs2YS13eyCzVewcklG+l35hkw9mX6ZEFjufMw04woonQ5C3DIl4DxEKUfEZlTXcV/k0yQw= X-Received: by 2002:a05:6602:2d90:: with SMTP id k16mr8418319iow.19.1599758752981; Thu, 10 Sep 2020 10:25:52 -0700 (PDT) MIME-Version: 1.0 References: <159958075822.806.6403222206022210649@ietfa.amsl.com> In-Reply-To: From: Martin Duke Date: Thu, 10 Sep 2020 10:25:42 -0700 Message-ID: To: Barry Leiba Cc: The IESG , httpapi@ietf.org, httpapi-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000032a7b105aef8dc58" Archived-At: Subject: Re: [httpapi] Martin Duke's Block on charter-ietf-httpapi-00-00: (with BLOCK) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 17:25:55 -0000 --00000000000032a7b105aef8dc58 Content-Type: text/plain; charset="UTF-8" I'm in the same boat as Alissa. I can live with this is a provisional standing WG that takes whatever comes in, for now, but if there's a probation period it should be in the charter. On Thu, Sep 10, 2020 at 9:31 AM Barry Leiba wrote: > The -00-01 version of the proposed charter includes Mark's latest > edits. Martin, will you check it and let us know what you think? > > On Tue, Sep 8, 2020 at 11:59 AM Martin Duke via Datatracker > wrote: > > > > Martin Duke has entered the following ballot position for > > charter-ietf-httpapi-00-00: Block > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/charter-ietf-httpapi/ > > > > > > > > ---------------------------------------------------------------------- > > BLOCK: > > ---------------------------------------------------------------------- > > > > I certainly support creation of a working group of this nature; however, > from > > the charter I have no idea what portion of this large problem space > constitutes > > the short-term objectives of this group. > > > > > > > > > > > --00000000000032a7b105aef8dc58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm in the same boat as Alissa. I can live with this i= s a provisional standing WG that takes whatever comes in, for now, but if t= here's a probation period it should be in the charter.

On Thu, Sep 10, 2= 020 at 9:31 AM Barry Leiba <b= arryleiba@computer.org> wrote:
The -00-01 version of the proposed charter includes M= ark's latest
edits.=C2=A0 Martin, will you check it and let us know what you think?

On Tue, Sep 8, 2020 at 11:59 AM Martin Duke via Datatracker
<noreply@ietf.org<= /a>> wrote:
>
> Martin Duke has entered the following ballot position for
> charter-ietf-httpapi-00-00: Block
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-= ietf-httpapi/
>
>
>
> ----------------------------------------------------------------------=
> BLOCK:
> ----------------------------------------------------------------------=
>
> I certainly support creation of a working group of this nature; howeve= r, from
> the charter I have no idea what portion of this large problem space co= nstitutes
> the short-term objectives of this group.
>
>
>
>
>
--00000000000032a7b105aef8dc58-- From nobody Thu Sep 10 10:28:46 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C729B3A0E47; Thu, 10 Sep 2020 10:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiN5omH6Q_oa; Thu, 10 Sep 2020 10:28:40 -0700 (PDT) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) (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 82E493A0E2F; Thu, 10 Sep 2020 10:28:40 -0700 (PDT) Received: by mail-io1-f48.google.com with SMTP id z25so7960182iol.10; Thu, 10 Sep 2020 10:28:40 -0700 (PDT) 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=PZs/punzAZcI5I0G4+Q0a2J+DBBGq/XMTRA4gYIKrUE=; b=nBQZst41MMyWh3iSvsvFmyvgb3nkMQwb0oBG69TCSKBhcD6RAbxnTp0VS+mAYYxaez e65X+eQREuasD5aJ90XEtXCdY80TnLmpiuBfb2LA0SEN/xsZqcHeIO6/1uQ69f0Sj6ho zDs8/IK+sXH9nWatyUcppJmRKHDw3Ex2mFbVrGYZWEF4k3ubHTqeXS4G9V5TY+tNs07D mespKJVO8/Crsu80cf8diArvuaU4QSmKvTm09bULKYnjwegQnAmnAyfhbiZaSXJtR3uU XYVIKNoK/w/nP/Lh0bnlZb/O/1+7211V6ZHM7Mjye22D1QjMDBDTajZcZ9TJKuAcxyKS tNKA== X-Gm-Message-State: AOAM530iP3inymXvkso+imimdkflJxcbbxEWS1f0jLc7TLfjqiQu1d+n Qs7o6rT+w/3kokUEq/xxmfEeszNuRiJEsdGU93M= X-Google-Smtp-Source: ABdhPJwbGXHeHQV2bmy9PloW44tbREx/hUeRiHq5fK3pXiXv6/kQ3AyuIYJvDaGEU0/dr+PBEEs9n+RqYzBKgI4pC+U= X-Received: by 2002:a02:9149:: with SMTP id b9mr9444522jag.50.1599758919686; Thu, 10 Sep 2020 10:28:39 -0700 (PDT) MIME-Version: 1.0 References: <159958075822.806.6403222206022210649@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Thu, 10 Sep 2020 13:28:26 -0400 Message-ID: To: Martin Duke , Alissa Cooper Cc: The IESG , httpapi@ietf.org, httpapi-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [httpapi] Martin Duke's Block on charter-ietf-httpapi-00-00: (with BLOCK) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 17:28:42 -0000 > I'm in the same boat as Alissa. I can live with this is a provisional standing WG that takes > whatever comes in, for now, but if there's a probation period it should be in the charter. What do the two of you think about a provision to review the charter and WG progress annually, at each year's 3rd IETF meeting? Barry > On Thu, Sep 10, 2020 at 9:31 AM Barry Leiba wrote: >> >> The -00-01 version of the proposed charter includes Mark's latest >> edits. Martin, will you check it and let us know what you think? >> >> On Tue, Sep 8, 2020 at 11:59 AM Martin Duke via Datatracker >> wrote: >> > >> > Martin Duke has entered the following ballot position for >> > charter-ietf-httpapi-00-00: Block >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut this >> > introductory paragraph, however.) >> > >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/charter-ietf-httpapi/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > BLOCK: >> > ---------------------------------------------------------------------- >> > >> > I certainly support creation of a working group of this nature; however, from >> > the charter I have no idea what portion of this large problem space constitutes >> > the short-term objectives of this group. >> > >> > >> > >> > >> > From nobody Thu Sep 10 10:40:55 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86303A0BCD; Thu, 10 Sep 2020 10:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=cooperw.in header.b=Cmjh39bQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=r/BlUWpU 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 B81jidL5W8XX; Thu, 10 Sep 2020 10:40:49 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F05AE3A0BA0; Thu, 10 Sep 2020 10:40:48 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 4AD0C5C00E8; Thu, 10 Sep 2020 13:40:48 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 10 Sep 2020 13:40:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=T /oRjLnJu8CHOzUdvRPk+twH073FQoQNNR5VdCDbRLY=; b=Cmjh39bQAYQjtNy2Z 9T0Y62mMGbKyC0aDlFCSnxz0DgYfv/DV6R2PJIQjXg1MhLCB2GqhPYHPgGZZkRLI NH8hGTakTFQQb1cBY+6JfYd5a38Anl42vVN91Yf+TI3BxRgAPDtbJyTJ/KRvCkLV 0j/jsZbShh0xJ+mETkvle9R7NZuhyQRG6coiwZ3JHmCuz7ieiQ8QJPKY956o6wJv PqKTJ0X7/5FcEIrMCodnqIClCJ0DGPz3P9ll34OJC2Up2Kdx2d1hsu4L8GRNhOOs 314CuYXQdYlTzwWpeYb3TXePmqDTF4cHLXvJPHJ8e6C33I5ZOb16MoTEp1jAmgSv DfOzQ== 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=T/oRjLnJu8CHOzUdvRPk+twH073FQoQNNR5VdCDbR LY=; b=r/BlUWpUL8bYZ+NxeiqyMFNL4qu99pr1Z2uQP1PxsDO4ansqP6BvATaeL UlUsa3A1buYqnHBP5RdFsh6rlkOZHyWcYMzPRr7XTyyJZ8BIlrDAHCrHwn49/9Bu aXHT9x7mqnWk8IpAaqNhkTAAgC/iwTkANrfwF/g6xV030QCoG7chzUd3TXE9Zwxs JylRySJ3x0Ahuk7AyFOCp+VF1Oztnc7mIghBkApZNwbMHwIuXAW5H3kqVSDqHRz4 tkLvhER0SYFCF87n9MdThWSFpAmQY10+nm3PrD40XLQaNgme2r+78ofe3WBGGqzS OAHZXz8NY//sX08Mo0CNYPOWVdS5w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehjedguddtlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhi shhsrgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuggftrf grthhtvghrnhepfeduhffgtefgtedvvdffiedutdekffegvdejjedtieehfefgleefuedt ledvgffgnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduud ejrdekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pegrlhhishhsrgestghoohhpvghrfidrihhn X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.84]) by mail.messagingengine.com (Postfix) with ESMTPA id 61BBC3064683; Thu, 10 Sep 2020 13:40:47 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Alissa Cooper In-Reply-To: Date: Thu, 10 Sep 2020 13:40:46 -0400 Cc: Martin Duke , IESG , httpapi@ietf.org, httpapi-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8CA2E360-D2D7-49F6-AFCA-922C42844B39@cooperw.in> References: <159958075822.806.6403222206022210649@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [httpapi] Martin Duke's Block on charter-ietf-httpapi-00-00: (with BLOCK) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 17:40:51 -0000 WFM > On Sep 10, 2020, at 1:28 PM, Barry Leiba = wrote: >=20 >> I'm in the same boat as Alissa. I can live with this is a provisional = standing WG that takes >> whatever comes in, for now, but if there's a probation period it = should be in the charter. >=20 > What do the two of you think about a provision to review the charter > and WG progress annually, at each year's 3rd IETF meeting? >=20 > Barry >=20 >> On Thu, Sep 10, 2020 at 9:31 AM Barry Leiba = wrote: >>>=20 >>> The -00-01 version of the proposed charter includes Mark's latest >>> edits. Martin, will you check it and let us know what you think? >>>=20 >>> On Tue, Sep 8, 2020 at 11:59 AM Martin Duke via Datatracker >>> wrote: >>>>=20 >>>> Martin Duke has entered the following ballot position for >>>> charter-ietf-httpapi-00-00: Block >>>>=20 >>>> When responding, please keep the subject line intact and reply to = all >>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>> introductory paragraph, however.) >>>>=20 >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/charter-ietf-httpapi/ >>>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> BLOCK: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> I certainly support creation of a working group of this nature; = however, from >>>> the charter I have no idea what portion of this large problem space = constitutes >>>> the short-term objectives of this group. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 From nobody Thu Sep 10 10:41:23 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D11A3A0F56; Thu, 10 Sep 2020 10:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 VyLc7TYIDHig; Thu, 10 Sep 2020 10:41:19 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 391CE3A0F55; Thu, 10 Sep 2020 10:41:19 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id f82so1807765ilh.8; Thu, 10 Sep 2020 10:41:19 -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=wEikYWVa8h+kJNjVeijmCgkzR5L+0E2XMuAigTRvWpA=; b=ippTuUerx9DSfGHTZMvc4OaIdwkRJA8iUZM0jz40qDr6jr0c81rUAWRrMIA2vbstpj wQsG7hmKWBY5lbgvTPydpvw+A735OFNqrc91JWZ/186lVsFYlSrWv8ijiujimkeBlVry uz9YQGQ6JkAOr36XvIQETVORkSNoV+w+I04oQbcHQvybG166VDLo7fLxipEYb5OTR7GQ PgyJBYhT7JSIKnkkLTk9itIkZcHa/DerHmeSdcEFmfvjurnOguzFNXQgNa/rABWOuUe4 HtgbZ1Bx1mrOfjrxBdz5Z/nGnLTMv19UbapXN6zG3og52dlvQ64Gmki0O5RIE+ivzLod vJXg== 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=wEikYWVa8h+kJNjVeijmCgkzR5L+0E2XMuAigTRvWpA=; b=I+CI0z/RPL7nb1guXibcXoNLp8qH9TCYIe22GqoHDBaAbK2UrchRir5AdFQA21JZim jbTlE38dRH1OkJ6di8JNtp+S8KG9zzDR9erw0hzpDOt2yZySn5ALrvTmu+YPCT6gHV3z OTOLMhNp5vEt2pSS3qAyfm0E+d7uaOMFKKRl9QFkWUhR7mCGwkT7nX2D4pD/tH47PY2l 7aFwx3ESGNrpdaZLMYmY8/ec/f5EAXc5Eaz/sXbgTYnBjiOwJgx6Mib5yGSpgez0i74a emB5iiKEjf/66jC64rvlkMe5o28AMck5WCF5Ud55ky+KUnEBDVKPUQSit2LWjTo6l932 ihTQ== X-Gm-Message-State: AOAM531nQezDb/dGigg2HMI0aum5dIjKuXQ3lQFrNwhCjDYALv0+EmXb Y6AQpxoy4kNN9VqcwLH83o+YB1BRfYKM/iaw1+A= X-Google-Smtp-Source: ABdhPJy4haeNJszi8Zc2r3g1At004CpPrIxRcXLD4/otPtCW8z6oeXneegepuH+kuCL+q3YZ/aIyl3OFHTXhdNH1p8Y= X-Received: by 2002:a92:6906:: with SMTP id e6mr8904822ilc.249.1599759678481; Thu, 10 Sep 2020 10:41:18 -0700 (PDT) MIME-Version: 1.0 References: <159958075822.806.6403222206022210649@ietfa.amsl.com> In-Reply-To: From: Martin Duke Date: Thu, 10 Sep 2020 10:41:08 -0700 Message-ID: To: Barry Leiba Cc: Alissa Cooper , The IESG , httpapi@ietf.org, httpapi-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000005ca94d05aef913f6" Archived-At: Subject: Re: [httpapi] Martin Duke's Block on charter-ietf-httpapi-00-00: (with BLOCK) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 17:41:21 -0000 --0000000000005ca94d05aef913f6 Content-Type: text/plain; charset="UTF-8" If that's in there, I would remove my BLOCK. However, I wonder why we wouldn't just hold a WG forming BOF to figure out what they're going to do, rather than form the WG and then figure out the initial objectives. The latter has the same first meeting while also having less organizational overhead. On Thu, Sep 10, 2020 at 10:28 AM Barry Leiba wrote: > > I'm in the same boat as Alissa. I can live with this is a provisional > standing WG that takes > > whatever comes in, for now, but if there's a probation period it should > be in the charter. > > What do the two of you think about a provision to review the charter > and WG progress annually, at each year's 3rd IETF meeting? > > Barry > > > On Thu, Sep 10, 2020 at 9:31 AM Barry Leiba > wrote: > >> > >> The -00-01 version of the proposed charter includes Mark's latest > >> edits. Martin, will you check it and let us know what you think? > >> > >> On Tue, Sep 8, 2020 at 11:59 AM Martin Duke via Datatracker > >> wrote: > >> > > >> > Martin Duke has entered the following ballot position for > >> > charter-ietf-httpapi-00-00: Block > >> > > >> > When responding, please keep the subject line intact and reply to all > >> > email addresses included in the To and CC lines. (Feel free to cut > this > >> > introductory paragraph, however.) > >> > > >> > > >> > > >> > The document, along with other ballot positions, can be found here: > >> > https://datatracker.ietf.org/doc/charter-ietf-httpapi/ > >> > > >> > > >> > > >> > ---------------------------------------------------------------------- > >> > BLOCK: > >> > ---------------------------------------------------------------------- > >> > > >> > I certainly support creation of a working group of this nature; > however, from > >> > the charter I have no idea what portion of this large problem space > constitutes > >> > the short-term objectives of this group. > >> > > >> > > >> > > >> > > >> > > --0000000000005ca94d05aef913f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If that's in there, I would remove my BLOCK.

<= /div>
However, I wonder why we wouldn't just hold a WG forming BOF = to figure out what they're going to do, rather than form the WG and the= n figure out the initial objectives. The latter has the same first meeting= =C2=A0while also having less organizational overhead.

On Thu, Sep 10, = 2020 at 10:28 AM Barry Leiba <barryleiba@computer.org> wrote:
> I'm in the same boat as Alissa. I can live= with this is a provisional standing WG that takes
> whatever comes in, for now, but if there's a probation period it s= hould be in the charter.

What do the two of you think about a provision to review the charter
and WG progress annually, at each year's 3rd IETF meeting?

Barry

> On Thu, Sep 10, 2020 at 9:31 AM Barry Leiba <barryleiba@computer.org> wrot= e:
>>
>> The -00-01 version of the proposed charter includes Mark's lat= est
>> edits.=C2=A0 Martin, will you check it and let us know what you th= ink?
>>
>> On Tue, Sep 8, 2020 at 11:59 AM Martin Duke via Datatracker
>> <noreply@= ietf.org> wrote:
>> >
>> > Martin Duke has entered the following ballot position for
>> > charter-ietf-httpapi-00-00: Block
>> >
>> > When responding, please keep the subject line intact and repl= y to all
>> > email addresses included in the To and CC lines. (Feel free t= o cut this
>> > introductory paragraph, however.)
>> >
>> >
>> >
>> > The document, along with other ballot positions, can be found= here:
>> > https://datatracker.ietf.org/doc= /charter-ietf-httpapi/
>> >
>> >
>> >
>> > -------------------------------------------------------------= ---------
>> > BLOCK:
>> > -------------------------------------------------------------= ---------
>> >
>> > I certainly support creation of a working group of this natur= e; however, from
>> > the charter I have no idea what portion of this large problem= space constitutes
>> > the short-term objectives of this group.
>> >
>> >
>> >
>> >
>> >
--0000000000005ca94d05aef913f6-- From nobody Thu Sep 10 11:22:27 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFCA3A097C; Thu, 10 Sep 2020 11:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=akamai.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 sN_yJtXu5B_Q; Thu, 10 Sep 2020 11:22:20 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 44C7A3A0BD3; Thu, 10 Sep 2020 11:22:20 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 08AILqmq022216; Thu, 10 Sep 2020 19:22:16 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=0g5dUYz+a72USy8Gl2Mh5MkJeu8K0RQ+WEAqgTRrqxg=; b=feFVkipFMesMn4DDLyaB5ghSqWzUKTTtnVjjl3Mz0pLPwk9qOQK5EQwOccxS/osAvsw5 sV8uuhgBMWPW4DorabeRk7yxOYgChRknlOo/hN+3gEc62RqWuf4J7Hfqtvo0wRIrNPED /aQm63/dHkO6jUm/xpi4ORreG06zVM5u2ErWiqy37pVz8Fr9Leu99AjM4+36Z3C24CeT vaKN5Br8WwHLBvx98L6l6+wQj5emibtVg2ZgkaYiEhsLO+b7QMnCXafvQt9AJvpreb+F JwEkBWmZI/kuLgsCpwJ4lRH9KILkmmQBceEAttV0XCdKaONDS+74UM5YRe8Yq9OLQRTK mQ== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 33byrs72yu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Sep 2020 19:22:16 +0100 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 08AIGko8019792; Thu, 10 Sep 2020 11:22:15 -0700 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint5.akamai.com with ESMTP id 33c8n9vfmd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 10 Sep 2020 11:22:15 -0700 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 10 Sep 2020 14:22:15 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1497.006; Thu, 10 Sep 2020 14:22:14 -0400 From: "Salz, Rich" To: Martin Duke , Barry Leiba CC: Alissa Cooper , The IESG , "httpapi@ietf.org" , "httpapi-chairs@ietf.org" Thread-Topic: Martin Duke's Block on charter-ietf-httpapi-00-00: (with BLOCK) Thread-Index: AQHWhfkNzRS4/0Th10WuKA+1MpAZ4qliVr8AgAAPLgCAAADDAIAAA40A///IbQA= Date: Thu, 10 Sep 2020 18:22:14 +0000 Message-ID: References: <159958075822.806.6403222206022210649@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081201 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_A20E689CA528433583A5F416F0769912akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-10_05:2020-09-10, 2020-09-10 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=764 adultscore=0 bulkscore=0 mlxscore=0 spamscore=0 malwarescore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009100167 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-10_08:2020-09-10, 2020-09-10 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 priorityscore=1501 suspectscore=0 phishscore=0 clxscore=1011 lowpriorityscore=0 mlxlogscore=699 bulkscore=0 spamscore=0 adultscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009100169 Archived-At: Subject: Re: [httpapi] Martin Duke's Block on charter-ietf-httpapi-00-00: (with BLOCK) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 18:22:22 -0000 --_000_A20E689CA528433583A5F416F0769912akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgc2VlbXMgcHJvaGliaXRpdmVseSBoYXJkIHRvIGRvIGEgdmlydHVhbCBCb0YsIGJhc2VkIG9u IHdoYXQgSeKAmXZlIHNlZW4uIFlNTVYuDQo= --_000_A20E689CA528433583A5F416F0769912akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkl0IHNlZW1zIHByb2hpYml0aXZlbHkgaGFyZCB0byBkbyBhIHZpcnR1YWwgQm9GLCBi YXNlZCBvbiB3aGF0IEnigJl2ZSBzZWVuLiBZTU1WLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_A20E689CA528433583A5F416F0769912akamaicom_-- From nobody Thu Sep 10 11:29:05 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560EF3A0BFA; Thu, 10 Sep 2020 11:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-KaYgY9twUa; Thu, 10 Sep 2020 11:28:59 -0700 (PDT) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) (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 39F2D3A097C; Thu, 10 Sep 2020 11:28:59 -0700 (PDT) Received: by mail-io1-f53.google.com with SMTP id r9so8236663ioa.2; Thu, 10 Sep 2020 11:28:59 -0700 (PDT) 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=WjkWZBk+PdhokQkVbHgqKEBqD/McEyzyYQbskm33uuA=; b=uRe0444XjUV8MUIHN3rRYhoHCvo98p7QXAKzvwETFLspLzonmqeGwQhkbAA4RGFmLz wDUUCpW3958eTTnbA/OfMM7IAZUpTYyRB805gKN58F1J/Lm2cOu5KKf3zOsBKqJhpu8v wcClUo737YDvNyu3e5EoW0kEuVQrzLpxA++BtZsWdSqzPwHzRzu7l18VdZsuNzMJfVqa SuMJ+sn6JO1wedWZA18esfG22/cNelCK3rAkEK9U3U1HHwrgOygoQGmJ1alKLMdcTjCL df3HZDF02P17g171CbcMBMyOO1cHVl5bSeWwyB1jBzL3iVoiK7Yg8fLnEgrBlvLQBCZB s8OA== X-Gm-Message-State: AOAM533NBFkTqg1MRCwQCbCzBqRAiVVpb8Rb+chnDudyb5MRjUSKQgBv /TtIxbg/RZ0zjfRHvLfbnYPjypGmwgmd257Jvtg= X-Google-Smtp-Source: ABdhPJysNiFteLmNwCjSz1ne77W/DhJ2LuT+9kXucMCw7SfopHqJ3jsxcvv+KZqHdNGSwgO8D4rMd4ugFS93ccOgb24= X-Received: by 2002:a6b:e718:: with SMTP id b24mr8965630ioh.9.1599762538374; Thu, 10 Sep 2020 11:28:58 -0700 (PDT) MIME-Version: 1.0 References: <159958075822.806.6403222206022210649@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Thu, 10 Sep 2020 14:28:47 -0400 Message-ID: To: Martin Duke Cc: Alissa Cooper , The IESG , httpapi@ietf.org, httpapi-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [httpapi] Martin Duke's Block on charter-ietf-httpapi-00-00: (with BLOCK) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 18:29:01 -0000 >> What do the two of you think about a provision to review the charter >> and WG progress annually, at each year's 3rd IETF meeting? > > If that's in there, I would remove my BLOCK. Thanks, Martin. > However, I wonder why we wouldn't just hold a WG forming BOF to figure out what > they're going to do, rather than form the WG and then figure out the initial objectives. > The latter has the same first meeting while also having less organizational overhead. Part of the point of this working group is to involve a community that we know is there and has work to do, but that wouldn't normally go to an IETF BoF. It's not that there isn't work to do, nor that there aren't people prepared to do it, but that the process of getting work started in the IETF doesn't rope in that community. We could try pushing them into that process for a BoF for this working group... or we can do a slight adaptation for them. I think the latter is the better approach, and I think we'll need to look, moving into the future, at how to continue adapting in order to include different communities better. And I do think a "let's check and make sure this is working" thing is a good idea, so thanks, Martin and Alissa, for pushing on that. Barry From nobody Thu Sep 10 11:38:14 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D613A0BFA; Thu, 10 Sep 2020 11:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 P3i3_PP4dzsZ; Thu, 10 Sep 2020 11:38:08 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 47FAA3A0B70; Thu, 10 Sep 2020 11:38:08 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id u126so8218237iod.12; Thu, 10 Sep 2020 11:38:08 -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=LWs50hKOYpE1YY/tRBuByRDJ63YYwOUDQRYVZP/xdZA=; b=Rlldyn8kbskw3QLC/5pEaw2ujXbijtwzw43YiASUXdwAvw+qHer2gy8YVER41NqRej hVUWEmHjtp0AaqDQmrb2fOn/8WZ/0NN9S73dEWhd4YutqtzB8cR+X6GVyhcDdJKNaLH9 tPdWLPPinNBUDT+aGkiGe7+Xo1eDcXgkPQ/Z3o6waPp4KJEQozhsHy2DMZG1MKfBy8FK uA/w8XJMHR2L3NitpouhzL36+MymlD2oWwolFaDjWFcxJ1ZzsBoNK3Ysfu3Tu5GKns/d tiLrELB61BM9elVqko5yZp4b+EpbdG7N0aZP/jYGt8KbMV4qv5nJSiwYy9jCH5m2qinj aPHg== 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=LWs50hKOYpE1YY/tRBuByRDJ63YYwOUDQRYVZP/xdZA=; b=GPMTRlZWDi/hoIKBEVaIiYv4wXhCeLtKT9yhXPCScIO1UacZRuhmwPHBbyCUdyzEvF IS/OgTu1+kGRTyaJ/t3g1vc/vETMQ1QrG671L1utAQ1qXoCt0nyC2XWvDcchRCF9z0iA ScFnL6d0MnihocJ3y+s+IrAfSlzAOJdggN8JyGTtMe24WtU8wN46NC/3K2anxnCMG903 ok+X4x7DRf8psRIbKrjCu3ESh6kgZoSQHvoafHCDi9FNMibZQPTkbX9qWlacvwAlGQpc YM2Bm3EbD9VOWsKYnxmbLVVnhcL4vPbaBNhIMcRLCq+jX25v8AD0MA8Mr6mnEjL0LgYk cFBA== X-Gm-Message-State: AOAM5317T7MmwuEBzpkdjohuHluCQqBhdukKzKkCMSfj2oZk/u9xd8vZ wkmcahSMA+dggMof7I5p/cyslyJwqggZZyE9r4M= X-Google-Smtp-Source: ABdhPJweqzqr0E+D7ElW0yHJc41M7XtNcTNM086ruODDOl4/41ONIJwFt24fn3lANTt9abfDTcojpShOGJQBIpM//C8= X-Received: by 2002:a05:6602:2d86:: with SMTP id k6mr8868422iow.20.1599763087433; Thu, 10 Sep 2020 11:38:07 -0700 (PDT) MIME-Version: 1.0 References: <159958075822.806.6403222206022210649@ietfa.amsl.com> In-Reply-To: From: Martin Duke Date: Thu, 10 Sep 2020 11:37:57 -0700 Message-ID: To: Barry Leiba Cc: Alissa Cooper , The IESG , httpapi@ietf.org, httpapi-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000008d225805aef9dea9" Archived-At: Subject: Re: [httpapi] Martin Duke's Block on charter-ietf-httpapi-00-00: (with BLOCK) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 18:38:10 -0000 --0000000000008d225805aef9dea9 Content-Type: text/plain; charset="UTF-8" That seems like a well-thought-out reason. Carry on. On Thu, Sep 10, 2020 at 11:28 AM Barry Leiba wrote: > >> What do the two of you think about a provision to review the charter > >> and WG progress annually, at each year's 3rd IETF meeting? > > > > If that's in there, I would remove my BLOCK. > > Thanks, Martin. > > > However, I wonder why we wouldn't just hold a WG forming BOF to figure > out what > > they're going to do, rather than form the WG and then figure out the > initial objectives. > > The latter has the same first meeting while also having less > organizational overhead. > > Part of the point of this working group is to involve a community that > we know is there and has work to do, but that wouldn't normally go to > an IETF BoF. It's not that there isn't work to do, nor that there > aren't people prepared to do it, but that the process of getting work > started in the IETF doesn't rope in that community. We could try > pushing them into that process for a BoF for this working group... or > we can do a slight adaptation for them. I think the latter is the > better approach, and I think we'll need to look, moving into the > future, at how to continue adapting in order to include different > communities better. > > And I do think a "let's check and make sure this is working" thing is > a good idea, so thanks, Martin and Alissa, for pushing on that. > > Barry > --0000000000008d225805aef9dea9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That seems like a well-thought-out reason. Carry on.
=
On Thu= , Sep 10, 2020 at 11:28 AM Barry Leiba <barryleiba@computer.org> wrote:
>> What do the two of you think abo= ut a provision to review the charter
>> and WG progress annually, at each year's 3rd IETF meeting?
>
> If that's in there, I would remove my BLOCK.

Thanks, Martin.

> However, I wonder why we wouldn't just hold a WG forming BOF to fi= gure out what
> they're going to do, rather than form the WG and then figure out t= he initial objectives.
> The latter has the same first meeting while also having less organizat= ional overhead.

Part of the point of this working group is to involve a community that
we know is there and has work to do, but that wouldn't normally go to an IETF BoF.=C2=A0 It's not that there isn't work to do, nor that t= here
aren't people prepared to do it, but that the process of getting work started in the IETF doesn't rope in that community.=C2=A0 We could try<= br> pushing them into that process for a BoF for this working group... or
we can do a slight adaptation for them.=C2=A0 I think the latter is the
better approach, and I think we'll need to look, moving into the
future, at how to continue adapting in order to include different
communities better.

And I do think a "let's check and make sure this is working" = thing is
a good idea, so thanks, Martin and Alissa, for pushing on that.

Barry
--0000000000008d225805aef9dea9-- From nobody Thu Sep 10 18:25:08 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA783A12C3; Thu, 10 Sep 2020 18:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=k11brTOT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=s2IPbmNp 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 SUScaFUBdR_V; Thu, 10 Sep 2020 18:25:04 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F193A09F3; Thu, 10 Sep 2020 18:25:04 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 09F445C0109; Thu, 10 Sep 2020 21:25:02 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 10 Sep 2020 21:25:02 -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=V i3gwKRA+DFjEE/S2eLAVP0YHu79fluSe9MLQrlTby0=; b=k11brTOT/lPP6wRth pCzWPdYUIp1bMUvmVtUIfHKOF6Na1BzSQvn5YhzNqhIPROLuOO1MBNfqZFXPC8Y3 Ut0Faie+1HIuN3f+MG/x47vLMLmRvUYgoXeOHjDcNsby2Ml3p2TaoxbKbHvCGfGI lDTcC7Eg+iZE/K2VsuWqq9ahiLKkdad6JxieaJbBJDjutGbbbJS8Jseq+Cr8+xBt teQe8wTxB3Br9lRcbsTwBMkwMMtmNlhu4iLVyJs0oECXwxuHJemSLqxefcJgnote 5TuzdibjO9aom8mqle3aLuBoFYN3Lplq0dA24BTfpKWobUNTmacT9sMMhsC560dZ zTHNg== 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=Vi3gwKRA+DFjEE/S2eLAVP0YHu79fluSe9MLQrlTb y0=; b=s2IPbmNpMsoEqjfnUdJ84VetQC46IShMhb1Qv/n4IlSVnQssvgF7Xj24u j8Yk3d/J4pQ5/sk7ubxapTrNuTZB9Fj6CF4pXGw2BIX0XpPjCO7+SSQeZmdMFyMa SzdUb4u0g0C+iSW0eBKa+veTfjJhngxQEzQhk0XNbYW1ZXflu38JS5sdpQbmcYSX LaBR/48wSZJr68i49pW7+vapdA4blQR/NgvTpDP3k1CnY9oxqKfHfHETWBg9MTmD 6ncUPX5keR4WmC1/GeaOyD8MkSS9Y+xwkgLC9NXdmQJE7oxrm9CcCY2mx3B1Lz5r DkNfUoWADNZ91iXnEAmhO8rQGQvIg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehkedggeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpedtgfevieevvefgtdduheefhedvhfeuhffftdeiieeivdehfeffheetfeelkeek teenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepud duledrudejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 0D6BE3064674; Thu, 10 Sep 2020 21:24:59 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <752C5863-F10A-44A4-8459-CBF7529C14CC@cooperw.in> Date: Fri, 11 Sep 2020 11:24:57 +1000 Cc: httpapi@ietf.org, IESG , httpapi-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <55E84A4F-0A93-4E0C-B24B-263E32A68A05@mnot.net> References: <159966323879.8094.15005725001447785927@ietfa.amsl.com> <752C5863-F10A-44A4-8459-CBF7529C14CC@cooperw.in> To: Alissa Cooper X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [httpapi] Alissa Cooper's Block on charter-ietf-httpapi-00-00: (with BLOCK and COMMENT) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2020 01:25:06 -0000 Responses below. See updated charter at: https://gist.github.com/mnot/8a29455df65df33d92902a1ecc3e7e68 > On 10 Sep 2020, at 10:43 pm, Alissa Cooper wrote: >>=20 >> So, to Murray and Roman's comments, yes this is intended to be a = standing group -- *if* it is healthy. I would consider it on probation = for at least 6-9 months, to see if it's able to have good interaction = with the rest of the API community and be productive; if not, as I've = said many times I'll be the one most loudly calling for it to be shut = down. >=20 > I would say we put that in the charter then, so everyone agrees to = revisit on the same time frame. I've added a nine-month checkup. >> There are a number of potential drafts out there that the group could = adopt, but I'd rather see a CfAs happen in the group, rather than as = part of the chartering process; that will help form the community and = give it ownership over what's going on (and will give it some experience = running the CfA process). I gave a talk about API standards and linked = to the mailing list last night, and so far the mailing list has almost = 20 new members -- many who AFAICT are new to the IETF and also actively = practicing in this area. >>=20 >> So if the IESG insists, we can add a few initial drafts as = milestones, but for the reasons above I have a fairly strong preference = not to. >>=20 >>> In particular, I am wondering how the WG will define "specific use = cases or applications" as referred to where the text says, "this WG will = not take on work items for APIs for specific use cases or applications." >>=20 >> It says the WG will *not* do those things. >=20 > Right, my question is how do you know which things you won=E2=80=99t = do?=20 >=20 >> That text is intended to prevent the WG from defining specific APIs. = For example, if someone wants to create a HTTP API for DNS (to use a = recent example), this group wouldn't be an appropriate place to do that. >=20 > I think for applications it=E2=80=99s clearer, but what is a = =E2=80=9Cspecific use case=E2=80=9D? To use your example above, let=E2=80=99= s say my use case is that I want to be able to digitally sign the = contents of HTTP messages. Since that is apparently in scope for the WG, = why does it not count as a =E2=80=9Cspecific use case=E2=80=9D? I=E2=80=99= m not arguing with the limitation, I=E2=80=99m just hoping to have the = charter be more expressive in describing the boundary. Ah, I see. I've tried to address this, see what you think. >>> I agree with Magnus that it is unclear whether the third bullet = encompasses work that the WG will do or not. >>=20 >> The intent there was that the group could talk about proposals for = new status codes, but would need to defer their actual standardisation = to the HTTP WG (since in HTTP status codes, like methods, are generic = and not supposed to be specific to any application or even type of = application). >=20 > Ok. It shouldn=E2=80=99t be in a bulleted list of what the WG=E2=80=99s = outputs will be, but maybe can be described in its own paragraph. Previously done. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Fri Sep 11 09:34:21 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3A93A140E; Fri, 11 Sep 2020 09:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFMps0QH22sx; Fri, 11 Sep 2020 09:34:13 -0700 (PDT) Received: from mail-il1-f171.google.com (mail-il1-f171.google.com [209.85.166.171]) (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 54A6A3A13EF; Fri, 11 Sep 2020 09:34:13 -0700 (PDT) Received: by mail-il1-f171.google.com with SMTP id p13so9553900ils.3; Fri, 11 Sep 2020 09:34:13 -0700 (PDT) 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:content-transfer-encoding; bh=9y7iRAO7u0RgvS+119SHv8skOFSJInXlFUOYH7CPh1g=; b=Lbx01uUoglGlII+1mTjekEh3lOXNPx64PuwSm+5DAz2QHQeFYqbDN0an7vSR0DxyhR bfKjD7bC4xoslVo9KD4ZihVzC05CdY3H4hNtJGE6GS0tp6KUe/s1nf97AI+Rvh3cSzPA 4vbSsYju8Vd8RLE8zM0NaIX0R29p4uhNa+JyU8sJeS7R5Nn6moxRXgdBQyPw38nUYEdL UELLt/awzM0ZevQiXLwUGtmQbSbwZnrhayR2/J4fpzy3/3DPa/AI07Z/tzU3CU+pKYuJ INSg0XXVQziUPbZb9BZ3nNmeikLg6r2SHJtWLjsRHzJ8nHWXdmOuscpBOxjHCSLG2EKa n2fQ== X-Gm-Message-State: AOAM531PGO6XPEjTiKdVd4OJSpNTBDM1rcTvDl/kmm0zMNfSINWiF+LL lvrN34Pha20QYqhf+T1VtnBBVQuuI6y/Ua+pOwooIGXOtFE= X-Google-Smtp-Source: ABdhPJyln4KKLHrhMIvLRxGq4e72m129Z9rKan6tOMu8jPxhIzK02CTw4zn8IMIH+/JvJTSdQMQBaK6nF85Y8rFhGnI= X-Received: by 2002:a92:d482:: with SMTP id p2mr2536416ilg.9.1599842052398; Fri, 11 Sep 2020 09:34:12 -0700 (PDT) MIME-Version: 1.0 References: <159966323879.8094.15005725001447785927@ietfa.amsl.com> <752C5863-F10A-44A4-8459-CBF7529C14CC@cooperw.in> <55E84A4F-0A93-4E0C-B24B-263E32A68A05@mnot.net> In-Reply-To: <55E84A4F-0A93-4E0C-B24B-263E32A68A05@mnot.net> From: Barry Leiba Date: Fri, 11 Sep 2020 12:34:01 -0400 Message-ID: To: Mark Nottingham Cc: Alissa Cooper , httpapi@ietf.org, IESG , httpapi-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [httpapi] Alissa Cooper's Block on charter-ietf-httpapi-00-00: (with BLOCK and COMMENT) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2020 16:34:16 -0000 I have put Mark's latest version into the datatracker as -00-02. Barry On Thu, Sep 10, 2020 at 9:25 PM Mark Nottingham wrote: > > Responses below. See updated charter at: > https://gist.github.com/mnot/8a29455df65df33d92902a1ecc3e7e68 > > > > On 10 Sep 2020, at 10:43 pm, Alissa Cooper wrote: > >> > >> So, to Murray and Roman's comments, yes this is intended to be a stand= ing group -- *if* it is healthy. I would consider it on probation for at le= ast 6-9 months, to see if it's able to have good interaction with the rest = of the API community and be productive; if not, as I've said many times I'l= l be the one most loudly calling for it to be shut down. > > > > I would say we put that in the charter then, so everyone agrees to revi= sit on the same time frame. > > I've added a nine-month checkup. > > >> There are a number of potential drafts out there that the group could = adopt, but I'd rather see a CfAs happen in the group, rather than as part o= f the chartering process; that will help form the community and give it own= ership over what's going on (and will give it some experience running the C= fA process). I gave a talk about API standards and linked to the mailing li= st last night, and so far the mailing list has almost 20 new members -- man= y who AFAICT are new to the IETF and also actively practicing in this area. > >> > >> So if the IESG insists, we can add a few initial drafts as milestones,= but for the reasons above I have a fairly strong preference not to. > >> > >>> In particular, I am wondering how the WG will define "specific use ca= ses or applications" as referred to where the text says, "this WG will not = take on work items for APIs for specific use cases or applications." > >> > >> It says the WG will *not* do those things. > > > > Right, my question is how do you know which things you won=E2=80=99t do= ? > > > >> That text is intended to prevent the WG from defining specific APIs. F= or example, if someone wants to create a HTTP API for DNS (to use a recent = example), this group wouldn't be an appropriate place to do that. > > > > I think for applications it=E2=80=99s clearer, but what is a =E2=80=9Cs= pecific use case=E2=80=9D? To use your example above, let=E2=80=99s say my = use case is that I want to be able to digitally sign the contents of HTTP m= essages. Since that is apparently in scope for the WG, why does it not coun= t as a =E2=80=9Cspecific use case=E2=80=9D? I=E2=80=99m not arguing with th= e limitation, I=E2=80=99m just hoping to have the charter be more expressiv= e in describing the boundary. > > Ah, I see. I've tried to address this, see what you think. > > > >>> I agree with Magnus that it is unclear whether the third bullet encom= passes work that the WG will do or not. > >> > >> The intent there was that the group could talk about proposals for new= status codes, but would need to defer their actual standardisation to the = HTTP WG (since in HTTP status codes, like methods, are generic and not supp= osed to be specific to any application or even type of application). > > > > Ok. It shouldn=E2=80=99t be in a bulleted list of what the WG=E2=80=99s= outputs will be, but maybe can be described in its own paragraph. > > Previously done. > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Fri Sep 11 11:32:51 2020 Return-Path: X-Original-To: httpapi@ietf.org Delivered-To: httpapi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1CB3A166D; Fri, 11 Sep 2020 11:32:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: httpapi-chairs@ietf.org, httpapi@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.16.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <159984916888.7681.4751733647331664977@ietfa.amsl.com> Date: Fri, 11 Sep 2020 11:32:48 -0700 Archived-At: Subject: [httpapi] Alissa Cooper's No Objection on charter-ietf-httpapi-00-02: (with COMMENT) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2020 18:32:49 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-httpapi-00-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-httpapi/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my comments. From nobody Sat Sep 12 01:07:19 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3196C3A0921; Sat, 12 Sep 2020 01:07:17 -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 I6sLySs03v3U; Sat, 12 Sep 2020 01:07:15 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 C894B3A091A; Sat, 12 Sep 2020 01:07:14 -0700 (PDT) Received: from p200300dee7459100adc5aed73c04105b.dip0.t-ipconnect.de ([2003:de:e745:9100:adc5:aed7:3c04:105b]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1kH0Yy-0001Ua-8N; Sat, 12 Sep 2020 10:07:12 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Mirja Kuehlewind In-Reply-To: Date: Sat, 12 Sep 2020 10:07:11 +0200 Cc: Martin Duke , httpapi@ietf.org, Alissa Cooper , The IESG , httpapi-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <573B2E55-60E7-4D90-8171-FB0F1503C47E@kuehlewind.net> References: <159958075822.806.6403222206022210649@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.3608.120.23.2.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1599898035;a036cd2c; X-HE-SMSGID: 1kH0Yy-0001Ua-8N Archived-At: Subject: Re: [httpapi] Martin Duke's Block on charter-ietf-httpapi-00-00: (with BLOCK) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2020 08:07:17 -0000 > On 10. Sep 2020, at 20:28, Barry Leiba = wrote: >=20 > Part of the point of this working group is to involve a community that > we know is there and has work to do, but that wouldn't normally go to > an IETF BoF. It's not that there isn't work to do, nor that there > aren't people prepared to do it, but that the process of getting work > started in the IETF doesn't rope in that community.=20 Not that I want to impact your decision about this working group but I = find this argument that people are willing to come to a working group = meeting but not to a BoF meeting not very connivence. If people are = willing to do work in the IETF, they should should do it within the = (actually low amount of) process that we have. Just my 2c. Mirja From nobody Sat Sep 12 07:50:39 2020 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8583A099C; Sat, 12 Sep 2020 07:50:33 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=akamai.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 Hcn1MYSeTgo5; Sat, 12 Sep 2020 07:50:32 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 A4E5F3A0414; Sat, 12 Sep 2020 07:50:32 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 08CElfEj007073; Sat, 12 Sep 2020 15:50:24 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=qSmCSrse48xU4DrLl0X4URnhW0oXBMiF+iEhvxb1nxA=; b=S2MKUDZpFv6BfK1OMbwhRR5irXuXMBrL/YY1Pw72g+EzSqEPZR7OK/MwXVNevkB2bDpt qbjp5rDEKhoe6XEdiCAj5xzzYtOr83egfgNBu2HfynYCOi/napxYzTsu7pZkcUCVxUms y5fEY9osOFYjZGz93G0xfBL/HJ5pntRFvub/rijSCcNspWBK2zStIKmG4BJviRRWbW8p GWgBf/nCETKUyZ5D1LBAU9fTlGMand/zkbll5rn+bfY+NWY1Mv9UQow3BccX77YitHC4 q3riS0O54AE+wbTJojXe5Rgz87UydMV8G2NIZAt6w9jFpJzZMyfLat7Rva+9YfGchGaK Lg== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 33gnyx0sjj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 12 Sep 2020 15:50:24 +0100 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 08CEklW8021202; Sat, 12 Sep 2020 07:50:23 -0700 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint5.akamai.com with ESMTP id 33gvaa0bbf-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 12 Sep 2020 07:50:23 -0700 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 12 Sep 2020 10:49:41 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1497.006; Sat, 12 Sep 2020 10:49:41 -0400 From: "Salz, Rich" To: Mirja Kuehlewind , Barry Leiba CC: Martin Duke , "httpapi@ietf.org" , Alissa Cooper , The IESG , "httpapi-chairs@ietf.org" Thread-Topic: Martin Duke's Block on charter-ietf-httpapi-00-00: (with BLOCK) Thread-Index: AQHWhfkNzRS4/0Th10WuKA+1MpAZ4qliVr8AgAAPLgCAAADDAIAAA40AgAANUICAAnb9gIAALWeA Date: Sat, 12 Sep 2020 14:49:41 +0000 Message-ID: <50022B34-7F9B-4677-9BCF-08A0A945B94A@akamai.com> References: <159958075822.806.6403222206022210649@ietfa.amsl.com> <573B2E55-60E7-4D90-8171-FB0F1503C47E@kuehlewind.net> In-Reply-To: <573B2E55-60E7-4D90-8171-FB0F1503C47E@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081201 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.118.139] Content-Type: text/plain; charset="utf-8" Content-ID: <0BAF11691F31B04B8ECB08D8A46A4BAD@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-12_06:2020-09-10, 2020-09-12 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxlogscore=849 spamscore=0 suspectscore=0 adultscore=0 phishscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009120140 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-12_06:2020-09-10, 2020-09-12 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 impostorscore=0 malwarescore=0 phishscore=0 adultscore=0 mlxscore=0 bulkscore=0 spamscore=0 priorityscore=1501 mlxlogscore=811 lowpriorityscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009120142 Archived-At: Subject: Re: [httpapi] Martin Duke's Block on charter-ietf-httpapi-00-00: (with BLOCK) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2020 14:50:34 -0000 SSBiZWxpZXZlIHRoZXJlIGlzIGEgYmlnIGRpZmZlcmVuY2UgYmV0d2VlbiBhIFdHIC0tIGhlcmUg aXMgdGhlIHdvcmsgd2UgYXJlIGdvaW5nIHRvIGRvIC0tIGFuZCBhIEJvRiAtLSBsZXQncyBkaXNj dXNzIHdoYXQgd29yayB3ZSB3YW50IHRvIGRvLCBzcGVuZCBzb21lIHRpbWUgaW4gdGhlIHdlZWRz IHBpY2tpbmcgZGF0ZXMgYW5kIHdvcmRzbWl0aGluZywgYW5kIGhvcGUgaXQgZ2V0cyBhcHByb3Zl ZC4NCg0KVG8gYW4gb3V0c2lkZXIsIGl0J3Mgbm90IGEgbG93IGFtb3VudCBvZiBwcm9jZXNzLg0K DQoNCg== From nobody Wed Sep 30 09:04:17 2020 Return-Path: X-Original-To: httpapi@ietf.org Delivered-To: httpapi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A82923A0AE3; Wed, 30 Sep 2020 09:04:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.17.1 Auto-Submitted: auto-generated Precedence: bulk Cc: httpapi@ietf.org Reply-To: iesg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <160148185559.24946.17875142176860266330@ietfa.amsl.com> Date: Wed, 30 Sep 2020 09:04:15 -0700 Archived-At: Subject: [httpapi] WG Review: Building Blocks for HTTP APIs (httpapi) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 16:04:16 -0000 A new IETF WG has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2020-10-10. Building Blocks for HTTP APIs (httpapi) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Darrel Miller Rich Salz Assigned Area Director: Barry Leiba Applications and Real-Time Area Directors: Barry Leiba Murray Kucherawy Mailing list: Address: httpapi@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/httpapi Archive: https://mailarchive.ietf.org/arch/browse/httpapi/ Group page: https://datatracker.ietf.org/group/httpapi/ Charter: https://datatracker.ietf.org/doc/charter-ietf-httpapi/ In addition to its use for web browsing, HTTP is often used for machine-to-machine communication, facilitated by HTTP APIs. This Working Group will standardise HTTP protocol extensions for use in such cases, with a focus on building blocks for separate or combined use. Its output can include the following: • Specifications for HTTP extensions that relate to HTTP APIs (typically, new HTTP header and/or trailer fields) • Specifications for new message body formats, or conventions for their use in HTTP APIs (e.g., patterns of JSON objects) • Best practices and other documentation for HTTP API designers, consumers, implementers, operators, etc. Other items are out of scope. In particular, this WG will not take on work items for HTTP APIs for specific applications or services, and it will not define new HTTP extension points. APIs for HTTP itself (e.g., in clients and servers) are also out of scope. New work items can be added after a Call for Adoption on the working group mailing list and consultation with the Area Director. To assess whether the group is functioning well in this mode, this charter will be reviewed by the IESG nine months after chartering. To be successful, this Working Group will need to have active and broad representation from across the industry -- e.g., API gateway vendors (and other intermediaries), API consultants, API tool vendors, in-house API teams. Therefore, adopted proposals should have public support from multiple implementers and/or deployments before being sent to the IESG. This Working Group will also need to coordinate closely with the HTTP Working Group, in particular when new methods and status codes are proposed. Work items that are more broadly applicable (e.g., for implementation in Web browsers) are likely to be more appropriate in the HTTP Working Group, but it is expected that coordination and discussion between the groups' Chairs and Area Director(s) will guide work items to the appropriate venue. Milestones: TDB