From nobody Wed Feb 3 08:31:57 2021 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 D3BE73A0C93 for ; Wed, 3 Feb 2021 08:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=web.de 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 Rn-k_IoEWOPj for ; Wed, 3 Feb 2021 08:31:48 -0800 (PST) Received: from mout.web.de (mout.web.de [217.72.192.78]) (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 04BCD3A0A87 for ; Wed, 3 Feb 2021 08:31:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1612369893; bh=rLQg+DfbZMQqn26wiAbMmT6CSP5DFqGq+e4SHLujNeU=; h=X-UI-Sender-Class:To:Cc:From:Subject:Date; b=MY1w2FOABH6oDI4AVmXsJydlvHtRwlMYzWZmqBv6WmxNsDm2e55+6bDne9k2Kx2V0 ipovURrXnd+6gEhoZGcz3VlSIcxcpMUcCQr43meCmKfJvMpHoVtyPa6HkJ+EGckIc7 wtAvt7NQUGO0xhKwRO7JNBot/5jEXMHr/fBG15lk= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from [192.168.178.20] ([91.54.150.63]) by smtp.web.de (mrweb103 [213.165.67.124]) with ESMTPSA (Nemesis) id 0LtFQN-1m4H8Q18Fn-012s7i; Wed, 03 Feb 2021 17:31:33 +0100 To: "httpapi@ietf.org" Cc: Ruben Verborgh , Herbert Van de Sompel From: "Lars G. Svensson" Message-ID: <8fa3ca4f-e38b-0011-cf62-6e8184af7ea5@web.de> Date: Wed, 3 Feb 2021 17:31:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:Q4CP2RTVpjmEmPp7WW1F7e4iIvTtYIv7QvpDtNLxR10+ISbWnVv ReJm6qv10SKvGhDnUMI/PNsnx6XJ2lDDJIFelppPOPpf7mt0Odmn5hXpWs5JzLxwVM45L1i UT+1V/UH4cs3bXJ9SmACDZql/a6CT3X8ViycUEssX+b0locehLsHGC1pz5t3OILubadUYmS YbmKw74n1/1sTSTBr/raA== X-UI-Out-Filterresults: notjunk:1;V03:K0:dvd8kEs/KVc=:CVDb1crsdGLEGnJ5nj/QLZ tiqSN+UR/nymb67IXSDU3S1ZhXbt8eKsRKBZ6araHLzpRn7w3Zb+sT4GTeoSEXrVyeDDXoyMY nQfn3LrS9KW+hqPmo/1OaDjqZvJS0OUd6j8s+x+zJN3zTR0Wgrm/AmJEdrfxOdyVJKjHx7p6I zZxPg1WP4nWZzMDksUXtb1hHpFqXNFZx0ed3gRhFVvpByNALCg/5/DEF6qr6FCKv5ocqvSjws vX2754FC4CAOgEgr32no7i0wTe2qwcvu6shCTfm5vcVbK+/PVIvc5FHvWJrjbqfT5PvxdKu+j kwNyko0jaXAx3r7j7H61UFOk8JtvMZjpAXx+mYHxwzGfqFGBxn+DguZ8xRlDJ8mOFjHkP/s2E OC8RW+zJFsZAQeNqJ8uKy0PMIPn0/uLmrjL+tkT/kF3nzkYY4P2mUvGCLRYcuCCxFmCLkXrqU 3cbxjWQDA5BZ0jYMFOxazCxCVEdiG/rY4osvNgDzB+mtuRN3/L9R0hl3BUNWTgm6E7uK5cKid vDl77PDgDR2xAu2Axo1vTxFiLaz/eEzL5+Rzyzc+0Xc5dXvnqB4ioDenK4m6hPWJSGikXcQdS BSwMIkJsJ/TMPjk0i9PMkr4prvCvk/vkAYaENnVqY9k9MFC4Ddvv7KxljjyQjCOsPbzCnZF+V YW8lwp19GsCYJBjt/NMjcq69oO1CzpT2zWi0nuMsk2Z8/3117dPtgoVwneRnWehwhVlOjhsJB BNLn+4FNjr6qaf8tsQwm8k5im96pkQgCkUCbBfc8qRDDNQH/aDTKf241bFUFmi6kDlOJXkrHg gjXY2VOLjdnQrA1jNy6vjI+Bb8qndgtkzqaIdbh7g/UHTHeCQ10u2KZ0JbRLF7yLENN978pkA qy4eRslvuOuZJxjnb4eQ== Archived-At: Subject: [httpapi] Introduction and introducing proposal for standardisation of profile negotiation 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, 03 Feb 2021 16:31:56 -0000 All, My name is Lars Svensson and while not entirely new to IETF standardisation (I was active in URNbis) this is my first stab at http standardisation. For some time now, Ruben Verborgh, Herbert Van de Sompel and I together with folks in W3C have been working on a proposal for http content negotiation using profiles. This is done by adding a new http header "Accept-Profile" and re-using the "Link"-header (RFC 8288). The proposal was uploaded as an I-D earlier today [1]. The work has been done in co-operation with the W3C Data Exchange WG [2] and there is a corresponding document on rec track there [3]. In terms of implementation work we know of some implementations and would be happy to share that information, too, if it is of interest. We ask the WG to consider adopting this draft as part of its work. [1] https://www.ietf.org/archive/id/draft-svensson-profiled-representations-00= .txt [2] https://www.w3.org/2017/dxwg/ [3] https://www.w3.org/TR/dx-prof-conneg/ Thanks in advance, Lars for the authors From nobody Fri Feb 5 10:54:46 2021 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 0A1A43A0E7C for ; Fri, 5 Feb 2021 10:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, 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 PbxHeppKQiZQ for ; Fri, 5 Feb 2021 10:54:43 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 512CB3A1406 for ; Fri, 5 Feb 2021 10:54:29 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 115IrvqA018432 for ; Fri, 5 Feb 2021 18:54:28 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=8dH/xIGT8vurzPm0ev04JPpZcKO0uZLMjq+SUzRJVX8=; b=l14I/9Ct4U+V/da1myEDazxW7G3AQd+8/bejCqxyEKSGuMcYBcWST6zsxME1YrYnjYBK VYxTY6JkS4dF/K89dxTbwwIPfaP2++vbMLfSLYW0vHw/OTfHnrMMcqgKuPk4FZ9vX5dm 9K5uGZzeLdAZYOZHgfDp8dIelFnC3ESpYBuCv4GKera07J30UGfPK0zLqIEY0oHc0x4z fD+nK14/6AAwdKI6t/5KDfyqXd5KhxLLIYfPlRz9mfGJrDltfYLlCVkkn8zgcFJs/mcH Ti/OzUgs5CeFoYwTlKZhHz7PTce+5FJu4F+ZJqEntrq54cvIZvVsfagKQMzvflNoSawf gA== Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 36d0k6ttfs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 05 Feb 2021 18:54:28 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 115Incbc016111 for ; Fri, 5 Feb 2021 13:54:27 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.117]) by prod-mail-ppoint3.akamai.com with ESMTP id 36d3p4s3yq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 05 Feb 2021 13:54:27 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 5 Feb 2021 12:54:27 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.010; Fri, 5 Feb 2021 12:54:26 -0600 From: "Salz, Rich" To: "httpapi@ietf.org" Thread-Topic: client-specified timeout? Thread-Index: AQHW+/BTluM3M+wTdkuU+jT2kk+MZA== Date: Fri, 5 Feb 2021 18:54:25 +0000 Message-ID: <7613F010-431C-47B3-802E-5258BAA5E156@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.45.21011103 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_7613F010431C47B3802E5258BAA5E156akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.737 definitions=2021-02-05_10:2021-02-05, 2021-02-05 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 mlxlogscore=734 adultscore=0 suspectscore=0 bulkscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102050115 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.737 definitions=2021-02-05_10:2021-02-05, 2021-02-05 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 suspectscore=0 clxscore=1015 lowpriorityscore=0 priorityscore=1501 mlxscore=0 impostorscore=0 spamscore=0 mlxlogscore=631 malwarescore=0 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102050116 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.31) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint3 Archived-At: Subject: [httpapi] client-specified timeout? 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, 05 Feb 2021 18:54:45 -0000 --_000_7613F010431C47B3802E5258BAA5E156akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXMgaXQgcmVhc29uYWJsZSBmb3IgYSBjbGllbnQgdG8gd2FudCB0aGUgYWJpbGl0eSB0byBzYXkg dGhpbmdzIGxpa2Ug4oCcaWYgdGhpcyB0YWtlcyBtb3JlIHRoYW4gMzAwbXMgc2VuZCBhIGZhaWx1 cmUgc3RhdHVzIGNvZGUgYmFja+KAnSA/DQpBbnlvbmUgaW4gdGhlIFdHIGludGVyZXN0ZWQgaW4g dGhpbmtpbmcvd29ya2luZyBvbiB0aGlzPw0KDQo= --_000_7613F010431C47B3802E5258BAA5E156akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <70598CB4E5ED3E4C9980331CB4144FAF@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0 eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPklzIGl0 IHJlYXNvbmFibGUgZm9yIGEgY2xpZW50IHRvIHdhbnQgdGhlIGFiaWxpdHkgdG8gc2F5IHRoaW5n cyBsaWtlIOKAnGlmIHRoaXMgdGFrZXMgbW9yZSB0aGFuIDMwMG1zIHNlbmQgYSBmYWlsdXJlIHN0 YXR1cyBjb2RlIGJhY2vigJ0gPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BbnlvbmUgaW4gdGhlIFdHIGlu dGVyZXN0ZWQgaW4gdGhpbmtpbmcvd29ya2luZyBvbiB0aGlzPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7613F010431C47B3802E5258BAA5E156akamaicom_-- From nobody Fri Feb 5 11:04:11 2021 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 DD2D33A0E82 for ; Fri, 5 Feb 2021 11:04:10 -0800 (PST) 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 EJYJAxiF2Zjz for ; Fri, 5 Feb 2021 11:04:08 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 999493A0E7E for ; Fri, 5 Feb 2021 11:04:08 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id q9so6816014ilo.1 for ; Fri, 05 Feb 2021 11:04:08 -0800 (PST) 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:content-transfer-encoding; bh=tDxM58qrB9pi4qwDtG1H4XYtmKQnjzB8n1kVxZBci7E=; b=eHVNbo5ckZF+cnloW8Nrc6oUkqmJw51Cmnm8NzAx6gLQOMH4jIIYdE/rXUX8NexhdP D3zif2xeCz1+aZsrxP8U890YYmIBZzB0TxX2oScpMK4DbdYj8PufexSDqz9WcaYfxZVb peM0LZqnxv8HR5b0aZKSdBXD08elc0Ds2CL21wv6yLVURF69IYpSHc9Ei9pAHTuwjSMM olK1ckgmWrACY//5Z0U/hCPBhsdgjJM9w2EmWDyXhYWRRG01x4BcIV98Z1ev552WEfPO mvewzTYXqfC8Ba5gxk9Rp1q9eb+tQniA2IkWcUW5Ln51E0QSwLGCz3J6NJRusBV3yD5+ rkkg== 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=tDxM58qrB9pi4qwDtG1H4XYtmKQnjzB8n1kVxZBci7E=; b=FmmhjJlxrcAn8Y7/ZgitE43vGoZfHTkIvcbp0oBNuZKcsyacHUYhwo49DBpahVLJGv j1V5BGdAeO5itJ0T6qpdHr9SRe0pi+Z3fpNti0zeRti1yyjIj8g1NNY60U5PM2VHjdyp V2bLh9Q6oads3vrFqVeCElgY6k/yS+6aWt3yOUB8UNp7PL/01475baph3dZqTM4JtbIl PjoLImeiwx+vZTYA8316jLxlGzxm7+phiN1N+1lCpTgIPd3+Dj3Fvt33zJV2huNt85aX VLMXfXo+gvXqRVWe7gAkpQJ0km/FBw8SBVtC9dPC/ufN1FFZYLG79fDj7VVv12YTh3Mx fLAQ== X-Gm-Message-State: AOAM533uxQ/VPIK8z7TnzpDoahQZgHXxz3RwUx7GWpo+zc3y5aGax7Y+ idsYO1sygnoog26ysePNHF7CS/d879EtWs3w+qY= X-Google-Smtp-Source: ABdhPJwBfeXLW0rYJVFlNwmj3AWjyW23hPMs662vLFg7a7vSKUC6QFPaRTxbpB2djLzlhHLIKs2nDrGWwc71aZwWWMs= X-Received: by 2002:a05:6e02:1608:: with SMTP id t8mr5140866ilu.79.1612551847907; Fri, 05 Feb 2021 11:04:07 -0800 (PST) MIME-Version: 1.0 References: <7613F010-431C-47B3-802E-5258BAA5E156@akamai.com> In-Reply-To: <7613F010-431C-47B3-802E-5258BAA5E156@akamai.com> From: James Date: Fri, 5 Feb 2021 20:03:56 +0100 Message-ID: To: "Salz, Rich" Cc: "httpapi@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [httpapi] client-specified timeout? 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, 05 Feb 2021 19:04:11 -0000 If your ask is about standardisation of the request header and negotiation of it, yes I would be interested. But my biggest question is about how the server should respond - 504 assumes the server is a proxy, 408 is for unused connections, neither of these at initial glance appear to fit the use case. - J On Fri, 5 Feb 2021 at 19:54, Salz, Rich wrote: > > Is it reasonable for a client to want the ability to say things like =E2= =80=9Cif this takes more than 300ms send a failure status code back=E2=80= =9D ? > > Anyone in the WG interested in thinking/working on this? > > > > -- > httpapi mailing list > httpapi@ietf.org > https://www.ietf.org/mailman/listinfo/httpapi From nobody Fri Feb 5 11:49:24 2021 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 6CA103A083E for ; Fri, 5 Feb 2021 11:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cal-berkeley-edu.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CharSIuhHHuM for ; Fri, 5 Feb 2021 11:49:21 -0800 (PST) Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) (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 B88FB3A0839 for ; Fri, 5 Feb 2021 11:49:21 -0800 (PST) Received: by mail-oo1-xc2e.google.com with SMTP id u7so1930233ooq.0 for ; Fri, 05 Feb 2021 11:49:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cal-berkeley-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uQLNgJEfPdFezvBj0643F5hdDNQ1B2dXEh5gKe2T3uA=; b=Bc9RvwJr+Hz6tc3n+xBok808zwfZDD7DStL74KTc4awKQUKKDiUVZU2368TR45dx8F 6+LqnAtmseiacVgQFZlL6qX1amUN3/u4+CMvk0jxLOgvcU0SZa5n9ABtLwqoki2/pVSs 0lH+LdA9s6NNxs3I0hDlhcyWNLrVkUbsjp9JdKcLRvvSZX7zDiKwmCe9WNETkadu7rc9 Kqh1XJMOc5dCIs4EnepS7lXQuq1owd0mtRcnKSBCQoXjyc+iDBdVOz+BF+GcGbTq8W+v pEDNaYBvRjeI+O0wvaoRGo/PXrNA9CmZY657fadvk0j34BVCdKdXo8sk3e7MQnI6+ChQ LVZA== 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=uQLNgJEfPdFezvBj0643F5hdDNQ1B2dXEh5gKe2T3uA=; b=VF807DsP4VCT+LLgRJQg4BxI7WHqXauvOuXkHTGw7H3KmiI/bOIPcroLKatb96YBKT WkiVzXaNaOswz4o51S5YyHETHfYmvrQN7DqlAMGhU11ptUIl87ilJoo1h/AUQEJxiv6J lTsSdeCp8clwvtuS8BV4sh9FpodtHOyXzIxOXuP2j5ln/rLWivZ12leKoGGwzc7w5wez ZqRFeC+YNNWBJs5SF+nZhVoLQ7Z/SWzyKK05t2fxurJh6STTL0Losvmj0WxB3vBQw45Z gLJZE0G82DgLZkddCN/ItigydBKN1+A/fq87YDmHaXQo+RfKV/i7SfsIrC6ISmwCR1Ls XIQw== X-Gm-Message-State: AOAM532NxKS0by1gsmxC38cCx6csl7Fedr7oofDN4rLYLwCvoPZMuApm RvBPOaLYbTna25qCmCcR9cJB74fLm+MOXRgVdSE= X-Google-Smtp-Source: ABdhPJygPd8IVl6OH8lphpr1jjFQGrELDCjSlI7kDUM33ja0rBvOlCXwDUmbMLw5QW4sMkrqgMfPOx/hoVFF7cNKAXU= X-Received: by 2002:a4a:7616:: with SMTP id t22mr4703324ooc.65.1612554561055; Fri, 05 Feb 2021 11:49:21 -0800 (PST) MIME-Version: 1.0 References: <7613F010-431C-47B3-802E-5258BAA5E156@akamai.com> In-Reply-To: From: Sanjay Dalal Date: Fri, 5 Feb 2021 11:49:09 -0800 Message-ID: To: James Cc: "Salz, Rich" , "httpapi@ietf.org" Content-Type: multipart/alternative; boundary="000000000000caf10105ba9c1d08" Archived-At: Subject: Re: [httpapi] client-specified timeout? 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, 05 Feb 2021 19:49:23 -0000 --000000000000caf10105ba9c1d08 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Should there be a standard way for a client to ask for this using the Prefer header https://tools.ietf.org/html/rfc7240? sanjay On Fri, Feb 5, 2021 at 11:04 AM James wrote: > If your ask is about standardisation of the request header and > negotiation of it, yes I would be interested. But my biggest question > is about how the server should respond - 504 assumes the server is a > proxy, 408 is for unused connections, neither of these at initial > glance appear to fit the use case. > > - J > > On Fri, 5 Feb 2021 at 19:54, Salz, Rich > wrote: > > > > Is it reasonable for a client to want the ability to say things like = =E2=80=9Cif > this takes more than 300ms send a failure status code back=E2=80=9D ? > > > > Anyone in the WG interested in thinking/working on this? > > > > > > > > -- > > httpapi mailing list > > httpapi@ietf.org > > https://www.ietf.org/mailman/listinfo/httpapi > > -- > httpapi mailing list > httpapi@ietf.org > https://www.ietf.org/mailman/listinfo/httpapi > --000000000000caf10105ba9c1d08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Should there be a standard way for a client to ask for thi= s using the Prefer header=C2=A0https://tools.ietf.org/html/rfc7240?

sanjay

On Fri, Feb 5, 2021 at 11:04 AM James <james.ietf@gmail.com> wrote:
If your ask is about standardisation of the req= uest header and
negotiation of it, yes I would be interested. But my biggest question
is about how the server should respond - 504 assumes the server is a
proxy, 408 is for unused connections, neither of these at initial
glance appear to fit the use case.

- J

On Fri, 5 Feb 2021 at 19:54, Salz, Rich
<rsalz=3D40akamai.com@dmarc.ietf.org> wrote:
>
> Is it reasonable for a client to want the ability to say things like = =E2=80=9Cif this takes more than 300ms send a failure status code back=E2= =80=9D ?
>
> Anyone in the WG interested in thinking/working on this?
>
>
>
> --
> httpapi mailing list
> httpapi@ietf.org=
> https://www.ietf.org/mailman/listinfo/httpapi<= br>
--
httpapi mailing list
httpapi@ietf.org<= br> https://www.ietf.org/mailman/listinfo/httpapi
--000000000000caf10105ba9c1d08-- From nobody Fri Feb 5 11:58:38 2021 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 075603A08F9 for ; Fri, 5 Feb 2021 11:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPyeucznhpaV for ; Fri, 5 Feb 2021 11:58:35 -0800 (PST) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0FCB3A08F8 for ; Fri, 5 Feb 2021 11:58:34 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id w1so13778751ejf.11 for ; Fri, 05 Feb 2021 11:58:34 -0800 (PST) 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=LmVobyejxinJ0oWA6AojFMTElpXKWh+EQKYEihQzCBM=; b=dw6PRK8M3bjZN5r+du213SIW0oIkMmG2NAH3A4hf98aYUGKPOboQVkH3ebvEiL+7lc uVuZ0yl70tZiOIi+rC58GQHu1ic4WGnQJQkI+vcQpDvJokhRh5OMv+NDpgyiOJZHQe3B qBGJbPKjlztZ1c0wpQdbwBJNu0ZGAfLhLSeklH7MleUCpqMpDvQbPxlFjw7uj7XR+QV2 R0LCKZh1nnU4g08049JR3bJvMbOKgLNMedckSEdBmeZ/gVNqT8EGuZ7FixydWfjxOtbJ KoLNi4pcbPjHnku7AqNlgkND4/rI6Va2k9UGpWNkX+D3GVpvY9MkBGdjosRqlQagyrNh 7cpQ== 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=LmVobyejxinJ0oWA6AojFMTElpXKWh+EQKYEihQzCBM=; b=lTaSOQtYH8+J+ZsOWO+jloWxuRUU5vrMnnPgSjRrV5BUorG1fUQ+vu2rsMJr+dn4m4 EO7fdejgque1T1D0+8YzcqJGVXWEkDqOUjHvPhudJT38s3JF7a3OWT7AOzafc1nrtJbg Y/6+SwDQjJDFNL3nk8Fowrjy8BKb9qB3iYTsfN9zA5XDPov6cTheQqVZldDRZbq3xNO0 D3tl29WxejmMP1jjMQjrp9EHX9sE8JP9UvaQJC0HrTvQ/93HbFS7jlG8iNFUftYbhvOd pY5nCYc8lpbVKKvR3VUZduNElAD2t+fhcIwt7wEVQJ2+uIIpfJIUiUWGYmscWGoXzW7O CXqQ== X-Gm-Message-State: AOAM533BC0QZT9sl7WX037EEcXLeCFHVg0U5X7Z8jQ+4bnTOGVdEJhWe pCB+lQnyTl9Deotgm/9cAS6xD4ESXuZz9TbI18E= X-Google-Smtp-Source: ABdhPJyKwdjVsEbZTr0Vnp3aXynu6wj9UGDcMH2PClDvJOKCNzo1wfFcG9EImuEuv3fcQjfebdDSihc/BE1tGMSoWvA= X-Received: by 2002:a17:907:970f:: with SMTP id jg15mr5682178ejc.440.1612555113459; Fri, 05 Feb 2021 11:58:33 -0800 (PST) MIME-Version: 1.0 References: <7613F010-431C-47B3-802E-5258BAA5E156@akamai.com> In-Reply-To: From: Lucas Pardue Date: Fri, 5 Feb 2021 19:58:23 +0000 Message-ID: To: Sanjay Dalal Cc: James , httpapi@ietf.org, "Salz, Rich" Content-Type: multipart/alternative; boundary="000000000000b7f6fe05ba9c3e44" Archived-At: Subject: Re: [httpapi] client-specified timeout? 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, 05 Feb 2021 19:58:36 -0000 --000000000000b7f6fe05ba9c3e44 Content-Type: text/plain; charset="UTF-8" 300ms is a measurement of what exactly? This seems like something very hard to get right with a multiplexed protocol. > --000000000000b7f6fe05ba9c3e44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
300ms is a measurement of what exactly?
=
This seems like something very hard to get righ= t with a multiplexed protocol.


--000000000000b7f6fe05ba9c3e44-- From nobody Fri Feb 5 12:38:13 2021 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 E53773A0045 for ; Fri, 5 Feb 2021 12:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-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 VFoEiroiy64J for ; Fri, 5 Feb 2021 12:38:09 -0800 (PST) Received: from mail.server.beonex.com (mail.server.beonex.com [144.76.227.234]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658673A003E for ; Fri, 5 Feb 2021 12:38:08 -0800 (PST) From: Ben Bucksch To: httpapi@ietf.org References: <7613F010-431C-47B3-802E-5258BAA5E156@akamai.com> Organization: Me, myself and I Message-ID: <35f5defe-e908-d0b8-5947-bba0da6a34c8@bucksch.org> Date: Fri, 5 Feb 2021 21:38:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <7613F010-431C-47B3-802E-5258BAA5E156@akamai.com> Content-Type: multipart/alternative; boundary="------------08B1BA7F2C9EF1B8EB9F41FD" Content-Language: fr Archived-At: Subject: Re: [httpapi] client-specified timeout? 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, 05 Feb 2021 20:38:12 -0000 This is a multi-part message in MIME format. --------------08B1BA7F2C9EF1B8EB9F41FD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Am 05.02.21 um 19:54 schrieb Salz, Rich: > > Is it reasonable for a client to want the ability to say things like > “if this takes more than 300ms send a failure status code back” ? > Question: What would that mean for the server, exactly? Do you mean the server should attempt to make the query (e.g. against a SQL database or similar), and if 300ms have passed and no result could be obtained yet, abort the query? If that's what you want, then the client can already abort the HTTP request/connection, and the server should notice that and abort the backend query. Many servers already do that (abort query when client aborts), and many clients already have implemented such a timeout feature. Or do you mean the server should make guess whether the query will take more than 300ms (possibly with the help of the database, which checks how the query would look like and perform), and return a failure code immediately, *without* attempting to actually make the query? This detail would be important to specify. The whole purpose of such a header field would be to save server resources. (Otherwise the client should just abort the request and/or ignore a late result, which many clients already do as-is.) So the purpose of such a header would be to avoid wasting server resources. If that's the goal, then the question whether a server would attempt a slow query or would make a quick and cheap reply "too slow", would be really important for the client. I could even see that client logic depends on exactly these semantics: Attempt to make a few queries, and if they are slow, narrow them down, or make other queries, or whatever. But if such attempts already use server resources, that wouldn't be a viable client strategy. So, if you define such a header, I think it would be important to clarify whether the server is expected to abort queries right away, before running them, or whether the server is expected to make an attempt, and abort only when the query actually took too long. In the "make an attempt and abort after the time elapsed" case, I would argue that it would be better to give the client a clear and clean way to abort a query, and then the client can do the timeout. Or abort based on other criteria, e.g. whether the user has already moved on to something else or clicked on something else. I think that would be more generic. Ben --------------08B1BA7F2C9EF1B8EB9F41FD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Am 05.02.21 um 19:54 schrieb Salz, Rich:

Is it reasonable for a client to want the ability to say things like “if this takes more than 300ms send a failure status code back” ?


Question:

What would that mean for the server, exactly?

Do you mean the server should attempt to make the query (e.g. against a SQL database or similar), and if 300ms have passed and no result could be obtained yet, abort the query? If that's what you want, then the client can already abort the HTTP request/connection, and the server should notice that and abort the backend query. Many servers already do that (abort query when client aborts), and many clients already have implemented such a timeout feature.

Or do you mean the server should make guess whether the query will take more than 300ms (possibly with the help of the database, which checks how the query would look like and perform), and return a failure code immediately, *without* attempting to actually make the query?

This detail would be important to specify. The whole purpose of such a header field would be to save server resources. (Otherwise the client should just abort the request and/or ignore a late result, which many clients already do as-is.) So the purpose of such a header would be to avoid wasting server resources. If that's the goal, then the question whether a server would attempt a slow query or would make a quick and cheap reply "too slow", would be really important for the client. I could even see that client logic depends on exactly these semantics: Attempt to make a few queries, and if they are slow, narrow them down, or make other queries, or whatever. But if such attempts already use server resources, that wouldn't be a viable client strategy.

So, if you define such a header, I think it would be important to clarify whether the server is expected to abort queries right away, before running them, or whether the server is expected to make an attempt, and abort only when the query actually took too long.

In the "make an attempt and abort after the time elapsed" case, I would argue that it would be better to give the client a clear and clean way to abort a query, and then the client can do the timeout. Or abort based on other criteria, e.g. whether the user has already moved on to something else or clicked on something else. I think that would be more generic.

Ben

--------------08B1BA7F2C9EF1B8EB9F41FD-- From nobody Fri Feb 5 12:47:28 2021 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 05CB13A0813 for ; Fri, 5 Feb 2021 12:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, 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 onTxDOw59GM1 for ; Fri, 5 Feb 2021 12:47:24 -0800 (PST) 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 52D673A0812 for ; Fri, 5 Feb 2021 12:47:24 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 115KePWE022825; Fri, 5 Feb 2021 20:47:17 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=ez9QAL7cUM6qhqIPpH6zFcivQEglIDf8KyfnaGphTDg=; b=CxzKUw9HMPH0n3uvAlNNGu83HVkbGlBV2W9XAXNVpt/VJAmJz71K/oCaa/nB/4gN9em1 X+ELe0zfRx+ozmRbLJLpiv8ug49vFuCTNsu4JfDN2313OBSDd2WSMOWohj5GyPtU1mwu rrq0HOsOe8HBScsk/ZV3NpPf4v2ORJth6XVlXEeHo1S6+3wQIFKp7yQpW7vAvOB/fJU3 3aFN26IGotG/2H3p89MNzH3Kx7b6fTttgNtxd9N4zbKJKET/zr+ls9Mho0/IV/jBPmSl ySybOqejPYa2XHzGIvuGkKGTrpTnsN5GuREZt8twyKq4i6/+z81o5SLwlDYBWD9lCfbR AQ== Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 36d0k1txxj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 05 Feb 2021 20:47:17 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 115KZfKR031656; Fri, 5 Feb 2021 15:47:16 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint3.akamai.com with ESMTP id 36d3p4ssw6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 05 Feb 2021 15:47:16 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.165.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 5 Feb 2021 14:47:15 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.010; Fri, 5 Feb 2021 14:47:15 -0600 From: "Salz, Rich" To: Ben Bucksch , "httpapi@ietf.org" Thread-Topic: [httpapi] client-specified timeout? Thread-Index: AQHW+/BTluM3M+wTdkuU+jT2kk+MZKpKakoA//+uwwA= Date: Fri, 5 Feb 2021 20:47:14 +0000 Message-ID: References: <7613F010-431C-47B3-802E-5258BAA5E156@akamai.com> <35f5defe-e908-d0b8-5947-bba0da6a34c8@bucksch.org> In-Reply-To: <35f5defe-e908-d0b8-5947-bba0da6a34c8@bucksch.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.45.21011103 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_C315C78601604806965DE47D001D5247akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.737 definitions=2021-02-05_11:2021-02-05, 2021-02-05 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 mlxlogscore=994 adultscore=0 suspectscore=0 bulkscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102050128 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.737 definitions=2021-02-05_11:2021-02-05, 2021-02-05 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 lowpriorityscore=0 impostorscore=0 mlxscore=0 suspectscore=0 clxscore=1015 bulkscore=0 phishscore=0 spamscore=0 mlxlogscore=908 adultscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102050129 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.31) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint3 Archived-At: Subject: Re: [httpapi] client-specified timeout? 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, 05 Feb 2021 20:47:26 -0000 --_000_C315C78601604806965DE47D001D5247akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgT3IgZG8geW91IG1lYW4gdGhlIHNlcnZlciBzaG91bGQgbWFrZSBndWVzcyB3aGV0aGVy IHRoZSBxdWVyeSB3aWxsIHRha2UgbW9yZSB0aGFuIDMwMG1zIChwb3NzaWJseSB3aXRoIHRoZSBo ZWxwIG9mIHRoZSBkYXRhYmFzZSwgd2hpY2ggY2hlY2tzIGhvdyB0aGUgcXVlcnkgd291bGQgbG9v ayBsaWtlIGFuZCBwZXJmb3JtKSwgYW5kIHJldHVybiBhIGZhaWx1cmUgY29kZSBpbW1lZGlhdGVs eSwgKndpdGhvdXQqIGF0dGVtcHRpbmcgdG8gYWN0dWFsbHkgbWFrZSB0aGUgcXVlcnk/DQoNClRo aXMuDQoNCkkgdGhpbmsgdGhlIOKAnHN0YXJ0IGFuZCBhYm9ydCBpZiB0aW1lIGV4Y2VlZGVk4oCd IGlzIGFscmVhZHkgaGFuZGxlZCwgYXMgeW91IHBvaW50IG91dC4NCg0KDQo= --_000_C315C78601604806965DE47D001D5247akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <8CE499CBF155024490A22E9F2C1A3D29@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjgyMzQ3MjA5NTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6LTQyODE4ODQ5NiAxMTc3Mzg0NzIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo2MTI1Ow0KCW1zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2Fs aWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWst d29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxp IHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+T3IgZG8geW91IG1lYW4gdGhlIHNlcnZl ciBzaG91bGQgbWFrZSBndWVzcyB3aGV0aGVyIHRoZSBxdWVyeSB3aWxsIHRha2UgbW9yZSB0aGFu IDMwMG1zIChwb3NzaWJseSB3aXRoIHRoZSBoZWxwIG9mIHRoZSBkYXRhYmFzZSwgd2hpY2ggY2hl Y2tzIGhvdyB0aGUgcXVlcnkgd291bGQgbG9vayBsaWtlIGFuZCBwZXJmb3JtKSwgYW5kIHJldHVy biBhIGZhaWx1cmUgY29kZSBpbW1lZGlhdGVseSwNCiAqd2l0aG91dCogYXR0ZW1wdGluZyB0byBh Y3R1YWxseSBtYWtlIHRoZSBxdWVyeT88bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwPlRoaXMuPG86 cD48L286cD48L3A+DQo8cD5JIHRoaW5rIHRoZSDigJxzdGFydCBhbmQgYWJvcnQgaWYgdGltZSBl eGNlZWRlZOKAnSBpcyBhbHJlYWR5IGhhbmRsZWQsIGFzIHlvdSBwb2ludCBvdXQuPG86cD48L286 cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_C315C78601604806965DE47D001D5247akamaicom_-- From nobody Fri Feb 5 15:18:12 2021 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 CECC13A0D4D for ; Fri, 5 Feb 2021 15:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-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 Sv_f8SXZnfbv for ; Fri, 5 Feb 2021 15:18:09 -0800 (PST) Received: from mail.server.beonex.com (mail.server.beonex.com [144.76.227.234]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DEB83A0D4B for ; Fri, 5 Feb 2021 15:18:07 -0800 (PST) To: "Salz, Rich" , "httpapi@ietf.org" References: <7613F010-431C-47B3-802E-5258BAA5E156@akamai.com> <35f5defe-e908-d0b8-5947-bba0da6a34c8@bucksch.org> From: Ben Bucksch Organization: Me, myself and I Message-ID: <8981145b-bc34-4cfb-8e14-d0c5d8c0e83b@bucksch.org> Date: Sat, 6 Feb 2021 00:18:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CF215CE7C06E0A99CFF624A5" Content-Language: fr Archived-At: Subject: Re: [httpapi] client-specified timeout? 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, 05 Feb 2021 23:18:12 -0000 This is a multi-part message in MIME format. --------------CF215CE7C06E0A99CFF624A5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Am 05.02.21 um 21:47 schrieb Salz, Rich: > > * Or do you mean the server should make guess whether the query will > take more than 300ms (possibly with the help of the database, > which checks how the query would look like and perform), and > return a failure code immediately, *without* attempting to > actually make the query? > > This. > > I think the “start and abort if time exceeded” is already handled, as > you point out. > Perfect. Glad for that clear answer. That makes sense. It would be good to put that into the spec. --------------CF215CE7C06E0A99CFF624A5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Am 05.02.21 um 21:47 schrieb Salz, Rich:
  • Or do you mean the server should make guess whether the query will take more than 300ms (possibly with the help of the database, which checks how the query would look like and perform), and return a failure code immediately, *without* attempting to actually make the query?

This.

I think the “start and abort if time exceeded” is already handled, as you point out.


Perfect. Glad for that clear answer. That makes sense.

It would be good to put that into the spec.

--------------CF215CE7C06E0A99CFF624A5-- From nobody Fri Feb 5 15:40:19 2021 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 080083A0DDA for ; Fri, 5 Feb 2021 15:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, 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 0bAeiDFPODw8 for ; Fri, 5 Feb 2021 15:40:16 -0800 (PST) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 1CF3C3A0DD8 for ; Fri, 5 Feb 2021 15:40:16 -0800 (PST) Received: by mail-ej1-x635.google.com with SMTP id lg21so14852754ejb.3 for ; Fri, 05 Feb 2021 15:40:16 -0800 (PST) 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=davl+0Y7kMIT55Y+ZDrryaDPAV8KdHgZuSLLFfTWgHA=; b=MrlKTRmYobmlDqDoEIQN4B+xlqWSqiRoP2pgAFvNYiFkzFir1yCGkbpt+Sge3baQWT SDlX9TinhkEI9p9FRycwV4InN0oJ9GJ5HVEpaxseHSxX4oqWrHhbW981AloqVn8YMf3i VKOSJ+T1lZ0zIbRAeKxymZaii7Aodhj3IdGVdoMaH0kv6Fc/mbEXjiYY8Izjt+4WZ9Jf aQQ6Eh81/N8Z4uzhBUqna2OQ347niK/w4Xr8SjAqLknGCd8Im3a17BDgw03b42BR3Spz 4iTCzfJfB0vxMGrBvbnchNbcqpqogk9W6O3Zi0+AeDz6WqkspWUDR/bDKB7wvMmXM0Gy mAAg== 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=davl+0Y7kMIT55Y+ZDrryaDPAV8KdHgZuSLLFfTWgHA=; b=dTjIdiJ6A73DttxT83fqG2/awDAMFFkF9yv2XpreFzhulBhPpO5SuubMIiRFqUs9qc 0A0y/57bLUHt+7vAaDc8YBwLQ7Z764KxTkNpMOQvA5M6vjUGV+8Ws4Utgjlxee7IhFNK lAkUPbdDqxZq16DrW3hOj7se48BNtK15ILixL0HEo1sjVxEXFzXlcxjCfGrPFOSr4Q4K Sxm3VobADVnrmRTL6NB8TyOQO/yy60UMp6CUq+nHaN5uAgdKrMJcuipSGXolcrHy2phj rIaC5KFn/tDfnukJxGrrasxcsK8i5xYzJgXZqQQkm+7BBFho1oA915dExSYbKn+ODujl f/Ww== X-Gm-Message-State: AOAM530uO2y2/l7LHJi0FTAUeFRYMdKDWxDXb/agxoFfRgBejw7GSll0 m7QWYR49AGq/UligVWRtAKln06TwloKHhj2JU/g= X-Google-Smtp-Source: ABdhPJx4RWQcU7ReV76x43bSUR1bXTx6FyXwuRaRHRP1xQJ0+8dQQunnUT7ZOVnm2WOi+D3Ta4MyHj+pMFuL+gmFuOs= X-Received: by 2002:a17:906:5d0b:: with SMTP id g11mr6253618ejt.542.1612568414726; Fri, 05 Feb 2021 15:40:14 -0800 (PST) MIME-Version: 1.0 References: <7613F010-431C-47B3-802E-5258BAA5E156@akamai.com> <35f5defe-e908-d0b8-5947-bba0da6a34c8@bucksch.org> <8981145b-bc34-4cfb-8e14-d0c5d8c0e83b@bucksch.org> In-Reply-To: <8981145b-bc34-4cfb-8e14-d0c5d8c0e83b@bucksch.org> From: Lucas Pardue Date: Fri, 5 Feb 2021 23:40:04 +0000 Message-ID: To: Ben Bucksch Cc: "Salz, Rich" , httpapi@ietf.org Content-Type: multipart/alternative; boundary="000000000000892eb905ba9f57d6" Archived-At: Subject: Re: [httpapi] client-specified timeout? 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, 05 Feb 2021 23:40:18 -0000 --000000000000892eb905ba9f57d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So one way to squint at this problem is as a time dimension* in HTTP prioritization and scheduling. Just because a server might be able to retrieve a resource in the desired time doesn't necessarily mean it can return it to the client in the same window. In HTTP/2 or 3 imagine a small API response getting stuck behind a larger resource (whether purposeful scheduling or HoL blocking). So one way to approach this problem might be to define an extension parameter to Extensible Prioirities [1] that augments urgency with a time bound. For example priority: u=3D0, target-time=3D300 would describe a requ= est that is the most urgent until its target time elapsed. What happens after that can be further refined (5xx, reset stream, lower urgency). There's probably a bunch a problem with this in practice but just sayin'. Cheers Lucas * There's a totally different use case for time dimensions related to the timely delivery of real-time AV, after which the object becomes useless. [1] https://tools.ietf.org/html/draft-ietf-httpbis-priority-03 On Fri, 5 Feb 2021, 23:18 Ben Bucksch, wrote: > Am 05.02.21 um 21:47 schrieb Salz, Rich: > > > - Or do you mean the server should make guess whether the query will > take more than 300ms (possibly with the help of the database, which ch= ecks > how the query would look like and perform), and return a failure code > immediately, *without* attempting to actually make the query? > > This. > > I think the =E2=80=9Cstart and abort if time exceeded=E2=80=9D is already= handled, as you > point out. > > > Perfect. Glad for that clear answer. That makes sense. > > It would be good to put that into the spec. > -- > httpapi mailing list > httpapi@ietf.org > https://www.ietf.org/mailman/listinfo/httpapi > --000000000000892eb905ba9f57d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So one way to squint at this problem is as a time dimensi= on* in HTTP prioritization and scheduling.

Just because a server might be able to retrieve a resource in = the desired time doesn't necessarily mean it can return it to the clien= t in the same window. In HTTP/2 or 3 imagine a small API response getting s= tuck behind a larger resource (whether purposeful scheduling or HoL blockin= g).

So one way to approa= ch this problem might be to define an extension parameter to Extensible Pri= oirities [1] that augments urgency with a time bound. For example priority:= u=3D0, target-time=3D300 would describe a request that is the most urgent = until its target time elapsed.=C2=A0 What happens after that can be further= refined (5xx, reset stream, lower urgency). There's probably a bunch a= problem with this in practice but just sayin'.
=
Cheers
Lucas

* There's a totally different u= se case for time dimensions related to the timely delivery of real-time AV,= after which the object becomes useless.

<= div dir=3D"auto">[1]=C2=A0https://tools.ietf.org/html/draft-ietf-httpbis-priori= ty-03

On Fri, 5 Feb 2021, 23:18 Ben Bucksch, <news@bucksch.org> wrote:
=20 =20 =20
Am 05.02.21 um 21:47 schrieb Salz, Rich:
=20
  • Or do you mean the server should make guess whether the query will take more than 300ms (possibly with the help of the database, which checks how the query would look like and perform), and return a failure code immediately, *without* attempting to actually make the query?

This.

I think the =E2=80=9Cstart and abort if time exceeded=E2=80=9D i= s already handled, as you point out.


Perfect. Glad for that clear answer. That makes sense.

It would be good to put that into the spec.

--
httpapi mailing list
ht= tpapi@ietf.org
https://www.ietf.org/mailman/listinfo/httpap= i
--000000000000892eb905ba9f57d6-- From nobody Fri Feb 5 18:43:04 2021 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 90B113A10E2 for ; Fri, 5 Feb 2021 18:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=poCewKd6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZMRjqoqj 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 IX5nNdxZmIJq for ; Fri, 5 Feb 2021 18:43:02 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46053A10E3 for ; Fri, 5 Feb 2021 18:43:01 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 0FE2C5C0161; Fri, 5 Feb 2021 21:43:01 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 05 Feb 2021 21:43:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=1 rJWCJjj7aZzKT7XmV9FFBE3rbaF76uQEIKlhWCcLCU=; b=poCewKd6rOCNbI12y jWJTWpqKK6B0+4/PRxNrQh8P3H5r9wibVPhewcuQQVWc+IZFzwprB+qUamgA+TnA PJXamyTZnZ0YNR21c8JDDL/ZoCCwk3UC3t7A5BWFiOIygr/XiGxt7x8OzzZAfAtJ sJ3DNNCb9xM8TK5/IAEK/r3TVAhCltv2FxMUOkZNMJLasSXJ9QLvf/JcVlZjgVBj DO7WagKSZtcHG7gJHc2/55oDmtXj0eEjple+lsTjugUUWNEwR6/8tOTBAA1DkuK9 49An+nfWxCZ3D7BUxdJlvVRFClfJwuySMvkQXQInRbjuirV1n7w/Qo20VpImU+Wk HOfJw== 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=fm2; bh=1rJWCJjj7aZzKT7XmV9FFBE3rbaF76uQEIKlhWCcL CU=; b=ZMRjqoqj7I99enLpz/iXe1gWgFOmFivO2fCxVn8dw+mQq46Fu7KUkLyoY 2BkPORIBac/WHZd4DjLNqvwk/L1M9GiuMxgclOOCAjODt9sRwIUTmhWmb2blwqF5 OLXeZoaNZSweSDUKqtQ0KIvzzQ5ap+6xNvvEC5d75jplElc2+FtuUr7XO0YC6CgO jBNrfOVHx2gPdMKXXyLuLBX1sh8gGgzBC7YxfFNhaW/T2ojiuxmazRAHu3VTCYGt KeApQs1BceMRWYZonjpJJ1gWIbK+7Sj0EYwUZqNczcnn+04Mnu+VTlSKZNxUBUN0 DTU3EI6bAmshDT1YSvxRVBkWPdMUA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrgeejgdegjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtjeenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekgfefieekleeflefhhedvveekveehle eifefhleetffevteeiheeltdetleeuffenucffohhmrghinhepudhhohhsthgvgigrmhhp lhgvrdhorhhgpdhivghtfhdrohhrghdpmhhnohhtrdhnvghtnecukfhppeduudelrdduje drudehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehmnhhothesmhhnohhtrdhnvght 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 1BAC01080057; Fri, 5 Feb 2021 21:42:58 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Mark Nottingham In-Reply-To: <7613F010-431C-47B3-802E-5258BAA5E156@akamai.com> Date: Sat, 6 Feb 2021 13:42:56 +1100 Cc: "httpapi@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <7613F010-431C-47B3-802E-5258BAA5E156@akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [httpapi] client-specified timeout? 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, 06 Feb 2021 02:43:04 -0000 Something like: GET /foo HTTP/1.1 Host: example.org Prefer: wait=3D2 ? IIRC that was specified in seconds, not ms, because of concern that very = small periods desired by the client would effectively be a race with the = network; e.g., if your client wants a result in 200ms and you make a = request to a server even mildly far away (due to connection setup times, = etc.), the response is likely to take longer. If we wanted something with finer granularity, we'd probably want to = caution against such assumptions on the client side -- i.e., that 200ms = is *server-side* processing, and the client shouldn't try to enforce the = timeout.=20 It might also be interesting to think about sending a 103 Early Hints = response with a Preference-Applied header in some circumstances, so that = the client knows the server is honouring the preference... Cheers, > On 6 Feb 2021, at 5:54 am, Salz, Rich = wrote: >=20 > Is it reasonable for a client to want the ability to say things like = =E2=80=9Cif this takes more than 300ms send a failure status code = back=E2=80=9D ? > Anyone in the WG interested in thinking/working on this? > =20 > --=20 > httpapi mailing list > httpapi@ietf.org > https://www.ietf.org/mailman/listinfo/httpapi -- Mark Nottingham https://www.mnot.net/ From nobody Mon Feb 8 09:46:06 2021 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 7D6E03A13F1 for ; Mon, 8 Feb 2021 09:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, 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 6bvSrX5_LLxb for ; Mon, 8 Feb 2021 09:46:03 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 28D4D3A13F0 for ; Mon, 8 Feb 2021 09:46:02 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 118HjMnp017680; Mon, 8 Feb 2021 17:46:01 GMT 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=IrOICyElIit3iqIyERnMM+FFG9F1r9JshC+y+Dipo1o=; b=fs70Mf90PZjJGHGE8LNT0kNa413NKdM65ImlL31yKrQAQA2jMgierxUjQu8Uqv2zm5JW ljLeowq5p/S4kHQ6+mdw1cSheeQQJfjdQP34vBasH1zv4JDCGnl2SE802hzUcdBIDqNE 9uH0WYC3mjxSELP0meNj8Vr6PoL8CJKq5RtxXs0MsPN++NXzoLw4x72FB0nGzoEgtTv+ dOespEbGG++4W4Z6/DREtXa0xgK5hjqRSD6TWIcy+ZXxGgZf6npPnrhBmwE57cTOxBgB Bvou7EjXtT5sn+BDfgpjPGKrTJZsDvuD62peBuXdlBbhN5hZYNBCNaREPc6thqw1mYjb Hw== Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 36hruyn0pu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Feb 2021 17:46:01 +0000 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 118HKNit026593; Mon, 8 Feb 2021 12:46:00 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint8.akamai.com with ESMTP id 36hqb3j1f2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 08 Feb 2021 12:46:00 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 8 Feb 2021 11:46:00 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.010; Mon, 8 Feb 2021 11:45:59 -0600 From: "Salz, Rich" To: "Lars G. Svensson" , Ruben Verborgh , Herbert Van de Sompel CC: "httpapi@ietf.org" Thread-Topic: [httpapi] Introduction and introducing proposal for standardisation of profile negotiation Thread-Index: AQHW+kozWA3OM+cRjkSkirMTL4jlpKpOoLIA Date: Mon, 8 Feb 2021 17:45:59 +0000 Message-ID: <4E863808-7B28-478C-B217-5FA87CE0B0F0@akamai.com> References: <8fa3ca4f-e38b-0011-cf62-6e8184af7ea5@web.de> In-Reply-To: <8fa3ca4f-e38b-0011-cf62-6e8184af7ea5@web.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.45.21011103 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: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.737 definitions=2021-02-08_10:2021-02-08, 2021-02-08 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 mlxlogscore=999 malwarescore=0 spamscore=0 suspectscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102080109 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.737 definitions=2021-02-08_10:2021-02-08, 2021-02-08 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 adultscore=0 suspectscore=0 bulkscore=0 malwarescore=0 mlxlogscore=999 priorityscore=1501 spamscore=0 impostorscore=0 phishscore=0 lowpriorityscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102080111 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.34) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint8 Archived-At: Subject: Re: [httpapi] Introduction and introducing proposal for standardisation of profile negotiation 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: Mon, 08 Feb 2021 17:46:05 -0000 TGFycywgUnViZW4sIEhlcmJlcnQ6DQoNCj4gICAgRm9yIHNvbWUgdGltZSBub3csIFJ1YmVuIFZl cmJvcmdoLCBIZXJiZXJ0IFZhbiBkZSBTb21wZWwgYW5kIEkgdG9nZXRoZXINCiAgICB3aXRoIGZv bGtzIGluIFczQyBoYXZlIGJlZW4gd29ya2luZyBvbiBhIHByb3Bvc2FsIGZvciBodHRwIGNvbnRl bnQNCiAgICBuZWdvdGlhdGlvbiB1c2luZyBwcm9maWxlcy4gVGhpcyBpcyBkb25lIGJ5IGFkZGlu ZyBhIG5ldyBodHRwIGhlYWRlcg0KICAgICJBY2NlcHQtUHJvZmlsZSIgYW5kIHJlLXVzaW5nIHRo ZSAiTGluayItaGVhZGVyIChSRkMgODI4OCkuIFRoZSBwcm9wb3NhbA0KICAgIHdhcyB1cGxvYWRl ZCBhcyBhbiBJLUQgZWFybGllciB0b2RheSBbMV0uDQoNClRoYW5rcyBmb3IgYnJpbmdpbmcgdGhp cyBmb3J3YXJkLiAgV2UgKHRoZSBjaGFpcnMpIGRpc2N1c3NlZCB0aGlzLCBhbmQgdGhpbmsgdGhh dCB0aGlzIHNob3VsZCBiZSBicm91Z2h0IGZvcndhcmQgdG8gdGhlIERJU1BBVENIIHdvcmtpbmcg Z3JvdXAgKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvZGlzcGF0Y2gvYWJvdXQvKSAg IFRoZXJlIGlzIGEgbWVldGluZyBwbGFubmVkIGF0IHRoZSBuZXh0IHZpcnR1YWwgSUVURiBvbiBN b25kYXkgMjAyMS0wMy0wOCAxMzowMCBDRVQgKDEyOjAwIFVUQykuIFRoZXJlIHNlZW1zIHRvIGJl IHBsZW50eSBvZiB0aW1lIHRvIGdldCBvbiB0aGUgYWdlbmRhOyB5b3UgY2FuIGZpbmQgdGhlIERJ U1BBVENIIGNoYWlycyBvbiB0aGUgYWJvdXQgcGFnZS4NCg0KT3VyIHJlYXNvbnMgZm9yIGRvaW5n IHRoaXMgaXMgdGhhdCB3ZSdyZSBub3Qgc3VyZSBhYm91dCBIVFRQQklTIHZzLiBIVFRQLUFQSTsg Y2xlYXJseSBjcm9zcy1jb2xsYWJvcmF0aW9uIHdpbGwgYmUgcmVxdWlyZWQuICBBbHNvIG5vdGUg dGhhdCB0aGUgSUVURiBoYXMgYSBsb3Qgb2YgaGlzdG9yeSBpbiB0aGlzIGFyZWEgYW5kIHdlJ3Jl IG5vdCBxdWl0ZSBzdXJlIHdoeSB0aGlzIHdvdWxkIGJlIGRpZmZlcmVudCBhbmQgaG93IHRvIGVu c3VyZSBzdWNjZXNzLiAgRXhhbXBsZXMgaW5jbHVkZSBSRkMncyAyMjk1IDI3MDMsIDI1MzQsIDI5 MTIsIDI5MTMsIHRoZSBub3ctY2xvc2VkIENPTk5FRyB3b3JraW5nIGdyb3VwIChodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL3dnL2Nvbm5lZy9hYm91dC8pIGFuZCBhIGNvdW50ZXItYXJndW1l bnQgaHR0cHM6Ly93aWtpLndoYXR3Zy5vcmcvd2lraS9XaHlfbm90X2Nvbm5lZw0KDQpUaGFua3Mu DQpSaWNoLCBmb3IgdGhlIGNoYWlycy4NCg0KDQo= From nobody Fri Feb 12 16:37:32 2021 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 547F13A1204; Fri, 12 Feb 2021 16:33:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: barryleiba@computer.org, httpapi@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161317641132.31337.16233872250352942674@ietfa.amsl.com> Date: Fri, 12 Feb 2021 16:33:31 -0800 Archived-At: Subject: [httpapi] httpapi - Requested session has been scheduled for IETF 110 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: Sat, 13 Feb 2021 00:33:39 -0000 Dear Rich Salz, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. httpapi Session 1 (2:00 requested) Friday, 12 March 2021, Session III 1700-1900 Room Name: Room 1 size: 501 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/110/sessions/httpapi.ics Request Information: --------------------------------------------------------- Working Group Name: Building Blocks for HTTP APIs Area Name: Applications and Real-Time Area Session Requester: Rich Salz Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 150 Conflicts to Avoid: Chair Conflict: acme Technology Overlap: httpbis quic tls jsonpath People who must be present: Barry Leiba Darrel Miller Mark Nottingham Rich Salz Resources Requested: Special Requests: ---------------------------------------------------------