From nobody Fri Jan 1 22:16: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 EE6AB3A0D98 for ; Fri, 1 Jan 2021 22:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Q0cIxi80kK3d for ; Fri, 1 Jan 2021 22:16:03 -0800 (PST) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (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 2B7373A0D92 for ; Fri, 1 Jan 2021 22:16:02 -0800 (PST) Received: from [108.205.51.24] (port=55155 helo=dretpro.attlocal.net) by postoffice.gristmillmedia.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kvaCm-00072R-O6; Sat, 02 Jan 2021 01:16:01 -0500 To: Darrel Miller , "httpapi@ietf.org" References: From: Erik Wilde Message-ID: Date: Fri, 1 Jan 2021 22:15:57 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [httpapi] Scope of deprecation header 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, 02 Jan 2021 06:16:05 -0000 hello darrel. thanks for your feedback, and apologies for the delay. i discussed this with sanjay, and we agree that currently, there is a bit of an implicit mismatch between some statements. On 2020-12-02 18:07, Darrel Miller wrote: > In the introduction of the document, the following statement is made. > > * It just informs client of the fact that a resource is deprecated. > > In the documentation, there is further qualification, > > ØFor a resource, deprecation could involve one or more parts of > > * request, response or both. > > https://tools.ietf.org/html/draft-dalal-deprecation-header-00#section-3.1 > > There is then a list of potential partial deprecations, including > methods, headers and request or response body elements. > > By introducing the possibility of signalling the deprecation of some > element of the overall HTTP interaction, it seems to be in conflict with > the original statement that says a “resource is deprecated”.  It also > introduces other conflicts such as not allowing multiple deprecation > headers.  If deprecation can be partial, wouldn’t it be likely there > would be multiple deprecations for a single resource? you're absolutely right that being able to deprecate "aspects" of an API complicates the picture a fair bit. sanjay went through the APIs that we are aware of that use deprecation (in some shape or form, not necessarily using our draft), and with one exception, they all deprecate at the resource-level. > The Sunset header is more explicit about the granularity of impact.  RFC > 8594 describes the impact of the sunset header, > > Øindicates that a URI is likely to become unresponsive at a > > Ø   specified point in the future in my mind, aligning with the sunset spec (which also works at the resource level) would make sense. if we did choose the route of being able to deprecate specific aspects, then we would need to have a well-defined model of how to identify them, and we don't have that in the current draft. > Is it intended that there be different granularity for the deprecated > header vs sunset header? our proposal is to stay with the model that we currently support and describe in the intro, and to fix the language so that it does not create the impression that individual aspects can be deprecated using this spec. we could then see whether over time momentum is building up for a more refined model. if that's the case, this might then be best addressed with a different header field. thanks and cheers and happy new year everybody, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Sat Jan 2 10:44:02 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 E58CF3A0CDD for ; Sat, 2 Jan 2021 10:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 drnahxlYtPj8 for ; Sat, 2 Jan 2021 10:43:59 -0800 (PST) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (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 8867F3A0CDB for ; Sat, 2 Jan 2021 10:43:59 -0800 (PST) Received: from [108.205.51.24] (port=56957 helo=dretpro.attlocal.net) by postoffice.gristmillmedia.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kvlsb-0006kQ-Mb; Sat, 02 Jan 2021 13:43:57 -0500 To: Herbert Van de Sompel , "Salz, Rich" Cc: "httpapi@ietf.org" References: <48058830-D096-4DBE-8476-0487544D880E@akamai.com> From: Erik Wilde Message-ID: <49ff5ddf-da27-efe5-fa86-66860d2a72c3@dret.net> Date: Sat, 2 Jan 2021 10:43:53 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [httpapi] Should we adopt linkset media types and link relation? 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, 02 Jan 2021 18:44:01 -0000 hello all. happy new year everybody! On 2020-12-14 23:54, Herbert Van de Sompel wrote: > I hope this clarifies the issue that was discussed in the recent WG > meeting. And, like Erik, I hope the I-D can be adopted. looking at the minutes it seems that generally speaking, the group was ok with adopting the draft. the only question being raised was by alexey melnikov about possible overlaps with CoRE. herbert was nice enough to post the summary of our considerations when we looked at CoRE at the very beginning of the linkset work. CoRE does look similar (and it is), but we decided that the approach wasn't matching our needs. unless alexey (or anybody else) is asking for clarifications or a more detailed discussion, i think we have addressed the one outstanding issue that was identified in the IETF 109 meeting. can we move forward with a formal request for adoption? this work is already used in implementations out there (including the very major scenario of GS1 as presented by phil archer), so our goal is to move it forward. thanks a lot and cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Sat Jan 2 12:38:10 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 670C33A0DEA for ; Sat, 2 Jan 2021 12:38:09 -0800 (PST) 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=unavailable 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 XFCxZL5zIIZ2 for ; Sat, 2 Jan 2021 12:38:08 -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 6BE383A0DE8 for ; Sat, 2 Jan 2021 12:38:08 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 102KXkoL021079; Sat, 2 Jan 2021 20:37:23 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=uK1cRJ4B0j1xOv+2xOhUYs4OpoTFhtwyTEX2QxxM3wk=; b=NXKMFwA76CxTgtpiu+/X7xj/FbEmnknONqmpVuIhfB9TN6uS+c3TJLjdQItS2yzv5eBw wmCekCjgnCHxPDlUENV2Q+r6YTy+3bqtV5EtywX1MSU+8a4vJTpO16KZrWHxrOzH9o5R WD4B+wHGN8kZuJ+s2L4PTMHw13bp4W6UcV6NLlzVbqYNhg0TxtZW4AmgP+bB92WFvXS9 NrnN/mCiUx+Urt2hDG2JPimkgWjIgukE8FKE++4pjpNwh4hlZApPH1H8VC10IWs1+Va2 49UqWrIp0lQjzzg3w8284ZsOR1VTkogHDz0CQo7vXNGLvWRZsBarnz2Fl9D61IYArLei Aw== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 35tj4eb5g1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 02 Jan 2021 20:37:23 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 102KYYsu026113; Sat, 2 Jan 2021 12:37:22 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint5.akamai.com with ESMTP id 35tqpersus-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 02 Jan 2021 12:37:22 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 2 Jan 2021 15:37:21 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.010; Sat, 2 Jan 2021 15:37:21 -0500 From: "Salz, Rich" To: Erik Wilde , Herbert Van de Sompel , "Salz, Rich" CC: "httpapi@ietf.org" Thread-Topic: [httpapi] Should we adopt linkset media types and link relation? Thread-Index: AQHWzw5ANCi0d6N62k+2t9Jo7Hp+/6n14BuAgAJExoCAHP9DgP//y+QA Date: Sat, 2 Jan 2021 20:37:21 +0000 Message-ID: References: <48058830-D096-4DBE-8476-0487544D880E@akamai.com> <49ff5ddf-da27-efe5-fa86-66860d2a72c3@dret.net> In-Reply-To: <49ff5ddf-da27-efe5-fa86-66860d2a72c3@dret.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.44.20121301 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: <1A48E9E888CDB5448C4B18553F93C65B@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-02_13:2020-12-31, 2021-01-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 spamscore=0 phishscore=0 malwarescore=0 suspectscore=0 mlxlogscore=999 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101020131 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-02_13:2020-12-31, 2021-01-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 mlxscore=0 phishscore=0 adultscore=0 priorityscore=1501 clxscore=1015 bulkscore=0 spamscore=0 impostorscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101020131 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.60) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint5 Archived-At: Subject: Re: [httpapi] Should we adopt linkset media types and link relation? 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, 02 Jan 2021 20:38:09 -0000 PiAgICBoZXJiZXJ0IHdhcyBuaWNlIGVub3VnaCB0byBwb3N0IHRoZSBzdW1tYXJ5IG9mIG91ciBj b25zaWRlcmF0aW9ucyB3aGVuIA0KICAgIHdlIGxvb2tlZCBhdCBDb1JFIGF0IHRoZSB2ZXJ5IGJl Z2lubmluZyBvZiB0aGUgbGlua3NldCB3b3JrLiBDb1JFIGRvZXMgDQogICAgbG9vayBzaW1pbGFy IChhbmQgaXQgaXMpLCBidXQgd2UgZGVjaWRlZCB0aGF0IHRoZSBhcHByb2FjaCB3YXNuJ3QgDQog ICAgbWF0Y2hpbmcgb3VyIG5lZWRzLg0KDQpQZXJoYXBzIHNvbWUgb2YgdGhhdCBjYW4gbWFrZSBp dCBpbnRvIHRoZSBkcmFmdC4NCg0KPiAgICBjYW4gd2UgbW92ZSBmb3J3YXJkIHdpdGggYSBmb3Jt YWwgcmVxdWVzdCBmb3IgYWRvcHRpb24/DQoNClN1cmUsIEknbGwgc3RhcnQgaXQgbmV4dCB3ZWVr LiANCg0K From nobody Sat Jan 2 14:19:18 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 4A9733A0E9F for ; Sat, 2 Jan 2021 14:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 V5lN21T2PEEF for ; Sat, 2 Jan 2021 14:19:16 -0800 (PST) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (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 ED0683A0E9D for ; Sat, 2 Jan 2021 14:19:15 -0800 (PST) Received: from [108.205.51.24] (port=55186 helo=[192.168.1.67]) by postoffice.gristmillmedia.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kvpEw-0003KD-4k; Sat, 02 Jan 2021 17:19:14 -0500 To: "Salz, Rich" , Herbert Van de Sompel Cc: "httpapi@ietf.org" References: <48058830-D096-4DBE-8476-0487544D880E@akamai.com> <49ff5ddf-da27-efe5-fa86-66860d2a72c3@dret.net> From: Erik Wilde Message-ID: <38e52708-6be8-ca6a-3021-9ad64bcbc7f0@dret.net> Date: Sat, 2 Jan 2021 14:19:10 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [httpapi] Should we adopt linkset media types and link relation? 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, 02 Jan 2021 22:19:17 -0000 hello. On 2021-01-02 12:37, Salz, Rich wrote: >> herbert was nice enough to post the summary of our considerations when > we looked at CoRE at the very beginning of the linkset work. CoRE does > look similar (and it is), but we decided that the approach wasn't > matching our needs. > > Perhaps some of that can make it into the draft. i am not sure this would be particularly helpful except for people with a very specific knowledge of CoRE. asking the list: anybody having an opinion whether including a brief comparison with CoRE would be helpful or not? >> can we move forward with a formal request for adoption? > > Sure, I'll start it next week. great, thanks! cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Sat Jan 2 14:39:18 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 85E233A0EF1 for ; Sat, 2 Jan 2021 14:39:16 -0800 (PST) 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=unavailable 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 R8TDrpVcepCZ for ; Sat, 2 Jan 2021 14:39:15 -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 85DD83A0EDA for ; Sat, 2 Jan 2021 14:39:15 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 102MUL1A030248; Sat, 2 Jan 2021 22:37:56 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=hqfaEEqjNMqyFrLJwk8X+FLeHdvZfn5xDutQK7tQT6I=; b=aNOwHELAgSxGPjxWc9/OCehUM2o2bVn3Cqtl8EJQCoR3h6Xd8qPEPYQ37tTsa66FWo5Y ibBNh2JQBCuajZ+iDJuTip0g5bNYAn5BTzj7hWX8OuCs/mErkb1Uv19Q39QYvs3mQ5bL uh1hlj2cEODCA1CjOCVkjfPQaJu0XPOVrs5D6zTlaG0UTUMbEDAqWcQa78EYxIhQaaxX y24y+8L3mixjvSAQkg8e8PCyQWmtraHVBMqznVNOpsdPZkTzcN079StXAO99lbHQx7aL DWMcgs/f548gBO8t/iAXvqcl07lgPibP7TlIdF3kUFSu880lS+euhqFPjS9um9wiJBvf xw== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 35tek1nkba-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 02 Jan 2021 22:37:56 +0000 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 102MXk9f031529; Sat, 2 Jan 2021 17:37:55 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint6.akamai.com with ESMTP id 35tn2396jr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 02 Jan 2021 17:37:55 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 2 Jan 2021 17:37:55 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.010; Sat, 2 Jan 2021 17:37:55 -0500 From: "Salz, Rich" To: Erik Wilde , "Salz, Rich" , Herbert Van de Sompel CC: "httpapi@ietf.org" Thread-Topic: [httpapi] Should we adopt linkset media types and link relation? Thread-Index: AQHWzw5ANCi0d6N62k+2t9Jo7Hp+/6n14BuAgAJExoCAHP9DgP//y+QAgABwQwD//7FqAA== Date: Sat, 2 Jan 2021 22:37:54 +0000 Message-ID: References: <48058830-D096-4DBE-8476-0487544D880E@akamai.com> <49ff5ddf-da27-efe5-fa86-66860d2a72c3@dret.net> <38e52708-6be8-ca6a-3021-9ad64bcbc7f0@dret.net> In-Reply-To: <38e52708-6be8-ca6a-3021-9ad64bcbc7f0@dret.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.44.20121301 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: <8E662B9530F348409568AB777F2C4E97@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-02_13:2020-12-31, 2021-01-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 bulkscore=0 spamscore=0 adultscore=0 phishscore=0 malwarescore=0 mlxlogscore=975 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101020143 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-02_13:2020-12-31, 2021-01-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 adultscore=0 malwarescore=0 priorityscore=1501 mlxscore=0 suspectscore=0 lowpriorityscore=0 mlxlogscore=893 clxscore=1015 impostorscore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101020143 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.61) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint6 Archived-At: Subject: Re: [httpapi] Should we adopt linkset media types and link relation? 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, 02 Jan 2021 22:39:17 -0000 ICAgID4+ICAgICBoZXJiZXJ0IHdhcyBuaWNlIGVub3VnaCB0byBwb3N0IHRoZSBzdW1tYXJ5IG9m IG91ciBjb25zaWRlcmF0aW9ucyB3aGVuDQogICAgPiAgICAgIHdlIGxvb2tlZCBhdCBDb1JFIGF0 IHRoZSB2ZXJ5IGJlZ2lubmluZyBvZiB0aGUgbGlua3NldCB3b3JrLiBDb1JFIGRvZXMNCiAgICA+ ICAgICAgbG9vayBzaW1pbGFyIChhbmQgaXQgaXMpLCBidXQgd2UgZGVjaWRlZCB0aGF0IHRoZSBh cHByb2FjaCB3YXNuJ3QNCiAgICA+ICAgICAgbWF0Y2hpbmcgb3VyIG5lZWRzLg0KICAgID4gDQog ICAgPiBQZXJoYXBzIHNvbWUgb2YgdGhhdCBjYW4gbWFrZSBpdCBpbnRvIHRoZSBkcmFmdC4NCg0K ICAgIGkgYW0gbm90IHN1cmUgdGhpcyB3b3VsZCBiZSBwYXJ0aWN1bGFybHkgaGVscGZ1bCBleGNl cHQgZm9yIHBlb3BsZSB3aXRoIA0KICAgIGEgdmVyeSBzcGVjaWZpYyBrbm93bGVkZ2Ugb2YgQ29S RS4gYXNraW5nIHRoZSBsaXN0OiBhbnlib2R5IGhhdmluZyBhbiANCiAgICBvcGluaW9uIHdoZXRo ZXIgaW5jbHVkaW5nIGEgYnJpZWYgY29tcGFyaXNvbiB3aXRoIENvUkUgd291bGQgYmUgaGVscGZ1 bCANCiAgICBvciBub3Q/DQoNCkl0IGNhbiBiZSBpbiBhIGRyYWZ0IGFuZCB0aGVuIHJlbW92ZWQs IG9yIGl0IGNhbiBiZSBtYXJrZWQgInBsZWFzZSByZW1vdmUgdGhpcyBzZWN0aW9uIGJlZm9yZSBw dWJsaWNhdGlvbiBhcyBhbiBSRkMiICBCdXQgSSBleHBlY3QgdGhhdCBoZWFkaW5nIG9mZiBhIGxp a2VseSBJRVNHIHF1ZXN0aW9uIHdvdWxkIGJlIGEgZ29vZCB0aGluZyB0byBkby4NCg0K From nobody Sat Jan 2 15:44:42 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 83B113A1001 for ; Sat, 2 Jan 2021 15:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 M7vu27EndbhP for ; Sat, 2 Jan 2021 15:44:38 -0800 (PST) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (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 A5DAC3A0FF7 for ; Sat, 2 Jan 2021 15:44:38 -0800 (PST) Received: from [108.205.51.24] (port=58778 helo=dretpro.attlocal.net) by postoffice.gristmillmedia.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kvqZY-0008Jv-Nc; Sat, 02 Jan 2021 18:44:36 -0500 To: "Salz, Rich" , Herbert Van de Sompel Cc: "httpapi@ietf.org" References: <48058830-D096-4DBE-8476-0487544D880E@akamai.com> <49ff5ddf-da27-efe5-fa86-66860d2a72c3@dret.net> <38e52708-6be8-ca6a-3021-9ad64bcbc7f0@dret.net> From: Erik Wilde Message-ID: <0f2f6dd3-7a9e-5c80-1b93-de85dff3c89a@dret.net> Date: Sat, 2 Jan 2021 15:44:33 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [httpapi] Should we adopt linkset media types and link relation? 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, 02 Jan 2021 23:44:41 -0000 hello rich. On 2021-01-02 14:37, Salz, Rich wrote: > i am not sure this would be particularly helpful except for people with > a very specific knowledge of CoRE. asking the list: anybody having an > opinion whether including a brief comparison with CoRE would be helpful > or not? > > It can be in a draft and then removed, or it can be marked "please remove this section before publication as an RFC" But I expect that heading off a likely IESG question would be a good thing to do. fair enough. we'll turn that into the honorary first issue once we have the repo for managing the draft. thanks and cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Mon Jan 4 05:49: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 12A7D3A0E03 for ; Mon, 4 Jan 2021 05:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[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, RCVD_IN_BL_SPAMCOP_NET=1.246, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 (1024-bit key) header.d=redhat.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 5uckdOBA-JxZ for ; Mon, 4 Jan 2021 05:48:57 -0800 (PST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838023A0D7C for ; Mon, 4 Jan 2021 05:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1609768133; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cTwC53cudOyss6iZgBQYZMvnY8ACNWnFMZ6Y+e/PMro=; b=GojY3KaE2PPt4E58GZPr4GYj/Al/dAqPC5Qp8ldAq7GidYi81PNkNRVpUyl5NHI8X6g8ri 6xsGf8XV3daOLKsZgNFb34Jd6RN6qrBVfs/cQ9AWOzoAx2HF2BpVdJcGl1VhaYw72zi73e fhym2U7eJ0gYZ0S0da481SxojJlz50s= Received: from mail-yb1-f200.google.com (mail-yb1-f200.google.com [209.85.219.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-342-ks3sB7U0PpS_gLa0hLxxBQ-1; Mon, 04 Jan 2021 08:48:52 -0500 X-MC-Unique: ks3sB7U0PpS_gLa0hLxxBQ-1 Received: by mail-yb1-f200.google.com with SMTP id k7so51740436ybm.13 for ; Mon, 04 Jan 2021 05:48:51 -0800 (PST) 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=cTwC53cudOyss6iZgBQYZMvnY8ACNWnFMZ6Y+e/PMro=; b=Ndw0Yqta+TzlWmBEvJFLxdcKaNY92Kqom4VILtyE3jiXJsdQxVOGo+QobFSpfsOl3u I3lHsdh1V/UV/BWSkvWH4PvQYrrQBfQThJSFEufI5ihgJMZooRHcfWSIODATgK/v70eD A33EbP0bt7O5gv0/p68b0QGQVUQ/zXllN8ruQHqZ12mnj/gNNTr9WeX73msd39FuP5h5 vhjKVLfpEoz5O82lQPe1jaf/XEwbr9E75UTiVRdXA/fhpKVjllMehaqxzyr/WI20P7JO qPd6Gy1/3+QMOC3LabASKm94/dj9pjjx632RImhWgVQqK7QSp5zm9rYHCIaibNSXWvzz Cgcg== X-Gm-Message-State: AOAM5301ukt7oraqi8HlQV4ef+72SiqLe1Sq0575htmojZa02FJEHLMi Zb3zmhJBi5YFAp2ocrPrchG0C35ecbHZVN9jV8HmGQd8klStM//wFINEO4mb4eEpRq1eZRHhPyo N27NyJSFML/H2/W2U6w8yTtz3 X-Received: by 2002:a25:a029:: with SMTP id x38mr69361286ybh.105.1609768130789; Mon, 04 Jan 2021 05:48:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJz1PJ4uvioq55y0F2edEnQCB2swTzA7n+fborSxJCjZT3l7RYXcRBfsuCAAxPHHRavhtfoeQRbnYuWgZqA4K+4= X-Received: by 2002:a25:a029:: with SMTP id x38mr69361271ybh.105.1609768130623; Mon, 04 Jan 2021 05:48:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alex Martinez Date: Mon, 4 Jan 2021 13:48:39 +0000 Message-ID: To: Darrel Miller Cc: "httpapi@ietf.org" , "robipolli@gmail.com" Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=amartine@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="00000000000098cc3005b813594c" Archived-At: Subject: Re: [httpapi] RateLimit Header client implementations 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, 04 Jan 2021 13:49:05 -0000 --00000000000098cc3005b813594c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Darrel, On Wed, Dec 30, 2020 at 3:17 AM Darrel Miller wrote: > [...] > > > From what I understand there are a few scenarios where clients can use > these headers: > > > > 1. Optimizing polling frequency: i.e. check quota and window and > determine optimum calling interval > 2. Prioritization between client tasks: Don=E2=80=99t let low priorit= y tasks > starve high priority tasks of quota > 3. Enable user agents to avoid hitting rate limit due to some kind of > punitive behavior. > > > > Are you aware of other scenarios? Are there implementations of these > scenarios? > The scenario about "hitting rate limiting" is quite broad in scope. You can have rate limits apply per API endpoint, per user identity, per connection, per time of day, per infrastructure resources, or even per service type or cost, or a combination of them all - which is quite a bit more than just limiting some misbehavior. The immediate benefit of these headers to service providers is being able to signal expectations to clients so they can adapt. Sometimes it is just a matter of adjusting to some specific rate of resource consumption. Some other times the only way to adapt is just to stop using a service entirely for a while or use another endpoint, and that's more useful than just returning a 403 or 50X without further information, ie. during a maintenance window you can use the headers to signal that window with 0 quota units and avoid useless traffic. I can't think of any other specific scenarios and I don't know yet of generic client implementations targeting specifically these headers. My hope is that such clients support just enough of these headers to reap the main benefits, that is, basic rate limiting information enabling some form of throttling. Cheers, Alex --00000000000098cc3005b813594c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Darrel,

On Wed, Dec 30, 2020 at 3:1= 7 AM Darrel Miller <darrel@tavis.ca> wrote:
[...]

The scenario about "hitting rate limiting" is quite broad = in scope. You can have rate limits apply per API endpoint, per user identit= y, per connection, per time of day, per infrastructure resources, or even p= er service type or cost, or a combination of them all - which is quite a bi= t more than just limiting some misbehavior.

Th= e immediate benefit of these headers to service providers is being able to = signal expectations to clients so they can adapt. Sometimes it is just a ma= tter of adjusting to some specific rate of resource consumption. Some other= times the only way to adapt is just to stop using a service entirely for a= while or use another endpoint, and that's more useful than just return= ing a 403 or 50X without further information, ie. during a maintenance wind= ow you can use the headers to signal that window with 0 quota units and avo= id useless traffic.

I can't think of any other= specific scenarios and I don't know yet of generic client implementati= ons targeting specifically these headers. My hope is that such clients supp= ort just enough of these headers to reap the main benefits, that is, basic = rate limiting information enabling some form of throttling.

<= /div>
Cheers,
=C2=A0 Alex
--00000000000098cc3005b813594c-- From nobody Tue Jan 5 08:17:17 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 845473A0E4C for ; Tue, 5 Jan 2021 08:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=microsoft.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 geZFveDiq6ce for ; Tue, 5 Jan 2021 08:17:14 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650103.outbound.protection.outlook.com [40.107.65.103]) (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 282C33A0E05 for ; Tue, 5 Jan 2021 08:17:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QikYvbTSmR/rQQPx92C3H+Di5tlHZy+NsUfrkGxTnlTW50+51cl3FSdHHvip70HZzAmA0Q+KF4zSuBwBIPL0Y8PxvDpGN0O8ksWEBpCidEqqdiMQCvFKhZDKHLF7ZJE0Eu2Qh3bZjjY9kFUo1t3t1rlG+RNryW0N/9aw2Xica1Lpvde9O3D3yhUQc3Qn2DN/LXmlvHmrPbWkyE1SLbIY3Q3g68OKty9yf21JYgycsjbX3wem/Mu2zRqeoLoA790iFh7QWqhx1aboabpWC1VVjbCcpg1UvquWRlZIKlfOFiUgzckeMxBmPDslMmze46asyK5QPqgKhk53guxv+IAF0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PGrbGeDfJpYoIdK2GJ5vBJRs4/eoL0Qk/DkVSs/mvqU=; b=IZjyeUEUzd7Hfcjp31POLrIFkcd6y3YS5b7YqbgwaDK+KJWbZ1hRilSac8ND76+tmmVb1HsO2/WbjXC/Z8t+p3m8vdihQxRVW5CrCZpJMuZV0837AeFk6Oapu81I+eaTjrnbCjaQ2qs2VX0jVP2RFKS/Cyk8hsTajMKOb9CFX2xZtnHfzng7xvvILEwu3eijyBGeNFnElWQ/JrP9PnIJD/3tcPPW1tpqy05g50t7tS1vVqoUXLuKkNtE1rMlb5/CEvZFJcBLoyY33LK181VImZgdPJmYKoHFV+BxrfbNy2oNP8OiIf7Y7RZJG39WxJjknoPNrVyco3RJG4lw+68b5g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PGrbGeDfJpYoIdK2GJ5vBJRs4/eoL0Qk/DkVSs/mvqU=; b=MuSttvl7Z2zIZAJt8YvmEx82J6BOZS8/ChS8V34IakxFnF8utIfC8ntX89Vq2xfXcOYnvsOZgBIy3olnTUK+mKEPsaeqcWXbQFY4We7zN8WARws40OZm//Cs3IYvUpDwVSTYdZ2f7wDzH5fjVPTULkSdwLGz6haNGbC+cCufSuQ= Received: from (2603:10b6:a03:1d9::20) by BY5PR00MB0840.namprd00.prod.outlook.com (2603:10b6:a03:1d7::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3775.0; Tue, 5 Jan 2021 16:17:04 +0000 Received: from BY5PR00MB0837.namprd00.prod.outlook.com ([fe80::dd10:ecf5:45f7:b6f4]) by BY5PR00MB0837.namprd00.prod.outlook.com ([fe80::dd10:ecf5:45f7:b6f4%4]) with mapi id 15.20.3779.000; Tue, 5 Jan 2021 16:17:04 +0000 From: Darrel Miller To: "amr@redhat.com" , "darrel@tavis.ca" , "httpapi@ietf.org" CC: "robipolli@gmail.com" Thread-Topic: [httpapi] RateLimit Header client implementations Thread-Index: AQHW3lKxGhpPRJVD8kOy66GCWE4TNKoXg/eAgAGy0so= Date: Tue, 5 Jan 2021 16:17:04 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-01-05T16:17:04.650Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [74.15.147.35] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c47e0eeb-b380-4bc0-1da7-08d8b195577f x-ms-traffictypediagnostic: BY5PR00MB0840: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: teXG5euyJVSLdBoA1unEi0tmm9mNriW5p5QA6q5iihewZtHplVZTb+FlhUM9fhlw8Ib/H5PkBH1eBLUCDk3YmNdrScvU8uQG69FpobSQcnPCkH0V9iQWJn6TU0X5pb2PUfcUM0NqzhPDPD1jVhor+NRdItJ/kb6ghgXXmrc9GD2IPjcYly6szaWiIswjqiQI10PDzledWW27zlDo7FFLcOSqb3WRXMhRQa9BPDd8HepZtwXDUa13dD/AMrgAgQaJC9FBbfcqsrJdDuu5Vf7ofwpGSNy03TmiIMFDYJ4vMGx+gTuEr/27yUflGJ+mC13f+tjZWBmaHMoAtQ768/QqQvjRI+PVs13HRBt8k32CFsxt6dryztVQAudXsoxT3DxByLGF4jFHb2SFwmvBgFtQHg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR00MB0837.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(498600001)(83380400001)(2906002)(110136005)(5660300002)(8936002)(82960400001)(82950400001)(26005)(6506007)(66946007)(10290500003)(4326008)(76116006)(66476007)(64756008)(66446008)(7696005)(8990500004)(66556008)(55016002)(52536014)(8676002)(9686003)(53546011)(71200400001)(33656002)(86362001)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?ia9tpvZC8edu0gyY/frO+I7Ev56W18WxFF3ZXzJB0Jlvolp1/JVX//+GKB?= =?iso-8859-1?Q?/0UbCTMij2dUAoWBke0lXziM4zC7XM8FgeTZVX3diArddESv8QhegSYlUG?= =?iso-8859-1?Q?12Edux9OF4dkH0t7PbFEK6bCtozJ+BAlwucbE1vjZJdhVDJ6YzYDjqdVQk?= =?iso-8859-1?Q?EwQkKoUc4L3089Qaf2QJSQOPUg1WgG+XeA5+/Bm28JqQ+LIdxolWg6N3WD?= =?iso-8859-1?Q?ElVoNF7M0ay1zKGj/Q86/9QrTrxhLKtqgSykkQKW/wCY9pDLTtjnQDsyP2?= =?iso-8859-1?Q?tZEi94DIFYiLyuj+YEwkk30Y8XDNWEml4ZhN6yOXYNaP0HkoBf5wXEqWol?= =?iso-8859-1?Q?Wf7DnHn1OMKDoT1AX5J1+JqtKdkcLTRajbbYqAkAQy+mF0JeX30Z3r6P4b?= =?iso-8859-1?Q?S4EYdt8W15pFl4r9Wo3GHKcK8UEbaPVQpADKx1/+xduzrGvlGHXuZH7rL+?= =?iso-8859-1?Q?A52haJzfGxPbjTSv0zAxNWt9kuRZxiVs4ANCnZ+ocvaOnjV+54bA4RXIp0?= =?iso-8859-1?Q?rCPvF3gFgIMXebIggrBM8uqMDSOPWbeAvajw/HqAMwHsR1i7yeyHRYmXlS?= =?iso-8859-1?Q?pYxGDsU2GtAyFXTV9rJHfC8uUXyVeJkEL6Be8BKTisSf0uAku5xPCjqBSA?= =?iso-8859-1?Q?7xQ3oVuyJprY7fT3/ev+NZ2itV1sclB6UomO3qT3M1g41abcwekbB1ggqL?= =?iso-8859-1?Q?naogSQjR2aR5XvMpd8qjaqsdqHJYT3V1yq4AYykQcSiWSSrzrQ2v9LoenY?= =?iso-8859-1?Q?4OPJbff2NBICMtJqAPRkpUFfHV/WJwfbbPK66USQsFF9PWOXFIaqnbU0r9?= =?iso-8859-1?Q?+EmLMk0rW1CX4gqbSIeehdtyOvB9HOTFvvcBjGsywQJ0GnVx+yZzdjpQjr?= =?iso-8859-1?Q?xaABxakUdWyW4LZiw4beRZlC8h5FinP+ZHsDQ9J3jJm6qLSxVvVon5nk2C?= =?iso-8859-1?Q?io8EgVYNbfYTyvHyg4csEWE63sW+bhCw3l5JtwCZuryo5VRgGPa10LLelc?= =?iso-8859-1?Q?IfOE8SkxjC9DyxUpSsQPdTCbg+Jn6hzIkoIJ5rByOnfw52cbT01FEYTGHQ?= =?iso-8859-1?Q?ExlQernbLslJ2x5XKznw8JJvChlaX0MM2gXSAmN6zxyQ?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR00MB0837.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c47e0eeb-b380-4bc0-1da7-08d8b195577f X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2021 16:17:04.7862 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tavM6rCuI82nuuMxLFvLkKwD0Hbhs+idM18VroEeKvvNFX8bxsb/H6XkZvxL2QhIEtikESqRUjq3QRdfUCRA6w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR00MB0840 Archived-At: Subject: Re: [httpapi] RateLimit Header client implementations 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, 05 Jan 2021 16:17:16 -0000 Hey Alex,=0A= =0A= > From: httpapi on behalf of Alex Martinez =0A= > Hi Darrel,=0A= >> On Wed, Dec 30, 2020 at 3:17 AM Darrel Miller wrote:= =0A= [...] =0A= >> =A0... =0A= >> Enable user agents to avoid hitting rate limit due to some kind of puni= tive behavior.=0A= >> =A0=0A= =0A= > The scenario about "hitting rate limiting" is quite broad in scope. You c= an have rate limits=0A= > apply per API endpoint, per user identity, per connection, per time of d= ay, per infrastructure =0A= > resources, or even per service type or cost, or a combination of them all= - which is quite a=0A= > bit more than just limiting some misbehavior.=0A= =0A= Sorry, I wasn't clear. I completely understand the variety of ways that AP= I providers need to limit excessive behavior by clients. I was meaning som= ething different. Some API providers we go beyond simply returning a 429 a= nd a retry-after header to slow down the consumer. They will "punish" the = client for reaching the limits. Some services will "tarpit" the client by d= eliberately slowing the response down. I believe Roberto mentioned about s= ome services dropping the connection. =0A= =0A= My assertion is that if we discouraged API providers from punishing consume= r for reaching a rate limit, and we promote the use of the retry-after as a= signal to the client to back-off before making another call, then there ar= e fewer scenarios where a client is required to constantly monitor "the num= ber of calls left before reaching the limit". Returning and monitoring "ca= lls remaining" is potentially an expensive operation, especially when multi= ple clients can consume the same quota, e.g. in the case of calls per user = that is using multiple applications.=0A= =0A= > The immediate benefit of these headers to service providers is being able= to signal expectations =0A= > to clients so they can adapt.=0A= =0A= The question I have is with the existing non-standard headers, how many peo= ple have actually bothered to write this adaptive client code? Do we belie= ve that lack of standardization has been sufficient to discourage people fr= om writing that code? Are the only people writing that code the ones who a= re trying to avoid punitive behavior? If so, maybe a best practices docume= nt that recommends not doing that would be more constructive.=0A= =0A= > Sometimes it is just a matter of adjusting to some specific rate of =0A= > resource consumption. Some other times the only way to adapt is just to s= top using a service =0A= > entirely for a while or use another endpoint, and that's more useful than= just returning a 403 =0A= > or 50X without further information, ie. during a maintenance window you c= an use the headers =0A= > to signal that window with 0 quota units and avoid useless traffic.=0A= =0A= Why would a 503 with a retry-after header with a period that matches the ma= intenance window not be sufficient here?=0A= =0A= Darrel= From nobody Tue Jan 5 19:45:34 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 DA4583A0B2D; Tue, 5 Jan 2021 19:45:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160990472880.2928.17937318379978525908@ietfa.amsl.com> Date: Tue, 05 Jan 2021 19:45:28 -0800 Archived-At: Subject: [httpapi] The HTTPAPI WG has placed draft-wilde-linkset in state "Call For Adoption By WG Issued" 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, 06 Jan 2021 03:45:29 -0000 The HTTPAPI WG has placed draft-wilde-linkset in state Call For Adoption By WG Issued (entered by Rich Salz) The document is available at https://datatracker.ietf.org/doc/draft-wilde-linkset/ Comment: Going via the DataTracker, to mark that this draft-wilde-linkset is now in the "call for adoption" state. From nobody Tue Jan 5 19:47:15 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 3892F3A0B2D for ; Tue, 5 Jan 2021 19:47:14 -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 vUGriK7cekWJ for ; Tue, 5 Jan 2021 19:47:12 -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 917E43A0B35 for ; Tue, 5 Jan 2021 19:47:11 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 1063TTpZ008633 for ; Wed, 6 Jan 2021 03:47:11 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 : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=9tkKYsYwMXkMLy2oUWYQggRxGJ64h2eN+GBqt11RiPk=; b=C4h3UMPVqlyfOYIhzpKfvxVT4qkoNAHrDbRbtBXlN989I1dpl0ddYTjF9QXOkfQHfPg/ bbsWbGQ/ilJuMjIKLi5WfDtt8qVNORcDSILyzsegiw403v4/sAcru49wGL3FKgMOfpdn OnLQIZDNY9udOxONYKhASH4it7L0lP4xZMqYR3+8T1ItfyRSyi/nkCCrJgItldZwpR10 UF51pTbeQonseQ6RyiavHmvm5Won+/jpCARFodtbiS9EG9RmJorwzc7Zs4iZGVVBeKNy yd3DSdsfjjoWygbNWwAZK+D4Z2GZn3pq4r/26iw9j1uPNyjBOjT18DxgJX8WjcTmA+4t hA== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 35tgyj439a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 06 Jan 2021 03:47:11 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 1063Z1nJ022135 for ; Tue, 5 Jan 2021 19:47:09 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint5.akamai.com with ESMTP id 35tqpeyt10-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 05 Jan 2021 19:47:09 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 5 Jan 2021 22:47:08 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.010; Tue, 5 Jan 2021 22:47:08 -0500 From: "Salz, Rich" To: "httpapi@ietf.org" Thread-Topic: The HTTPAPI WG has placed draft-wilde-linkset in state "Call For Adoption By WG Issued" Thread-Index: AQHW495hSIrwHS5NQkC3bo9HyWL1LaoZ9XiA Date: Wed, 6 Jan 2021 03:47:08 +0000 Message-ID: <886B7500-20BA-4990-864B-52533A0533A8@akamai.com> References: <160990472880.2928.17937318379978525908@ietfa.amsl.com> In-Reply-To: <160990472880.2928.17937318379978525908@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.44.20121301 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.343, 18.0.737 definitions=2021-01-06_03:2021-01-05, 2021-01-06 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 spamscore=0 phishscore=0 malwarescore=0 suspectscore=0 mlxlogscore=875 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101060020 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-06_03:2021-01-05, 2021-01-06 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 bulkscore=0 mlxlogscore=789 phishscore=0 priorityscore=1501 clxscore=1015 spamscore=0 impostorscore=0 mlxscore=0 lowpriorityscore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101060020 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.60) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint5 Archived-At: Subject: Re: [httpapi] The HTTPAPI WG has placed draft-wilde-linkset in state "Call For Adoption By WG Issued" 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, 06 Jan 2021 03:47:14 -0000 DQpJZiB5b3UgYXJlIG9wcG9zZWQgdG8gdGhlIFdHIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQsIGFz IGl0IHNlZW1zIGNvbnNlbnN1cyBzbyBmYXIgaXMgaW4gZmF2b3IsIHBsZWFzZSBwb3N0IGJlZm9y ZSB0aGUgZW5kIG9mIHRoZSB3ZWVrLg0KDQrvu79PbiAxLzUvMjEsIDEwOjQ1IFBNLCAiSUVURiBT ZWNyZXRhcmlhdCIgPGlldGYtc2VjcmV0YXJpYXQtcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KDQoN CiAgICBUaGUgSFRUUEFQSSBXRyBoYXMgcGxhY2VkIGRyYWZ0LXdpbGRlLWxpbmtzZXQgaW4gc3Rh dGUNCiAgICBDYWxsIEZvciBBZG9wdGlvbiBCeSBXRyBJc3N1ZWQgKGVudGVyZWQgYnkgUmljaCBT YWx6KQ0KDQogICAgVGhlIGRvY3VtZW50IGlzIGF2YWlsYWJsZSBhdA0KICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdpbGRlLWxpbmtzZXQvDQoNCiAgICBDb21tZW50 Og0KICAgIEdvaW5nIHZpYSB0aGUgRGF0YVRyYWNrZXIsIHRvIG1hcmsgdGhhdCB0aGlzIGRyYWZ0 LXdpbGRlLWxpbmtzZXQgaXMgbm93IGluDQogICAgdGhlICJjYWxsIGZvciBhZG9wdGlvbiIgc3Rh dGUuDQoNCg0K From nobody Thu Jan 7 02:01:41 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 5104B3A0E2D for ; Thu, 7 Jan 2021 02:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.069 X-Spam-Level: X-Spam-Status: No, score=-3.069 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.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 ZxDBBuxYNfgb for ; Thu, 7 Jan 2021 02:01:38 -0800 (PST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D98663A0E25 for ; Thu, 7 Jan 2021 02:01:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610013696; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=WdLR2v81rgx20dRsGYUBZOI0uApiLuRilyBfn0ThxaU=; b=FxQ1yFOjqjz1zu7RdLsiZXnDJg0LiD27iPWdntbvM6OGbW8uSD0PYc0AQC53OmtGE5DjQ7 DRSpDN2iIkJiS/+WSxzsqy8IEy1bQIWZcMq/QtjTognj4cTb2Fd9vn2h0O+c+uEwZF+VCb /u8vBCUfT3FXc4lUtZn22TL1u3Tx9zY= Received: from mail-yb1-f198.google.com (mail-yb1-f198.google.com [209.85.219.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-261-LpxlPEzcOvyvFzYvMicDNg-1; Thu, 07 Jan 2021 05:01:34 -0500 X-MC-Unique: LpxlPEzcOvyvFzYvMicDNg-1 Received: by mail-yb1-f198.google.com with SMTP id e68so9345132yba.7 for ; Thu, 07 Jan 2021 02:01:34 -0800 (PST) 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=WdLR2v81rgx20dRsGYUBZOI0uApiLuRilyBfn0ThxaU=; b=Nu2t/t9x6LBVsaCvXHZ+k5UAHwt2NNlDmRf9iiFE5uxe43tc/DigbBeRjhPEnaSC4c eSIIspXuhXshDFl8z/vE5MdEsEPvy6k4oqoNPbfZlkGbtD0YMnpsiqKJjPUI6oET+jyR bNE39j6Qqnlydjpaqczlf9pzGCyRJk+8i4r2OEg2g6gZ1iTAneUkGMTMUJUmFa32unv+ KW1kW2MlNRybBjRsdz0Vw7pRG0ucWZ3rRrnpD6VdO3ktARTyy5I6koY61onEA6rG8hkd e0IVawv1AlOaCj8tcAzlHfKhOvmvlld3CkCa5ol8TQ8y1YJVCWDNYxQ7dXYv3dRU5GI6 EhyA== X-Gm-Message-State: AOAM533HeZC/LrduN+n2viBAD0cUksZ8DXZTa3kqszbhZBoyW6solInf zhT6DFN3k7p444iwVO7phrWtiuz1le+yQv18SP3b2qbSknljlWO1BvIGgf99iMKXpgKL3aemMaT s67ur7g3BR5wiQ6QTxRBXunH8 X-Received: by 2002:a25:bc41:: with SMTP id d1mr12419634ybk.100.1610013693821; Thu, 07 Jan 2021 02:01:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJzvj7+Po1BuwY7lf4Z9jc9w9csAE7CBuwKbMCY1nK5n7WZztvnS+2xpQajL6b9bG6178NKeOhTWhrvapO7F/ro= X-Received: by 2002:a25:bc41:: with SMTP id d1mr12419607ybk.100.1610013693582; Thu, 07 Jan 2021 02:01:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alex Martinez Date: Thu, 7 Jan 2021 10:01:22 +0000 Message-ID: To: Darrel Miller Cc: "darrel@tavis.ca" , "httpapi@ietf.org" , "robipolli@gmail.com" Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=amartine@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="0000000000004a378805b84c8658" Archived-At: Subject: Re: [httpapi] RateLimit Header client implementations 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, 07 Jan 2021 10:01:40 -0000 --0000000000004a378805b84c8658 Content-Type: text/plain; charset="UTF-8" Hi Darrel, On Tue, Jan 5, 2021 at 4:17 PM Darrel Miller wrote: > > My assertion is that if we discouraged API providers from punishing > consumer for reaching a rate limit, and we promote the use of the > retry-after as a signal to the client to back-off before making another > call, then there are fewer scenarios where a client is required to > constantly monitor "the number of calls left before reaching the limit". > Returning and monitoring "calls remaining" is potentially an expensive > operation, especially when multiple clients can consume the same quota, > e.g. in the case of calls per user that is using multiple applications. > That's a valid observation. That's why clients receiving these headers should consider them a hint and the next request they perform could be responded with new data in the headers that would make little sense if taken in isolation without further knowledge of what could be consuming the quotas. Service specific policies specified in the headers could help reduce that uncertainty, but those are too broad and diverse, so there's been little discussion on the topic other than allowing people to specify those so service specific clients can make use of those extra bits of information. > > The immediate benefit of these headers to service providers is being > able to signal expectations > > to clients so they can adapt. > > The question I have is with the existing non-standard headers, how many > people have actually bothered to write this adaptive client code? Do we > believe that lack of standardization has been sufficient to discourage > people from writing that code? Are the only people writing that code the > ones who are trying to avoid punitive behavior? If so, maybe a best > practices document that recommends not doing that would be more > constructive. > Yes, I believe that because there is no standardization there's been little to no effort in writing such adaptive code in generic HTTP clients, but this is pure speculation. I think it is very likely that most people doing so are the ones writing service specific clients, and in many cases they could be the same people that wrote the service in the first place, unless the service happens to see lots of usage across the board with many independent clients. At a minimum, retry-after could be used to signal generic clients that no request should be performed for a while, but that falls short of the minimum information that generic clients could use with these headers. > > Sometimes it is just a matter of adjusting to some specific rate of > > resource consumption. Some other times the only way to adapt is just to > stop using a service > > entirely for a while or use another endpoint, and that's more useful > than just returning a 403 > > or 50X without further information, ie. during a maintenance window you > can use the headers > > to signal that window with 0 quota units and avoid useless traffic. > > Why would a 503 with a retry-after header with a period that matches the > maintenance window not be sufficient here? > You are right, the immediate effect is the same. That said, you would be lacking some extra information about the nominal quota units and duration of the current window and the windows applying after this one is elapsed (ie. after recovery you'd have information about the expected rates, and those could also signal some sort of punitive policy), though that information might be next to useless in the current window since the intended effect is to stop traffic altogether for a while. Yet it would not work in a closely related scenario in which you would have some partial maintenance work but keeping the ability to serve clients in a degraded service manner -- that is, unless you kept giving clients shorter no-service windows interleaved with service responses as usual, hence generating a lot more wasteful traffic. Cheers, Alex --0000000000004a378805b84c8658 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --0000000000004a378805b84c8658-- From christoph.kappestein@gmail.com Sat Jan 9 04:10: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 839B53A1241 for ; Sat, 9 Jan 2021 04:10:46 -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=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 JG_3Xn966VOR for ; Sat, 9 Jan 2021 04:10:45 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 2F8E33A123D for ; Sat, 9 Jan 2021 04:10:45 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id u25so8709454lfc.2 for ; Sat, 09 Jan 2021 04:10:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=hA2LEX5me6BG6qnKfScCFGDaNYuJtWruAO2a9Ue8xKY=; b=p22xhrE0fUM2LH4Bws57P+vqbKEHplRGxloRvkTH5zbnQbcdDqkZcfSukZ2dZQ9LSO /9IIJeNfzkcCLYX82TDgYz7c9A6P8OUHHdbgg5fTTNB34JnLIdXYsXKO5yyhY6iyvg6z MgWGvvPHBvz6EE66hl0I9XSNV2iAW7PqTCwJ6zRkoIoJtp7nEx8obYN8Y6HoNUdmmp8h kL0taL7c/VLugaQEI7RyHHk70PS/jCOBnc3nfo8ysfnmZCDSqPie1OisOyBfJv4RjAYV ZUIw3HwOm2S6M5CqlBq9Z71j21TSWNTuQKQ69VYIziLvY46g4xXtYV4ciQ+/zD4x/7vD AvTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hA2LEX5me6BG6qnKfScCFGDaNYuJtWruAO2a9Ue8xKY=; b=ICsAEvuIJ+MdpgzVQug8sxtTpScR8K9qbDa0z0rO3GW9qLuhM7uc6OzNoDimDb7kT/ 3Ll8FdmnrI99BG4T1BAWExGt90KmPGTRRAvujwZm8GyMETcwEgvmxLcQNr8xKCkZh2jf JyjIFA7G6OCUFJ6Uzfp5n9OSKOdPw8S1ad80Q4QwF2Xd6pQxrY0FNWYWLZk/2CEEm3ye faQWkTMDWdZuLbU+aj8FrlzGvZ+eeaUKBXU1i1hIxyD3Om9CNYA6iYzjftlyn4n7mQpN tuJ37aEx5Kk3AYWmN+odfJt3SGsaKmWL1NyV2fGtsECqB7Taw/HgYhL0t+g5+BsakKyc qaBA== X-Gm-Message-State: AOAM531qYPUktCw0Myn7gf1FbpHBYHYRIzreu9cUFj3k79J7+pmrwpp9 jpJhZIGHHfTUQG5RZJ3LvzGEiaM8r/TcqKYQDQrq0hbF X-Google-Smtp-Source: ABdhPJwoRJjUcf7NB5k3VqWgIPFZvqjOw3RHBIY3znAbS6uQ7+0g9wBu9J9pn3ausOtkJ36e7LCp5zlEKYCTomwGubs= X-Received: by 2002:a2e:850b:: with SMTP id j11mr3613078lji.84.1610194242735; Sat, 09 Jan 2021 04:10:42 -0800 (PST) MIME-Version: 1.0 Received: by 2002:ab3:6f03:0:0:0:0:0 with HTTP; Sat, 9 Jan 2021 04:10:42 -0800 (PST) From: Christoph Kappestein Date: Sat, 9 Jan 2021 13:10:42 +0100 Message-ID: To: httpapi@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [httpapi] Introduction 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, 09 Jan 2021 13:44:21 -0000 Hello, my name is Christoph I am a developer in the API space and I just found out about this Working-Group through this video https://www.youtube.com/watch?v=vyeEqJNKq6Y I am happy to see some process in this space. Currently we are working on a JSON format called TypeSchema (https://typeschema.org/) which describes JSON payloads and is optimized for code generation. We have started this since there is currently no great standard which describes JSON payloads and is optimized for code generation. So if this a topic which you want address I would be happy to share my experiences. In general we are also working on an open source API management product called Fusio s. https://github.com/apioo/fusio so we are also interested in other standards like i.e. the Deprecation header which we plan to implement, currently we simply issue a standard "Warning" header to inform developers that an API is deprecated, but it is great to see that there is now a dedicated header for this. I am not too familiar with the process to comment an RFC but is there in general a form where I can provide written feedback to existing specifications or is this done through this mailing list? best regards Christoph From nobody Sat Jan 9 08:41:05 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 D89293A110F for ; Sat, 9 Jan 2021 08:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=gmx.net 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 H1tkQhAcA8nS for ; Sat, 9 Jan 2021 08:41:01 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 6F3D93A10FF for ; Sat, 9 Jan 2021 08:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1610210456; bh=AA205kuE3Dayq0nQd2O0WOp3kCcDllWfsxeYiA9swns=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=CK2kyZcg0jZLl8BViZPjkLmbyv5zeQJYYwqMuiMrr47WBZSEA/ClNveaiG8oFjUbD RJNunMkxBxV3BknfgguZZykwf0I06NEVakkvrq+6lEApvTr7cEaK7X4prO+QypWsnQ LSXXp2rYMwGMgsHC17g0VPINHrAVIP73cNmyH7H0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.20] ([84.171.150.161]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M1po0-1kw4My1vg0-002D6k for ; Sat, 09 Jan 2021 17:40:56 +0100 To: httpapi@ietf.org References: From: Julian Reschke Message-ID: <710607e0-71e7-5ac7-c55d-5a258886d2d3@gmx.de> Date: Sat, 9 Jan 2021 17:40:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:umdzPnLx7Xj3QaIRdzC3YYjNPzWOw0BbWb8eXH9pCY7CijoNBbO 9BIjwPwbqoKwldmBONvRTQFGkACoO9DD+rZ5DGOvwW//dySZF583bP9zTq561wK9i+yH7MV DhoxJWQ1CpXJ6zgubl7fZWnhZzQc5IRfO+3waNW9WmczGRB3PPuLADSZ4l+/rSgML7fP0Le cqZ9DKNA/LZFAZC9kLjhA== X-UI-Out-Filterresults: notjunk:1;V03:K0:xuX19oZytuU=:zZXnjrjrfXro0/GjMDetKg sRpMDc5NqCeQqd42XDQ24JmYJFpLwUUPamS94mFmjMPQb1SBkPinJozJPalvBHdMd8eRgt0l+ Dtm337mpdjXRH60rn45y7ULToOrWb35EWXt621S3KdHNytGIldizVHp7u5JisMYTBGWZuTsC4 XO9XT3Fxm7zqPKzdCOetGuGIABQsIPbE2oQ3ncLDFpxEWGn58vL7ubVHIIyH79XJILBHp3wdC Hd4QlDWkQYO+uqzsEOe3Xw5+1kyHMRSpYOhv27J9jc0vWbjV6A/rlkNXUFw6o7XmarlZwmg2K DgEJ+pGQoyoQeQ3+fB1lcUv/zXR4O4hBaAWEu4PHDqrAL9YUhWXA/ry4AD8n5f8gORMSy3KFq HhyFfOXn3LEcWWna423OhQNMLBWZYG/DWDA7VmFyD7TO0oQ7uTd+OGHUdgKbTMH5gjitN4r1b CiVZuuwjnxatAU9ib1JHBH0goK4an/hDES5Iqs0wOTy4rZiJDtv5bj+xjw5KhHFLQGO4263V2 LylL7lxtclliLqUBf+mFdS8QyeU2T6imRceHBTcKRk7xJmicPZV6v6fZJznkUgdXQrU5Zon5J u/LG9DI535pN6gw95wTGXH39vGk3K/DLbSxDccjEH/VKUoP1wMz+tDplPIsBAxeyXIjZdPsgp 5yPyR9a+FN7Y2Dzx2Fvzc7ZKbk+Iz0FUOhzj+wZTqdu2ihh4Gf/0CSwLtx38qY8v+m4oPD55r 2znRW4MKTPoUqrVo7AxUQIJfFKY2wx2xWfz36pJAlAZ/GHMfFKcpgyGGvWNMonaJMCz4tib1s NZZLsLYNGnziIiANuF0ClQN7vjRi8A/BH7pDvIisBBZL6XZs4f/sX3dOXYDguMVLJFg+fPUg7 JGHMe903edczd2lmW+0Q== Archived-At: Subject: Re: [httpapi] Introduction 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, 09 Jan 2021 16:41:04 -0000 Am 09.01.2021 um 13:10 schrieb Christoph Kappestein: > Hello, > > my name is Christoph I am a developer in the API space and I just > found out about > this Working-Group through this video > https://www.youtube.com/watch?v=3DvyeEqJNKq6Y Hi Christoph! > I am happy to see some process in this space. Currently we are working o= n a > JSON format called TypeSchema (https://typeschema.org/) which describes = JSON > payloads and is optimized for code generation. > > We have started this since there is currently no great standard which de= scribes > JSON payloads and is optimized for code generation. So if this a topic w= hich you > want address I would be happy to share my experiences. > > In general we are also working on an open source API management product = called > Fusio s. https://github.com/apioo/fusio so we are also interested in oth= er > standards like i.e. the Deprecation header which we plan to implement, c= urrently > we simply issue a standard "Warning" header to inform developers that an= API > is deprecated, but it is great to see that there is now a dedicated head= er for > this. > > I am not too familiar with the process to comment an RFC but is there in= general > a form where I can provide written feedback to existing specifications o= r is > this done through this mailing list? RFCs, are despite their names, "finished" documents. If you find an outright bug, you can raise an erratum (). That said, *all* of the base HTTP specs are currently being revised (that is HTTP/1.1 & related documents, HTTP/2), so if you have feedback on some of these internet drafts, now is a good time to send it. For these however, it's a different WG (HTTPBIS). You can see the documents currently being worked on at and . Send feedback to the HTTPBIS mailing list (, or alternatively use the issue tracker - repos at ). Similarly, for *this* WG, you can see the active documents at , and send feedback through this mailing list, or through the Github repos (). Best regards, Julian From nobody Sat Jan 9 09:40:29 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 3CB543A13C9 for ; Sat, 9 Jan 2021 09:40:28 -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 cHLV8HUsQ1cH for ; Sat, 9 Jan 2021 09:40:26 -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 6A1003A13C8 for ; Sat, 9 Jan 2021 09:40:26 -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 109HXxVY015459; Sat, 9 Jan 2021 17:40:25 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 : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=bCP2yipRRS8EXr4PT4otdoE+7uDqJGdN+8i1P6mysR4=; b=drVLzHLKFfzWLURYzRGdKIViTRM6lTL/Z0En2+XHityf6CWEZwTZyVN3J67ZQ+sdBMpu axQ1E8s5wYa/YK7EC6C2WObJZcXkRhz+uHRFon6LVJm9JFyp1HjCZv4bY5ZH16JNyzVV DUfLCDEM2BEC6PbLBbpWnPgPPLpMV4HbMZyQ0UdMVt8FEFHNEw7UGaJAHlabUb6wR4E9 h7uiRfZtTC80WYZMjlMgbF1h0hP6qhiZzd+G2P4Zvov8gTXFDANk5z2Uh6zmbfgt8Pmg fLpdXtlUO+8xk+BPY04MuobsMQ1OtP5myC9VUoUO+P6u6ilTYiCdhVXKi5ckfp9CO12/ hQ== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 35y5e06vf1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 09 Jan 2021 17:40:25 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 109HZ7t8016609; Sat, 9 Jan 2021 09:40:24 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint5.akamai.com with ESMTP id 35ybbe0gbx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 09 Jan 2021 09:40:24 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 9 Jan 2021 12:40:23 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.010; Sat, 9 Jan 2021 12:40:23 -0500 From: "Salz, Rich" To: Christoph Kappestein , "httpapi@ietf.org" Thread-Topic: [httpapi] Introduction Thread-Index: AQHW5o2MTfOy5tg/IUqCBSkAUmxvDKofj+aA Date: Sat, 9 Jan 2021 17:40:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.45.21010502 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: <18D580F63BEE414D971D7DF143688BC6@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-09_09:2021-01-07, 2021-01-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 suspectscore=0 spamscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101090117 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-09_09:2021-01-07, 2021-01-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 impostorscore=0 mlxscore=0 bulkscore=0 priorityscore=1501 phishscore=0 lowpriorityscore=0 suspectscore=0 spamscore=0 mlxlogscore=999 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101090117 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.60) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint5 Archived-At: Subject: Re: [httpapi] Introduction 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, 09 Jan 2021 17:40:28 -0000 PiAgICBXZSBoYXZlIHN0YXJ0ZWQgdGhpcyBzaW5jZSB0aGVyZSBpcyBjdXJyZW50bHkgbm8gZ3Jl YXQgc3RhbmRhcmQgd2hpY2ggZGVzY3JpYmVzDQogICAgSlNPTiBwYXlsb2FkcyBhbmQgaXMgb3B0 aW1pemVkIGZvciBjb2RlIGdlbmVyYXRpb24uIFNvIGlmIHRoaXMgYSB0b3BpYyB3aGljaCB5b3UN CiAgICB3YW50IGFkZHJlc3MgSSB3b3VsZCBiZSBoYXBweSB0byBzaGFyZSBteSBleHBlcmllbmNl cy4NCg0KVGhlIElFVEYgaGFzIGhhZCBhIGNvdXBsZSBvZiB3b3JraW5nIGdyb3VwcyBvbiBKU09O OyB5b3UgY2FuIGZpbmQgdGhlICJjb25jbHVkZWQiIG9uZXMgYXQgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9ncm91cC9jb25jbHVkZWQvIGFuZCB0aGUgYWN0aXZlIG9uZXMgYXQgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy8gIExvb2sgZm9yICJqc29uIiBpbiB0aGUgbmFtZS4g IEV2ZW4gY29uY2x1ZGVkIGdyb3VwcyBzdGlsbCBoYXZlIHRoZWlyIG1haWxpbmcgbGlzdCBrZXB0 IG9wZW4uIEkgZG9uJ3Qga25vdyBpZiB0aGF0IHdpbGwgYmUgaGVscGZ1bCBvciBub3QuICBBcyBm b3Igd2hldGhlciBvciBub3QgdGhpcyBXRyB3YW50cyB0byBkaXNjdXNzIHRoaXMsIGl0J3MgdXAg dG8gdGhlIFdHIHRvIGRlY2lkZSBpZiB0aGV5J3JlIGludGVyZXN0ZWQgKGJ5IGhhdmluZyB0aGlz IGtpbmQgb2YgZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0KSwgYW5kIGlmIG5lY2Vzc2Fy eSB0byB3b3JrIHdpdGggdGhlIEFyZWEgRGlyZWN0b3IgdG8gZGV0ZXJtaW5lIGlmIHdlIG5lZWQg dG8gbW9kaWZ5IHRoZSBXRyBjaGFydGVyIG9yIG5vdC4NCg0KPiAgICBJIGFtIG5vdCB0b28gZmFt aWxpYXIgd2l0aCB0aGUgcHJvY2VzcyB0byBjb21tZW50IGFuIFJGQyBidXQgaXMgdGhlcmUgaW4g Z2VuZXJhbA0KICAgIGEgZm9ybSB3aGVyZSBJIGNhbiBwcm92aWRlIHdyaXR0ZW4gZmVlZGJhY2sg dG8gZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMgb3IgaXMNCiAgICB0aGlzIGRvbmUgdGhyb3VnaCB0 aGlzIG1haWxpbmcgbGlzdD8NCg0KUkZDJ3MgYXJlIHB1Ymxpc2hlZCBkb2N1bWVudHMsIG5vdCBk cmFmdHM7IHRoZSBuYW1lICJyZXF1ZXN0IGZvciBjb21tZW50cyIgaXMgYSBub2RlIHRvIElFVEYg aGlzdG9yeS4gIEhvdyB0byBwcm92aWRlIGZlZWRiYWNrIG9uIHB1Ymxpc2hlZCBSRkMncyBkZXBl bmRzIG9uIHRoZSBhbW91bnQgYW5kIG5hdHVyZSBvZiBmZWVkYmFjay4gIElmIHlvdSBoYXZlIGEg d2VsbC1jb250YWluZWQgdGVjaG5pY2FsIGVycm9yLCB5b3Ugd2FudCB0byByZXBvcnQgYW4gImVy cmF0YSIgYWdhaW5zdCB0aGUgUkZDLiAgSWYgaXQncyBtb3JlIHBoaWxvc29waGljYWwgb3IganVz dCAibW9yZSIsIGl0IG1pZ2h0IGJlIGJldHRlciB0byBmaW5kIHRoZSBXRyB0aGF0IHB1Ymxpc2hl ZCB0aGUgUkZDIGFuZCBwb3N0IHRvIHRoYXQgbWFpbGluZyBsaXN0IChzZWUgYWJvdmUpLiAgVG8g ZmluZCB0aGUgV0cgZm9yIHJmYyAxMjM0LCBnbyB0byBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9y Zy9pbmZvL3JmYzEyMzQgYW5kIGxvb2sgYXQgdGhlICJTb3VyY2UiIGxhYmVsLCB3aGljaCB3aWxs IGhhdmUgYSBsaW5rIHRvIHRoZSBXRy4NCg0KSG9wZSB0aGlzIGhlbHBzLiAgV2VsY29tZSENCg0K From nobody Sat Jan 9 09:49:35 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 296CC3A13E3 for ; Sat, 9 Jan 2021 09:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-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 8ZzIXiHoxa4M for ; Sat, 9 Jan 2021 09:49:33 -0800 (PST) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (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 51E043A13E2 for ; Sat, 9 Jan 2021 09:49:33 -0800 (PST) Received: from [108.205.51.24] (port=52691 helo=dretpro.attlocal.net) by postoffice.gristmillmedia.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kyIMl-0006mZ-47; Sat, 09 Jan 2021 12:49:31 -0500 To: Christoph Kappestein , httpapi@ietf.org References: From: Erik Wilde Message-ID: Date: Sat, 9 Jan 2021 09:49:27 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [httpapi] Introduction 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, 09 Jan 2021 17:49:35 -0000 hello christoph! welcome to the group! i have nothing to add to the general remarks of julian, who is extremely well-versed in all things IETF. On 2021-01-09 04:10, Christoph Kappestein wrote: > I am happy to see some process in this space. Currently we are working on a > JSON format called TypeSchema (https://typeschema.org/) which describes JSON > payloads and is optimized for code generation. just as a pointer: https://tools.ietf.org/html/rfc8927 may be interesting for you, but i don't know how much overlap there is between TypeSchema's goals and JTD. > We have started this since there is currently no great standard which describes > JSON payloads and is optimized for code generation. So if this a topic which you > want address I would be happy to share my experiences. JTD is out there as an RFC, but that of course doesn't mean that it's the only way to address this use case. JTD was submitted as an individual draft (i.e., not via this group, which didn't yet exist when JTD was getting finalized), but i do think that discussing this topic might be interesting for this group. but that's just my personal opinion. > In general we are also working on an open source API management product called > Fusio s. https://github.com/apioo/fusio so we are also interested in other > standards like i.e. the Deprecation header which we plan to implement, currently > we simply issue a standard "Warning" header to inform developers that an API > is deprecated, but it is great to see that there is now a dedicated header for > this. that's good to see. if you end up implementing deprecation header support, can you please let us know so that we can add your product to our list of implementations? thanks! because of https://datatracker.ietf.org/doc/draft-cedik-http-warning/ i am also wondering whether you use warnings for other things as well, and if you do, i'd be interested to hear more about it. thanks and cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Sat Jan 9 11:49:22 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 73DF23A1441 for ; Sat, 9 Jan 2021 11:49:20 -0800 (PST) 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, RCVD_IN_DNSWL_BLOCKED=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 GZA2LfG43mjm for ; Sat, 9 Jan 2021 11:49:18 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450: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 4AB183A143D for ; Sat, 9 Jan 2021 11:49:18 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id o13so31355986lfr.3 for ; Sat, 09 Jan 2021 11:49:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0+Ls1xn6G6KAoD552K38pIP4KW012M3v9FTBwGr9Dqc=; b=uanw/1+2KnFbi0U43gJ5pAdqkevSMikJwt5OgpYTKMILQqEj5yiTsSGPsCVw/0Iat2 zid9LtbVsWQGiq8LuVh0SXtd3y3qKd8D2S8BWY44hEt1DWfGTNjQwWIOn4oQ71IPdNaD b+6n/67IWKqRPniSalqbb3XmPi6U+H/gd6jn34fnRd8HPBjwSLQwDGWrDpPWlPm2U5Xy py4YIRg1pQ2V/XldnFLc2jf49w5jdUs+oboXohIMSLUlMLpapf4Q04QZwpiI85UnZSwg +b1IhBL1Ai6CtthDEzQ5IOCT+3YOWsb6SVdq7HGfIUGaLdns0m6QBJe04dIKLKyXG1l0 KCrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0+Ls1xn6G6KAoD552K38pIP4KW012M3v9FTBwGr9Dqc=; b=lKkwN2lnjNF/1cdHuksvevb9cl7LvE2iFs8aA/BZlaKpSVw4LtZuMVwsuKxsLN2ClK KebWgq8PCz0pbzf3EmkR+5hSb5WtEv3+TDtowNw3VV42JowFgKTtZR1EqGf/s03PADx+ cHK9F93SZYXGFRQdcPn3Rx5hrweNQ6s8FEylzdD1xpQKBrOVYOAxkth7DN4NhszI23cB TeZjJrBvDsyuNM/R3N638n5/KOaxbKdUK/4hUtVL7aDY260inWPA1kPbQ/Wm7u7HLcP2 2PmrlBnOxfiQwjPHHGf9fO3OR+9mbSPOpXEwU8d1B7Xm92f8RxQ/vAbovgFFvvjIijGe Zl4w== X-Gm-Message-State: AOAM531uibK0XS+WwuFY6bM7k6hU6uVR8L4cw5rLFfGJ80a1c6SuLjA1 z0NXBn0X9C/tAVghyuObm7mF4eKm3d/CAkJoYHRH6H3V X-Google-Smtp-Source: ABdhPJypUgNsEbyF2+6kaXMiK7w3l4cygd4uS1tC5VQjbkVXYE1FX/3p9WGNvKuq7f9lzhHxgczeHWpNRNtevuBDI1I= X-Received: by 2002:a2e:574c:: with SMTP id r12mr4348586ljd.139.1610221755982; Sat, 09 Jan 2021 11:49:15 -0800 (PST) MIME-Version: 1.0 Received: by 2002:ab3:6f03:0:0:0:0:0 with HTTP; Sat, 9 Jan 2021 11:49:15 -0800 (PST) In-Reply-To: References: From: Christoph Kappestein Date: Sat, 9 Jan 2021 20:49:15 +0100 Message-ID: To: Erik Wilde Cc: httpapi@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [httpapi] Introduction 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, 09 Jan 2021 19:49:21 -0000 Hi all, thanks for the information and pointers. @Julian just to get a better understanding, if we say that RFCs are finished documents, does this mean that also those draft RFCs i.e. listed here https://datatracker.ietf.org/wg/httpapi/documents/ are finished? I totally understand that RFCs like 3986 are finished and will not change easily or only in case there is an actual error. But I assumed that we can evolve and iterate those "draft" RFCs easier until they become a "real" RFC. But this is only my understanding from an outsider perspective so please let me know whether this makes sense. @Rich @Erik thanks for the pointer to JTD, this project looks indeed interesting. I had also some contact with the author before and I think both projects have similar goals but there is also a feature gap. Since JTD is already an RFC it is probably difficult to change, but if there is a way to evolve this spec I would be really interested in this. This could then become also an interesting alternative schema specification for the OpenAPI spec. @Erik regarding the "Deprecation" header, sure I will let you know if we have implemented this. I was not aware of the "Content-Warning" RFC, we use the old "Warning" header with an 199 code only to return the status of an endpoint, we have currently the status: Experimental, Production, Deprecated, Closed. The status closed maps probably to the "Sunset" date at the deprecation header RFC, in this case our gateway simply returns always an 410 status code with an info message. So we use the warning header only for this information but I will also take a look at the Content-Warning RFC. best regards Christoph 2021-01-09 18:49 GMT+01:00, Erik Wilde : > hello christoph! > > welcome to the group! i have nothing to add to the general remarks of > julian, who is extremely well-versed in all things IETF. > > On 2021-01-09 04:10, Christoph Kappestein wrote: >> I am happy to see some process in this space. Currently we are working on >> a >> JSON format called TypeSchema (https://typeschema.org/) which describes >> JSON >> payloads and is optimized for code generation. > > just as a pointer: https://tools.ietf.org/html/rfc8927 may be > interesting for you, but i don't know how much overlap there is between > TypeSchema's goals and JTD. > >> We have started this since there is currently no great standard which >> describes >> JSON payloads and is optimized for code generation. So if this a topic >> which you >> want address I would be happy to share my experiences. > > JTD is out there as an RFC, but that of course doesn't mean that it's > the only way to address this use case. JTD was submitted as an > individual draft (i.e., not via this group, which didn't yet exist when > JTD was getting finalized), but i do think that discussing this topic > might be interesting for this group. but that's just my personal opinion. > >> In general we are also working on an open source API management product >> called >> Fusio s. https://github.com/apioo/fusio so we are also interested in >> other >> standards like i.e. the Deprecation header which we plan to implement, >> currently >> we simply issue a standard "Warning" header to inform developers that an >> API >> is deprecated, but it is great to see that there is now a dedicated header >> for >> this. > > that's good to see. if you end up implementing deprecation header > support, can you please let us know so that we can add your product to > our list of implementations? thanks! > > because of https://datatracker.ietf.org/doc/draft-cedik-http-warning/ i > am also wondering whether you use warnings for other things as well, and > if you do, i'd be interested to hear more about it. > > thanks and cheers, > > dret. > > -- > erik wilde | mailto:erik.wilde@dret.net | > | http://dret.net/netdret | > | http://twitter.com/dret | > From nobody Sat Jan 9 14:02: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 85D513A0365 for ; Sat, 9 Jan 2021 14:02:23 -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 x-YSV9BQNRjc for ; Sat, 9 Jan 2021 14:02:22 -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 2E7DF3A0317 for ; Sat, 9 Jan 2021 14:02:21 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 109Lx32M026938; Sat, 9 Jan 2021 22:01:38 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=NRseGrRd5Z9mGz3WO18blbFWhB+OgEl+Ha+wMOsCtYc=; b=WEq+JQmdwUayVVSJziHhUYECwNmMMTGV4CxPEdSFpsqQ3u1kplsgKOjndebwyrn5tRPy /ylg5k0rLD6aO1TJQAY9D/0kuoXe36aSVMl0k6Ktmv/y7xVl3NVFcFKuaOduuignE2+C ju6XO73/4z7RbYzruzF2M5lnqQ5s98Jj/hAn/RdjWZ1KvUJi1MXJF5eXdpfLwi8ffxaF eZ98A7SKKB2p8p1UH6NQmGLjHzb/s7XavoJ8D6M3Wqtn/02j+mKPId1dZ88o/Tk6Bdn+ By3YMF0uLndMM04Is2lggm3bafOpgxWPI/kxsojYmiM/JCaBhBgCNDRsFavSguuBVldL ug== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 35y5sb5c7e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 09 Jan 2021 22:01:38 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 109LZS0H019577; Sat, 9 Jan 2021 17:01:38 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint1.akamai.com with ESMTP id 35y8q2s2ux-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 09 Jan 2021 17:01:38 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 9 Jan 2021 17:01:37 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.010; Sat, 9 Jan 2021 17:01:37 -0500 From: "Salz, Rich" To: Christoph Kappestein , Erik Wilde CC: "httpapi@ietf.org" Thread-Topic: [httpapi] Introduction Thread-Index: AQHW5o2MTfOy5tg/IUqCBSkAUmxvDKof5kKAgAAheYD//9EngA== Date: Sat, 9 Jan 2021 22:01:36 +0000 Message-ID: <8BC13893-6E08-4D29-9942-623392D1F546@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.45.21010502 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: <857EBB4033EB8349A22CD85E2DA85236@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-09_13:2021-01-07, 2021-01-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 mlxscore=0 bulkscore=0 adultscore=0 phishscore=0 suspectscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101090143 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-09_13:2021-01-07, 2021-01-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 phishscore=0 spamscore=0 mlxlogscore=969 suspectscore=0 impostorscore=0 bulkscore=0 clxscore=1015 priorityscore=1501 adultscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101090145 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.18) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint1 Archived-At: Subject: Re: [httpapi] Introduction 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, 09 Jan 2021 22:02:24 -0000 PiAgICBASnVsaWFuIGp1c3QgdG8gZ2V0IGEgYmV0dGVyIHVuZGVyc3RhbmRpbmcsIGlmIHdlIHNh eSB0aGF0IFJGQ3MgYXJlIGZpbmlzaGVkDQogICAgZG9jdW1lbnRzLCBkb2VzIHRoaXMgbWVhbiB0 aGF0IGFsc28gdGhvc2UgZHJhZnQgUkZDcyBpLmUuIGxpc3RlZCBoZXJlDQogICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy93Zy9odHRwYXBpL2RvY3VtZW50cyAgYXJlIGZpbmlzaGVkPyBJ IHRvdGFsbHkNCiAgICB1bmRlcnN0YW5kIHRoYXQgUkZDcyBsaWtlIDM5ODYgYXJlIGZpbmlzaGVk IGFuZCB3aWxsIG5vdCBjaGFuZ2UgZWFzaWx5IG9yIG9ubHkNCiAgICBpbiBjYXNlIHRoZXJlIGlz IGFuIGFjdHVhbCBlcnJvci4gQnV0IEkgYXNzdW1lZCB0aGF0IHdlIGNhbiBldm9sdmUgYW5kIGl0 ZXJhdGUNCiAgICB0aG9zZSAiZHJhZnQiIFJGQ3MgZWFzaWVyIHVudGlsIHRoZXkgYmVjb21lIGEg InJlYWwiIFJGQy4gQnV0IHRoaXMgaXMgb25seSBteQ0KICAgIHVuZGVyc3RhbmRpbmcgZnJvbSBh biBvdXRzaWRlciBwZXJzcGVjdGl2ZSBzbyBwbGVhc2UgbGV0IG1lIGtub3cgd2hldGhlciB0aGlz DQogICAgbWFrZXMgc2Vuc2UuDQoNCllvdSBhcmUgY29ycmVjdC4gIEJ1dCB0aGUgZHJhZnQgZG9j dW1lbnRzIGFyZSBjYWxsZWQgaW50ZXJuZXQtZHJhZnRzIG9yIEktRCdzOyB3ZSBkb24ndCB1c2Ug dGhlIHRlcm0gImRyYWZ0IFJGQyIgYmVjYXVzZSBpdCBsZWFkcyB0byBjb25mdXNpb24uDQoNClRo ZSBwbGFjZSB0byBjb21tZW50IG9uIHRob3NlIHNwZWNpZmljIGRvY3VtZW50cyBpcyBieSBwb3N0 aW5nIHRvIHRoZSBsaXN0LiAgT3IgcmFpc2luZyBpc3N1ZXMgb24gR2l0SHViOyBodHRwczovL2dp dGh1Yi5jb20vaWV0Zi13Zy1odHRwYXBpIGhhcyByZXBvJ3MgZm9yIGVhY2ggZHJhZnQuDQogDQoN Cg== From nobody Sat Jan 9 18:04:43 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 6274F3A08BE for ; Sat, 9 Jan 2021 18:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-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 OpNmOuAR7hHD for ; Sat, 9 Jan 2021 18:04:39 -0800 (PST) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (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 9F17D3A08B0 for ; Sat, 9 Jan 2021 18:04:39 -0800 (PST) Received: from [108.205.51.24] (port=54229 helo=dretpro.attlocal.net) by postoffice.gristmillmedia.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kyQ5t-00080n-Cw; Sat, 09 Jan 2021 21:04:37 -0500 To: Christoph Kappestein Cc: httpapi@ietf.org References: From: Erik Wilde Message-ID: <3cafe1e6-0afc-06e5-aa6b-1fce061e62f2@dret.net> Date: Sat, 9 Jan 2021 18:04:33 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [httpapi] Introduction 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: Sun, 10 Jan 2021 02:04:41 -0000 hello christoph. On 2021-01-09 11:49, Christoph Kappestein wrote: > @Rich @Erik thanks for the pointer to JTD, this project looks indeed > interesting. > I had also some contact with the author before and I think both projects have > similar goals but there is also a feature gap. Since JTD is already an RFC it is > probably difficult to change, but if there is a way to evolve this spec I > would be really interested in this. the RFC is what it is. currently it's an individual submission (i.e., it wasn't discussed/developed in an IETF working group) and classified as experimental. but if there is building up momentum, it's not out of the question to consider updating it. > This could then become also an interesting > alternative schema specification for the OpenAPI spec. absolutely. the 3.x versions of OpenAPI will keep JSON schema as a hard-coded part of the language, but there are plans to decouple things a bit more in 4.x and support alternative schema languages. i am a fan of the idea of making OpenAPI's schema part simpler, or at least allowing flexibility, but the main initiative in this case will have to be on the OpenAPI side (which is a different group and not part of the IETF). > @Erik regarding the "Deprecation" header, sure I will let you know if we have > implemented this. I was not aware of the "Content-Warning" RFC, we use the old > "Warning" header with an 199 code only to return the status of an endpoint, we > have currently the status: Experimental, Production, Deprecated, > Closed. The status closed maps probably to the "Sunset" date at the > deprecation header RFC, in this case our gateway simply returns always an 410 > status code with an info message. So we use the warning header only for this > information but I will also take a look at the Content-Warning RFC. just as a heads up: the warning header will not be part of the revised HTTP version, which is one of the reasons why for the draft we have decided to mint a new HTTP header field. i like the idea of signalling the "maturity stage" of an API, but it's hard to come up with a maturity model that fits everybody's needs. this is why there currently are specific headers for the API being shut down (the sunset RFC) and the API being deprecated (the current draft). cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Sun Jan 10 08:27:21 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 D401F3A114D for ; Sun, 10 Jan 2021 08:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 BPKxX6F9XrFQ for ; Sun, 10 Jan 2021 08:27:11 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640135.outbound.protection.outlook.com [40.107.64.135]) (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 090113A1146 for ; Sun, 10 Jan 2021 08:27:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=URvyt9NbCb7zoe3cI4wbtofb6a8nkHYxUOrtSc7ZfBTD8J6CKDktRmbtR28KcwWPHIV3AyOhwLeTpx+MZiluyizI2DbcKvEWvvLccLnN7LMpS7xUsvIZSmScLwl5Y1ayg6vjwMJ12RypPtTW7x7duRg1qezIzAQvFSNKSI9QhU3+BFxQfDP9ifx2l+r5I+FDyomw72Oo0jxRrbtv5uJtsTFrYqy7/NqycywpkgFieaZjT7zcC4bB9kt3mbrMnHGsXTrzdwx1/yylfyoiKxXxGTxRnRlWIA/vsAJyes4uTFkLmMiWBzhK27PLzQPjatXdLlPgVSNV750UVbmg6RENCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G1TAuc4F1HdOzWZl3kgRdYKQzB5NvcwnTDsvU2zSlPs=; b=au/wA2jnpubKTmA32aiAIt3q/CLMHehfIB98Wn/Eljn+SwasO9M8FeKzohG1izTZyVsPMn9djomTXGwweuSM3kmVnNRasvMNghdCCsQ2Xs/m6/h9Vdlq2TQuG6/3yXWZx3viPZzlfKQva0fze/cSgN/CreJT/yJD8++kxvX3nh5cLC2FGrRxAKCrShAN4cspZhweDra2bYE8hUc31evMHYvsVM74O5N+VkaUuDDcuji4XRrlUKBvz9rOS804Q5vXdNL6IwVHZ2bqtIFv0IiBgAJTfmVo0VR7//VqI2uacBNngZGnRSoK/HQ/A3EL7w/8MNUBAn8BjufLa2VnVWG+6g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G1TAuc4F1HdOzWZl3kgRdYKQzB5NvcwnTDsvU2zSlPs=; b=KOmPdwQQ6deGu9Vg4n4MtU26s3VqN7ONkCh5CJVgvEy5Vf8WL6psV1rEzpRJSvdFmLnN5wuTsWmm3pZoJiple+KZmzLzqYJWwVwDhYzJD3Dw8XY2MQZlr48qX6dv5J0TC3jBDBwZ4atFWHYpjzf9kfK4kx2jP8xJlBIgnZURq/0= Received: from (2603:10b6:5:1bf::13) by DM6PR00MB0751.namprd00.prod.outlook.com (2603:10b6:5:1be::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3787.0; Sun, 10 Jan 2021 16:27:02 +0000 Received: from DM6PR00MB0848.namprd00.prod.outlook.com ([fe80::7139:b869:d380:4aa]) by DM6PR00MB0848.namprd00.prod.outlook.com ([fe80::7139:b869:d380:4aa%5]) with mapi id 15.20.3794.000; Sun, 10 Jan 2021 16:27:02 +0000 From: Darrel Miller To: "amr@redhat.com" CC: "darrel@tavis.ca" , "httpapi@ietf.org" , "robipolli@gmail.com" Thread-Topic: [httpapi] RateLimit Header client implementations Thread-Index: AQHW3lKxGhpPRJVD8kOy66GCWE4TNKoXg/eAgAGy0sqAAsSsAIAFIO02 Date: Sun, 10 Jan 2021 16:27:02 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-01-10T16:27:03.823Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [74.15.147.35] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 43864086-00f5-473f-dce5-08d8b5848f8a x-ms-traffictypediagnostic: DM6PR00MB0751: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RCjpvfcxXVaR8zOni4qN+aQ3TtYEbLDMulraQFTcKmQKuUJRHNUcMXgG2EETp7Fm5ZU804q5GddGakNNED2rpUQfkhV70gUAKJdWFaFtd0PYM1rP8oM0lshp6dBhyuqe3klQ5GrvGZkamGVUt7VOZETmJWqgPT2CPkX1X2N7HgrEoWOepF+qN9BGaJXawD1xZs7qkLd0av9uXYozRqAT640PFsZxDqWvnXCvrX38NgsVLyA4ULtaqt98n+w1dWdOcKPqGqEufI9z3P0OMmhsOFfUge2/WcYJtm5JOcpN0Cqta2wuTXiFutQreaR+ZiEoChKlypvQzSxexWBSr6T0/y7Xm3JfWS4oG+gWJvTHvwxjRQ0iGuobcZJsYZSdmVRIDXNPzGe5KY7VC2kaXdMsYQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0848.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(39860400002)(136003)(396003)(346002)(66446008)(83380400001)(66556008)(8676002)(8936002)(19627405001)(66476007)(54906003)(7696005)(76116006)(9686003)(66946007)(186003)(82960400001)(82950400001)(8990500004)(5660300002)(55016002)(33656002)(478600001)(6506007)(26005)(2906002)(71200400001)(10290500003)(6916009)(4326008)(52536014)(86362001)(316002)(64756008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?B256TtT3+j2nIsrHuDEect9YvgyR7DwAPQnswFtcEDNqfXtw4xlyZCrc/N?= =?iso-8859-1?Q?IGkQq3wNUhT3CUMTc4yRSnxVwE/sIEIXMPa2fwkAxRri2q9X9yL70nYWhu?= =?iso-8859-1?Q?ELd6c1/RSEc183TwsA4YOzEdeykTawAAabXPyRJ9QpsjT2kkr+qdH8PGAd?= =?iso-8859-1?Q?LS9OyygwAbom2cSMu5DF7FOzLIOeKZTqcmOnGdeq8w+n+BDogtsdM3ZfRp?= =?iso-8859-1?Q?YpCgsAqThtnx/pPfZZ6HZD6BNvmfIbU4ze4pDA0U36THijp0WMdLkJJDdq?= =?iso-8859-1?Q?kAcvm/WM87efiL5RGyDxmfVuxNLqZ7ybmefdaZ91kR2X70yTKjNmkYvdzc?= =?iso-8859-1?Q?WjYxRttE4phwqPmN1881fdZYygYUj29ctvGhCD+BtVq0zhRdQA0dQ2n+eX?= =?iso-8859-1?Q?PKNJ6/O/p72ChkCwnyPGJ7OeEnFcsQhI/2LDK8R2RHnGsPmgEIndyjd2aP?= =?iso-8859-1?Q?Bl6DzzVw3lge046+uw2kNjedP5nkg2aooOhWUXH2hxYQHS/04IB+DP3KBz?= =?iso-8859-1?Q?6q32WGT8EqzWthbwVfXvJrCPCZzo2Ipi7RhEZ+R7DVBeDKQ5Qd5NmdhK5N?= =?iso-8859-1?Q?aQ1pylj7X78Td0PXmUJUbQg0cLsskfIt/bKxy84WWVbkH50RGYq8Ll74nv?= =?iso-8859-1?Q?lpmciw1d2YXgH2optvKKNeOuL4qDkTbRJyn8/q3adzJZCspQZcbIc8Eus4?= =?iso-8859-1?Q?avwVVbyCHcItUdko++tFe50/KmDJ8SGEbAtntarxwmPpoAMx2Rq4XrlsR8?= =?iso-8859-1?Q?zvw/IA9UmMuO8ZBZlpTbSf+UQ+XYgus4lw0J/9pk/kB5Csk8XPeFd6xP55?= =?iso-8859-1?Q?ru9q42z+AqW5hijZEj6rtEa6rZff0TQxd0fkrXRIIoZrDDSlZ/OGbMjkzp?= =?iso-8859-1?Q?sKTpW8tFT+8Kkwv+7os+D8GHL9UuGqeAoQfBuBdwYMREm2ffA2kxudy09W?= =?iso-8859-1?Q?VkpgvJpcRBrnTG/CkE1OH85VFRDkvzpJN5jv52JPCsY5A+8+RT+dN2zo90?= =?iso-8859-1?Q?YrxndntNFKQMrYVNg+x95QK6ASMgz6jaP3HSIxDQXaHZZeUsLJIUYWlp9j?= =?iso-8859-1?Q?VLAPc1Tn6SyRXgtzqq80Ei0=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0848E28FDF172BCC02F718E6F0AC9DM6PR00MB0848namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0848.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 43864086-00f5-473f-dce5-08d8b5848f8a X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2021 16:27:02.0532 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: W4uD4eVbZedXLMR92JmiRfKQiJX2cm0rmDNmt4QIZS0509v8yvWS5kU10UWhLCLPQ9N+NOxWYKI+9G/buhYYwA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0751 Archived-At: Subject: Re: [httpapi] RateLimit Header client implementations 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: Sun, 10 Jan 2021 16:27:20 -0000 --_000_DM6PR00MB0848E28FDF172BCC02F718E6F0AC9DM6PR00MB0848namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alex, Thanks for the additional context. You are right, the immediate effect is the same. That said, you would be la= cking some extra information about the nominal quota units and duration of = the current window and the windows applying after this one is elapsed (ie. = after recovery you'd have information about the expected rates, and those c= ould also signal some sort of punitive policy), though that information mig= ht be next to useless in the current window since the intended effect is to= stop traffic altogether for a while. Yet it would not work in a closely re= lated scenario in which you would have some partial maintenance work but ke= eping the ability to serve clients in a degraded service manner -- that is,= unless you kept giving clients shorter no-service windows interleaved with= service responses as usual, hence generating a lot more wasteful traffic. Would be useful to clarify that these additional headers are intended to su= pport scenarios where rate limiting constraints applied by a service are dy= namic over time? Yes, I believe that because there is no standardization there's been littl= e to no effort in writing such adaptive code in generic HTTP clients, but t= his is pure speculation. I think it is very likely that most people doing s= o are the ones writing service specific clients, and in many cases they cou= ld be the same people that wrote the service in the first place, unless the= service happens to see lots of usage across the board with many independen= t clients. I look forward to seeing some feedback from implementers on the value deriv= ed from generic client code that handles these headers. Darrel --_000_DM6PR00MB0848E28FDF172BCC02F718E6F0AC9DM6PR00MB0848namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Alex,

Thanks for the additional context.
You are right, the immediate effect is the same. That said, you would be lacking some extra information about the nom= inal quota units and duration of the current window and the windows applyin= g after this one is elapsed (ie. after recovery you'd have information abou= t the expected rates, and those could also signal some sort of punitive policy), though that information m= ight be next to useless in the current window since the intended effect is = to stop traffic altogether for a while. Yet it would not work in a closely = related scenario in which you would have some partial maintenance work but keeping the ability to serve client= s in a degraded service manner -- that is, unless you kept giving clients s= horter no-service windows interleaved with service responses as usual, henc= e generating a lot more wasteful traffic.
Would be useful to clarify that these additional he= aders are intended to support scenarios where rate limiting constraints app= lied by a service are dynamic over time?
 Yes, I believe that becau= se there is no standardization there's been little to no effort in writing such adaptive code in generic HTTP clients, but th= is is pure speculation. I think it is very likely that most people doing so= are the ones writing service specific clients, and in many cases they coul= d be the same people that wrote the service in the first place, unless the service happens to see lots of = usage across the board with many independent clients. 
I look forward to seeing = some feedback from implementers on the value derived from generic client code that handles these headers.=

Darrel

--_000_DM6PR00MB0848E28FDF172BCC02F718E6F0AC9DM6PR00MB0848namp_-- From andre.cedik@googlemail.com Mon Jan 11 04:21:51 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 E3C853A03F5 for ; Mon, 11 Jan 2021 04:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=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=googlemail.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 91RjPjng3wit for ; Mon, 11 Jan 2021 04:21:49 -0800 (PST) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 1EA623A03FC for ; Mon, 11 Jan 2021 04:21:49 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id m5so16184850wrx.9 for ; Mon, 11 Jan 2021 04:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Tiww6a3W9TMmwMZvpE/UCwPP1kpV3wdp7Na98+okfiQ=; b=MedZGdGjc/oFgHX3rtvL7HaJw79idYuEjKR+5w/+mVNTtkMY0F817b2UygXDBaLqmf dvRN+4oJG3OlmaxYe8BAJQlgLljUMoTk5AAJIuw+UvYm/4dZvc3A8tJ8YW577sNvzWsA +WjZPDNwluIAhWd3H5vA887PqpVgW1IMt2I8xObHH25JYPyrrtyg4bzmh5/Xibj6rFYH KiAhtcVgAXBDr+j+TothdiOBXVmuxW/GnmKEAGI3aQPmRqGyK/tSpZFNM+ePn3UsOn5x txcVDfDUNKVlk46R2OySmKJL2v9CAsgdZLrAGcnh3fFS7TT/3om5XKIilpoAZtIZRdZq npuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Tiww6a3W9TMmwMZvpE/UCwPP1kpV3wdp7Na98+okfiQ=; b=BofcuG72YEBrn+LsqqlXXoJqzatsFF8EDVEdwgfwLwN01Dq0g3GZ+FoWUt4VA0WPFD i7Ily4V05vqwgZWBnTe2h4Ye/ucmSkvKxUinyx11vB2AcotktIwCBlRMZTrMrnYIoa73 7rwNmwsxUek+VZewrHxwlkdLiscih7uXTq9og8T2aidA2HCWxev6PhvKzHNO3wYvHNra /15nZSJnGvQEVqWLy9eJyhAmqoYQPBBej1BBvITrN37tdvAPga+UdNKxt4f1m9kgaNgs K6kWet3pTeavqFC9CD6u9s3+EtDlRNUVvhXqsTjwm7h7GRBl54HJZusN/AloPML73bqu lElg== X-Gm-Message-State: AOAM5312WijS8/q6tkFzB4hTTFrsUE0WkipMUwX+OzH/BCA8C6WTglba aJK22AjGF/B7/MnRHx46DErKNngbtkR7/5bxqTg+VMiD4cDNLg== X-Google-Smtp-Source: ABdhPJzOdZoCxmNE/hYjrnAj+tFy/SfHf4fas8QKiNb2DyxwCgRTelHeLuOIzJXAJ7mL7i4jUZvOI07DbbEDEJVlhCo= X-Received: by 2002:adf:92a4:: with SMTP id 33mr15825103wrn.347.1610367707257; Mon, 11 Jan 2021 04:21:47 -0800 (PST) MIME-Version: 1.0 References: <88ED49DB-E081-4C97-9FB9-080A1C585435@akamai.com> <80acc592-be10-533d-d6ba-e39ea78ef8de@dret.net> In-Reply-To: From: =?UTF-8?B?QW5kcsOpIENlZGlr?= Date: Mon, 11 Jan 2021 13:21:36 +0100 Message-ID: To: "httpapi@ietf.org" Content-Type: multipart/alternative; boundary="00000000000026206305b89ef37d" Archived-At: Subject: Re: [httpapi] Discussion of adopting Content-Warning header 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, 11 Jan 2021 12:30:40 -0000 --00000000000026206305b89ef37d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey everyone and a happy new year, I'd like to take the opportunity (since it is the first day back at work for me) to get the ball rolling again. Interestingly my first message in December seems to not have made it to the list. At least that's what I get from the archive, where it is missing. So I've added it to the end just for reference since the discussion has already been going further. Back to Darrel's question/suggestion. I have certainly run into scenarios where there is value in returning > warnings with a response and I've see the Warnings header from RFC 7234 > used in several cases. However, the Warning header includes the Warn-Cod= e > to provide some details about the reason for the warning. One advantage = of > using the Warning header was the fact that the warnings did not need to > affect the structure of the payload. > Would you consider a change to this draft that enabled representing > details of the warning in the header itself? Do you already have anything specific in mind? Maybe even an example when warnings were returned using the Warnings header? It would definitely make sense to have some kind of "code" to be returned when a warning is present, but I am not sure if the use cases for different APIs might be too specific to be handled by an overarching code. Hence every API might need different codes for what they are trying to convey. The advantage of returning the warnings in the body would be that more specific information could be returned than trying to squeeze it into the header. Roberto is right. It would be possible to add more specific things using the Content-Warning Type Registry --- Original message: > Thank you Rich for bringing this up again. > I was planning on writing to the list about the draft, but haven't found > the time yet. So it's great that you put some pressure on us. > Let me try to answer two of the questions that came up during the IETF 10= 9 > meeting. > Is this just for JSON documents? > Absolutely not! > It is the goal of the header to signal to a client that warnings are > being returned. > The value "embedded-warning" is merely one idea of telling this client, > that more information can be found in the body. > One could return a different content type than "application/json" and > embed the warnings in there. > The example shown in section 6 ( > https://tools.ietf.org/html/draft-cedik-http-warning-02#section-6) is > just there so we have a proposition of how this could be returned. > Ideally, we'd have a common way of returning warnings. Independent of wha= t > the content type is. But I'm not sure if this is possible. > Can we mix errors and warnings? > If you have a look at the initial proposal - which was based on the > warning header - we've had an example with errors and warnings. > https://tools.ietf.org/html/draft-cedik-http-warning-00#section-5.2 > I can definitely see that there is a use case for having both at the same > time since a warning could have occurred before the actual error came to > be. So in this case returning the warning and the error could be helpful > for a client. > If you have further questions just let me know. Best Andr=C3=A9 On Tue, Dec 15, 2020 at 4:32 PM Roberto Polli wrote: > Hi @all, > > > Il giorno mar 15 dic 2020 alle ore 06:00 Darrel Miller > ha scritto: > > > if > > > there isn't enough interest, an alternative path may be to keep > > > developing it as an individual draft > I think this draft will benefit from a wider discussion, including the > considerations provided by Darrell. > > > [..] I've see the Warnings header from RFC 7234 used in several cases. > > [..] One advantage of using the Warning header was the fact that the > warnings did not need to affect the structure of the payload. > > Would you consider a change to this draft that enabled representing > details of the warning in the header itself? > iiuc this behavior can be configured via the content-warning-type: the > payload one is "embedded-warning", > so the field definition already has an extension mechanism capable of > supporting further types, eg "expensive-request" or "old-api-version" > or whatever. > > I think this kind of discussions are the kind of activity of the workgrou= p. > > Have a nice day, > R. > > -- > httpapi mailing list > httpapi@ietf.org > https://www.ietf.org/mailman/listinfo/httpapi > --00000000000026206305b89ef37d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey everyone and a happy new year,

I'd like to take the opportunit= y (since it is the first day back at work for me) to get the ball rolling a= gain.

Interestingly my first message in December s= eems to not have made it to the list. At least that's what I get from t= he archive, where=C2=A0it is missing.=C2=A0
So I've added it = to the end just for reference since the discussion has already been going f= urther.

Back to Darrel's question/suggestion.<= /div>

= I have certainly run into scenarios where there is value in returning warni= ngs with a response and I've see the Warnings header from RFC 7234 used= in several cases.=C2=A0 However, the Warning header includes the Warn-Code= to provide some details about the reason for the warning.=C2=A0 One advant= age of using the Warning header was the fact that the warnings did not need= to affect the structure of the payload.
Would you consider a change to = this draft that enabled representing details of the warning in the header i= tself?

Do you already have anything specifi= c in mind? Maybe even an example when warnings were returned using the Warn= ings header?
It would definitely make sense to have some kind of = "code" to be returned when a warning is present, but I am not sur= e if the use cases for different APIs might be too specific to be handled b= y an=C2=A0overarching code. Hence every API might need different codes for = what they are trying to convey. The advantage of returning the warnings in = the body would be that more specific information could be returned than try= ing to squeeze it into the header.

Roberto is righ= t. It would be possible to add more specific things using the=C2=A0Content-= Warning Type Registry

---=C2=A0

Original message:
Thank you Rich for bringing this up again.=C2=A0
I was planning=C2= =A0on writing to the list about the draft, but haven't found the time y= et. So it's great that you put some pressure on us.
Let me try to an= swer two of the questions that came up during the IETF 109 meeting.
=C2=A0
Is this just for JSON = documents?
Absolutely not!=C2=A0
It is the goal of the=C2=A0header=C2=A0to signal to a client that warnings are = being returned.=C2=A0
The value "embedded-= warning" is merely one idea of telling this client, that more i= nformation can be found in the body.
One could return a different=C2=A0<= span class=3D"gmail-il">content=C2=A0type than "application/jso= n" and embed the warnings in there.
The example shown in section 6 = (https://tools.ietf.org/html/draft-cedik-http-warning-02#section-6) is just there so we have = a proposition of how this could be returned.=C2=A0
Ideally, we'd hav= e a common way of returning warnings. Independent of what the=C2=A0content=C2=A0type is. But I'm not sure if this = is possible.
=C2=A0
Ca= n we mix errors and warnings?
If you have a look at the initial proposal= - which was based on the=C2=A0warning=C2= =A0header=C2=A0- we've had an example w= ith errors and warnings.=C2=A0
https://tools.ietf= .org/html/draft-cedik-http-warning-00#secti= on-5.2
I can definitely see that there is a use case for having both= at the same time since a=C2=A0warning=C2= =A0could have occurred before the actual error came to be. So in this case = returning the=C2=A0warning=C2=A0and the err= or could be helpful for a client.
If you have further questions just let= me know.

Best=C2=A0
Andr= =C3=A9


On Tue, Dec 15, 2020 at 4:32 PM Roberto Polli &l= t;robipolli@gmail.com> wrote:=
Hi @all,


Il giorno mar 15 dic 2020 alle ore 06:00 Darrel Miller
<Darrel.Miller=3D40microsoft.com@dmarc.ietf.org> ha scritto:
> > if
> > there isn't enough interest, an alternative path may be to ke= ep
> > developing it as an individual draft
I think this draft will benefit from a wider discussion, including the
considerations provided by Darrell.

> [..] I've see the Warnings header from RFC 7234 used in several ca= ses.
> [..] One advantage of using the Warning header was the fact that the w= arnings did not need to affect the structure of the payload.
> Would you consider a change to this draft that enabled representing de= tails of the warning in the header itself?
iiuc this behavior can be configured via the content-warning-type: the
payload one is=C2=A0 "embedded-warning",
so the field definition already has an extension mechanism capable of
supporting further types, eg "expensive-request" or "old-api= -version"
or whatever.

I think this kind of discussions are the kind of activity of the workgroup.=

Have a nice day,
R.

--
httpapi mailing list
httpapi@ietf.org<= br> https://www.ietf.org/mailman/listinfo/httpapi
--00000000000026206305b89ef37d-- From nobody Wed Jan 13 09:47: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 68C5F3A0EBB for ; Wed, 13 Jan 2021 09:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.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 g4g1yRJ7ZlxH for ; Wed, 13 Jan 2021 09:47:00 -0800 (PST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 832BF3A1216 for ; Wed, 13 Jan 2021 09:47:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610560019; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=O/0/I3r2x0gomKbxxV9lPOgj8QTYSB/RZY4/gWSXYqk=; b=Kq7IbforAGjs/+xqKUoplg/n/h8G41VCPYuAvuBPl7mJdd+Td4F10xvawdn69aDU0HV1C/ peLYTouHh3gXcqp+mXbBAahTMPn7iaCi/GJ0p+toPnC6gC+j47r25KMVQKYwXHsZzn522m JkPflKlcUwKxU3JT59Gp/LBiBEAnAUg= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-393-xUHJue2kN_uKvusFnTUmKQ-1; Wed, 13 Jan 2021 12:46:57 -0500 X-MC-Unique: xUHJue2kN_uKvusFnTUmKQ-1 Received: by mail-qt1-f198.google.com with SMTP id 22so1957724qty.14 for ; Wed, 13 Jan 2021 09:46:57 -0800 (PST) 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=O/0/I3r2x0gomKbxxV9lPOgj8QTYSB/RZY4/gWSXYqk=; b=cUcTiPf7LjBzJ6ybuqHsPu19cAxmsNWUlemjc8G1UQ1kUVkIr9txe6qqqNN7kV+/AV HMnq7BkRrUaHCxtvGBRX36Z1ICBtel+ghXkn6Z+96cMz1OrRDRJEXbYwbjiDQfe5YVeC n/bCL87efsCD9qp92gtjjqfpDhSv+5Ffig1Es7dZfpLqP2OQFyy917PWMqfZ4AgvTcpJ 6w5mYo+HB+viXDnxCEnFO/0A1FRvO1NGuVHEQdLDHiFnQZoN6C3B1MpeZaKPOKRAfdJJ lsAkNyNHYm7BfZelpDVAZPxwZmG+GIDzAmrzcxtal/V2/BdEpC7C+P70KB7RSO3zll40 o+jg== X-Gm-Message-State: AOAM531II7pAxY6Y/O4PTyW9vx3t6yRzKYjiFOV7ggbYnbGBvOrXxUy+ lcUM3kvQgQbJOI5tEWKn0FXu5jnHPWglUWeaZY1Ko7EZyVYAFvoGZ1HxkOFGl+UAtLmevmpwYgm Mt6TVwTEjACl2VMAh7TXJNUYL X-Received: by 2002:a25:a029:: with SMTP id x38mr5063133ybh.105.1610560016568; Wed, 13 Jan 2021 09:46:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJxctXGDj82+yn5AWqD8zEKUMeL3uKmDOpXJ7+5LHBezy1BZauWfVXgYBUT32hSLpbaBXoNGaRBuZFCDd+hOhB4= X-Received: by 2002:a25:a029:: with SMTP id x38mr5063099ybh.105.1610560016323; Wed, 13 Jan 2021 09:46:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alex Martinez Date: Wed, 13 Jan 2021 17:46:45 +0000 Message-ID: To: Darrel Miller Cc: "darrel@tavis.ca" , "httpapi@ietf.org" , "robipolli@gmail.com" Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=amartine@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="000000000000a9b62e05b8cbb91a" Archived-At: Subject: Re: [httpapi] RateLimit Header client implementations 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, 13 Jan 2021 17:47:02 -0000 --000000000000a9b62e05b8cbb91a Content-Type: text/plain; charset="UTF-8" Hi Darrel, On Sun, Jan 10, 2021 at 4:27 PM Darrel Miller wrote: > Alex, > > Thanks for the additional context. > > You are right, the immediate effect is the same. That said, you would be > lacking some extra information about the nominal quota units and duration > of the current window and the windows applying after this one is elapsed > (ie. after recovery you'd have information about the expected rates, and > those could also signal some sort of punitive policy), though that > information might be next to useless in the current window since the > intended effect is to stop traffic altogether for a while. Yet it would not > work in a closely related scenario in which you would have some partial > maintenance work but keeping the ability to serve clients in a degraded > service manner -- that is, unless you kept giving clients shorter > no-service windows interleaved with service responses as usual, hence > generating a lot more wasteful traffic. > > Would be useful to clarify that these additional headers are intended to > support scenarios where rate limiting constraints applied by a service are > dynamic over time? > Sure, we can look into clarifying this - perhaps my own reading of the document makes this obvious to me having worked on rate limiting stuff for some time. > Yes, I believe that because there is no standardization there's been > little to no effort in writing such adaptive code in generic HTTP clients, > but this is pure speculation. I think it is very likely that most people > doing so are the ones writing service specific clients, and in many cases > they could be the same people that wrote the service in the first place, > unless the service happens to see lots of usage across the board with many > independent clients. > > I look forward to seeing some feedback from implementers on the value > derived from generic client code that handles these headers. > Understandably these don't exist yet - the easy thing to do is implementing support for these in servers that do some sort of rate limiting or integrate with a component that does, and that's why most (all?) of the implementations we know of are server code. I also look forward to the possibilities in clients, and it would be great to have basic support in the most commonly used HTTP client libraries, but admittedly the implementation work is not trivial. I don't really know whether such projects would go for an I-D even if it's already on the standards track, but we can certainly ask! Cheers, Alex > --000000000000a9b62e05b8cbb91a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Darrel,

On Sun, Jan 10, 2021 at 4:2= 7 PM Darrel Miller <Darre= l.Miller@microsoft.com> wrote:
Alex,

Thanks for the additional context.
You are right, the immediate effect is the same. That said, you would be lacking some extra information about the nom= inal quota units and duration of the current window and the windows applyin= g after this one is elapsed (ie. after recovery you'd have information = about the expected rates, and those could also signal some sort of punitive policy), though that information m= ight be next to useless in the current window since the intended effect is = to stop traffic altogether for a while. Yet it would not work in a closely = related scenario in which you would have some partial maintenance work but keeping the ability to serve client= s in a degraded service manner -- that is, unless you kept giving clients s= horter no-service windows interleaved with service responses as usual, henc= e generating a lot more wasteful traffic.
Would be useful to clarify that these additional headers ar= e intended to support scenarios where rate limiting constraints applied by = a service are dynamic over time?

Sure, we can look into clarifying this - perhaps my own reading of= the document makes this obvious to me having worked on rate limiting stuff= for some time.
=C2=A0Yes, I believe that because there is no standa= rdization there's been little to no effort in writing such adaptive code in generic HTTP clients, but th= is is pure speculation. I think it is very likely that most people doing so= are the ones writing service specific clients, and in many cases they coul= d be the same people that wrote the service in the first place, unless the service happens to see lots of = usage across the board with many independent clients.=C2=A0
I look forward to seeing some feedback from im= plementers on the value derived from generic client code that handles these headers.=

Understandably these do= n't exist yet - the easy thing to do is implementing support for these = in servers that do some sort of rate limiting or integrate with a component= that does, and that's why most (all?) of the implementations we know o= f are server code. I also look forward to the possibilities in clients, and= it would be great to have basic support in the most commonly used HTTP cli= ent libraries, but admittedly the implementation work is not trivial. I don= 't really know whether such projects would go for an I-D even if it'= ;s already on the standards track, but we can certainly ask!

=
Cheers,
=C2=A0 Alex
--000000000000a9b62e05b8cbb91a-- From nobody Thu Jan 14 10:21:02 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 9569B3A1232 for ; Thu, 14 Jan 2021 10:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=gmx.net 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 su5toannbY0k for ; Thu, 14 Jan 2021 10:20:59 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 50F003A129D for ; Thu, 14 Jan 2021 10:20:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1610648454; bh=DPoCSV0y8nRSXLUDJssFyw4Uw0rtDv5j4svpSuF8PrQ=; h=X-UI-Sender-Class:Subject:References:To:From:Date:In-Reply-To; b=esD/jJzGPdZ7fb09OYcfIYoNP9OgPrQ6gcYknTt534m+MKLnD6t9cgycxM6Xg+hQ5 trrGhEVQ7YIBZ66gkhDgFVfnNHqnuk2NWC0XL74BZRVilABCOHa4Ne5Yeq7qgT56bI tq9YJHsn7yTcUirKYPWI2I/GY+2huV4y0g8X8wNU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.20] ([91.61.54.166]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MvbFs-1lsUm82Rh0-00scKc for ; Thu, 14 Jan 2021 19:20:54 +0100 References: <85B2C1D6-28D6-4988-9B91-068D3039BB8C@apple.com> To: httpapi@ietf.org From: Julian Reschke X-Forwarded-Message-Id: <85B2C1D6-28D6-4988-9B91-068D3039BB8C@apple.com> Message-ID: <0e301d86-ea7a-6634-cd0f-71b92d374202@gmx.de> Date: Thu, 14 Jan 2021 19:20:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <85B2C1D6-28D6-4988-9B91-068D3039BB8C@apple.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:Ivh2YfZXp7bRDFAmtoo4piT8h2ZrAM6NWjhkfXZIwW1ftTRI8bc HLjupXn1YJroPhxqy9EfuEmE6RPj+jv2P+z4p3CmPQZ4q8EqiXr2VgtgTMl2/nJLknNyPbY iquOW7pRyg4xT0PjEOylWc/Zw+28Y14LfaBSeOlWPeDFWYw90/kb3/VFzfIUKUt9k8WjJFh 3yXzttGBbKAdE5AYiKh5w== X-UI-Out-Filterresults: notjunk:1;V03:K0:wvHiYbtEnz4=:bgnC5AW2PxCbNwgVk5CwnA idepylmEMBEadh7uHuB9AXQ3guKUHS69Q6rTL85UO8wTw37TVN+AdY7b1Ulg9Eyo20pZKQfdq MXe9H38wPwQZ+Iuz3p4cprfb7NPSn1a8F4lYc6cxndJPiuAQ1kbdhwsA4pLseE5YgsRxbUu+d LCoMyJE09v3occVwYGk2fbi/tDnioZgMYGvLuddDspLIEYsWv7z+PTlkC/GJ/mrV/8VDYak83 qFIwPUjqiZFi7x+NJ0jImHnHxEKileV2S1hTuSMzGrODHEPjWShuVIPMBqJJbawH2iuWMcgfi Gfxeend7QHwNEonM8oNEwLVuuOVqGaH2CTYxHuNDo1Uikh4hUEfIe63gVMdt4CyC58yc6CXEs f5nyp9NtRn3qkSFKuAVL73d46lngbl3ppt2F+3yfAmcYeQUOapOD4aEbNh1Hp0GU9VhRsxOz6 OO1XG8KETIbHeLT03RV2mO+dxnwWcx45l4D5KFPIEuQII/ne7JXHmWukbmq5m+q1t8rbCln1G 62d/Ms6OcKlTogrQhkGhdA0+SLlzhQ47GNroMV20CPbdlTvliol5Ga3VccHZbG3Kl95qo01uY cuUp5LqWL1ZR0XleVIKcHfOOoOX0CtkNPtjA9vDfhGa5DQ9lhRaTuPuEGhPR6E9kX31Aa1jHs 4r2f89yBmQnRXY++hpCsJKaGFCIqzJ2nae8tpWL/n8yVOQqJcHl+Pk7VcMU+hqWoHE7u4Eh4n gHi9aWv6T3kcG2JfcChkw4iCuZ+h9213focjTvi5gCyf++VBeKp3hkqC4K5i29X0vkTiuTbSV BN9xxNmWcih+lnj05tnRQQzUXs9jZiHojQwId1j8PdayMnf+6JwkYbAXo5VnrBvNiHFyLgVgI jQFCkbF+3ZzsfU/tk0Hw== Archived-At: Subject: [httpapi] Fwd: Working Group Last Call: HTTP Core Documents 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, 14 Jan 2021 18:21:02 -0000 (FYI) =2D------- Weitergeleitete Nachricht -------- Betreff: Working Group Last Call: HTTP Core Documents Weitersenden-Datum: Thu, 14 Jan 2021 17:49:41 +0000 Weitersenden-Von: ietf-http-wg@w3.org Datum: Thu, 14 Jan 2021 09:49:22 -0800 Von: Tommy Pauly An: HTTP Working Group Hello HTTP WG, The time has come to start our Working Group Last Call for our current =E2=80=9Ccore=E2=80=9D documents! The issues list for these documents has = been whittled down and we=E2=80=99re ready to have the working group review them in dept= h in preparation to progress them towards publication. These are substantial drafts, so your time in reviewing is very much appreciated. We'll plan to have a three-and-a-half-week last call, so that we will get feedback prior to our planned interim dates. The last call will end on *Monday, February 8, 2021*. The three drafts to review are: HTTP Semantics,=C2=A0draft-ietf-httpbis-semantics https://www.ietf.org/archive/id/draft-ietf-httpbis-semantics-14.html HTTP/1.1,=C2=A0draft-ietf-httpbis-messaging https://www.ietf.org/archive/id/draft-ietf-httpbis-messaging-14.html HTTP Caching,=C2=A0draft-ietf-httpbis-cache https://www.ietf.org/archive/id/draft-ietf-httpbis-cache-14.html Please send email to the working group list with comments and feedback, and state if you think these documents are ready to progress. You can also file issues here: https://github.com/httpwg/http-core/issues . Many thanks to Julian, Mark, and Roy for their hard work on editing these documents! Best, Tommy From nobody Thu Jan 14 10:58:42 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 BD8453A12A0 for ; Thu, 14 Jan 2021 10:58:39 -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=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 6IfGOeC5tp-f for ; Thu, 14 Jan 2021 10:58:38 -0800 (PST) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 24B423A1295 for ; Thu, 14 Jan 2021 10:58:38 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id r5so6846657eda.12 for ; Thu, 14 Jan 2021 10:58:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=P8sv6JZ4f5CeTXHiBxZaU5AzyNqy1cO0POixxVxJnvg=; b=F1P7ftQBhvzAN/n9hBXfLHdFSFPMOi+G6EqbMqy0eQl6r/FAiJvPc2OKX6XICka4m0 O0ABUarTdN+mHhiEx4+oDRGwhcUcEWZJOASnYt9p+MHpEfGTcsrRcdJ06lX589cKEZvK kqVNYwb3Fp1y7oam19osehKryxRfl1qGL2X9GJoi4SVMiJvSTUf/obvqyGH/8oQpeC4m it0CtFEH42tyWTl7IgG1PKz9S2godSszz0MKHra6qZyJ9LKHoOi8Q7cdIX3t52HMROXf BGumUFUGR5lJobO9/oxkNIT3B5n6y84uudyi1XhMgFw8k57Esxkqj7aVuJxXL1I1/aV5 ioxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=P8sv6JZ4f5CeTXHiBxZaU5AzyNqy1cO0POixxVxJnvg=; b=loF9YpCJhE12nZK6/g9j+nNHjY9aNcKet1IOku5CLs5GcfISFE0uedLKcvx1oys+jM R2CYhIpAg9c8QOUd2kcFO37WsRcAbycJmea0ywFO05CjZTJTcudsffCSb9feYaL37lri d5xOm/AoHVuGzLoAqOSCxNvxuMnvRO3LZuISC9M0l3hASkA4pf0yD88mspp+AS6AvH/s 2se3/4xEYTVTvupzjiQB5PQbI3p5EdQUD81vgg94G2yojrXqEql68iw7+GgVs/T1WFyc ix4RBT/71fPoaFFDgNck+oyPtvPyzc3uQqIoJ+h0cGNJVEvRiMtEUcs/O5zcVHFFBPQE 9+aA== X-Gm-Message-State: AOAM531zpfx+vTI10wRlqJ9scV/SnwGOdFM+r1sBDebF3LB1lLzCbBUj 3OayTvQ0hb+FFMZNowiQjDo= X-Google-Smtp-Source: ABdhPJwFXS6vqJLMDpMssZ/Z9m3579i7YDWcl6g3CJ4EByhLIyze09G79VAzajjogy9rJ35x0Ob/wg== X-Received: by 2002:aa7:d803:: with SMTP id v3mr1234730edq.153.1610650716305; Thu, 14 Jan 2021 10:58:36 -0800 (PST) Received: from [192.168.178.26] (83-84-20-152.cable.dynamic.v4.ziggo.nl. [83.84.20.152]) by smtp.gmail.com with ESMTPSA id p22sm2303623ejx.59.2021.01.14.10.58.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Jan 2021 10:58:35 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Herbert Van de Sompel In-Reply-To: <886B7500-20BA-4990-864B-52533A0533A8@akamai.com> Date: Thu, 14 Jan 2021 19:58:34 +0100 Cc: httpapi@ietf.org Message-Id: <4F856D5C-657B-48B4-B469-0118CFB15895@gmail.com> References: <886B7500-20BA-4990-864B-52533A0533A8@akamai.com> To: "Salz, Rich" X-Mailer: iPad Mail (18B92) Archived-At: Subject: Re: [httpapi] The HTTPAPI WG has placed draft-wilde-linkset in state "Call For Adoption By WG Issued" 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, 14 Jan 2021 18:58:40 -0000 On Jan 6, 2021, at 04:47, Salz, Rich w= rote: >=20 > If you are opposed to the WG adopting this document, as it seems consensus= so far is in favor, please post before the end of the week. >=20 If I am interpreting Rich=E2=80=99s call and the resulting silence correctly= , I think it means that draft-wilde-linkset has been adopted by the WG. Much= appreciated! Forwards ... Greetings Herbert > =EF=BB=BFOn 1/5/21, 10:45 PM, "IETF Secretariat" wrote: >=20 >=20 > The HTTPAPI WG has placed draft-wilde-linkset in state > Call For Adoption By WG Issued (entered by Rich Salz) >=20 > The document is available at > https://datatracker.ietf.org/doc/draft-wilde-linkset/ >=20 > Comment: > Going via the DataTracker, to mark that this draft-wilde-linkset is now= in > the "call for adoption" state. >=20 >=20 > --=20 > httpapi mailing list > httpapi@ietf.org > https://www.ietf.org/mailman/listinfo/httpapi From nobody Thu Jan 14 11:44: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 8E2593A158A for ; Thu, 14 Jan 2021 11:44:36 -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, RCVD_IN_DNSWL_BLOCKED=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 mWRybA1MMfeB for ; Thu, 14 Jan 2021 11:44:33 -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 C13333A1579 for ; Thu, 14 Jan 2021 11:44:33 -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 10EJi27X008693; Thu, 14 Jan 2021 19:44:32 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=Yx07iE6dJtm9Dv5KF8i/CI5AKbJIx/RiJmRT/Rr2utE=; b=YxI9u3CWTU6+bvKiwWJlUgip8z/JxNfq1HLwm21rtL7zzHduLoAPApjiLviMAA1WiIJY 0B/E4Pe7GTlPs/EBrbqYEbBK+sfQqqDwKO1rsXs62xIJZzcsF9y+Ww6ThNRxKf22CXDw /M8b7NG6ZVTD8VnE3cOU8YVwraN0gqgcO8wEnYPi5fKZE0ViDWvGts4dowqZip8pHlBc sMumxBZ3RRaIM7yuf6VsPfTgpZywaWhBA4sx5ANsIGIuyKD/gfxFuKeIrMRjGl5K8j3I 5FVMiBLkxO4K0HKuKX9GFbIyEYA+AUbwZko8yAkvVvsJAr0ngjhwWEvhtg9RthV2xPkJ WA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 35y5hcnhhg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Jan 2021 19:44:32 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 10EJZ23E023639; Thu, 14 Jan 2021 14:44:30 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint2.akamai.com with ESMTP id 35y8q2bt8n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 14 Jan 2021 14:44:30 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 14 Jan 2021 14:44:29 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.010; Thu, 14 Jan 2021 14:44:29 -0500 From: "Salz, Rich" To: Herbert Van de Sompel CC: "httpapi@ietf.org" Thread-Topic: [httpapi] The HTTPAPI WG has placed draft-wilde-linkset in state "Call For Adoption By WG Issued" Thread-Index: AQHW495hSIrwHS5NQkC3bo9HyWL1LaoZ9XiAgA3lIAD//7kDgA== Date: Thu, 14 Jan 2021 19:44:29 +0000 Message-ID: <92E051A4-6CFF-423C-9912-99EDDEC06AB8@akamai.com> References: <886B7500-20BA-4990-864B-52533A0533A8@akamai.com> <4F856D5C-657B-48B4-B469-0118CFB15895@gmail.com> In-Reply-To: <4F856D5C-657B-48B4-B469-0118CFB15895@gmail.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: text/plain; charset="utf-8" Content-ID: <923CB3276B419C4BAE52219BB86D2D83@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-14_07:2021-01-14, 2021-01-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 mlxlogscore=999 malwarescore=0 spamscore=0 phishscore=0 bulkscore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101140111 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-14_07:2021-01-14, 2021-01-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0 phishscore=0 suspectscore=0 impostorscore=0 spamscore=0 lowpriorityscore=0 bulkscore=0 priorityscore=1501 mlxscore=0 malwarescore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101140113 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.19) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint2 Archived-At: Subject: Re: [httpapi] The HTTPAPI WG has placed draft-wilde-linkset in state "Call For Adoption By WG Issued" 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, 14 Jan 2021 19:44:37 -0000 PiAgICBJZiBJIGFtIGludGVycHJldGluZyBSaWNo4oCZcyBjYWxsIGFuZCB0aGUgcmVzdWx0aW5n IHNpbGVuY2UgY29ycmVjdGx5LCBJIHRoaW5rIGl0IG1lYW5zIHRoYXQgZHJhZnQtd2lsZGUtbGlu a3NldCBoYXMgYmVlbiBhZG9wdGVkIGJ5IHRoZSBXRy4gTXVjaCBhcHByZWNpYXRlZCENCg0KWWVz LCBJIHdhcyBraW5kIG9mIHdhaXRpbmcgdG8gc2VlIGlmIHRoZSBEYXRhdHJhY2tlciBzZW50IG1l IHJlbWluZGVycywgYnV0IEknbGwgc2V0IHVwIHRoZSByZXBvIHNob3J0bHkuDQogICAgRm9yd2Fy ZHMgLi4uDQoNCiAgICBHcmVldGluZ3MNCg0KICAgIEhlcmJlcnQNCg0KDQogICAgPiBPbiAxLzUv MjEsIDEwOjQ1IFBNLCAiSUVURiBTZWNyZXRhcmlhdCIgPGlldGYtc2VjcmV0YXJpYXQtcmVwbHlA aWV0Zi5vcmc+IHdyb3RlOg0KICAgID4gDQogICAgPiANCiAgICA+ICAgIFRoZSBIVFRQQVBJIFdH IGhhcyBwbGFjZWQgZHJhZnQtd2lsZGUtbGlua3NldCBpbiBzdGF0ZQ0KICAgID4gICAgQ2FsbCBG b3IgQWRvcHRpb24gQnkgV0cgSXNzdWVkIChlbnRlcmVkIGJ5IFJpY2ggU2FseikNCiAgICA+IA0K ICAgID4gICAgVGhlIGRvY3VtZW50IGlzIGF2YWlsYWJsZSBhdA0KICAgID4gICAgaHR0cHM6Ly91 cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXdpbGRlLWxpbmtzZXQvX187ISFHanZUel92ayFBWTBPUEpVY2R5R2hqRWZrdXBMTUJIUmhFQm5r YTBWR0VLV1Jlc3ZsdzlVN3pVR2JneHlaUUItOElRVWwkIA0KICAgID4gDQogICAgPiAgICBDb21t ZW50Og0KICAgID4gICAgR29pbmcgdmlhIHRoZSBEYXRhVHJhY2tlciwgdG8gbWFyayB0aGF0IHRo aXMgZHJhZnQtd2lsZGUtbGlua3NldCBpcyBub3cgaW4NCiAgICA+ICAgIHRoZSAiY2FsbCBmb3Ig YWRvcHRpb24iIHN0YXRlLg0KICAgID4gDQogICAgPiANCiAgICA+IC0tIA0KICAgID4gaHR0cGFw aSBtYWlsaW5nIGxpc3QNCiAgICA+IGh0dHBhcGlAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vdXJs ZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h0 dHBhcGlfXzshIUdqdlR6X3ZrIUFZME9QSlVjZHlHaGpFZmt1cExNQkhSaEVCbmthMFZHRUtXUmVz dmx3OVU3elVHYmd4eVpRSmM1Y3RVXyQgDQoNCg== From nobody Thu Jan 14 15:10:47 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 E338C3A03F3 for ; Thu, 14 Jan 2021 15:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-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 unJ9qMjjVhj9 for ; Thu, 14 Jan 2021 15:10:44 -0800 (PST) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (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 4D1673A03EB for ; Thu, 14 Jan 2021 15:10:44 -0800 (PST) Received: from [108.205.51.24] (port=50399 helo=dretpro.attlocal.net) by postoffice.gristmillmedia.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1l0BlK-0005aW-BG; Thu, 14 Jan 2021 18:10:42 -0500 To: "Salz, Rich" , Herbert Van de Sompel Cc: "httpapi@ietf.org" References: <886B7500-20BA-4990-864B-52533A0533A8@akamai.com> <4F856D5C-657B-48B4-B469-0118CFB15895@gmail.com> <92E051A4-6CFF-423C-9912-99EDDEC06AB8@akamai.com> From: Erik Wilde Message-ID: <1bb3b823-d28f-ec30-6ed9-cd311d643d07@dret.net> Date: Thu, 14 Jan 2021 15:10:38 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <92E051A4-6CFF-423C-9912-99EDDEC06AB8@akamai.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [httpapi] The HTTPAPI WG has placed draft-wilde-linkset in state "Call For Adoption By WG Issued" 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, 14 Jan 2021 23:10:46 -0000 hello rich. On 2021-01-14 11:44, Salz, Rich wrote: > Yes, I was kind of waiting to see if the Datatracker sent me reminders, but I'll set up the repo shortly. sweet, thanks! let me know when it's ready and then we'll migrate the draft from its current location to the new repo. for anybody who wants to take a look before the migration, you can find it here for the time being: https://github.com/dret/I-D/tree/master/linkset thanks and cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Thu Jan 14 18:52: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 3DCA33A09D6 for ; Thu, 14 Jan 2021 18:52: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=unavailable 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 h8BWjF70O1wP for ; Thu, 14 Jan 2021 18:52:02 -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 56D5E3A09CD for ; Thu, 14 Jan 2021 18:52:02 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 10F2jN7D009916; Fri, 15 Jan 2021 02:51:17 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=K1asAdEA5rbXlUJ+MTiVpF7Auq3SY19zWzDjMJ/kQ9w=; b=liGwGeIzpHfdDZU3gsvM61aUhw/FUgSemAhvzGNiQQaE6IBACH10BP+rJ+Gh/XyP2jY/ knDrT4AwBtX1lRtSGxLbauOdkfZMv3ernOG2FXwD9nV69xL7HLdvFDI0MC3YrZjrd6Ww 7bYJkYeKHzpfewEtEJKyV90uqpmHHenN6sllWKkwlxQ4I/Fk7Gue62Xfaj7lXyIm7ssa 20grF/w6zdYbQgc0cR2BSWZl/LbDLfi/dKJHDSJQJ6rHuRiuRV3mmk5cRRPjWo3DzXoS MdnIeHacAtO3JvnPkjmC8WbAUnqPXTbGgtvn1SNTbZekBpeaA1lkxMoPKH4s75aDviCs qQ== Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 35y5ep2tca-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Jan 2021 02:51:17 +0000 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 10F2mUR3019732; Thu, 14 Jan 2021 21:51:16 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint7.akamai.com with ESMTP id 35y8q4c8s9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 14 Jan 2021 21:51:16 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 14 Jan 2021 21:51:15 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.010; Thu, 14 Jan 2021 21:51:08 -0500 From: "Salz, Rich" To: Erik Wilde , "Salz, Rich" , Herbert Van de Sompel CC: "httpapi@ietf.org" Thread-Topic: [httpapi] The HTTPAPI WG has placed draft-wilde-linkset in state "Call For Adoption By WG Issued" Thread-Index: AQHW495hSIrwHS5NQkC3bo9HyWL1LaoZ9XiAgA3lIAD//7kDgIAAjWoA///pygA= Date: Fri, 15 Jan 2021 02:51:08 +0000 Message-ID: <47676FCD-4FBC-4FA5-8B85-A24E72C9856A@akamai.com> References: <886B7500-20BA-4990-864B-52533A0533A8@akamai.com> <4F856D5C-657B-48B4-B469-0118CFB15895@gmail.com> <92E051A4-6CFF-423C-9912-99EDDEC06AB8@akamai.com> <1bb3b823-d28f-ec30-6ed9-cd311d643d07@dret.net> In-Reply-To: <1bb3b823-d28f-ec30-6ed9-cd311d643d07@dret.net> 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: 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.343, 18.0.737 definitions=2021-01-14_10:2021-01-14, 2021-01-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 malwarescore=0 adultscore=0 mlxlogscore=999 suspectscore=0 mlxscore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101150012 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-14_10:2021-01-14, 2021-01-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 priorityscore=1501 suspectscore=0 bulkscore=0 mlxlogscore=977 mlxscore=0 lowpriorityscore=0 malwarescore=0 adultscore=0 impostorscore=0 spamscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101150012 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.33) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint7 Archived-At: Subject: Re: [httpapi] The HTTPAPI WG has placed draft-wilde-linkset in state "Call For Adoption By WG Issued" 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, 15 Jan 2021 02:52:04 -0000 UmVwbyBodHRwczovL2dpdGh1Yi5jb20vaWV0Zi13Zy1odHRwYXBpL2xpbmtzZXQgZ3JlYXRlZC4N ClBsZWFzZSBjcmVhdGUgZHJhZnQtaWV0Zi1odHRwYXBpLWxpbmtzZXQgZG9jdW1lbnQsIGFuZCBw b3N0IGl0IHRvIHRoZSBkYXRhdHJhY2tlci4gIE1hcmsgdGhhdCBpdCByZXBsYWNlcyBkcmFmdC13 aWxkZS1saW5rc2V0Lg0KDQpUaGFua3MhICBIYXZlIGF0IGl0LCBncm91cCENCg0K77u/T24gMS8x NC8yMSwgNjoxMSBQTSwgIkVyaWsgV2lsZGUiIDxlcmlrLndpbGRlQGRyZXQubmV0PiB3cm90ZToN Cg0KICAgIGhlbGxvIHJpY2guDQoNCiAgICBPbiAyMDIxLTAxLTE0IDExOjQ0LCBTYWx6LCBSaWNo IHdyb3RlOg0KICAgID4gWWVzLCBJIHdhcyBraW5kIG9mIHdhaXRpbmcgdG8gc2VlIGlmIHRoZSBE YXRhdHJhY2tlciBzZW50IG1lIHJlbWluZGVycywgYnV0IEknbGwgc2V0IHVwIHRoZSByZXBvIHNo b3J0bHkuDQoNCiAgICBzd2VldCwgdGhhbmtzISBsZXQgbWUga25vdyB3aGVuIGl0J3MgcmVhZHkg YW5kIHRoZW4gd2UnbGwgbWlncmF0ZSB0aGUgDQogICAgZHJhZnQgZnJvbSBpdHMgY3VycmVudCBs b2NhdGlvbiB0byB0aGUgbmV3IHJlcG8uDQoNCiAgICBmb3IgYW55Ym9keSB3aG8gd2FudHMgdG8g dGFrZSBhIGxvb2sgYmVmb3JlIHRoZSBtaWdyYXRpb24sIHlvdSBjYW4gZmluZCANCiAgICBpdCBo ZXJlIGZvciB0aGUgdGltZSBiZWluZzoNCg0KICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMv X19odHRwczovL2dpdGh1Yi5jb20vZHJldC9JLUQvdHJlZS9tYXN0ZXIvbGlua3NldF9fOyEhR2p2 VHpfdmshRnR5R2VjRER6Qk5jakxLSnJBbndIVXd3a01GQ0h1eXpoVE9pai1TbVVpWTdiZU9OWWdZ X2x3UVlIWG5rJCANCg0KICAgIHRoYW5rcyBhbmQgY2hlZXJzLA0KDQogICAgZHJldC4NCg0KICAg IC0tIA0KICAgIGVyaWsgd2lsZGUgfCBtYWlsdG86ZXJpay53aWxkZUBkcmV0Lm5ldCB8DQogICAg ICAgICAgICAgICAgfCBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cDovL2RyZXQubmV0 L25ldGRyZXRfXzshIUdqdlR6X3ZrIUZ0eUdlY0REekJOY2pMS0pyQW53SFV3d2tNRkNIdXl6aFRP aWotU21VaVk3YmVPTllnWV9sNWdaaUxpTSQgICAgIHwNCiAgICAgICAgICAgICAgICB8IGh0dHBz Oi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwOi8vdHdpdHRlci5jb20vZHJldF9fOyEhR2p2VHpf dmshRnR5R2VjRER6Qk5jakxLSnJBbndIVXd3a01GQ0h1eXpoVE9pai1TbVVpWTdiZU9OWWdZX2w0 OTAzY1UyJCAgICAgfA0KDQogICAgLS0gDQogICAgaHR0cGFwaSBtYWlsaW5nIGxpc3QNCiAgICBo dHRwYXBpQGlldGYub3JnDQogICAgaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaHR0cGFwaV9fOyEhR2p2VHpfdmshRnR5R2Vj RER6Qk5jakxLSnJBbndIVXd3a01GQ0h1eXpoVE9pai1TbVVpWTdiZU9OWWdZX2wwbW1qR3JLJCAN Cg0K From nobody Thu Jan 14 19:30:16 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 B77A23A0AC4; Thu, 14 Jan 2021 19:30:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: httpapi@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: httpapi@ietf.org Message-ID: <161068141470.9429.15382865266237932242@ietfa.amsl.com> Date: Thu, 14 Jan 2021 19:30:14 -0800 Archived-At: Subject: [httpapi] I-D Action: draft-ietf-httpapi-linkset-00.txt 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, 15 Jan 2021 03:30:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Building Blocks for HTTP APIs WG of the IETF. Title : Linkset: Media Types and a Link Relation Type for Link Sets Authors : Erik Wilde Herbert Van de Sompel Filename : draft-ietf-httpapi-linkset-00.txt Pages : 29 Date : 2021-01-14 Abstract: This specification defines two document formats and respective media types for representing sets of links as stand-alone resources. One format is JSON-based, the other aligned with the format for representing links in the HTTP "Link" header field. This specification also introduces a link relation type to support discovery of sets of links. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpapi-linkset/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-httpapi-linkset-00 https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-linkset-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 14 20:43: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 0EA483A0C36 for ; Thu, 14 Jan 2021 20:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-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 L1TdwBBh98-i for ; Thu, 14 Jan 2021 20:43:25 -0800 (PST) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (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 8563F3A0A1E for ; Thu, 14 Jan 2021 20:43:25 -0800 (PST) Received: from [108.205.51.24] (port=52857 helo=dretpro.attlocal.net) by postoffice.gristmillmedia.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1l0GxH-0003eM-GD; Thu, 14 Jan 2021 23:43:23 -0500 To: "Salz, Rich" , "Salz, Rich" , Herbert Van de Sompel Cc: "httpapi@ietf.org" References: <886B7500-20BA-4990-864B-52533A0533A8@akamai.com> <4F856D5C-657B-48B4-B469-0118CFB15895@gmail.com> <92E051A4-6CFF-423C-9912-99EDDEC06AB8@akamai.com> <1bb3b823-d28f-ec30-6ed9-cd311d643d07@dret.net> <47676FCD-4FBC-4FA5-8B85-A24E72C9856A@akamai.com> From: Erik Wilde Message-ID: <2b83a046-472d-0b0c-c8da-bbdec6afed16@dret.net> Date: Thu, 14 Jan 2021 20:42:12 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <47676FCD-4FBC-4FA5-8B85-A24E72C9856A@akamai.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [httpapi] The HTTPAPI WG has placed draft-wilde-linkset in state "Call For Adoption By WG Issued" 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, 15 Jan 2021 04:43:27 -0000 hello. On 2021-01-14 18:51, Salz, Rich wrote: > Repo https://github.com/ietf-wg-httpapi/linkset greated. > Please create draft-ietf-httpapi-linkset document, and post it to the datatracker. Mark that it replaces draft-wilde-linkset. > Thanks! Have at it, group! thanks, rich, for creating the repo! group, https://datatracker.ietf.org/doc/draft-ietf-httpapi-linkset/ is the new group draft and https://github.com/ietf-wg-httpapi/linkset is the repo where it is available. i tried to transfer issues from the original repo to the new one, but github only supports transferring issues between repos owned by the same user/org. this means that the issues are still in the original repo (for now), but there are only four open issues left: https://github.com/dret/I-D/labels/linkset if you want to open new issues for the draft, please make sure to use the new repo and its list of issues: https://github.com/ietf-wg-httpapi/linkset/issues thanks and cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Fri Jan 15 04:42:45 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 54C333A0C70 for ; Fri, 15 Jan 2021 04:42:43 -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, 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 sO83XnpbG5cZ for ; Fri, 15 Jan 2021 04:42:41 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 CBBDB3A0C6C for ; Fri, 15 Jan 2021 04:42:41 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id d13so14578119ioy.4 for ; Fri, 15 Jan 2021 04:42:41 -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=gjmUZEl73dLcIYVVdI7/SB1ximKGuFyP5kCzfs+YQXM=; b=N476WDNCzaJdezNDcm6nHtayoxmBzGys7X19vJOGNZBtOoM1Ev7+LYu4R9Efw6Q5/K dW9Z0aNXeRAi9mYHhGRRSNRpn0awdYuy7LXtFqhbGdrW1Bs0pP5n7aIKCKLkl/wUvbNd v9URLIb0j4IFpGn9YymDmv6uxSoKcSlsdsiCoF5O145INP83Pxotp4J33LETb3JiCQW8 Uqe1VPismJWIsxow9x2k0pP5sZllP3xgdsPywAIxSQ74HCdkcqQG2zs5gDqxhcbM2LuY Hls70x5wLAk5Q265XtBdANBgUVDP1tS1Xn0nGH792iPzjVTA1bbDeJAeVdIXq2iDxZ2S AvaA== 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=gjmUZEl73dLcIYVVdI7/SB1ximKGuFyP5kCzfs+YQXM=; b=Nx3hF3FISD+DsQ2YWuE6OGrVLZROWXuT2WevjZUJN6ODvIbrwEHCxYdq140m0r62aH 98RH+1ZlrXJrzVLqPzNLLCfB8rJ9PxWQBVqIHInktlPKoK4rftq60kNBe/CCWxss2Qj5 01DidBkutrHq+IJwwGiYWKufpJzF5WA1RLuBhZ9GgpgevEMVhVZnSSEeV05CTVcpSXLG Z6XSRDmRWDEUy8g645W1MAJNiL772FiOmVk/iF5cY3I4QuDScE8kM6OcO62Pljuvtb2U +Qo6vHUfUD1eP0bGCC1AObJbiqhPgfJrdpu6EWckHAjme6gBAFwtsqY5LJNMW5sYsG+y IUdg== X-Gm-Message-State: AOAM5334cfpBdgZqgpg5gUHukY8xYf4s4DrXOuOYGo870h4tgKbxsYXq k3P5uWYuZPPD1PMQTDQmR5EHGQWwLwkLyn78xYw= X-Google-Smtp-Source: ABdhPJwCJk9QW0RIUsoIwr2jTv3F7nnm7Y2XjYKa+X/8M5M4wmfhKEhEKamSCGuVj2P9kfo/TxUxfY6bbJXYgvO+1ts= X-Received: by 2002:a92:6a10:: with SMTP id f16mr2501235ilc.146.1610714560961; Fri, 15 Jan 2021 04:42:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roberto Polli Date: Fri, 15 Jan 2021 14:11:14 +0100 Message-ID: To: Alex Martinez Cc: Darrel Miller , "darrel@tavis.ca" , "httpapi@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [httpapi] RateLimit Header client implementations 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, 15 Jan 2021 12:42:43 -0000 Hi @all and sorry for the late reply. Il giorno mer 13 gen 2021 alle ore 18:47 Alex Martinez ha scritto: > On Sun, Jan 10, 2021 at 4:27 PM Darrel Miller wrote: >> You are right, the immediate effect is the same. That said, you would be= lacking some extra information about the nominal quota units and duration = of the current window and the windows applying after this one is elapsed (i= e. after recovery you'd have information about the expected rates, and thos= e could also signal some sort of punitive policy), though that information = might be next to useless in the current window since the intended effect is= to stop traffic altogether for a while. Yet it would not work in a closely= related scenario in which you would have some partial maintenance work but= keeping the ability to serve clients in a degraded service manner -- that = is, unless you kept giving clients shorter no-service windows interleaved w= ith service responses as usual, hence generating a lot more wasteful traffi= c. >> >> Would be useful to clarify that these additional headers are intended to= support scenarios where rate limiting constraints applied by a service are= dynamic over time? > Sure, we can look into clarifying this - perhaps my own reading of the do= cument makes this obvious to me having worked on rate limiting stuff for so= me time. This is addressed under =C2=A7This Proposal and =C2=A7Goals: - https://github.com/ietf-wg-httpapi/ratelimit-headers/blame/main/draft-iet= f-httpapi-ratelimit-headers.md#L143 - https://github.com/ietf-wg-httpapi/ratelimit-headers/blame/main/draft-iet= f-httpapi-ratelimit-headers.md#L175 but if the statements are not clear, suggestions are very welcome. As Alex said, a "first reader" eye would probably make a better proposal. >> I look forward to seeing some feedback from implementers on the value de= rived from generic client code that handles these headers. > [.. ] the implementation work is not trivial. I don't really know whether= such projects would go for an I-D even if it's already on the standards tr= ack, but we can certainly ask! Great. On my side, the main obstacle to the implementation was the inability to identify the headers and their content. How clients want to adapt their request policies to the quota-policies exposed by service providers is not an easy guess: some may want to focus on maximizing the throughput, others to avoid peaks and distribute requests fairly across time-frames, ... Our goal here is to allow clients to identify request policies and be able to act accordingly. Some behaviors might even be implemented in general-purpose libraries, but in many cases the logic will be managed and implemented according to the specific business goals of the clients. My2=C2=A2 + Peace, R: From sanjay.dalal@gmail.com Fri Jan 15 10:46:23 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 BEF633A1084 for ; Fri, 15 Jan 2021 10:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 NaTb8OqSmjiO for ; Fri, 15 Jan 2021 10:46:22 -0800 (PST) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 0602F3A108E for ; Fri, 15 Jan 2021 10:46:21 -0800 (PST) Received: by mail-oi1-x22f.google.com with SMTP id 9so10587173oiq.3 for ; Fri, 15 Jan 2021 10:46: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:from:date:message-id:subject:to; bh=3lGFJ3+rSsGts/xjzrJ2zuCrr1MSiswHyPWmCh4/tB8=; b=p3QfXsKA7pM/E5GJj5wfB0IUhtWPAB9bIdXLjU9rmOrTk4tVrc4uUACk7uS4KDAhTD lszIiy6hriQqx2biouKE5VGVRRF66Osr7ocfuX5kXcsbzxk1kZZrcyPKxIL6nXmMTfES kbWYx+eBPXan9gGxOXJ5pIUYJNLM8Lt4hFuC7aj4PmLZUJiSxBCnJ6kqIt9tx5wyZBVl Vz1wQrUIEofH/pBR5U35U3DlxawF00jUsnZZPCc1DbBfUK5lVDrrUnCCtQGuSwdftEQo /wfeTyb+pN/H3hd42Dwy0sS06JEvQ2KljTnKHg+62rEzF3n8Xp7OyLnvgXAF2fVDsPAt zUVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3lGFJ3+rSsGts/xjzrJ2zuCrr1MSiswHyPWmCh4/tB8=; b=H9adtgJUcmtieyUa3oKdbd3ggKcHlH9vG4Upqp+dmzwI0DVGF/uh+wMQWOTNnnIhuI l6RV2bdkV5FHNLHZNksufKnlLps8oO6WLKdrqZh9Fyvg5UVZDP5OhT5b4nww1ddmlYvd 9pIfrgEe72Ox6bJbAhqXSjocpjmKWhqhBdnp5twL0xo1v3YGFry3AgHP0XxU9arpZYQl YilC24N8enUOx9211musVOqon8hW9ZOfp8jYvv0yG82Nj3Fxn1kUGPjazztqZLozNseN mqn+GrEYcbfkc5rKn2b0F5kMwG6n+hhhBs2ga+tQpICk5tmxcl3C1wnww2HYjjncEQdj hihQ== X-Gm-Message-State: AOAM532GvRA4njSf6vYxVuUsKm5cB1lfQ1TTf5iuYWyANMI7rlVPTNDR BD1ZhX53HIjTM9SN5F7akj3sH3JLth5Nep1fXMzwI8RXOWC9WQ== X-Google-Smtp-Source: ABdhPJzBTcM/YbSIqSFQ1vmd5Y8TlLRuszFQ81D33UUXub9P+rZwuQ4LB5I6v9ZgsbRUS9OeYXpeV91UXwsjskB6DAc= X-Received: by 2002:aca:33d5:: with SMTP id z204mr6434573oiz.81.1610736380838; Fri, 15 Jan 2021 10:46:20 -0800 (PST) MIME-Version: 1.0 From: Sanjay Dalal Date: Fri, 15 Jan 2021 10:46:09 -0800 Message-ID: To: httpapi@ietf.org Content-Type: multipart/alternative; boundary="000000000000ce868a05b8f4c956" Archived-At: Subject: [httpapi] rfc7807 errata or just "more" 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, 15 Jan 2021 19:46:54 -0000 --000000000000ce868a05b8f4c956 Content-Type: text/plain; charset="UTF-8" Hello all, Thanks folks for providing instructions on how to provide feedback to an RFC. This feedback is for RFC 7807 , "Problem Details for HTTP APIs". I like RFC 7807. In fact, I have designed Error Catalog Service such that the problem types of RFC 7807 can be managed (CRUDL) and used in error responses, API definition, API documentation, API testing, etc. However, I find that RFC 7807 omitted one very common use case in its proposed schema for Problem Details Object (section 3.1). This use case is about reporting of multiple errors of the same problem type in an error response. RFC suggests defining an extension for this use case. As you know, having multiple schema validation related errors in payload of HTTP requests is a very common scenario for the HTTP APIs. How can we improve the Problem Details Object schema to accommodate this common use case? We should not expect API developers to respond with one error at a time in the case of 400 scenarios. That would be an unpleasant developer experience. Asking the API developers to define an extension for such a common scenario hurts in adoption of the Problem Types. In my opinion, instead of the proposed singular "*instance*" property of type string, there should be an array of *instances. *You can find what we have done for the error response of the Error Catalog service .There could be other ways. I have communicated with both Erik Wilde and Mark Nottingham about this issue. Both of them are open to discussing a revision under this WG if the group thinks it is necessary. Would love to get your comments, opinions, approaches and suggestions. thanks and regards, sanjay > I am not too familiar with the process to comment an RFC but is there in general a form where I can provide written feedback to existing specifications or is this done through this mailing list? >On Sat, Jan 9, 2021 at 9:40 AM Salz, Rich wrote: RFC's are published documents, not drafts; the name "request for comments" is a node to IETF history. How to provide feedback on published RFC's depends on the amount and nature of feedback. If you have a well-contained technical error, you want to report an "errata" against the RFC. If it's more philosophical or just "more", it might be better to find the WG that published the RFC and post to that mailing list (see above). apology in advance if you received multiple emails. --000000000000ce868a05b8f4c956 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

Th= anks folks for providing instructions on how to provide feedback to an RFC.= This feedback is for=C2=A0RFC 7807, "Problem Details for HTTP APIs".= =C2=A0

I like RFC 7807. In fact, I have designed= =C2=A0Error Catalog Service=C2=A0such that the problem types of R= FC 7807 can be managed (CRUDL) and used in error responses, API definition,= API documentation, API testing, etc.=C2=A0

Howeve= r, I find that RFC 7807 omitted one very common use case in its proposed sc= hema for=C2=A0Problem Details Object=C2=A0(section 3.1). This use=C2= =A0case is about reporting of multiple errors of the same problem type in a= n error response. RFC suggests defining an extension for this use case.

As you know, having multiple schema validation relate= d errors in payload of HTTP requests is a very common scenario for the HTTP= APIs. How can we improve the Problem Details Object schema to accommodate = this common use case? We should not expect API developers to respond with o= ne error at a time in the case of 400 scenarios. That would be an unpleasan= t=C2=A0developer experience. Asking the API developers to define an extensi= on for such a common scenario hurts in adoption of the Problem Types.

In my opinion, ins= tead of the proposed singular "instance" property of type = string, there should be an array of=C2=A0instances.=C2=A0You can fin= d what we have done for the=C2=A0error response of the Error Catalog service.There could be other= ways.

I have communicated with both Erik W= ilde and Mark Nottingham about this issue.=C2=A0Both of them are open to discussing a revision under th= is WG if the group=C2=A0thinks it is necessary. Would love to get yo= ur comments, opinions, approaches and suggestions.

thanks and regards,
sanjay


&g= t;=C2=A0 =C2=A0 I am not too familiar with the process to comment an RFC bu= t is there in general
=C2=A0 =C2=A0 a form where I can provide written f= eedback to existing specifications or is
=C2=A0 =C2=A0 this done through= this mailing list?

>On Sat, Jan 9, 2021 at 9:40 AM Salz, Rich &l= t;rsalz=3D= 40akamai.com@dmarc.ietf.org> wrote:
RFC's are published docum= ents, not drafts; the name "request for comments" is a node to IE= TF history.=C2=A0 How to provide feedback on published RFC's depends on= the amount and nature of feedback.=C2=A0 If you have a well-contained tech= nical error, you want to report an "errata" against the RFC.=C2= =A0 If it's more philosophical or just "more", it might be be= tter to find the WG that published the RFC and post to that mailing list (s= ee above).=C2=A0=C2=A0


apology in advance= if you received multiple emails.

--000000000000ce868a05b8f4c956-- From sanjay.dalal@gmail.com Fri Jan 15 10:32:27 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 30F293A107C for ; Fri, 15 Jan 2021 10:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 ZaiBxhluYLNw for ; Fri, 15 Jan 2021 10:32:25 -0800 (PST) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6393A0FC9 for ; Fri, 15 Jan 2021 10:32:25 -0800 (PST) Received: by mail-ot1-x333.google.com with SMTP id o11so9467126ote.4 for ; Fri, 15 Jan 2021 10:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cal-berkeley-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=jnIapBielCfTf1mlUnPRKAmA8g2SR4RDk2bJOuJBQKA=; b=ajevk1SDIQS+jWNfdtNvoY7G0n/3rwzlNsDgQDizwUETVO1d03sOvFwUCnv1tYKPR4 4S0bzBtcRqplZLuJQKeK2juBU3NEiNqJVEKbnhXuL1imIXmEbKtLfzYmIyk6fFxBYrTH j/5E5NGGl8U/Kwf7YkrTTjt1s8UNiiQG9kqfi3qWIfiXT/7o4FnPOBkaQ4H9UzNcAW7P KmUaG8e3gRwYx9HKSsocdEaPnBRQt+Hbv3lNRddqIF1cJNNZ3ZYdEwl7xriQ1sZlHaTF 1QVAn8uPPpWJ6/H4iiZ0YCej8pT8y5qE25qrcwzUZ/87PxL+7cJmzKa9AafvmhzBln00 Os0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jnIapBielCfTf1mlUnPRKAmA8g2SR4RDk2bJOuJBQKA=; b=rqWBy70PTZDL/Z1ZO6ErNyNNBgmyo3whHbUFYH5cvy9eMhNRWwRus6VKXtRhgB9inv CHpCfbU1TcxYCHGwlrWdBeklAP0HCGDwB48Bw4cuk/OZSYTQ4Ic1m9SL4+MxFxTdDeQo UQn2XSC932mTf6s+tFenqyg0Qrg8UiM300OVTjLZrmLv5zmpV69r/gs15ATqXdn1Yp33 iE4sh2cKaCVOopGfcdv58Pc0miE/bIK48Z8oCkB37JtytMkKFZ1uTGfo8JGyjDPA5Z4q NL8WqfcKFEqPXeJiXtbUbl/Lq8L3V82TZntmXxtZ14lCZkvupMxM+QSGAP/OLVP5223F wMYQ== X-Gm-Message-State: AOAM5314Jc3jqeVLcOUCUklgfpmTFVZ6385q3+lRKdkOkOIGU8FYkv3Q PaDP9zD/lqzZNZ9AsIR/SQltt1FTF5V+w6WSJjh/zRe+TvOn3g== X-Google-Smtp-Source: ABdhPJyvMfpODib/H0yRg2llwH3fkZvAKSSUEMhoN7raPgSoomc4/5ZNf9/U7yslPHy7xCHfzYwjZ2Nq4PzrmxV4iSM= X-Received: by 2002:a9d:6751:: with SMTP id w17mr3451692otm.328.1610735544354; Fri, 15 Jan 2021 10:32:24 -0800 (PST) MIME-Version: 1.0 From: Sanjay Dalal Date: Fri, 15 Jan 2021 10:32:13 -0800 Message-ID: To: httpapi@ietf.org Content-Type: multipart/alternative; boundary="000000000000f2cdb705b8f497e0" Archived-At: Subject: [httpapi] rfc7807 errata or just "more" 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, 15 Jan 2021 19:51:44 -0000 --000000000000f2cdb705b8f497e0 Content-Type: text/plain; charset="UTF-8" Hello all, Thanks folks for providing instructions on how to provide feedback to an RFC. This feedback is for RFC 7807 , "Problem Details for HTTP APIs". I like RFC 7807. In fact, I have designed Error Catalog Service such that the problem types of RFC 7807 can be managed (CRUDL) and used in error responses, API definition, API documentation, API testing, etc. However, I find that RFC 7807 omitted one very common use case in its proposed schema for Problem Details Object (section 3.1). This use case is about reporting of multiple errors of the same problem type in an error response. RFC suggests defining an extension for this use case. As you know, having multiple schema validation related errors in payload of HTTP requests is a very common scenario for the HTTP APIs. How can we improve the Problem Details Object schema to accommodate this common use case? We should not expect API developers to respond with one error at a time in the case of 400 scenarios. That would be an unpleasant developer experience. Asking the API developers to define an extension for such a common scenario hurts in adoption of the Problem Types. In my opinion, instead of the proposed singular "*instance*" property of type string, there should be an array of *instances. *You can find what we have done for the error response of the Error Catalog service .There could be other ways. I have communicated with both Erik Wilde and Mark Nottingham about this issue. Both of them are open to discussing a revision under this WG if the group thinks it is necessary. Would love to get your comments, opinions, approaches and suggestions. thanks and regards, sanjay > I am not too familiar with the process to comment an RFC but is there in general a form where I can provide written feedback to existing specifications or is this done through this mailing list? >On Sat, Jan 9, 2021 at 9:40 AM Salz, Rich wrote: RFC's are published documents, not drafts; the name "request for comments" is a node to IETF history. How to provide feedback on published RFC's depends on the amount and nature of feedback. If you have a well-contained technical error, you want to report an "errata" against the RFC. If it's more philosophical or just "more", it might be better to find the WG that published the RFC and post to that mailing list (see above). --000000000000f2cdb705b8f497e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

Thanks folks for = providing instructions on how to provide feedback to an RFC. This feedback = is for=C2=A0RFC 7807, "Problem Details for HTTP APIs".=C2=A0

I like RFC 7807. In fact, I have designed=C2=A0Error = Catalog Service=C2=A0such that the problem types of RFC 7807 can be man= aged (CRUDL) and used in error responses, API definition, API documentation= , API testing, etc.=C2=A0

However, I find that RFC= 7807 omitted one very common use case in its proposed schema for=C2=A0P= roblem Details Object=C2=A0(section 3.1). This use=C2=A0case is about r= eporting of multiple errors of the same problem type in an error response. = RFC suggests defining an extension for this use case.

<= div>As you know, having multiple schema validation related errors in payloa= d of HTTP requests is a very common scenario for the HTTP APIs. How can we = improve the Problem Details Object schema to accommodate this common use ca= se? We should not expect API developers to respond with one error at a time= in the case of 400 scenarios. That would be an unpleasant=C2=A0developer e= xperience. Asking the API developers to define an extension for such a comm= on scenario hurts in adoption of the Problem Types.

In my opinion, instead of the propos= ed singular "instance" property of type string, there shou= ld be an array of=C2=A0instances.=C2=A0You can find what we have don= e for the=C2=A0error respo= nse of the Error Catalog service.There could be other ways.
<= b>
I have communicated with both Erik Wilde and Mark Nott= ingham about this issue.=C2= =A0Both of them are open to discussing a revision under this WG if the grou= p=C2=A0thinks it is necessary. Would love to get your comments, opin= ions, approaches and suggestions.

thanks and regar= ds,
sanjay


>=C2=A0 =C2=A0 I= am not too familiar with the process to comment an RFC but is there in gen= eral
=C2=A0 =C2=A0 a form where I can provide written feedback to existi= ng specifications or is
=C2=A0 =C2=A0 this done through this mailing lis= t?

>On Sat, Jan 9, 2021 at 9:40 AM Salz, Rich <rsalz=3D40akamai.com@dmar= c.ietf.org> wrote:
RFC's are published documents, not drafts;= the name "request for comments" is a node to IETF history.=C2=A0= How to provide feedback on published RFC's depends on the amount and n= ature of feedback.=C2=A0 If you have a well-contained technical error, you = want to report an "errata" against the RFC.=C2=A0 If it's mor= e philosophical or just "more", it might be better to find the WG= that published the RFC and post to that mailing list (see above).=C2=A0=C2= =A0
--000000000000f2cdb705b8f497e0-- From nobody Fri Jan 15 20:08:31 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 9FF583A14BB for ; Fri, 15 Jan 2021 20:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-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 VAjK3E5rhGnY for ; Fri, 15 Jan 2021 20:08:26 -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 CFE7E3A14B9 for ; Fri, 15 Jan 2021 20:08:24 -0800 (PST) From: Ben Bucksch To: httpapi@ietf.org References: Organization: Beonex Message-ID: <5fc6752d-f3d7-0781-6e3a-1fd99f74a9ad@beonex.com> Date: Sat, 16 Jan 2021 05:08:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4C520C717EEBF22F1A4A357C" Content-Language: fr Archived-At: Subject: [httpapi] RFC for HTTP API error responses (was: rfc7807 errata or just "more") 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, 16 Jan 2021 04:08:30 -0000 This is a multi-part message in MIME format. --------------4C520C717EEBF22F1A4A357C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Sanjay, hello everybody, thank you for bringing this up. In fact, this topic is the very reason why I joined this mailling list and WG: I find that error responses - and more generally error handling - is severely lacking in many systems I come across, and it's causing problems during software development. I wanted to propose to make a new RFC for nailling down not only the error responses, but also what information is expected in the response, and the behavioral contract. Errors should be part of the protocol and API contract. I had written some document for my project and teams, in my role as software architect, based on my experience, and I wanted to share that with you as starting point for an RFC. The document I have is not suitable as Standard document, it's an software architecture document, but I think many of the ideas are viable to be included in the RFC. I would like to ask you, esp. the leaders of the WG: Would you be willing to discuss and adopt such a new RFC? It would probably include RFC 7807, but significantly extend it in its scope. Ben Bucksch Am 15.01.21 um 19:32 schrieb Sanjay Dalal: > Hello all, > > Thanks folks for providing instructions on how to provide feedback to > an RFC. This feedback is for RFC 7807 > , "Problem Details for HTTP APIs". > > I like RFC 7807. In fact, I have designed Error Catalog Service >  such that the > problem types of RFC 7807 can be managed (CRUDL) and used in error > responses, API definition, API documentation, API testing, etc. > > However, I find that RFC 7807 omitted one very common use case in its > proposed schema for Problem Details Object >  (section 3.1). This > use case is about reporting of multiple errors of the same problem > type in an error response. RFC suggests defining an extension for this > use case. > > As you know, having multiple schema validation related errors in > payload of HTTP requests is a very common scenario for the HTTP APIs. > How can we improve the Problem Details Object schema to accommodate > this common use case? We should not expect API developers to respond > with one error at a time in the case of 400 scenarios. That would be > an unpleasant developer experience. Asking the API developers to > define an extension for such a common scenario hurts in adoption of > the Problem Types. > > In my opinion, instead of the proposed singular "*instance*" property > of type string, there should be an array of *instances. *You can find > what we have done for the error response of the Error Catalog service > .There > could be other ways. > * > * > I have communicated with both Erik Wilde and Mark Nottingham about > this issue. Both of them are open to discussing a revision under this > WG if the group thinks it is necessary. Would love to get your > comments, opinions, approaches and suggestions. > > thanks and regards, > sanjay > > > >    I am not too familiar with the process to comment an RFC but is > there in general >     a form where I can provide written feedback to existing > specifications or is >     this done through this mailing list? > > >On Sat, Jan 9, 2021 at 9:40 AM Salz, Rich > > wrote: > RFC's are published documents, not drafts; the name "request for > comments" is a node to IETF history.  How to provide feedback on > published RFC's depends on the amount and nature of feedback. If you > have a well-contained technical error, you want to report an "errata" > against the RFC.  If it's more philosophical or just "more", it might > be better to find the WG that published the RFC and post to that > mailing list (see above). > --------------4C520C717EEBF22F1A4A357C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hello Sanjay, hello everybody,

thank you for bringing this up. In fact, this topic is the very reason why I joined this mailling list and WG: I find that error responses - and more generally error handling - is severely lacking in many systems I come across, and it's causing problems during software development.

I wanted to propose to make a new RFC for nailling down not only the error responses, but also what information is expected in the response, and the behavioral contract. Errors should be part of the protocol and API contract.

I had written some document for my project and teams, in my role as software architect, based on my experience, and I wanted to share that with you as starting point for an RFC. The document I have is not suitable as Standard document, it's an software architecture document, but I think many of the ideas are viable to be included in the RFC.

I would like to ask you, esp. the leaders of the WG: Would you be willing to discuss and adopt such a new RFC? It would probably include RFC 7807, but significantly extend it in its scope.

Ben Bucksch


Am 15.01.21 um 19:32 schrieb Sanjay Dalal:
Hello all,

Thanks folks for providing instructions on how to provide feedback to an RFC. This feedback is for RFC 7807, "Problem Details for HTTP APIs". 

I like RFC 7807. In fact, I have designed Error Catalog Service such that the problem types of RFC 7807 can be managed (CRUDL) and used in error responses, API definition, API documentation, API testing, etc. 

However, I find that RFC 7807 omitted one very common use case in its proposed schema for Problem Details Object (section 3.1). This use case is about reporting of multiple errors of the same problem type in an error response. RFC suggests defining an extension for this use case.

As you know, having multiple schema validation related errors in payload of HTTP requests is a very common scenario for the HTTP APIs. How can we improve the Problem Details Object schema to accommodate this common use case? We should not expect API developers to respond with one error at a time in the case of 400 scenarios. That would be an unpleasant developer experience. Asking the API developers to define an extension for such a common scenario hurts in adoption of the Problem Types.

In my opinion, instead of the proposed singular "instance" property of type string, there should be an array of instances. You can find what we have done for the error response of the Error Catalog service.There could be other ways.

I have communicated with both Erik Wilde and Mark Nottingham about this issue. Both of them are open to discussing a revision under this WG if the group thinks it is necessary. Would love to get your comments, opinions, approaches and suggestions.

thanks and regards,
sanjay


>    I am not too familiar with the process to comment an RFC but is there in general
    a form where I can provide written feedback to existing specifications or is
    this done through this mailing list?

>On Sat, Jan 9, 2021 at 9:40 AM Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org> wrote:
RFC's are published documents, not drafts; the name "request for comments" is a node to IETF history.  How to provide feedback on published RFC's depends on the amount and nature of feedback.  If you have a well-contained technical error, you want to report an "errata" against the RFC.  If it's more philosophical or just "more", it might be better to find the WG that published the RFC and post to that mailing list (see above).  


--------------4C520C717EEBF22F1A4A357C-- From nobody Sat Jan 16 05:14:27 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 BEACE3A1769 for ; Sat, 16 Jan 2021 05:14:25 -0800 (PST) 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 ADVHhqYhSz6U for ; Sat, 16 Jan 2021 05:14:24 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 407533A1768 for ; Sat, 16 Jan 2021 05:14:24 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id m25so17278477lfc.11 for ; Sat, 16 Jan 2021 05:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=rva2F4eLFr4nZvB5AIXrbK9LTcppJcmI7G8+kgYpxLc=; b=QphzFD1OWq+ZdgAOHZtkeWiMYhuqWW2gUIumTejirBiQTOXI/46LDzdGNcGm0tqMl3 PWqNiv6KV0kbGrZO1kZG3BMmIWq5gZJqIZqDeZ7LJPDAzU9QylKDZkAGEqqUhYJ65D40 KSabIBpeXgZRsVW4FkXDIWD2UbBRzE4jDnqq2CrQAYVa3OjE27jyGkgBqp2gXK/kzUkr WGeIQT4cPZqHmmZNPCDEFCZLCS0pkBdTULskL1cY2OvJIHbAACjWo/27YdhL9xVpIIjs 9668Q8kJc/vixpFL3KPPhcgfHYUCEzxBl5Qd5FcTHvsdKFOq88gPgu/MLmUD1pw6iQ0R iZUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rva2F4eLFr4nZvB5AIXrbK9LTcppJcmI7G8+kgYpxLc=; b=AN/QPb5s+8Fjh354v9sa/JjbIb+l7BnuUC+w1QBi4jG5TTf5WYjggwtGzHpamVzcC8 ywOwnPggmfhuvFs3BARerKt/sJISjWviRVhJVmbyZsuL3ElCQxZC27s7/tye/hhjBAmb 0Kk+E6I8OAbDc0NkM3HUwz1r0g3X//y2WQ9WATCGWRWOUWNHrJTbtc6BC7g3y2V4MdDX GFQzMxEVt87y+QCyi9evw9qvo1Z2lTrnRlvSpOEl8vn8GXqmfXyWekcC9/2TMbNWJM9A AtHsHO6UHVs90i3Amz0hEi9yh6kaspaGapCukcodWpeLZxm1YSMFWeRDVHGY57m1pUbI J0Ww== X-Gm-Message-State: AOAM532440tFz1LNk1ZwWmZt7kCCQg3ij8F8wTpCRqLW/w8UyZyIKGcI +GpiAimVrKSax0LpKL/12KKApyIvIptl82y70MnRizS7pwc= X-Google-Smtp-Source: ABdhPJyjtw3r8Wcm9TdcccuBH6kaB417OjK/3mSXEztvjUxjJPxSp6R64fFnNhcMF4IcPCoZrrvtlAMeHUH1SiEVShM= X-Received: by 2002:a05:6512:287:: with SMTP id j7mr7932624lfp.541.1610802861676; Sat, 16 Jan 2021 05:14:21 -0800 (PST) MIME-Version: 1.0 From: Christoph Kappestein Date: Sat, 16 Jan 2021 14:14:19 +0100 Message-ID: To: httpapi@ietf.org Content-Type: multipart/alternative; boundary="0000000000005f9b9d05b9044426" Archived-At: Subject: [httpapi] Discussion about JSON payloads and code generation 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, 16 Jan 2021 13:14:26 -0000 --0000000000005f9b9d05b9044426 Content-Type: text/plain; charset="UTF-8" Hi all, I would like to gauge whether there is some interest in discussing ways to describe JSON payloads with a focus on code generation on this WG. Also it would be interesting to gather feedback from other developers who have experiences in this space. I have wrote some thoughts about this topic in a separate blog post, if you are interested you can checkout the post at: https://chriskapp.medium.com/discussion-about-json-payloads-and-code-generation-8d60bc8fd94e Please let me know what you think. best regards Christoph --0000000000005f9b9d05b9044426 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I would like to gauge whether t= here is some interest in discussing ways to describe JSON payloads with a f= ocus on code generation on this WG. Also it would be interesting to gather = feedback from other developers who have experiences in this space.

I= have wrote some thoughts about this topic in a separate blog post, if you = are interested you can checkout the post at:
https://chriskapp.medium.com/discussion-about-json-payloads-and-code-gen= eration-8d60bc8fd94e

Please let me know what you think.

b= est regards
Christoph

--0000000000005f9b9d05b9044426-- From nobody Sat Jan 16 07:05:05 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 6B5A13A17EB for ; Sat, 16 Jan 2021 07:05:04 -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 QpByRP35sNJQ for ; Sat, 16 Jan 2021 07:05:03 -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 E4B7A3A17EA for ; Sat, 16 Jan 2021 07:05:02 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 10GF008l027335; Sat, 16 Jan 2021 15:04:51 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=jXHRKw928DPw11CWlciY/a58rUIGyjjXHZDSNXekPPA=; b=MSbUlqvhyEi2GAAG+Ps81fJY85QsEIinceq/dTgYvVMY8teZRETIYbfSGh28GMPTRzpo Q8OOI/qW4nPwqwbq+nTzsO8QkphckD35mN0MUI8cMBzGXDiqFwOpX1m2KytDJmbUv6VF Ju/e3qGFQcOYnCG2RlQnM73m/pTIvIhxvV1345hICtQkwyAXMvoLlgRLkXULInABTiud AHPZpwSnkiN1HcGYOqrKcpJJCsLWWOg1DDtvE0KzFQcTs0X5xPXJmcIbQF4onN6cAI75 wq0/O7RgQAaCD74YxzrdikUBzT6BypeSgcs62kl8nb5AbnKDTjzhT0ibneUXDFic9T9w eA== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 363sefa0q1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 16 Jan 2021 15:04:51 +0000 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 10GEn6KZ010603; Sat, 16 Jan 2021 10:04:50 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint6.akamai.com with ESMTP id 363vc2rmuf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 16 Jan 2021 10:04:50 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 16 Jan 2021 10:04:50 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.010; Sat, 16 Jan 2021 10:04:49 -0500 From: "Salz, Rich" To: Ben Bucksch , "httpapi@ietf.org" Thread-Topic: [httpapi] RFC for HTTP API error responses (was: rfc7807 errata or just "more") Thread-Index: AQHW671D4F+LuCjINEiVS2F0chyIdqoqWmGA Date: Sat, 16 Jan 2021 15:04:49 +0000 Message-ID: <942EFCF2-AF6C-4364-B4E9-2466B9A8D0AC@akamai.com> References: <5fc6752d-f3d7-0781-6e3a-1fd99f74a9ad@beonex.com> In-Reply-To: <5fc6752d-f3d7-0781-6e3a-1fd99f74a9ad@beonex.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_942EFCF2AF6C4364B4E92466B9A8D0ACakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-16_07:2021-01-15, 2021-01-16 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=993 spamscore=0 suspectscore=0 malwarescore=0 adultscore=0 bulkscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101160094 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-16_07:2021-01-15, 2021-01-16 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 malwarescore=0 suspectscore=0 mlxscore=0 spamscore=0 impostorscore=0 clxscore=1011 adultscore=0 mlxlogscore=886 priorityscore=1501 bulkscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101160096 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.61) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint6 Archived-At: Subject: Re: [httpapi] RFC for HTTP API error responses (was: rfc7807 errata or just "more") 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, 16 Jan 2021 15:05:04 -0000 --_000_942EFCF2AF6C4364B4E92466B9A8D0ACakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSB3b3VsZCBsaWtlIHRvIGFzayB5b3UsIGVzcC4gdGhlIGxlYWRlcnMgb2YgdGhlIFdH OiBXb3VsZCB5b3UgYmUgd2lsbGluZyB0byBkaXNjdXNzIGFuZCBhZG9wdCBzdWNoIGEgbmV3IFJG Qz8gSXQgd291bGQgcHJvYmFibHkgaW5jbHVkZSBSRkMgNzgwNywgYnV0IHNpZ25pZmljYW50bHkg ZXh0ZW5kIGl0IGluIGl0cyBzY29wZS4NCg0KSXTigJlzIHVwIHRvIHRoZSBtZW1iZXJzIG9mIHRo ZSBXRyB0byBkZWNpZGUgaWYgdGhleSB3YW50IHRvIHdvcmsgb24gdGhpcywgYW5kIGl04oCZcyB1 cCB0byB0aGUgV0cgY2hhaXJzICh3b3JraW5nIHdpdGggb3VyIEFyZWEgRGlyZWN0b3IpIHRvIHdv cmsgb24gbW9kaWZ5aW5nIHRoZSBjaGFydGVyLCBpZiBuZWNlc3NhcnksIG9yIHBvaW50aW5nIHRv IGFub3RoZXIgV0cuICBJbiB0aGlzIHBhcnRpY3VsYXIgY2FzZSwgc2luY2UgNzgwNyB3YXMgZG9u ZSBpbiB0aGUgbm93LWNsb3NlZCDigJxhcHBzYXdz4oCdIGdyb3VwIChodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL3dnL2FwcHNhd2cvY2hhcnRlci8pIGl0IHNlZW1zIGFwcHJvcHJpYXRlIHRv IGRpc2N1c3MgaXQgaGVyZS4gIElmIHRoZSBXRyBkZWNpZGVzIHRvIHRha2UgdGhpcyB3b3JrIG9u LCB0aGVuIHdl4oCZbGwgbWFrZSBzdXJlIHRoZSAgY2hhcnRlciBjb3ZlcnMgaXQuDQoNClNvLCBj aGF0IGF3YXkuDQo= --_000_942EFCF2AF6C4364B4E92466B9A8D0ACakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFy YWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28t c3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsN CgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2MTI0NDE5Njk7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzg5NzgzMzc0 IC0xNTEyMDQ0ODg4IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYW5zaS1mb250LXdlaWdodDpi b2xkO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5 bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 ZGl2Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzEiPkkgd291bGQgbGlrZSB0byBhc2sgeW91LCBlc3AuIHRoZSBsZWFkZXJzIG9mIHRo ZSBXRzogV291bGQgeW91IGJlIHdpbGxpbmcgdG8gZGlzY3VzcyBhbmQgYWRvcHQgc3VjaCBhIG5l dyBSRkM/IEl0IHdvdWxkIHByb2JhYmx5IGluY2x1ZGUgUkZDIDc4MDcsIGJ1dCBzaWduaWZpY2Fu dGx5IGV4dGVuZCBpdCBpbiBpdHMNCiBzY29wZS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SXTigJlzIHVwIHRvIHRoZSBtZW1iZXJzIG9mIHRoZSBXRyB0byBkZWNpZGUgaWYgdGhleSB3 YW50IHRvIHdvcmsgb24gdGhpcywgYW5kIGl04oCZcyB1cCB0byB0aGUgV0cgY2hhaXJzICh3b3Jr aW5nIHdpdGggb3VyIEFyZWEgRGlyZWN0b3IpIHRvIHdvcmsgb24gbW9kaWZ5aW5nIHRoZSBjaGFy dGVyLCBpZiBuZWNlc3NhcnksIG9yIHBvaW50aW5nIHRvIGFub3RoZXIgV0cuJm5ic3A7IEluIHRo aXMgcGFydGljdWxhciBjYXNlLA0KIHNpbmNlIDc4MDcgd2FzIGRvbmUgaW4gdGhlIG5vdy1jbG9z ZWQg4oCcYXBwc2F3c+KAnSBncm91cCAoPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy93Zy9hcHBzYXdnL2NoYXJ0ZXIvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dn L2FwcHNhd2cvY2hhcnRlci88L2E+KSBpdCBzZWVtcyBhcHByb3ByaWF0ZSB0byBkaXNjdXNzIGl0 IGhlcmUuJm5ic3A7IElmIHRoZSBXRyBkZWNpZGVzIHRvIHRha2UgdGhpcyB3b3JrIG9uLCB0aGVu IHdl4oCZbGwNCiBtYWtlIHN1cmUgdGhlJm5ic3A7IGNoYXJ0ZXIgY292ZXJzIGl0LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5TbywgY2hhdCBhd2F5LiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_942EFCF2AF6C4364B4E92466B9A8D0ACakamaicom_-- From nobody Sat Jan 16 13:41:48 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 5E1843A19E8 for ; Sat, 16 Jan 2021 13:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 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, RCVD_IN_MSPIKE_H2=-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=microsoft.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 mk2YAtEoQlBG for ; Sat, 16 Jan 2021 13:41:44 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640117.outbound.protection.outlook.com [40.107.64.117]) (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 C26D23A19E6 for ; Sat, 16 Jan 2021 13:41:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hppQQfPGPOOcq2I51v3/x0ubGHhCoZ1F1RDMwMRQRQ2XHxZkuN1/Klc/95rlGFSUIOAI0z6mlinTgFkj71zlQABd1xAt2TvylYyl2wdP6kR75ahcNSuTmxTcfy1XXrzbyCJDFQstXRq4gkdCqNdj+KaJCNI56Oe4vzz5RwnXZzi0SliWPzAI++55qVTM6XnisQIx/wQOXMScLaQkBJXMNLt2Xu2Nz2lZdgnMJvNcLvWZKbZSMBlXaZbBAJhLEEFNSQQY5t1HaQWlVUyY9KiWY3t0Uj81yCPUxnmlJT3eJV9SPSfdD4gjUPtb2QYH0+mKbG3m9zKICBGzSHTnLF+7Vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vPSvQTeitqYrcOHDtdExf1pb1As6o8OB6U1JL+Ttuac=; b=E0XvNPRn1q7yRP89CVjSLSaPyg//yFtmHImHaceK2Ivis14cFkg0efOvmtLw2OwkplIJIYbIi9vhjZNS3w8hi52Ix9/gLiI5Nmft8dzubQIZuGUT7dgwRxyi54xG78Tr1NAiOE5W355dzj3UsdyXMfp8IaBxx32M04f7vm19Cr+ER+ED50V4mpnkcwjG3xM2W+/Faton7wStiqT53dyAMlZL5pXyaHkII3DHH+Ro5sgu1aoHC7SqA+VUBjKTGCp6jigVF4EP4pIgLFsfqoStcqgRVpmTlXVfxs/MsCpEsbH8BjuDeruxtBr9nbOLDB8iGJaWe+AiVB1AiBVrmpQ+Lw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vPSvQTeitqYrcOHDtdExf1pb1As6o8OB6U1JL+Ttuac=; b=ZCsrWp2L1ItgsTKi2IpWNF59XqGNPfdj8qudmZvDO0F1dhbBLcbaNVpaQfEBHXxA60MAXGSf34RDnz6T6idK0XZRCFhNyV1vBG9H5HnnIjRrE9sSjHtB1ed0YDtyDukAuZsruNQdLZcEaHCrMLf0y1CygMJG4GTHiaXj1Pq5uX0= Received: from (2603:10b6:5:1bc::23) by DM6PR00MB0766.namprd00.prod.outlook.com (2603:10b6:5:20b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3807.0; Sat, 16 Jan 2021 21:41:37 +0000 Received: from DM6PR00MB0845.namprd00.prod.outlook.com ([fe80::6450:8a43:1d66:8d3d]) by DM6PR00MB0845.namprd00.prod.outlook.com ([fe80::6450:8a43:1d66:8d3d%5]) with mapi id 15.20.3812.000; Sat, 16 Jan 2021 21:41:37 +0000 From: Darrel Miller To: "sanjay.dalal@cal.berkeley.edu" , "httpapi@ietf.org" Thread-Topic: [httpapi] rfc7807 errata or just "more" Thread-Index: AQHW63flyWs2GD/CXEa43IG2VCAgqKoqxvae Date: Sat, 16 Jan 2021 21:41:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-01-16T21:41:37.745Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: cal.berkeley.edu; dkim=none (message not signed) header.d=none;cal.berkeley.edu; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [74.15.147.35] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b35c13bb-b0db-4ff5-5351-08d8ba678096 x-ms-traffictypediagnostic: DM6PR00MB0766: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xazfIbdDFiYZrT54Jq9tK5Iu/ukAakDIcfQxTHB+6MVTdsJXjjv4ZDW20Z57CPETZXzY8U0/+/PPPv0N1RQAOnpgE2rJh/b3qjPPVOpZH3Jv7qdkGSnv5xe5OoPUonZ4z73PYwtVyB0u/C5B4SQZklHCx6EED3MmyivS+5Qb7VieQ7TSdqU36DV5cG6BpU3PXGc1u31XvN0KzrhTWIlsrkd4FMahatgC1KKXgAQnOAY7n7ZjoM+Qc38mqO4Os9Q0Y9yfPRZCA9njMjTurru3I0NvHdqQs+EAy8VZkGstYrcFTGGHQ/qOopx459W2G16AEZMmlSwDWMPB949zFm+L3e3cJraiUaIfwLMXsiw40PBInET9ZP9l9qmd8s1x7NTIRsm6AKf8hqNdAz86DB7zp9TDMg3yFa9is1ksI/qNPDpvtx5WbYW0KL+t6Ishke3+dOVq7pD3tTdBC8xQO3znvvzRMFclzEg/Ur0crbeOLSou409yXeOFHKRBeTHWsRK/pKbaGx5R5BRQfHFS8bVK8w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0845.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(136003)(346002)(396003)(39860400002)(55016002)(9686003)(8676002)(5660300002)(10290500003)(8990500004)(186003)(76116006)(6506007)(83380400001)(71200400001)(33656002)(64756008)(52536014)(66446008)(66476007)(478600001)(66946007)(19627405001)(7696005)(86362001)(110136005)(8936002)(2906002)(82950400001)(316002)(26005)(66556008)(82960400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?qkDcofNE7Bz6S1B8CwILrP0UKzdyY8a8hsIFwS4JJCqIhekr3uz6W75win?= =?iso-8859-1?Q?FFjfwKlpfa3/gqWjELgLbiwi6lfCAF9x3JijZw/KXbtYdCv/G3vKJjUrqM?= =?iso-8859-1?Q?Dpl+O5b9tnm2o5mcwYl8obhYi74n2N3+3N4Fcv4CnfDOG1O4ex14mCZvAp?= =?iso-8859-1?Q?snmdSt5N0c3jLa1y9sALgE1Gr0afW3GgDDjLj5w+ybaKGz3ZIU35cjRkaj?= =?iso-8859-1?Q?BXVxddRck8rAyA9Qd1jKhYrIVoZ/BuN49BZvh7MA8eubIfegAmnBe2YRLg?= =?iso-8859-1?Q?5xOfVZmT4rhnTsgsZ/zGOPOd1EhCrUUSC2ce4kOy90Oaj+7WcWXWpAQVhE?= =?iso-8859-1?Q?vnESYny9fES3iN5CUjfdTmwMGne6dVP32YzkL+Yox+HO1HL5L8Ru39jyaZ?= =?iso-8859-1?Q?NHnh4youbCrFQne07pVa2Gg+On6w2LJ+OQ4u1dtFQccpcpAoSRj6h9xvIh?= =?iso-8859-1?Q?+AWAld4bbS+9lDzN1JkhwwZqENmFvSRIDnCIj8A5+r6lpUiXvWvBtMfrwi?= =?iso-8859-1?Q?7UXPz/2da1/m1L275NVu+8lPgq2MZNAudZ42DcRfAbw1bdLpASRNEXPQsa?= =?iso-8859-1?Q?D1YLYvXHWMAIAR8mn59DvxVj+KcwfjySymoQV/9l8cGC6klWRL+z/lHCV0?= =?iso-8859-1?Q?TEYQHi0yi73w9KWgm7gCU7Zun08yxELCMN0YaiA6Su39Wtg1mZ/gtVY272?= =?iso-8859-1?Q?1Yb1ceTu0aopPhJ2N/7ZgEap9avbNdVs+jNgR0iYIBFSocXmJ1Wx5Sple6?= =?iso-8859-1?Q?/JALb5dLToYAES/j2eyk5pmzlHsytKD7TehLvW4o40msze8VnJIjOIHBR3?= =?iso-8859-1?Q?8W5mVjcFTKCLrSh3PTreZIBA2QZkwtYBPsM9mwFbK6te8MuWOzO3qfaBvn?= =?iso-8859-1?Q?ua0eb4bGEwk0W0U2rDZH3ll3GTJhRouaV/HsssyPb/FvaBVF2YlQzQK1I5?= =?iso-8859-1?Q?v8N4gyP7gC7D+k9RV5HON9UtRGalCH64ocbFVtcmWpb7c99F7ENDRoyM9x?= =?iso-8859-1?Q?LSAltQGDR/VaSwLe4l5GA927vhr9Lu8iU+0fFiypg3ia2Iq3H5UVvz0cRv?= =?iso-8859-1?Q?BSnN1Fc03mwhUZ/z1O/WEzWvr7b2SxIkIoFrTVlqIb0C?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB08454A51EFCF8675F426EDA7F0A69DM6PR00MB0845namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0845.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b35c13bb-b0db-4ff5-5351-08d8ba678096 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2021 21:41:37.2935 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fpH9rYco58/LxH6f3HFSLK5n6eHtbePxDa8Z/j4ILjAB8lVHjgOZhsE5oAibs7MZ2IbX2G4OgqaXPawAeW52iQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0766 Archived-At: Subject: Re: [httpapi] rfc7807 errata or just "more" 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, 16 Jan 2021 21:41:46 -0000 --_000_DM6PR00MB08454A51EFCF8675F426EDA7F0A69DM6PR00MB0845namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sanjay, From: httpapi on behalf of Sanjay Dalal As you know, having multiple schema validation related errors in payload of= HTTP requests is a very common scenario for the HTTP APIs. I'm not sure an instances array is going to solve the issue here. In your = example, at the resource level, multiple issues have been detected as schem= a validation problems and you will need some explicit type to identify sche= ma validation problems.. As you say there may be many validation constrain= ts that were violated within the response payload. However, it is likely t= hat they are more than one type of validation failure. Just pointing to th= e instances of the failures without describing what kind of failures those = are would not be a great experience. That additional information about wha= t kind of failures each of those instances experienced is going to need to = be in extensions and the client will need to understand the semantics of th= e type. I accept there will be some scenarios where there are multiple instances of= problems associated to a single resource that are homogeneous, but there a= re going to be just as many that are heterogenous. I don't really see the = issue with using the type to define the necessary extensions. Darrel --_000_DM6PR00MB08454A51EFCF8675F426EDA7F0A69DM6PR00MB0845namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Sanjay,

From: httpapi <httpapi-b= ounces@ietf.org> on behalf of Sanjay Dalal 

As you know, having multiple schema v= alidation related errors in payload of HTTP requests is a very common scena= rio for the HTTP APIs. 

I'm not sure an instances array is go= ing to solve the issue here.  In your example, at the resource level, = multiple issues have been detected as schema validation problems and you wi= ll need some explicit type to identify schema validation problems..  As you say there may be many validation constr= aints that were violated within the response payload.  However, it is = likely that they are more than one type of validation failure.  Just p= ointing to the instances of the failures without describing what kind of failures those are would not be a great experience= .  That additional information about what kind of failures each of tho= se instances experienced is going to need to be in extensions and the clien= t will need to understand the semantics of the type.

I accept there will be some scenarios= where there are multiple instances of problems associated to a single reso= urce that are homogeneous, but there are going to be just as many that are = heterogenous.  I don't really see the issue with using the type to define the necessary extensions.

Darrel

--_000_DM6PR00MB08454A51EFCF8675F426EDA7F0A69DM6PR00MB0845namp_-- From nobody Sat Jan 16 14:12:50 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 B7A003A124F for ; Sat, 16 Jan 2021 14:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 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, RCVD_IN_MSPIKE_H2=-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=microsoft.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 sLLdT_uZTwTJ for ; Sat, 16 Jan 2021 14:12:46 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650120.outbound.protection.outlook.com [40.107.65.120]) (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 99CC63A11DB for ; Sat, 16 Jan 2021 14:12:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mKk2xQcq53SXCqmbhTm772UpmOC1sD8Y+4FdnYT9PGsbRadxPHNoK1/EtU1quNC9GFBBW6bL/GcTMKc3jyU78CfDtKNAHfefnOf84nXSktnxRPJ7y9IwkCPPF5E+JVrkgVzy0NSouNcqYXbJG4MHu2x28UCP59az8PN3X09FQcGQvn82CPzjY8v3KxiHM/T0cKkLg/O+oxOnhWBMs6hFsP89TYakVABEtM2xl468ZuN41xpbMcbbwd0xi7DDsRayqVlkuiI5qswwskH5Q6l3RxeWtq38/V0cqVJTsT7HMLFgVVk67Y4eCBQoXsTOEdzbQNseEv+OmycGtNCKbotOEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xdQi0UXPFnx5gKDGTFvrnFbTETdUrO8Khh+QLRa6jbc=; b=lN/aZmizPp2XBr7plw8unkyAmHFxzQsJWKmV4UNJ6euCVAAiLbg4e3tIcu4t0sR6Xq2E5Im1XyjROxDBbWdLmvjgD/FamAlBuEpZcM5DvDtoYp3wL5uOUq51gtBvxrcfN+fiHIRoeAPNeMpmAdZfjueK38giJ1IJ0h+1Qs/nNIjEY70dSRFl8DYUx/IHLc4byZ1+BNwI/h22bkoKTYmA2AQsSCyGkIlAfdfC7M4yToMHBnxGBFciATo4c7Orp8NKWePovFxCepVDDd1QN2OZZ2T51bhqqEL7bqmuywaqvhXzvv6J5lRkvhpE9Nm5MFUlDH/fVJ4HyhpECTnenFfIyA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xdQi0UXPFnx5gKDGTFvrnFbTETdUrO8Khh+QLRa6jbc=; b=WfVgPcvvNKFwVkSY4ah8kR78XvsR+eDqGBIb2/Uk8JV5FHTmjvTsVm2Z5bw8jmGUCCKLmba1cDHYppdRbJuDx8hYlL31m7hAeBY1xX3kLwvIsHHXXCzyCcsZkYkUBIJ62AXY8luWpZbdYL6rE6A2r+UuB+YG3whrKMzfhRfBIGg= Received: from (2603:10b6:5:1bc::23) by DM6PR00MB0765.namprd00.prod.outlook.com (2603:10b6:5:1bd::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3809.0; Sat, 16 Jan 2021 22:12:35 +0000 Received: from DM6PR00MB0845.namprd00.prod.outlook.com ([fe80::6450:8a43:1d66:8d3d]) by DM6PR00MB0845.namprd00.prod.outlook.com ([fe80::6450:8a43:1d66:8d3d%5]) with mapi id 15.20.3812.000; Sat, 16 Jan 2021 22:12:35 +0000 From: Darrel Miller To: "christoph.kappestein@gmail.com" , "httpapi@ietf.org" Thread-Topic: [httpapi] Discussion about JSON payloads and code generation Thread-Index: AQHW7AmIPyJ32zvjfE6Ci8mHOwNnYKoqynhf Date: Sat, 16 Jan 2021 22:12:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-01-16T22:12:36.555Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [74.15.147.35] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d4522eb9-de6a-46c0-3a0b-08d8ba6bd443 x-ms-traffictypediagnostic: DM6PR00MB0765: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Y2lF12NuLAe6ri3k45FM/dKrakiM7qhtHJ3W+p570YKsng8DVv8JOdWoTt8zc2mOXSwaKUnbYjWK8w30vAYLq//vE9WZ/KCKx8bmRAgxoEaO4hP9jAKqzdATyF1nwOcghJtukIQF2ionRRve9uOvwyZNB98imx/A3RrpkKBFnQynDPcGQvHGx3f5jEWHYhN5Gztl7zrtZ/OMtAJSrHlgPDh5pIMgZhdjOea++C+lbMesHd84EiNArc6pVg5/eeB1fXWURDdnbFF0mjsiwzJhC9rBw+oV11mxVV0H4ovedr2lqhiLEN2Png1ihv3pWv+JWygf5DMve64ElxER9dB5THR1hwuv16cUH7vVWXqQiFy1SSNn/5ahvygbECJ8WfCZzIvLhSFJ+F+GyfUSeVq/LGVLR+Tg+TL4aaXKJl9yMaS9MySw+KdFoJVj6qQlLA/3IKFc763YLQozk+JNBP8sV2WZS5GhbqnjdY6/6IOxZdAqNUS0bcN0Z6wv6H96mXs+BECmKaFANsV69TYPoh5eaYIA/W7tOte9zj6irCT28h47MlAw4yisokNndu3kKhRqxc7N2yO3CIo0ZTDw7up8hXZ7qPca5oZfxHOqEERcCwgzFXjKBH+0onJWumTwje8WAq1Oycy/ax57RSjR9rKm/w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0845.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(346002)(376002)(136003)(39860400002)(186003)(6506007)(26005)(7696005)(19627405001)(966005)(316002)(66946007)(110136005)(55016002)(8676002)(478600001)(10290500003)(9686003)(82950400001)(76116006)(64756008)(5660300002)(82960400001)(86362001)(52536014)(33656002)(166002)(71200400001)(8936002)(66556008)(66446008)(8990500004)(2906002)(66476007)(443494004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?yBW6DKj/9liplJ9+J80vSuA7WmF4N6E5csmWRc919tsRzEyIWqKAY4jbAR?= =?iso-8859-1?Q?i2+V0oyBXq9qPjGslpsnBjeWS4lsBFvLpYjXE8DKgAGX2DoaZgBeNDHd9D?= =?iso-8859-1?Q?fO+qzbrwHQEcdOdY0DGZAEwhjN9hzcPbjV+EUumf74h+4xZ2xa2VoAKuZ3?= =?iso-8859-1?Q?OsXonFMnrd3L9pqy77zNO1+4LpXPDMJ++OIaSHyuxfUzbgZIJngMG5CxZp?= =?iso-8859-1?Q?jxJI0jR/cX/k8jwhi5XdxEM9a4HtEj2aZZuq9QfE3V1Xk259ZuOXhRb8TA?= =?iso-8859-1?Q?4zPPdhA67GVyP51UbQ22qNK14Nj/lqHiL6D7i35nq19P1tgVmdWvHEgXsn?= =?iso-8859-1?Q?Zkg0KKjBpGqZ3lUEQ08TDuy79xZ69P2N6E96FqYF4q9wf+tZV/AQWdN+G9?= =?iso-8859-1?Q?SbjUQcCbGFL5BsrSiMXchaYxuVH5+fFFAH6N8ksMt/5WHlOagY2MVURSXI?= =?iso-8859-1?Q?PMW9VTajLqlk/5XF9+nZqa8LemzfEcNeTGmqkk8fVGWYhpUK9QDFeGXp1b?= =?iso-8859-1?Q?Rn/6AsDFRlXvUnbbrrNbIjc9CuO+sUB70Cmnzb1K9al+vKOfm7KJqFU3sX?= =?iso-8859-1?Q?eIXTtGK0AR2PfquH8kiUNSyTUIO4OWh+J5qlw/Sjb9vOfjuttoXRgNj01X?= =?iso-8859-1?Q?oXyOhBMmFjWFNUdrmblzK+emPOKWrS/F7EIkC7CPDh5eCgRGcHAqOlcVX2?= =?iso-8859-1?Q?kDQMarY85HcMZ60dLaKe+2Tvgbnw9wPQqj0TDbC/SIucD7nhgFV8hGg+5b?= =?iso-8859-1?Q?YJy5wBLBUMwxxiyKRHqP8yWLuemy+R5CAN/oZRT80AtnPNePPZqm5dhjjq?= =?iso-8859-1?Q?+HTP8/O8bnlKWY4oqSeZjD3pTbNv90KHNqfx42rI+UlqFhC9v3GeJ9f/hb?= =?iso-8859-1?Q?kbmdsnUcz86ScrN9l5T8mfMWJL3lsYFEuVLrzVMAco+KLPqJFAejirINrL?= =?iso-8859-1?Q?6f/YC5Mi+JdXPboQZJXcr2/l7oYIK3Siqtb+ZXfWNxofd/h74RcmAKXG57?= =?iso-8859-1?Q?6X6U4ET4W2ljk/Uociqgm3DQfeBEvTDuFPb4qfkXekEa6DvTFQG0t6H/QO?= =?iso-8859-1?Q?+JuLg0tcfuyKgHH8DNsUuAunnN8ljtQMHdYBKT9Ae5td?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0845824BE38945071F9774A5F0A69DM6PR00MB0845namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0845.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d4522eb9-de6a-46c0-3a0b-08d8ba6bd443 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2021 22:12:35.7949 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wl8b4ofqdoX86Bf8J0wFUNADBnFgsZsNNNaVFyMKmGyMwuMVY+xRYr5LqDYM6KFi2updD2VizZj1trsYSe4eMg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0765 Archived-At: Subject: Re: [httpapi] Discussion about JSON payloads and code generation 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, 16 Jan 2021 22:12:49 -0000 --_000_DM6PR00MB0845824BE38945071F9774A5F0A69DM6PR00MB0845namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Christoph, From: httpapi on behalf of Christoph Kappestein = I would like to gauge whether there is some interest in discussing ways to = describe JSON payloads with a focus on code generation on this WG. Also it = would be interesting to gather feedback from other developers who have expe= riences in this space. As an editor of the OpenAPI spec, that relies heavily on JSON Schema, consi= der my perspective to be heavily biased here. But I do agree wholeheartedly= that JSON Schema has challenges when it comes to describing types for code= generation. However, I would be reluctant to go down a path of defining a= new specification for describing types. The recent Postman developer survey https://www.postman.com/state-of-api/ f= ound that in their 13,000 respondents, 75% of them claimed to be users of J= SON Schema. Convincing developers to move to a different format is going t= o require a compelling alternative. What would be awesome to see is if a community could form around creating a= new JSON Schema vocabulary that targets type description. JSON Schema its= elf is now defined by a set of vocabularies, one of which is the validation= vocabulary. I know the JSON Schema core team have been looking for someon= e to spearhead this effort. https://github.com/json-schema-org/json-schem= a-vocabularies By taking this approach, the existing JSON Schema specifications and artifa= cts can be leveraged, and the new type definition keywords could be used al= ongside the validation keywords. Darrel --_000_DM6PR00MB0845824BE38945071F9774A5F0A69DM6PR00MB0845namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Christoph,

From: httpapi <httpapi-b= ounces@ietf.org> on behalf of Christoph Kappestein <christoph.kappest= ein@gmail.com>

I would like to gauge whether there is some interest in discussing way= s to describe JSON payloads with a focus on code generation on this WG. Als= o it would be interesting to gather feedback from other developers who have= experiences in this space.

As an editor of the OpenAPI spec, that relies heavily on JSON Schema, = consider my perspective to be heavily biased here. But I do agree wholehear= tedly that JSON Schema has challenges when it comes to describing types for= code generation.  However, I would be reluctant to go down a path of defining a new specification for describ= ing types.  

The recent Postman developer survey https://www.postman.com/state-of-api/ found t= hat in their 13,000 respondents, 75% of them claimed to be users of JSON Sc= hema.  Convincing developers to move to a different format is going to require a compelling alternative.

What would be awesome to see is if a community could form around creat= ing a new JSON Schema vocabulary that targets type description.  JSON = Schema itself is now defined by a set of vocabularies, one of which is the = validation vocabulary.  I know the JSON Schema core team have been looking for someone to spearhead this effort.&n= bsp;  https://github.com/json-schema-org/json-schema-vocabularies

By taking this approach, the existing JSON Schema specifications and a= rtifacts can be leveraged, and the new type definition keywords could be us= ed alongside the validation keywords.

Darrel


--_000_DM6PR00MB0845824BE38945071F9774A5F0A69DM6PR00MB0845namp_-- From nobody Sun Jan 17 03:46:39 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 AAF9F3A100E for ; Sun, 17 Jan 2021 03:46:37 -0800 (PST) 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 CcIQZbmiGSYX for ; Sun, 17 Jan 2021 03:46:35 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450: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 451C63A100C for ; Sun, 17 Jan 2021 03:46:35 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id h205so19892606lfd.5 for ; Sun, 17 Jan 2021 03:46: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=njUYIocrbz7JGjvY7qfGfamNpZSsrSAVmsVLzKb5kCc=; b=Ud7493L07sVmzb/xh5t+viVl27dVX90vo+x4lfLbztRMm/33lzBeCwR88fV5qRk2hv xzMKb4hjXuIDyu995dTca79lzzK+YlBSDFkY2UfJuG6++v+0ptixHyx4Z/t4Uj+HM4v4 M5xJzPYm33AktpSmjpHcN2MBz3eDN+G+dNcrn4gsaaYkaGpRpa6VWsnpD0S/JwmR6vYc L/EaZnAlYEWiqunpUJ0Ik3hgMW4NY3+RSA9klD3ZvFIgEObhlW4jBur4nANF271lnYLv I3k/+bAX5Sz+DDeHmhDb74oCWfUTPfdFfmpsp5cxePnHcE4YipzBPT7NtNGmx8gh1jDK 6toQ== 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=njUYIocrbz7JGjvY7qfGfamNpZSsrSAVmsVLzKb5kCc=; b=qtjXrj4gZDLTvW1bDw34UJBIwtuMga++GEdAzYi8On2C3FWr2vEXErePZpngDVMtYd Cj4vZF8b9irZJrvjJvFoFj0KaAXDDM4beYOXRP++DQInSJ4objxtz0j4tbyyht2BM8zA VkE/uYV1HYFEdabBoTx93M4Th0fLjFEX8VIJinjxNhzcFrxKefq+5aIKWCejMCDaxmGS OXQXQpLMIBodp8vofmN1Yx1nF+uY29KJZIpTcRdsj3fjmKCK1w9U/gPaXNdXqVUx79V6 nPUrvgc+hbSsLOzP7wPV1jFlad1ZM6HtIfhNxuG7cliiCOaHlsyShCpltCoFnlbD8VWX KojA== X-Gm-Message-State: AOAM530fMywygtp2RD1G8phAR5eyZnhEzg8tqbylr16yZVaAEWZvEV0s Te6+erTF3mtbbY2El9sDffztGjk0Uya1FoaVPUU= X-Google-Smtp-Source: ABdhPJxFm3amPL2OxAXeVGk0iIrzVM2HNeBsW2tX9q/YURn1lNeRVbonmYqLhW14u6g5LjSPM7CuWo01xw9ogkJmsac= X-Received: by 2002:a19:3d5:: with SMTP id 204mr8731347lfd.21.1610883992893; Sun, 17 Jan 2021 03:46:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Christoph Kappestein Date: Sun, 17 Jan 2021 12:46:21 +0100 Message-ID: To: Darrel Miller Cc: "httpapi@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002bbb0205b9172885" Archived-At: Subject: Re: [httpapi] Discussion about JSON payloads and code generation 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: Sun, 17 Jan 2021 11:46:38 -0000 --0000000000002bbb0205b9172885 Content-Type: text/plain; charset="UTF-8" Hi Darrel, Thank you for the feedback. I understand that it is not easy possible to change the schema specification but I had the hope that the OpenAPI spec will be in future versions more JSON schema independent. I.e. that a user could use XSD, JTD, Protobuf or any other specification to describe the request/response payload, also for payloads in the future which are not JSON. So that a user is not forced to use JSON schema and that an alternative could emerge. A core editor from the JSON schema spec has already approached me regarding a vocabulary, but from my point of view I think that those vocabularies inherit many properties from JSON schema which are not ideal for code generation. In the spirit of "do one thing and do it well" we could have different specifications for specific use cases, which would be a much more flexible framework than forcing every schema to be a vocabulary. A generator could then support only specific schema types. If I remember correctly the RAML specification solved this also in a similar way. This approach would be also great for the OpenAPI since they do not have to force a different schema spec but the users can decide which is the optimal solution. Thanks to the link of the API report, I was not aware of it and it looks really interesting. Regarding the OpenAPI spec, for me it would be really interesting to know whether there is such a plan to make the schema description part more JSON schema independent? best regards Christoph Am Sa., 16. Jan. 2021 um 23:12 Uhr schrieb Darrel Miller < Darrel.Miller@microsoft.com>: > Hi Christoph, > > *From:* httpapi on behalf of Christoph > Kappestein > > I would like to gauge whether there is some interest in discussing ways to > describe JSON payloads with a focus on code generation on this WG. Also it > would be interesting to gather feedback from other developers who have > experiences in this space. > > > As an editor of the OpenAPI spec, that relies heavily on JSON Schema, > consider my perspective to be heavily biased here. But I do agree > wholeheartedly that JSON Schema has challenges when it comes to describing > types for code generation. However, I would be reluctant to go down a path > of defining a new specification for describing types. > > The recent Postman developer survey https://www.postman.com/state-of-api/ found > that in their 13,000 respondents, 75% of them claimed to be users of JSON > Schema. Convincing developers to move to a different format is going to > require a compelling alternative. > > What would be awesome to see is if a community could form around creating > a new JSON Schema vocabulary that targets type description. JSON Schema > itself is now defined by a set of vocabularies, one of which is the > validation vocabulary. I know the JSON Schema core team have been looking > for someone to spearhead this effort. > https://github.com/json-schema-org/json-schema-vocabularies > > By taking this approach, the existing JSON Schema specifications and > artifacts can be leveraged, and the new type definition keywords could be > used alongside the validation keywords. > > Darrel > > > --0000000000002bbb0205b9172885 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Darrel,

Thank you for the feedback. I understand= that it is not easy possible to change the schema specification but I had = the hope that the OpenAPI spec will be in future versions more JSON schema = independent. I.e. that a user could use XSD, JTD, Protobuf or any other spe= cification to describe the request/response payload, also for payloads in t= he future which are not JSON. So that a user is not forced to use JSON sche= ma and that an alternative could emerge.

A core editor from the JSON= schema spec has already approached me regarding a vocabulary, but from my = point of view I think that those vocabularies inherit many properties from = JSON schema which are not ideal for code generation. In the spirit of "= ;do one thing and do it well" we could have different specifications f= or specific use cases, which would be a much more flexible framework than f= orcing every schema to be a vocabulary. A generator could then support only= specific schema types. If I remember correctly the RAML specification solv= ed this also in a similar way. This approach would be also great for the Op= enAPI since they do not have to force a different schema spec but the users= can decide which is the optimal solution.

Thanks to the link of the= API report, I was not aware of it and it looks really interesting. Regardi= ng the OpenAPI spec, for me it would be really interesting to know whether = there is such a plan to make the schema description part more JSON schema i= ndependent?

best regards
Christoph


Am Sa= ., 16. Jan. 2021 um 23:12=C2=A0Uhr schrieb Darrel Miller <Darrel.Miller@microsoft.com>:
Hi Christoph,

From= : httpapi <httpapi-bounces@ietf.org> on behalf of Christoph Kappestein <= ;christ= oph.kappestein@gmail.com>

I would like to gauge whether there is some interest in discussing way= s to describe JSON payloads with a focus on code generation on this WG. Als= o it would be interesting to gather feedback from other developers who have= experiences in this space.

As an editor of the OpenAPI spec, that relies heavily on JSON Schema, = consider my perspective to be heavily biased here. But I do agree wholehear= tedly that JSON Schema has challenges when it comes to describing types for= code generation.=C2=A0 However, I would be reluctant to go down a path of defining a new specification for describ= ing types.=C2=A0=C2=A0

The recent Postman developer survey=C2=A0https://www.postman.com/state-of-api= /=C2=A0found that in their 13,000 respondents, 75% of them claimed to b= e users of JSON Schema.=C2=A0 Convincing developers to move to a different format is going to require a compelling alternative.

What would be awesome to see is if a community could form around creat= ing a new JSON Schema vocabulary that targets type description.=C2=A0 JSON = Schema itself is now defined by a set of vocabularies, one of which is the = validation vocabulary.=C2=A0 I know the JSON Schema core team have been looking for someone to spearhead this effort.= =C2=A0 =C2=A0https://github.com/json-schema-org/json-schema-= vocabularies

By taking this approach, the existing JSON Schema specifications and a= rtifacts can be leveraged, and the new type definition keywords could be us= ed alongside the validation keywords.

Darrel


--0000000000002bbb0205b9172885-- From nobody Sun Jan 17 12:41: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 5824E3A1398 for ; Sun, 17 Jan 2021 12:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, 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=neutral reason="invalid (public key: invalid data)" header.d=hyperjump.io 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 L8WPkRSidwuR for ; Sun, 17 Jan 2021 12:41:02 -0800 (PST) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 4B7133A1397 for ; Sun, 17 Jan 2021 12:41:02 -0800 (PST) Received: by mail-oi1-x235.google.com with SMTP id d203so15717099oia.0 for ; Sun, 17 Jan 2021 12:41:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hyperjump.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eYIhm4avrND7q4N+KE1jh9lC2gXi/rtOQW8QwEj70vc=; b=a5fO6t+Y/yu5tZQG44vqz6CbBNK9Av6WGcv4jgX2Exyvu+aZPPx4j20QpKP41CjqIh zE6juBzQ5ZmKugYUKDkFwuU8v859SCn3Su17CspxPqWVqrYUp2yTK+nM35TeJsvZpPaN PyZcaEUFLUcviqjGqum6UWMYwPaqn6kjXcYH3d4hSCD+tURNDzifU6hQNpf64W6e0hcp Hfz+7qn36wMoZh7amcGlkWi2Baa4aFzuMj6xB86xxy4xR7Uuzq46V6r/KJbBfmPyE0k3 WPPCUFF5thAXBG4KOI1gl0pYPohMjxGtwh2SD9Ebf8Coi9uTZAAdzWo0mHmaik9S2/E7 2ALg== 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=eYIhm4avrND7q4N+KE1jh9lC2gXi/rtOQW8QwEj70vc=; b=cQjimOHgi9afbGn2E57OEpbp6pC89PwLjg1VNLEMBEni/YOrcbeXtl+OYk5fLyyWUj HfYmONMUvrsE8Rd2O3O9+GLqRVuygBZ9kInTFpGODJN5UFPJuDGL9NHordO5kZO+06j7 30f2Nhxdl3xWtRvKIJCMS0fxgPMzYmVQD8mJ0T8owGNW48lCLAeLV5ZcQUsNyTiz8rXf upMz+65dBLFOVNmzZoE7y9kNGm9LUH0L+skebKj5eRT1IVCrJOmr6Mbm2s58PbOYdlYk s8LtiSD0P0RsHKR61ZR1lMxji0i2Gkrg1dWDw1tbwKHpLwsuieL/3THBXFhSE7YkGK6t 0wyg== X-Gm-Message-State: AOAM533hcBgS6CAgnyr5JnE9nZkBlCeahXaty5nful+180WZYTCYymn/ K78bjHVoGNaOqJ+Tk3JD7DeK1KzlBlV7Vu/miBhazQ== X-Google-Smtp-Source: ABdhPJwgrUlCAnL91e9dH0yFsK9DjXsCcunqg1hPgRHNObK9oab7/04vtZe+4JTfIpd8QnyEBMUTzlQWBtE0t6ULD6s= X-Received: by 2002:aca:bac3:: with SMTP id k186mr10887446oif.93.1610916061405; Sun, 17 Jan 2021 12:41:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jason Desrosiers Date: Sun, 17 Jan 2021 12:40:50 -0800 Message-ID: To: Christoph Kappestein Cc: Darrel Miller , "httpapi@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009a77bc05b91e9fb5" Archived-At: Subject: Re: [httpapi] Discussion about JSON payloads and code generation 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: Sun, 17 Jan 2021 20:41:04 -0000 --0000000000009a77bc05b91e9fb5 Content-Type: text/plain; charset="UTF-8" Hi Christoph, Even if/when OpenAPI allows you to use something other than JSON Schema, I think you still have a serious problem. The problem with "do one thing and do it well" in this case is that you end up with a lot of duplication. I don't want to have to maintain separate and almost identical sets of schemas for code generation, validation, documentation, etc. Ideally, you would start with a simple and flexible core that other specifications can build off of to progressively enhance the core. That's what we're trying to enable with JSON Schema vocabularies. I believe it's possible to define a JSON Schema vocabulary for code generation that progressively enhances standard JSON Schema so only one schema needs to be maintained. I say that with all due humility and willingness to wrong. I have never attempted to implement a JSON Schema based code generator, but I have written other tooling with this kind of thing in mind. In our Github Issue, I'll share more details about how I think the problems you identified could be solved without breaking JSON Schema validation. Full disclosure: I am a member of the JSON Schema core team, so I should be considered even more biased than Darrel :-). But, even if you decide not to align with JSON Schema, I'd be happy to share lessons we've learned from developing JSON Schema that might apply to TypeSchema as well. Jason Desrosiers On Sun, Jan 17, 2021 at 3:46 AM Christoph Kappestein < christoph.kappestein@gmail.com> wrote: > Hi Darrel, > > Thank you for the feedback. I understand that it is not easy possible to > change the schema specification but I had the hope that the OpenAPI spec > will be in future versions more JSON schema independent. I.e. that a user > could use XSD, JTD, Protobuf or any other specification to describe the > request/response payload, also for payloads in the future which are not > JSON. So that a user is not forced to use JSON schema and that an > alternative could emerge. > > A core editor from the JSON schema spec has already approached me > regarding a vocabulary, but from my point of view I think that those > vocabularies inherit many properties from JSON schema which are not ideal > for code generation. In the spirit of "do one thing and do it well" we > could have different specifications for specific use cases, which would be > a much more flexible framework than forcing every schema to be a > vocabulary. A generator could then support only specific schema types. If I > remember correctly the RAML specification solved this also in a similar > way. This approach would be also great for the OpenAPI since they do not > have to force a different schema spec but the users can decide which is the > optimal solution. > > Thanks to the link of the API report, I was not aware of it and it looks > really interesting. Regarding the OpenAPI spec, for me it would be really > interesting to know whether there is such a plan to make the schema > description part more JSON schema independent? > > best regards > Christoph > > > Am Sa., 16. Jan. 2021 um 23:12 Uhr schrieb Darrel Miller < > Darrel.Miller@microsoft.com>: > >> Hi Christoph, >> >> *From:* httpapi on behalf of Christoph >> Kappestein >> >> I would like to gauge whether there is some interest in discussing ways >> to describe JSON payloads with a focus on code generation on this WG. Also >> it would be interesting to gather feedback from other developers who have >> experiences in this space. >> >> >> As an editor of the OpenAPI spec, that relies heavily on JSON Schema, >> consider my perspective to be heavily biased here. But I do agree >> wholeheartedly that JSON Schema has challenges when it comes to describing >> types for code generation. However, I would be reluctant to go down a path >> of defining a new specification for describing types. >> >> The recent Postman developer survey https://www.postman.com/state-of-api/ found >> that in their 13,000 respondents, 75% of them claimed to be users of JSON >> Schema. Convincing developers to move to a different format is going to >> require a compelling alternative. >> >> What would be awesome to see is if a community could form around creating >> a new JSON Schema vocabulary that targets type description. JSON Schema >> itself is now defined by a set of vocabularies, one of which is the >> validation vocabulary. I know the JSON Schema core team have been looking >> for someone to spearhead this effort. >> https://github.com/json-schema-org/json-schema-vocabularies >> >> By taking this approach, the existing JSON Schema specifications and >> artifacts can be leveraged, and the new type definition keywords could be >> used alongside the validation keywords. >> >> Darrel >> >> >> -- > httpapi mailing list > httpapi@ietf.org > https://www.ietf.org/mailman/listinfo/httpapi > --0000000000009a77bc05b91e9fb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Christoph,

Even if/when O= penAPI allows you to use something other than JSON Schema, I think you stil= l have a serious problem. The problem with "do one thing and do it wel= l" in this case is that you end up with a lot of duplication. I don= 9;t want to have to maintain separate and almost identical sets of schemas = for code generation, validation, documentation, etc. Ideally, you would sta= rt with a simple and flexible core that other specifications can build off = of to progressively enhance the core. That's what we're trying to e= nable with JSON Schema vocabularies.

I believe= it's possible to define a JSON Schema vocabulary for code generation t= hat progressively enhances standard JSON Schema so only one schema needs to= be maintained. I say that with all due humility and willingness to wrong. = I have never attempted to implement a JSON Schema based code generator, but= I have written other tooling with this kind of thing in mind. In our Githu= b Issue, I'll share more details about how I think the problems you ide= ntified could be solved without breaking JSON Schema validation.
=
Full disclosure: I am a member of the JSON Schema core team,= so I should be considered even more biased than Darrel :-). But, even if y= ou decide not to align with JSON Schema, I'd be happy to share lessons = we've learned from developing JSON Schema that might apply to TypeSchem= a as well.

Jason Desrosiers
On Sun, J= an 17, 2021 at 3:46 AM Christoph Kappestein <christoph.kappestein@gmail.com> wrote:
Hi Da= rrel,

Thank you for the feedback. I understand that it is not easy p= ossible to change the schema specification but I had the hope that the Open= API spec will be in future versions more JSON schema independent. I.e. that= a user could use XSD, JTD, Protobuf or any other specification to describe= the request/response payload, also for payloads in the future which are no= t JSON. So that a user is not forced to use JSON schema and that an alterna= tive could emerge.

A core editor from the JSON schema spec has alrea= dy approached me regarding a vocabulary, but from my point of view I think = that those vocabularies inherit many properties from JSON schema which are = not ideal for code generation. In the spirit of "do one thing and do i= t well" we could have different specifications for specific use cases,= which would be a much more flexible framework than forcing every schema to= be a vocabulary. A generator could then support only specific schema types= . If I remember correctly the RAML specification solved this also in a simi= lar way. This approach would be also great for the OpenAPI since they do no= t have to force a different schema spec but the users can decide which is t= he optimal solution.

Thanks to the link of the API report, I was not= aware of it and it looks really interesting. Regarding the OpenAPI spec, f= or me it would be really interesting to know whether there is such a plan t= o make the schema description part more JSON schema independent?

be= st regards
Christoph


Am Sa., 16. Jan. 2021 um 23= :12=C2=A0Uhr schrieb Darrel Miller <Darrel.Miller@microsoft.com>:
=
Hi Christoph,

From: httpapi <httpapi-bounces@ietf.org> on behalf= of Christoph Kappestein <christoph.kappestein@gmail.com>

I would like to gauge whether there is some interest in discussing way= s to describe JSON payloads with a focus on code generation on this WG. Als= o it would be interesting to gather feedback from other developers who have= experiences in this space.

As an editor of the OpenAPI spec, that relies heavily on JSON Schema, = consider my perspective to be heavily biased here. But I do agree wholehear= tedly that JSON Schema has challenges when it comes to describing types for= code generation.=C2=A0 However, I would be reluctant to go down a path of defining a new specification for describ= ing types.=C2=A0=C2=A0

The recent Postman developer survey=C2=A0https://www.postman.com/state-of-api= /=C2=A0found that in their 13,000 respondents, 75% of them claimed to b= e users of JSON Schema.=C2=A0 Convincing developers to move to a different format is going to require a compelling alternative.

What would be awesome to see is if a community could form around creat= ing a new JSON Schema vocabulary that targets type description.=C2=A0 JSON = Schema itself is now defined by a set of vocabularies, one of which is the = validation vocabulary.=C2=A0 I know the JSON Schema core team have been looking for someone to spearhead this effort.= =C2=A0 =C2=A0https://github.com/json-schema-org/json-schema-= vocabularies

By taking this approach, the existing JSON Schema specifications and a= rtifacts can be leveraged, and the new type definition keywords could be us= ed alongside the validation keywords.

Darrel


--
httpapi mailing list
httpapi@ietf.org<= br> https://www.ietf.org/mailman/listinfo/httpapi
--0000000000009a77bc05b91e9fb5-- From nobody Sun Jan 17 13:17:45 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 F02433A083B for ; Sun, 17 Jan 2021 13:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 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, RCVD_IN_MSPIKE_H2=-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=microsoft.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 kE1nroC5WtuL for ; Sun, 17 Jan 2021 13:17:42 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640136.outbound.protection.outlook.com [40.107.64.136]) (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 EB6A73A0813 for ; Sun, 17 Jan 2021 13:17:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=elmwn/46YTbZFxjez+NP4F1Bl0iJ+2X7q9DuLZRWegADqfth+WQlowRchjoOpCMNe718abaSX/IhqoiA8Jq/hf6yXZ3jLAh1nnloFsd7oiit+4iUqZjvYyjSb95Up7vx0vK9RUKKMaYTF2pVJJe/IXRLqxfNKxWJWqfcM2/3rCVU3mq573Om+tRXa2YElah6GOZDARkxl3v2P4kExjfgk3un5cxfTwRUFRHoAmwi/IrgjcROCBzA1/nGwAUN3EGpOecyuvGEA8/RGVpaeOCc9LpnbkkCeL8gVNUZj7xETmANDS863+vsIQokCrP8BH53+O++jlu0YrcLca5FKJt4sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eRlaBNnI4/rLm9Ar5CdA78CBaqNT/S0QUTemdMi35VQ=; b=jGcoedV7RNv6JFZRfNgunzNMEma4xkTuKw5WARlGUZDR6UlYKrWrx/6EG3d83drXuXsC9hnsDlxrFUU4WLL4UImzD6SQaRp7EGCJyn/FIgqJU8XrY4BSDQ19OtAeq6aEaMKSas44DeQFkrkqpvWh1glGCT6iCmXnDe/knZQAh3TRiWcv3cV2+NojZ0llZReOtCbkXwbAeDAvrybpGUDsP27TR3YWeDTRBtKySKu0655jZMCVF1ieCrlFXtD81mwvvStVnLZXtOtfOcqy4J4AoS/mGrwbhwfNw7NdAZQ2y2rYXJZ63M+KVp6j5d1vk7XqAgqt6gndRkpXyCgpjz2yAg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eRlaBNnI4/rLm9Ar5CdA78CBaqNT/S0QUTemdMi35VQ=; b=FHnK2fImLjCn2r93u19jlzUawV88gCtajRxijXAPKyhRm+HnLuy/SGDjEU2WFMx8/K9GSDal5QjmfWfjbz/y2poofkIJRs2jaCtuPAWSqF7zDZTem6sOBX9Fx092RNNH25R8YKR2mgPXMFaiXeE8T173znMOYGKsswb9Ea6E8hY= Received: from (2603:10b6:208:1c1::19) by BL0PR00MB0753.namprd00.prod.outlook.com (2603:10b6:208:1c2::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3814.0; Sun, 17 Jan 2021 21:17:28 +0000 Received: from BL0PR00MB0836.namprd00.prod.outlook.com ([fe80::f8d2:c96e:f99d:a228]) by BL0PR00MB0836.namprd00.prod.outlook.com ([fe80::f8d2:c96e:f99d:a228%9]) with mapi id 15.20.3814.000; Sun, 17 Jan 2021 21:17:28 +0000 From: Darrel Miller To: "christoph.kappestein@gmail.com" CC: "httpapi@ietf.org" Thread-Topic: [httpapi] Discussion about JSON payloads and code generation Thread-Index: AQHW7AmIPyJ32zvjfE6Ci8mHOwNnYKoqynhfgADqNICAAI74Bw== Date: Sun, 17 Jan 2021 21:17:28 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-01-17T21:17:27.318Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [74.15.147.35] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b397278c-b663-4763-daea-08d8bb2d4b4b x-ms-traffictypediagnostic: BL0PR00MB0753: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: b1Vi+LEbEDYVD4btqdzrsholjb1fVkdrWYL4zPzNEJx06K+cEi08xFXPosEIIBUVUnnGY/AjtyrxH0Ru3EZ/yasUG4CObFZSR/fvGuJkExs6NxzB4Z1DXGDcDQhjMDwBhyHO8wDsbJ1LugvisOp9yTPLRFvrKnbVwKf7HzcFfM9jB8lJ1jqDtq06Om+iMBD6wu7xmEHNrv3YlHTsqSWzrBIcvHqj53VV5SbBVS7J8cHKW5U5dBp3WDq49u442zfLaT+fwFB+ZGMTPOpz8G2c39CAtr5Rqn6aWOJ8PSvVcYZa/39c4vAs1jVf4LznvVFJjGeAmToPfvTyzHBhlUM7gcSYBQs+K9nuPmtIrjDiM0ICluJCFxI6kMvevNi7fju7tkLmoCuDqYJAdXbObeQJdIi7iHZi9PNGGnCVOT9+jGPZu/Mr3cROz54QT0SPTTkJ+Mcm7ajOfWeofSZjaQsTo2KeVwVO35MW/hn0GQNmhoL+JveCMm4vmgOlbMWWqp/VAxuM31YSgjwFTAbykQbwH4HAhl85DE4IGOgL0XFZLRqfOAOGuiz55iQQdyoZScpwsHhmw5pENG8RSxOtv8gX4spck+soi1HgptTOxM187pI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR00MB0836.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(136003)(39860400002)(376002)(366004)(6916009)(82960400001)(82950400001)(33656002)(8936002)(8676002)(7696005)(8990500004)(6506007)(2906002)(55016002)(9686003)(19627405001)(52536014)(5660300002)(71200400001)(76116006)(66446008)(478600001)(966005)(64756008)(66476007)(10290500003)(4326008)(186003)(26005)(166002)(83380400001)(316002)(66946007)(86362001)(66556008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?lyORd8qefNTG1U8yMpy5vrOXlozqLz8vEKP3f/gVO34Z6ErRUhgemdz/6l?= =?iso-8859-1?Q?kJYggHTFS3HFsgJRGPZLWJzb5fL3c67SAqHvX4iZPLRzh5K/P7ZXwC23PR?= =?iso-8859-1?Q?iRgHvVp5ZBAQja7bj+luuR7ExwBZGvaPyClqP7pj5KJ81gxB/poSw/pOJl?= =?iso-8859-1?Q?IpxC6a3YG8K2dpC6P7uWhTpAeBqCX4558wSNphiyZ/cVoChCwTCRSZqQgC?= =?iso-8859-1?Q?tdwTEv66BpsHzaOb5HGlWfPeVwiVMdDI2XQlRgJ7hdS1MnKWyRK+IIjxA5?= =?iso-8859-1?Q?0EHHEifP4yaNt0vnF8XNv5m3QwJ0Gc5begeQFxUNsIapqLG0o7hpQMO49A?= =?iso-8859-1?Q?4Tv1yxlSCCYvvyphlORJ+/g5Es7Q2945rptIngIg6kxcDqJe0HZP4TMW/5?= =?iso-8859-1?Q?ozWXSjrxT/X86VQfWcTNsl67Jzu0+jS6IYos2yB7hT6izFL1HXVMgPiQCt?= =?iso-8859-1?Q?/4IDZZaZy8mOiv06JXJ8nZY7IzN0/8J04JwLY3i8glBnSyUaSR4WMbDi8B?= =?iso-8859-1?Q?Fz4UxEh9+2E5TUvB5HTOoeI/wv7/n7ckQJeMo2q4ZDC/3nqafQZLtiBdCt?= =?iso-8859-1?Q?5veDg+9JHY4bFfMgv9c00iDd2c9xj7SrIWLw5vfC/WRhwKAT3DdyXRbrD1?= =?iso-8859-1?Q?fUBdXFiBbKTW7qEQkmFdQ5defhi+54TxTeW6y25uumHJ6edMO1KQDug3Ng?= =?iso-8859-1?Q?wYV677XtE/MKye0AarEQfRC7Xcy1xoaAT7FAG5/6jxv3DfdspOqlazG1ia?= =?iso-8859-1?Q?GEBBDoGwWOchI7TbGmGsSvFctknkvQL3uwdA4+Oycj4aetaiy2bVS4tERE?= =?iso-8859-1?Q?U628FwI3088wr01QWZ6tLvIWOvvET7+Sa8Qcg5MANt2kD/K/yvGV7PHb1P?= =?iso-8859-1?Q?MEoBfjd3PsDiEmAaWgaxQ4JUxXvIrXyBiimvoZgqLP2e6m2+PyNQeKeUJf?= =?iso-8859-1?Q?61MMFBTiRE5YyDWownX3coN1RUb0nIOGdtWTarR4iY2BYSt6STB3BJ3F3v?= =?iso-8859-1?Q?lcxQ2uu+3QLR95gTYBwVqNpqPpafqPdDNfqC5DPsZ2XWt8WCGrb9mt02Xi?= =?iso-8859-1?Q?3JulAWYI1jxnzRUeUtkk8z8=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR00MB083637DAD075EC8E5342A0A9F0A59BL0PR00MB0836namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR00MB0836.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b397278c-b663-4763-daea-08d8bb2d4b4b X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2021 21:17:28.3721 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8dGWFjqQ8d41zb0swhS7JBf3usHdireTdUvJ38LNdpclH5AyAUx0+pxbQo6qlh4b0R0zbDKPzEsrh61jVXQdPQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0753 Archived-At: Subject: Re: [httpapi] Discussion about JSON payloads and code generation 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: Sun, 17 Jan 2021 21:17:44 -0000 --_000_BL0PR00MB083637DAD075EC8E5342A0A9F0A59BL0PR00MB0836namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christoph, From: Christoph Kappestein Thank you for the feedback. I understand that it is not easy possible to ch= ange the schema specification but I had the hope that the OpenAPI spec will= be in future versions more JSON schema independent. I.e. that a user could= use XSD, JTD, Protobuf or any other specification to describe the request/= response payload, also for payloads in the future which are not JSON. So th= at a user is not forced to use JSON schema and that an alternative could em= erge. There is a proposal for supporting an "Alternative Schema" https://github.c= om/OAI/OpenAPI-Specification/blob/master/proposals/001_Alternative%20Schema= %20Proposal.md Implementation feedback was that that the current proposal is too complex t= o implement, so we likely will be revisiting it once OpenAPI 3.1 is release= d. A core editor from the JSON schema spec has already approached me regarding= a vocabulary, but from my point of view I think that those vocabularies in= herit many properties from JSON schema which are not ideal for code generat= ion. In the spirit of "do one thing and do it well" we could have different= specifications for specific use cases, which would be a much more flexible= framework than forcing every schema to be a vocabulary. A generator could = then support only specific schema types. Speaking purely as an individual, I think extending JSON Schema would be a = better first step. Getting traction in this space is hard, and successfull= y mapping to the type systems of multiple platforms is a problem that peopl= e have been failing at for decades, no matter how focused the effort was. Having said that. I wonder if this working group would be the right place = to create a specification that describes an extended set of primitive data = types and corresponding text-based wire representations. JSON Schema compl= etely punts on anything beyond what JSON defines for type, and format is le= ft as implementation dependent. I could imagine this kind of standardization would be helpful for query par= ameter values, header values as well as a range of media types used as payl= oads. I'm thinking of a single RFC that describes a set of serializations used in= HTTP APIs. Things like date-time, times, durations, currency, coordinates,= language identifiers, etc. It could also provide a standardized type ident= ifier to use in complex type definition/validation specifications I think it would be useful when writing specifications to be able to refere= nce a single spec and say primitive values are serialized as per RFCXXXX. = Looking at the structured headers spec, they have done this work for a few= core data types that are common in headers. https://httpwg.org/http-exten= sions/draft-ietf-httpbis-header-structure.html#section-4.1.3.1 So, bringing this back to TypeSchema. Do you think that it would be useful= for TypeSchema if there existed a standardized rich set of primitive data = types for HTTP APIs that were platform independent and optimized for wire r= epresentations? I'm pretty sure the JSON Schema folks would be delighted if there were some= well known values that could be used with format keyword. The OpenAPI spe= cification defines a few formats (https://github.com/OAI/OpenAPI-Specificat= ion/blob/master/versions/3.1.0.md#data-types) and we continue to get reques= ts for more, but I'm not convinced the OpenAPI specification is the right p= lace to do that. OData defines a bunch of their own https://docs.oasis-open= .org/odata/odata-csdl-json/v4.01/odata-csdl-json-v4.01.html#_Toc38466396 The feels like something that if properly scoped and standardized could mak= e life easier for a bunch of different efforts. Thoughts? Darrel --_000_BL0PR00MB083637DAD075EC8E5342A0A9F0A59BL0PR00MB0836namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Christoph,

From: Christoph Kappestein = <christoph.kappestein@gmail.com>
 
Thank you for the feedback. I understand that it is not ea= sy possible to change the schema specification but I had the hope that the = OpenAPI spec will be in future versions more JSON schema independent. I.e. = that a user could use XSD, JTD, Protobuf or any other specification to describe the request/response payload, also = for payloads in the future which are not JSON. So that a user is not forced= to use JSON schema and that an alternative could emerge.

Implementation feedback was that that the current proposal= is too complex to implement, so we likely will be revisiting it once OpenA= PI 3.1 is released.

A core editor from the JSON schema spec has already approa= ched me regarding a vocabulary, but from my point of view I think that thos= e vocabularies inherit many properties from JSON schema which are not ideal= for code generation. In the spirit of "do one thing and do it well" we could have different specifi= cations for specific use cases, which would be a much more flexible framewo= rk than forcing every schema to be a vocabulary. A generator could then sup= port only specific schema types. 

Speaking purely as an individual, I think extending JSON S= chema would be a better first step.  Getting traction in this space is= hard, and successfully mapping to the type systems of multiple platforms i= s a problem that people have been failing at for decades, no matter how focused the effort was.

Having said that.  I wonder if this working group wou= ld be the right place to create a specification that describes an extended = set of primitive data types and corresponding text-based wire representatio= ns.  JSON Schema completely punts on anything beyond what JSON defines for type, and format is left as implementation de= pendent.  

I could imagine this kind of standardization would be help= ful for query parameter values, header values as well as a range of media t= ypes used as payloads.

I'm thinking of a single RFC that describes a set of seria= lizations used in HTTP APIs. Things like date-time, times, durations, curre= ncy, coordinates, language identifiers, etc. It could also provide a standa= rdized type identifier to use in complex type definition/validation specifications

I think it would be useful when writing specifications to = be able to reference a single spec and say primitive values are serialized = as per RFCXXXX.   Looking at the structured headers spec, they ha= ve done this work for a few core data types that are common in headers.  https:= //httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#secti= on-4.1.3.1  

So, bringing this back to TypeSchema.  Do you think t= hat it would be useful for TypeSchema if there existed a standardized rich = set of primitive data types for HTTP APIs that were platform independent an= d optimized for wire representations?

I'm pretty sure the JSON Schema folks would be delighted i= f there were some well known values that could be used with format keyword.=   The OpenAPI specification defines a few formats (https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.1.0= .md#data-types) and we continue to get requests for more, but I'm not convinced the OpenAP= I specification is the right place to do that. OData defines a bunch of the= ir own https://docs.oasis-open.org/od= ata/odata-csdl-json/v4.01/odata-csdl-json-v4.01.html#_Toc38466396 =

The feels like something that if properly scoped and stand= ardized could make life easier for a bunch of different efforts.

Thoughts?

Darrel
--_000_BL0PR00MB083637DAD075EC8E5342A0A9F0A59BL0PR00MB0836namp_-- From nobody Mon Jan 18 02:17:05 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 246233A1213 for ; Mon, 18 Jan 2021 02:17:04 -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, 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=ulsberg.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 TQJsoIeCS_Ia for ; Mon, 18 Jan 2021 02:17:01 -0800 (PST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 75ECB3A1211 for ; Mon, 18 Jan 2021 02:17:01 -0800 (PST) Received: by mail-qt1-x829.google.com with SMTP id j26so10857768qtq.8 for ; Mon, 18 Jan 2021 02:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ulsberg.no; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FV3I5G3Fe7bba79N4VPthj86apXl6u026m4QVK1kJCg=; b=Cuy0YwgCd151hDW3II22S2BZKDrMUkSufJSuwvG7GKEnxLIgwxQ7SCQyyQWse8XhKo O2iTURgXz/9nQblP4Fjw1d3cBrZ2N6L//CjRIfD18N4CAM4gi0TdUrDG8pz0gF+xLH4R AjZ5zzG13OzRjxVwj+LRTfHunR9Zk3FcpD37413iiCnZLZxPIjRU12ZsXocyukHrmF0N 8nWhP8JyOqalr3YgfUJ2NuTowDZ/RmgdsQHkt4KayXeyfQiSwoWjSv8wLoOVmLhizxqq CObkrvWHn4kjKconOmkrK3d0UU5uRA3Bo3KK8iAl/51RoOapEYGtO977/nn+B+buJdlP IqRw== 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=FV3I5G3Fe7bba79N4VPthj86apXl6u026m4QVK1kJCg=; b=t0RLNGQt6RvgaViWq+h6D85FoL3hbt+Ro6NPyoi1fzY4SraKPwR7mwc4aO9otx4jgj uS+UG0lQP+fji+3XUj9zEbiJPrWMGuZIvufWAtceq6HmSxaEXj8J0HB8SM2qlRfwPIGX EEKTCotCuoU3cKQXYYAD4RmAm6KhgGFa6oV9VNWi4s0L0i48ekRwraA7Ct6XX/YFv381 NYlZ5DoRt4m5A6CZHzQUO0oHCSs1iTTCodBpAGvDrL4BBlJZXCDXfcAvcIG/yv1mPOWm 7DdrXwNRYxAHxoyEyeXcjUxs2oMmCFLBNzXLtMu3h+URhZdMPScw1opFty2KRSrhtV+r 4OKg== X-Gm-Message-State: AOAM531fYBwKYnWrlpOGtV2Hp9JFtLBn2ZMVUZWJ0tSWEaf5zstWOXOV eE7bhkoKnDD7KJtiOyGmDH0mDmPQypx620Dg X-Google-Smtp-Source: ABdhPJzLrE4xzOpfVADrQILbStVvOhOJTF5N1tlJKdTZOPdFEBeciqpTCWMocBNikEY7lY34E5wohg== X-Received: by 2002:ac8:7b56:: with SMTP id m22mr23162140qtu.380.1610965020148; Mon, 18 Jan 2021 02:17:00 -0800 (PST) Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com. [209.85.219.178]) by smtp.gmail.com with ESMTPSA id g3sm10150037qtc.3.2021.01.18.02.16.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Jan 2021 02:16:59 -0800 (PST) Received: by mail-yb1-f178.google.com with SMTP id r32so2434615ybd.5 for ; Mon, 18 Jan 2021 02:16:59 -0800 (PST) X-Received: by 2002:a25:26cf:: with SMTP id m198mr35538275ybm.454.1610965019132; Mon, 18 Jan 2021 02:16:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Asbj=C3=B8rn_Ulsberg?= Date: Mon, 18 Jan 2021 11:16:48 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Darrel Miller Cc: "christoph.kappestein@gmail.com" , "httpapi@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [httpapi] Discussion about JSON payloads and code generation 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, 18 Jan 2021 10:17:04 -0000 s=C3=B8n. 17. jan. 2021 kl. 22:17 skrev Darrel Miller : > In the spirit of "do one thing and do it well" we could have different > specifications for specific use cases, which would be a much more flexibl= e > framework than forcing every schema to be a vocabulary. A generator could= then > support only specific schema types. Ulysse Carion has already created a schema language specifically tailored for code generation with RFC 8927. https://www.rfc-editor.org/rfc/rfc8927.html --=20 Asbj=C3=B8rn Ulsberg -=3D|=3D- asbjorn@ulsberg.no =C2=ABHe's a loathsome offensive brute, yet I can't look away=C2=BB From nobody Mon Jan 18 09:02: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 1A7093A0CEE for ; Mon, 18 Jan 2021 09:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 Zyq8D0ZzoiMr for ; Mon, 18 Jan 2021 09:02:17 -0800 (PST) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 724593A0B91 for ; Mon, 18 Jan 2021 09:02:07 -0800 (PST) Received: by mail-ot1-x334.google.com with SMTP id 36so5384245otp.2 for ; Mon, 18 Jan 2021 09:02:07 -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=WWhgGb2ZyTd7mqQ3je6X7pgRutmJahiLeuJAvlqV28k=; b=jrudiO2STS/a7UtNSq6xDmPW4zRQbhvBT/+T8R9WJ0Ek6TqrzbqC/gzn5W0Nr3Fu5R Qz+9s47kSPMbK+W3Qyl5KRF928XtlQWk1fMeU2QAv4hyZILEeDyLa2Qr6FjO+ahrNINO 5w8qv0iV5BsjYCN7uc2yKezsIEimND6MwFFJyOtXqTqx9vQwxgA3urzphIcTxoOim00H 6CG3LIqeYu0m4Aafas7rZVQIIsyZgVeauOkN0UdRpgYqAz0R21ail6ry4AjLxKJ+HhdU 0VOj3sz9KuUGS9E0DE1AJhUijNvTlcwUKmEJqkVItrivQFoLtPVG9Tw/YSbGpnsF+79r i49Q== 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=WWhgGb2ZyTd7mqQ3je6X7pgRutmJahiLeuJAvlqV28k=; b=D/vvHN0953VEjIAKcYcGohM783oILH5lhz9lDmDaIPZedjFO8A4jPvw2bEl5h+gXEe JS0j1BkDT3BBmCv+AzNVU8kkFLE8rbUkLo6s61L4LQ7zNR7pGdSsD998YJPR6obG/ppQ zYrTyG3maWpHcMVRPugKatDk0mYQwqRjC5wHE1bXcziYrLHoMo/GlJTatv8qW+eG87Bg R9+z9AWwYJjjYr4ZPNSMYf8cWpvaNtgHTVgQ/OTlO4oLc8p8f1bEbOesEH5slkx2ajX2 7Mq9zsm7Ac0JEzVgTxXBWYJxnm+pVUmRxQPvTKmDtdR6ArhivoraDE/UhiGRyYXF3zCn cSnw== X-Gm-Message-State: AOAM532UK4C1ej9QxAAa9LKOBLJ/MzJ37NJ4boCetQVWEmmAHA75XBsN j3QfaRvSBJadBAEHEPlt+RgGWk4jfP4cLfjY+W4= X-Google-Smtp-Source: ABdhPJyncikCVXrOg6ko1YmPJRzc27IE5r6GcVTKS5bs1je0gy6NYi1c9i8DoyrOiF8dco53f6M73c+wsegSa7HzCVg= X-Received: by 2002:a05:6830:1349:: with SMTP id r9mr327210otq.256.1610989326597; Mon, 18 Jan 2021 09:02:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Sanjay Dalal Date: Mon, 18 Jan 2021 09:01:55 -0800 Message-ID: To: Darrel Miller Cc: "httpapi@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008c84ae05b92fae20" Archived-At: Subject: Re: [httpapi] rfc7807 errata or just "more" 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, 18 Jan 2021 17:02:26 -0000 --0000000000008c84ae05b92fae20 Content-Type: text/plain; charset="UTF-8" Hi Darrel, >Just pointing to the instances of the failures without describing what kind of failures those are would not be a great experience. I agree. However, if we have a schema that accommodates pointers to failure(s) and more details about the errors as part of RFC it would help many API developers. Such a schema could be defined in a very generic fashion like what we have attempted to do in the error catalog service API at https://github.com/sdatspun2/error-catalog-service/blob/master/ErrorResponseInErrorCatalog.md. These schemas are derived from rfc7807 and from JSON Schema spec, section 10 respectively. >That additional information about what kind of failures each of those instances experienced is going to need to be in extensions and the client will need to understand the semantics of the type...I accept there will be some scenarios where there are multiple instances of problems associated with a single resource that are homogeneous, but there are going to be just as many that are heterogenous. I don't really see the issue with using the type to define the necessary extensions. If we can provide a solution for the homogenous use case (I believe that is 80% in 80-20) and suggest to use extension for the heterogenous use case that would go a long way, imo. In fact, it would increase adoption of rfc7807 significantly. I did not use rfc7807 while designing PayPal's proprietary schema for the error response. I am sure we were not alone. Thanks. sanjay On Sat, Jan 16, 2021 at 1:41 PM Darrel Miller wrote: > Hi Sanjay, > > *From:* httpapi on behalf of Sanjay Dalal > > As you know, having multiple schema validation related errors in payload > of HTTP requests is a very common scenario for the HTTP APIs. > > I'm not sure an instances array is going to solve the issue here. In your > example, at the resource level, multiple issues have been detected as > schema validation problems and you will need some explicit type to identify > schema validation problems.. As you say there may be many validation > constraints that were violated within the response payload. However, it is > likely that they are more than one type of validation failure. Just > pointing to the instances of the failures without describing what kind of > failures those are would not be a great experience. That additional > information about what kind of failures each of those instances experienced > is going to need to be in extensions and the client will need to understand > the semantics of the type. > > I accept there will be some scenarios where there are multiple instances > of problems associated to a single resource that are homogeneous, but there > are going to be just as many that are heterogenous. I don't really see the > issue with using the type to define the necessary extensions. > > Darrel > > --0000000000008c84ae05b92fae20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Darrel,

>Just po= inting to the instances of the failures without describing what kind of fai= lures those are would not be a great experience.

I agree. However, if we have=C2=A0a schema that accommodates pointers to= failure(s) and more details about the errors as part of RFC it would help = many API developers. Such a schema could be defined in a very generic fashi= on like what we have attempted to do in the error catalog service API at https://github.com/sdatspun2/error-catalog-ser= vice/blob/master/ErrorResponseInErrorCatalog.md. These schemas are deri= ved from rfc7807 and from JSON Schema spec, section 10 respectively.
=

>That additional information about what kind of fail= ures each of those instances experienced is going to need to be in extensio= ns and the client will need to understand the semantics of the type...I acc= ept there will be some scenarios where there are multiple instances of prob= lems associated with a single resource that are homogeneous, but there are = going to be just as many that are heterogenous. I don't really see the = issue with using the type to define the necessary extensions.
If we can provide a solution for the homogenous use case (I bel= ieve that is 80% in 80-20) and suggest to use extension=C2=A0for the hetero= genous use case that would go a long way,=C2=A0imo. In fact, it would incre= ase adoption of rfc7807 significantly. I did not use rfc7807 while designin= g PayPal's proprietary schema for the error = response. I am sure we were not alone.

Thanks.
sanjay


On Sat, Jan 16, 2021 at 1:41 PM Darrel Mi= ller <Darrel.Miller@micro= soft.com> wrote:
Hi Sanjay,

From= : httpapi <httpapi-bounces@ietf.org> on behalf of Sanjay Dalal=C2=A0

As you kno= w, having multiple schema validation related errors in payload of HTTP requ= ests is a very common scenario for the HTTP APIs.=C2=A0

I'm no= t sure an instances array is going to solve the issue here.=C2=A0 In your e= xample, at the resource level, multiple issues have been detected as schema= validation problems and you will need some explicit type to identify schem= a validation problems..=C2=A0 As you say there may be many validation constr= aints that were violated within the response payload.=C2=A0 However, it is = likely that they are more than one type of validation failure.=C2=A0 Just p= ointing to the instances of the failures without describing what kind of failures those are would not be a great experience= .=C2=A0 That additional information about what kind of failures each of tho= se instances experienced is going to need to be in extensions and the clien= t will need to understand the semantics of the type.

I accept t= here will be some scenarios where there are multiple instances of problems = associated to a single resource that are homogeneous, but there are going t= o be just as many that are heterogenous.=C2=A0 I don't really see the issue with using the type to define the necessary extensions.

Darrel

--0000000000008c84ae05b92fae20-- From nobody Mon Jan 18 09:11:58 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 BE7C13A0ADF for ; Mon, 18 Jan 2021 09:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 V0g-bWjM4VEu for ; Mon, 18 Jan 2021 09:11:54 -0800 (PST) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 1082A3A0AC5 for ; Mon, 18 Jan 2021 09:11:54 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id w3so16911481otp.13 for ; Mon, 18 Jan 2021 09:11:54 -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=57Qt2sUMDO3fGGI35RY8B8CQzs6cuURw8kIvUZM1C34=; b=aO/jlqfMRAIhxQnjz63Uy3egTBz8irp4oVjB2wZs71goQ60L8KolKG3rhmYDOFFoiT 3BIINVIfQBfxa8yNATqT/Lscw1uhOkKk00cjR95L63UgFDGqlAxzBTrFJ71XjTSjTWpZ /7VQ8iujkW5Xn+ac9f+Dzj9nJ8js/ErCQnmv7h5B+S9PNKjheiFpE+jn4qDPia8sqmSy 0itX6KFc7nnzlP5bT/7xlMp8HT4ddnGpO5LroquTwAupSDrYepkG5zmLC1bCkI7okyaC ctWsm0r/8QIzLWtl3MISuI6UW84bfNnjvMwcJPJF0RV/k6N5Yy6U2S9Xd9XHVTPIFmL3 x90Q== 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=57Qt2sUMDO3fGGI35RY8B8CQzs6cuURw8kIvUZM1C34=; b=PoPcbKWQdEMuFt3+HDShOD14Gjmq7gnlFGcOL+8h0A1PX8nSJmp4NhDJg9jtMcy1kd Gr0PhuQp6TZlA8nII0hP/gQvUGgMZ2DogqdLdx+3qHhE244d2pCJk9CTrpk3A/ZdRgZt QrBZeNxHu03i6ZBXf7t+Xl/SCQoB6pR7t8wVDTOfF1qF48Wa8iJZCt4MoGocPDehmpcP 4fQy/FnTxUHXhm7YkCkgxQeiVv4oZO5IvjyWRokkHVckbKjkYbIzCbPgHEuDAtXczjlD PXwMcG2I0WEehoAJQOOFTjVZf7U13Lz2tSxUGodLjXTfsQHkNVJzLfcQgZA6MJS6g+em Ix7w== X-Gm-Message-State: AOAM531Ocytu4STYyrK2HCG1E3mzrObL8utGYVXi0a/zdHfD3PGDNybb 78iWY5j1x2WDLd9AgzeYMqLPJtncQp8e4Fc8cr55h6tOY62PkQ== X-Google-Smtp-Source: ABdhPJzcvxD2KxRzY2V2r+Cm00Xwbnpd5z78QU7gUKtJBCDthcKOVxX5fbVThIFzWeHYpBlXqSBBz2Mt9+FILDL7Ajk= X-Received: by 2002:a9d:6751:: with SMTP id w17mr355915otm.328.1610989912826; Mon, 18 Jan 2021 09:11:52 -0800 (PST) MIME-Version: 1.0 References: <5fc6752d-f3d7-0781-6e3a-1fd99f74a9ad@beonex.com> In-Reply-To: <5fc6752d-f3d7-0781-6e3a-1fd99f74a9ad@beonex.com> From: Sanjay Dalal Date: Mon, 18 Jan 2021 09:11:41 -0800 Message-ID: To: Ben Bucksch Cc: httpapi@ietf.org Content-Type: multipart/alternative; boundary="0000000000007da9ba05b92fd1db" Archived-At: Subject: Re: [httpapi] RFC for HTTP API error responses (was: rfc7807 errata or just "more") 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, 18 Jan 2021 17:11:56 -0000 --0000000000007da9ba05b92fd1db Content-Type: text/plain; charset="UTF-8" Hello Ben, >I find that error responses - and more generally error handling - is severely lacking in many systems I come across, and it's causing problems during software development. Huge +1. Lack of it, increases cost of support, affects developer experience. > I wanted to propose to make a new RFC for nailling down not only the error responses, but also what information is expected in the response, and the behavioral contract. Errors should be part of the protocol and API contract. Looking forward to seeing your starting point content and collaborating with you. Hope you got a chance to look at the Error Catalog Service and its OpenAPI extension . thanks, sanjay On Fri, Jan 15, 2021 at 8:08 PM Ben Bucksch wrote: > Hello Sanjay, hello everybody, > > thank you for bringing this up. In fact, this topic is the very reason why > I joined this mailling list and WG: I find that error responses - and more > generally error handling - is severely lacking in many systems I come > across, and it's causing problems during software development. > > I wanted to propose to make a new RFC for nailling down not only the error > responses, but also what information is expected in the response, and the > behavioral contract. Errors should be part of the protocol and API contract. > > I had written some document for my project and teams, in my role as > software architect, based on my experience, and I wanted to share that with > you as starting point for an RFC. The document I have is not suitable as > Standard document, it's an software architecture document, but I think many > of the ideas are viable to be included in the RFC. > > I would like to ask you, esp. the leaders of the WG: Would you be willing > to discuss and adopt such a new RFC? It would probably include RFC 7807, > but significantly extend it in its scope. > > Ben Bucksch > > > Am 15.01.21 um 19:32 schrieb Sanjay Dalal: > > Hello all, > > Thanks folks for providing instructions on how to provide feedback to an > RFC. This feedback is for RFC 7807 , > "Problem Details for HTTP APIs". > > I like RFC 7807. In fact, I have designed Error Catalog Service > such that the > problem types of RFC 7807 can be managed (CRUDL) and used in error > responses, API definition, API documentation, API testing, etc. > > However, I find that RFC 7807 omitted one very common use case in its > proposed schema for Problem Details Object > (section 3.1). This > use case is about reporting of multiple errors of the same problem type in > an error response. RFC suggests defining an extension for this use case. > > As you know, having multiple schema validation related errors in payload > of HTTP requests is a very common scenario for the HTTP APIs. How can we > improve the Problem Details Object schema to accommodate this common use > case? We should not expect API developers to respond with one error at a > time in the case of 400 scenarios. That would be an unpleasant developer > experience. Asking the API developers to define an extension for such a > common scenario hurts in adoption of the Problem Types. > > In my opinion, instead of the proposed singular "*instance*" property of > type string, there should be an array of *instances. *You can find what > we have done for the error response of the Error Catalog service > .There > could be other ways. > > I have communicated with both Erik Wilde and Mark Nottingham about this > issue. Both of them are open to discussing a revision under this WG if > the group thinks it is necessary. Would love to get your comments, > opinions, approaches and suggestions. > > thanks and regards, > sanjay > > > > I am not too familiar with the process to comment an RFC but is there > in general > a form where I can provide written feedback to existing specifications > or is > this done through this mailing list? > > >On Sat, Jan 9, 2021 at 9:40 AM Salz, Rich 40akamai.com@dmarc.ietf.org> wrote: > RFC's are published documents, not drafts; the name "request for comments" > is a node to IETF history. How to provide feedback on published RFC's > depends on the amount and nature of feedback. If you have a well-contained > technical error, you want to report an "errata" against the RFC. If it's > more philosophical or just "more", it might be better to find the WG that > published the RFC and post to that mailing list (see above). > > > -- > httpapi mailing list > httpapi@ietf.org > https://www.ietf.org/mailman/listinfo/httpapi > --0000000000007da9ba05b92fd1db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Ben,

>I= =C2=A0find that error responses - and more generally error handling - is se= verely lacking in many systems I come across, and it's causing problems= during software development.

Huge=C2=A0+1. Lack o= f it, increases cost of support, affects developer experience.
> I wanted to propose to make a new RFC for nailling down n= ot only the error responses, but also what information is expected in the r= esponse, and the behavioral contract. Errors should be part of the protocol= and API contract.

Looking forward to seeing= your starting point content and collaborating with you. Hope you got a cha= nce to look at the Error Catalog Service and its O= penAPI extension.=C2=A0

thanks,
sanj= ay


On Fri, Jan 15, 2021 at 8:08 PM Ben Bucksch <news@bucksch.org> wrote:
=20 =20 =20
Hello Sanjay, hello everybody,

thank you for bringing this up. In fact, this topic is the very reason why I joined this mailling list and WG: I find that error responses - and more generally error handling - is severely lacking in many systems I come across, and it's causing problems during software development.

I wanted to propose to make a new RFC for nailling down not only the error responses, but also what information is expected in the response, and the behavioral contract. Errors should be part of the protocol and API contract.

I had written some document for my project and teams, in my role as software architect, based on my experience, and I wanted to share that with you as starting point for an RFC. The document I have is not suitable as Standard document, it's an software architecture document, but I think man= y of the ideas are viable to be included in the RFC.

I would like to ask you, esp. the leaders of the WG: Would you be willing to discuss and adopt such a new RFC? It would probably include RFC 7807, but significantly extend it in its scope.

Ben Bucksch


Am 15.01.21 um 19:32 schrieb Sanjay Dalal:
Hello all,

Thanks folks for providing instructions on how to provide feedback to an RFC. This feedback is for=C2=A0RFC 7807, "Problem = Details for HTTP APIs".=C2=A0

I like RFC 7807. In fact, I have designed=C2=A0Error Cat= alog Service=C2=A0such that the problem types of RFC 7807 can be managed (CRUDL) and used in error responses, API definition, API documentation, API testing, etc.=C2=A0

However, I find that RFC 7807 omitted one very common use case in its proposed schema for=C2=A0Problem Details Object=C2=A0(section 3.1). This use=C2=A0case is about repo= rting of multiple errors of the same problem type in an error response. RFC suggests defining an extension for this use case.

As you know, having multiple schema validation related errors in payload of HTTP requests is a very common scenario for the HTTP APIs. How can we improve the Problem Details Object schema to accommodate this common use case? We should not expect API developers to respond with one error at a time in the case of 400 scenarios. That would be an unpleasant=C2=A0developer experience. Asking the API developers t= o define an extension for such a common scenario hurts in adoption of the Problem Types.

In my opinion, instead of the proposed singular "insta= nce" property of type string, there should be an array of=C2=A0inst= ances.=C2=A0You can find what we have done for the=C2=A0error response of the Error Catalog service.There could be other ways.

I have communicated with both Erik Wilde and Mark Nottingham about this issue.=C2=A0Both of them are open to discussing a revision under this WG if the group=C2=A0thinks it is necessary. Would love to get your comments, opinions, approaches and suggestions.

thanks and regards,
sanjay


>=C2=A0 =C2=A0 I am not too familiar with the process to comment= an RFC but is there in general
=C2=A0 =C2=A0 a form where I can provide written feedback to existi= ng specifications or is
=C2=A0 =C2=A0 this done through this mailing list?

>On Sat, Jan 9, 2021 at 9:40 AM Salz, Rich <rsalz=3D40akamai.com@dmar= c.ietf.org> wrote:
RFC's are published documents, not drafts; the name "reque= st for comments" is a node to IETF history.=C2=A0 How to provide feed= back on published RFC's depends on the amount and nature of feedback.= =C2=A0 If you have a well-contained technical error, you want to report an "errata" against the RFC.=C2=A0 If it's more philo= sophical or just "more", it might be better to find the WG that published = the RFC and post to that mailing list (see above).=C2=A0=C2=A0


--
httpapi mailing list
httpapi@ietf.org<= br> https://www.ietf.org/mailman/listinfo/httpapi
--0000000000007da9ba05b92fd1db-- From nobody Mon Jan 18 14:25:16 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 D89A53A0C2E for ; Mon, 18 Jan 2021 14:25:14 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=microsoft.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 LGIgXoCS5VwO for ; Mon, 18 Jan 2021 14:25:12 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640113.outbound.protection.outlook.com [40.107.64.113]) (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 D4C633A0934 for ; Mon, 18 Jan 2021 14:25:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LsIqUHOS+7vforh89NEzW+c2KAsjBRLbMNvf5dLCa+6E6+JQFm/BpVyNVQ4GOTyRvDWwwiJMPf31WVIAo6PIoe47nL/XI7ztVOfij52pQhesraRnmerJcvt3whg/ivd5hexae0JZjV3uhDU7lHXZLPBC3BGJ+aH2ZHswrvH9x8gE4MOiHRG9si9FtrKTtWFM+z5fLxJFLInb9MTAx3Oxe9F2y1v4SVIsWJrs5SwRBIRKszNgwVRyt/ovWrVyCwEnj3KJrI8vpQq0lkDiaXLBOesf8DCzPOeLNTfhLtZnZNM+EmSao/QM9lpzPTcZg7UHdZGj3u0Vk65RJbXOW4rVuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RtK0EKN2WTrn45JddJdIc/KbFHkrXRYmasC1HuzIg1E=; b=YEpx+4nFbPW7s/EVYJppVTy3ugEBBCdtLh+t/denXLHJ5VOrbTphQ3GWIMncPTHA30yT89SoRwWdz7KoRFn8XhkJkpV4PClcA2H54QQzRSXTTDVrcBtZjswQehDhs1GrrctnOea608ztx9iw+jYjBElJk/3/+LX74+ble+CqaK4ksVFL7Stpz1AG7YLspRfIkzGF0hRnmjkXUvOFLV0YpIWRJjrFTLUjTybOJNCgYN8092k/bpmpj5WcDifVSzXdL8wB1Epi7TgAbfSuALYu8hYD2wk02h41Apwau4dddA2W3lXBoN++xvRHuxKPfzxhT5d91sDAPDWdO5aQuPj8uQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RtK0EKN2WTrn45JddJdIc/KbFHkrXRYmasC1HuzIg1E=; b=iIF1agBPYDHGOXc+ySovvvt46YbxTQWN7EWf0/kTqMT1eL91JgkYR8RUtJ5sdUKB/GAeHuGfk6uEqOG2Gm3+/RUd0qtolCclO/+FWNZ74q0PaDII+b9WPY6ghtyM/UH+TqqTgv30mJCVahYYWOjlvoAXL0Ngu2hcy5tMvyTp684= Received: from (2603:10b6:5:1bc::23) by DM6PR00MB0845.namprd00.prod.outlook.com (2603:10b6:5:1bc::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3815.0; Mon, 18 Jan 2021 22:25:08 +0000 Received: from DM6PR00MB0845.namprd00.prod.outlook.com ([fe80::6450:8a43:1d66:8d3d]) by DM6PR00MB0845.namprd00.prod.outlook.com ([fe80::6450:8a43:1d66:8d3d%5]) with mapi id 15.20.3815.000; Mon, 18 Jan 2021 22:25:08 +0000 From: Darrel Miller To: "sanjay.dalal@cal.berkeley.edu" , "news@bucksch.org" CC: "httpapi@ietf.org" Thread-Topic: [httpapi] RFC for HTTP API error responses (was: rfc7807 errata or just "more") Thread-Index: AQHW671g/TACg64s7UWvLmCgYJV2FKoton+AgABSH7w= Date: Mon, 18 Jan 2021 22:25:07 +0000 Message-ID: References: <5fc6752d-f3d7-0781-6e3a-1fd99f74a9ad@beonex.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-01-18T22:25:08.508Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: cal.berkeley.edu; dkim=none (message not signed) header.d=none;cal.berkeley.edu; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [74.15.147.35] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 44ba2876-beb8-45c3-7fb2-08d8bbffe96b x-ms-traffictypediagnostic: DM6PR00MB0845: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aUOpwCzGlDSX9ruUGuItZYcLr3hsO96fxXg1UhT6EiUYzN0l1iocwt/jGcq1+vk7KxuhEGBYTEK3OmfuOElGILoMZzhuPJKSC4XMzBJRlD3H7joRxdJKa/PQgyEYntzeCuupSEauDSMEMKTspnpP7PcwRnXz41FEw6x/YfJ9xuNCarOZUgbG8kYGkW5yNMlAq0I5va903WV/9a//yEwhoSUU8zuTK5AsRygJR4838n0iM5vR6H7Wv+2Pcbr1wwX7z6B/gpacCE6AjZHmxVY3t1HEvCKs/rHrtGhrOaJUMh3sUugiHC+BKuPoDednsVt+6rMdaeEpeptLgdbLG4+nSBnS6x9Iqx3iZEsw2eMBeZyThbAxbVO/hzs1bEPTQzEuTo1VSHJM1kYwWMlKc1oS9AQcc2e45DJF+Ce+6jb4bksI7+qh+LaufdxDx5WbF7Ei94tLDmS+I5Y99Ni7cjYfaSpYdqhGQ76e8s/wmYPHDAs0qhcpNwi4GShQbJHsU9TmMsE8ImIiPXbaaENiQKPmEQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0845.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(366004)(136003)(396003)(39860400002)(71200400001)(66946007)(64756008)(76116006)(66556008)(66476007)(83380400001)(33656002)(66446008)(8990500004)(86362001)(4326008)(82950400001)(5660300002)(52536014)(19627405001)(82960400001)(7696005)(110136005)(316002)(55016002)(2906002)(8936002)(8676002)(478600001)(10290500003)(9686003)(6506007)(26005)(186003)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?xMEnWyff/sk44CE4XmC2m2O8EP2tur0rnz3/0/w1nuCwm66s/nI2/9fovu?= =?iso-8859-1?Q?k+0TSbbRZrR2dEWs9qnd4bffKX4oIaOHmMPkBhZNF714tsR9aTbvkklVC8?= =?iso-8859-1?Q?qsyi9I6fz1eEl78gTbkPvBHgGFH0gM3tu7wmGNANUmXMpCZeQTVJCvDdsw?= =?iso-8859-1?Q?TBrjKCWYYamf1vfQb4QQxu43/YgB98O7Tzx9LhgUpoc/MeyhNP5ydEPXJM?= =?iso-8859-1?Q?+yICmntBqZR/Zt9ByKdD6Dm4iUJmeLrdpCqg5a0uQHNeloXfmu0NJ6LenC?= =?iso-8859-1?Q?8g8XCA5JmThV64xgEyFNrXmhrWzwapu+0yzJHvsy3YDn8M82x0FwY298Yn?= =?iso-8859-1?Q?3Vk6QXVhYP4DO6iCZBXivW5ITZ0FozR3pAOL7MW+mCoG/E3r5ppXQxPGzW?= =?iso-8859-1?Q?a1aM04NR8sRdOGz6+sYq4MaWlhj30NFlWVMOrslelM2qX3WlBiSgil8yrp?= =?iso-8859-1?Q?Rwox7/P6OePo76xo7YUw5mgi3wUv2UWx+1MED16a9GcyHRWxbbNsuCM9hi?= =?iso-8859-1?Q?s1HxZDW+0H3TSegmQ9dakXJOPdLwGjvIAtOY437ix2bLT2DulPpy0Yagp9?= =?iso-8859-1?Q?lyTXdc7JxHdS3dYEfMD8rcCTaC+5Pozvjqm9GGUl7UVRJK+jV6GiaY+jII?= =?iso-8859-1?Q?teu1TWOUjPIzym+MnorB+NrGK2yYZuIHZP3NdISaUmz59AmGQHDOxqfkiH?= =?iso-8859-1?Q?XKsYjq6lMyXhyj2Env8oHVn7MkmO976OiLbyrb4uPdspk964dVcDgFCJs6?= =?iso-8859-1?Q?HtByiZu858Zrdzq5gEcP7zsIPn9MYW4rSTsqabhpQpdOnT8C93AOeM/NrH?= =?iso-8859-1?Q?JYU30OeT6CI7J6Ik4wYr3PSUSva24JZ2RpH8heAy6ahIzRCi4t1M/2P3o8?= =?iso-8859-1?Q?o2pGRmNTC6GWZU0Yq9C2/lFFyDIhxRPaEJGNUVjI989RqvjMlG/IApBR28?= =?iso-8859-1?Q?dfe2TlerdzSVmooZiPqbclXWG8QVP+zeHSo8uzqJBL9Rl7a+LCrsZ0HsCd?= =?iso-8859-1?Q?Ns42Fc3m6VVYp1mWrDMdccPFihdhMawXOxdsstsU0GgexlRNdU3V5QDIK/?= =?iso-8859-1?Q?jySNqp5vYd9poRwNKigcR2A=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB08451F917C6EA61EF2BBD5D1F0A49DM6PR00MB0845namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0845.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 44ba2876-beb8-45c3-7fb2-08d8bbffe96b X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2021 22:25:07.8981 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8icNuuKVK55qoa2k5t7+mpvpcQhNra0u6T1CMTsm8DVXztsHHltEl73g7iCkIPUc66KtNwM68BIvUXh7zINxJg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0845 Archived-At: Subject: Re: [httpapi] RFC for HTTP API error responses (was: rfc7807 errata or just "more") 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, 18 Jan 2021 22:25:15 -0000 --_000_DM6PR00MB08451F917C6EA61EF2BBD5D1F0A49DM6PR00MB0845namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ben, Sanjay, From: httpapi on behalf of Sanjay Dalal >I find that error responses - and more generally error handling - is sever= ely lacking in many systems I come across, and it's causing problems during= software development. Huge +1. Lack of it, increases cost of support, affects developer experienc= e. I agree that HTTP errors are often not handled well. However, usually I fi= nd that is because devs over simplify client code to something like: if status =3D=3D 200 then success else throw exception. I find it is this part of RFC 7231 that most developers don't follow, HTTP status codes are extensible. HTTP clients are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, a client MUST understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent to the x00 status code of that class, with the exception that a recipient MUST NOT cache a response with an unrecognized status code. Clients must handle each class of status code, but are not required to hand= le every specific failure condition. Is it your expectation that a client must understand all service-specific m= odes of failure in order to make a request to an HTTP API? On Fri, Jan 15, 2021 at 8:08 PM Ben Bucksch > wrote: I wanted to propose to make a new RFC for nailling down not only the error = responses, but also what information is expected in the response, and the b= ehavioral contract. Errors should be part of the protocol and API contract. Errors are part of the HTTP protocol. That's what 4XX and 5XX status codes= are. Possible errors can be called out in API descriptions like OpenAPI b= ut in my opinion they should never be relied on to be exhaustive by a clien= t. The layered nature of HTTP means that any intermediary could return an = HTTP error response that is not provided by the OpenAPI description. Creating a further refinement of HTTP status codes using service specific p= roblem types can be useful as long as clients can opt-in to processing thos= e new error types. Darrel --_000_DM6PR00MB08451F917C6EA61EF2BBD5D1F0A49DM6PR00MB0845namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ben, Sanjay,

From: httpapi <httpapi-b= ounces@ietf.org> on behalf of Sanjay Dalal <sanjay.dalal@cal.berkeley= .edu>
>I find that error responses - and more generally error handli= ng - is severely lacking in many systems I come across, and it's causing pr= oblems during software development.

Huge +1. Lack of it, increases cost of support, affects developer= experience.

I agree that HTTP errors are often not handled well.  However, us= ually I find that is because devs over simplify client code to something li= ke: 

   if status =3D=3D 200 then success else throw exception.

I find it is this part of RFC 7231 that most developers don't follow,<= /div> 

   HTTP status codes are ex=
tensible.  HTTP clients are not required to=0A=
   understand the meaning of all registered status codes, though =
such=0A=
   understanding is obviously desirable.  However, a client =
MUST=0A=
   understand the class of any status code, as indicated by the f=
irst=0A=
   digit, and treat an unrecognized status code as being equivale=
nt to=0A=
   the x00 status code of that class, with the exception that a=
=0A=
   recipient MUST NOT cache a response with an unrecognized statu=
s code.
Clients must handle each class of status code, but are not required to= handle every specific failure condition.

Is it your expectation that a client must understand all service-specific m= odes of failure in order to make a request to an HTTP API?

On Fri, Jan 15, 2021 at 8:08 PM Ben= Bucksch <news@bucksch.org> w= rote:
I wanted to propose to make a new RFC for nailling down not only the e= rror responses, but also what information is expected in the response, and = the behavioral contract. Errors should be part of the protocol and API cont= ract.
Errors are part of the HTTP protocol.  That's what 4XX and 5XX st= atus codes are.  Possible errors can be called out in API descriptions= like OpenAPI but in my opinion they should never be relied on to be exhaus= tive by a client.  The layered nature of HTTP means that any intermediary could return an HTTP error response that is no= t provided by the OpenAPI description.

Creating a further refinement of HTTP status codes using service speci= fic problem types can be useful as long as clients can opt-in to processing= those new error types.   

Darrel
--_000_DM6PR00MB08451F917C6EA61EF2BBD5D1F0A49DM6PR00MB0845namp_-- From nobody Mon Jan 18 14:40:41 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 DC7053A0C52 for ; Mon, 18 Jan 2021 14:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 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, HTTPS_HTTP_MISMATCH=0.1, 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=microsoft.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 ZdrHhDHLQQR6 for ; Mon, 18 Jan 2021 14:40:39 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06on0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe56::720]) (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 5E2B63A0C4F for ; Mon, 18 Jan 2021 14:40:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gVdWnA3xM4wAE1RrU+c9rfcDS3bIM8Hwb5QhzjwTXUQWLwWW0miuIfAJnWq4lKYxhu+EDUR0DKL0SrsfBrXm/VR+15MYmxUYQRqJ25rkVbW0v2NeDdiPjlhCWARwN8Msglf2h2xOH/264SMmXL2+xN3ho2M8S4SRYdzQRUR0hyVihTr+2O0Z3RpRXq0L/q02TtxKRkTInes0L1/xb3K7QmKx7Tyi6Qx3e+N1YnDNv4br2C++Va/FmI77VqvkSzHD1+7MC5sgvrlrjWD1ksm7snDvqC13+nFZKlaEzOsQsG4e53I3jAY5M5YNHoOejn6lq4YIQvpCUP1OscX1FoGVPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dTjVRMJEUsBCGyqMelgurXotKyIB47GuDLon6a0lEjQ=; b=fhX5r142RKNBcrG8oipH317F3NRcgcaKw8wN1dkfW0cFZ2NHcXnPM4oxBs9+luXDhnA4EzLUHyXFJNmmT8UkrrbLgrnLPf/Bvz6F5IS3EchoZ31UZ7LpCCYZtZSts6wJGRTQ8tZ7q9U80jFDrgQ71Ptuy+k6hk7eATuiKwoxBEZtJxMqz6wYjEh2EMQmyrkx3cLRizrctsnsqk5B/IN55PdJBp6MQRXS5iY5bSoG/xkIcmpiV8OW5F6AdIZ6RiX25EYVm0ua/Zrf9cytfQjgOdJ2PXxsiwKS94xr14uLJis9Xyd48HtS4gZA5CpZ7g307xRLv1GNW0sOHeaG3dsU7w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dTjVRMJEUsBCGyqMelgurXotKyIB47GuDLon6a0lEjQ=; b=K+9udGasHZAWofxZlpIkLO+PKEiW7YqKO86nUZKHNPt8mUmH7ik3jRtuGUflWj7hMxcqpO7zyMEIb1E6JSG3rCBmDNcKZPSwRAnKWOGwX5CnsUSSM0SPLG+85n5cOUcKHPtZbNBmVXR8D2OZMNrOG/WoKJoU4wa7H1/rRKN9T48= Received: from (2603:10b6:5:1bc::23) by DM6PR00MB0666.namprd00.prod.outlook.com (2603:10b6:5:220::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3816.0; Mon, 18 Jan 2021 22:40:25 +0000 Received: from DM6PR00MB0845.namprd00.prod.outlook.com ([fe80::6450:8a43:1d66:8d3d]) by DM6PR00MB0845.namprd00.prod.outlook.com ([fe80::6450:8a43:1d66:8d3d%5]) with mapi id 15.20.3815.000; Mon, 18 Jan 2021 22:40:25 +0000 From: Darrel Miller To: "sanjay.dalal@cal.berkeley.edu" CC: "httpapi@ietf.org" Thread-Topic: [httpapi] rfc7807 errata or just "more" Thread-Index: AQHW63flyWs2GD/CXEa43IG2VCAgqKoqxvaegALZWYCAAFsyMQ== Date: Mon, 18 Jan 2021 22:40:25 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-01-18T22:40:25.821Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: cal.berkeley.edu; dkim=none (message not signed) header.d=none;cal.berkeley.edu; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [74.15.147.35] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 84ac40c1-4ec7-40e8-9c32-08d8bc020c1e x-ms-traffictypediagnostic: DM6PR00MB0666: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bl5QucFdQ0/kopNe032GtjtRPbed6YVEs/JVTJXJIZwE+VetzFFUQ2qUml0nMs7F7O6dPZOSp2MgFxZAvocA0pK5XaEAnmQHgtcroBLG/hTH+9e5juZiB7CzhBq6dq2+IlaNlbKcCrqBeH//AFjZ2I10K8Xf7qCrkM0nadwf13WFbu2jAGATaNsBf6LYMEzAJL0nTYCeowjjL+CKlpeqiu204FIYgv4+t55zwIbZxFdk+1SIyio1uYR2DUxV0aaFzRyY4XJiWrgGVTKVFmL8uyXQ8el1R7VLRGEfdxCsg6gQytxBZczD5uKpaqnjGMxdmILP4SPDO+xgJhCnFgTp5RVw84ec5QyWwIX1xlSQgf1vML2GR0Qp+llqUv2pQKh7h2h0PpB9Z/nD9auGlcRshn/3otF4dt9ne0kYiOqjt2/GD2EIJMNlBXKBXBMipLLEznxBdT/X5D04ZWyUf/Y+Ucsyhn1liJZl4MgVselkD+yDynTZCa1tonnOui9rBZpqMI+ISF+KwwJwGhWvujloQyPX60ERI77Ysk4vTH85g9KlM3GHEoMEGfGR8hkfcYfgRJYZuLhDJqGNa3JAkNkkdiSAUqPE0nfaVHnOBOeb9oo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0845.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(376002)(346002)(39860400002)(396003)(5660300002)(55016002)(8936002)(33656002)(9686003)(86362001)(52536014)(10290500003)(66476007)(6506007)(82960400001)(82950400001)(64756008)(66446008)(478600001)(66946007)(8990500004)(66556008)(966005)(19627405001)(76116006)(8676002)(2906002)(4744005)(316002)(4326008)(6916009)(166002)(26005)(7696005)(71200400001)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?kCffiDvLHN1K/Hk1cJLSXZbvnb+U3ApGDPpiiLlRIlzsVh6Yd68sNzKihf?= =?iso-8859-1?Q?UDNwHbIsPGsbzmO8eI7LktRepsdqeqnLwYoU1vfiNZ44JSMm0V1z5HF8rA?= =?iso-8859-1?Q?wJMcDdNPDWjpZTeBei6QpJ2Ad7229gArbHr8PYz4F3HycOBroFl0QI2yex?= =?iso-8859-1?Q?Ue1qzOJXW7+TLySwVRqPql+gk/Erw425z85D3jEtVpJGVgcTdh87ypinDH?= =?iso-8859-1?Q?AuU9nhvJznr4P6NJIa243Eti8Ej3Hocjxjbxl8h1rZwIRxkxW2e9wCer5k?= =?iso-8859-1?Q?eftOaFN1phurrm2a5kFe9FbfOvAZHAY6nsf8JsltRO5ne/3nT99RF07Dfc?= =?iso-8859-1?Q?/+Zjj44bUeAegp2IRnZBwOGQoGRKwXzzgAGWYe2QhDgB3+acyb7wQaD6So?= =?iso-8859-1?Q?eDgOmqLFntqnzgPEsEnhF1ZHrgMED2RINuT+DsivNOL0dLxC/+2Saz9zk7?= =?iso-8859-1?Q?hDoAysRKH0FKMQ/A2x+GA/b4tf9nLOOVl0VAd4RbIfu8RLVQY8VPi1XwQ6?= =?iso-8859-1?Q?PsXlgtOTvAUv14XT2Sa0T0JwXqq4eF/i1BTGPZToKmOZlgidHASuCXrzS5?= =?iso-8859-1?Q?pXgPNisZlGAcMEVCUGW6vv8co4klMcve1KJeEct2OsghmSNza1yJ2aEFMM?= =?iso-8859-1?Q?kbudz0kVABb1fMGbRs8dF2T/hRMle8GJbo+zM1T/UI1a7YLhM27FN6Ktc6?= =?iso-8859-1?Q?8MCcg/zlIZ9u6a6IKanDXYS809bQL0BaN0RNF4Xi4eoePnB/ReK9ebedcx?= =?iso-8859-1?Q?IMIwefeu0yPyOWx0NYIfI2/w3rTeSPhfbaaVr2HRMSoMhR2GTC5gDBEKgE?= =?iso-8859-1?Q?v5sFiCETKs5Di6xD+V8HkoJiaI9Fni91D2+NEd3lYSZROUj3ml9WcWfXZU?= =?iso-8859-1?Q?qNy3uAYB79lZoFEsEvdDQfZwMbpr/OeWEZuSkgC7t1jHTxQUwW3LhpggpC?= =?iso-8859-1?Q?BZNp3ys1DAI0uA+S2gqRzhkzD7Qu3eqVDoQFBV/OBKbCAZhtO0w2+68A+A?= =?iso-8859-1?Q?dDcyhNzFKeQrWMcZ9DH2RUafpoSYkAGq5RH7rKanRxxzlWsFiEWN347xF/?= =?iso-8859-1?Q?yrikhqOPJTu4+96qz6AcCZI=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB08453480DEAC88B5ACBC5076F0A49DM6PR00MB0845namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0845.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 84ac40c1-4ec7-40e8-9c32-08d8bc020c1e X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2021 22:40:25.1597 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: w7ja1FJl5I1wVXvEq6y+icqS+3Y7BvlnPVcNi1O6LOzi8SzXZlIFN8dFgCAyEctBwSsmAqAqu/9tf/Hxdwc1LQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0666 Archived-At: Subject: Re: [httpapi] rfc7807 errata or just "more" 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, 18 Jan 2021 22:40:41 -0000 --_000_DM6PR00MB08453480DEAC88B5ACBC5076F0A49DM6PR00MB0845namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sanjay, From: Sanjay Dalal Such a schema could be defined in a very generic fashion like what we have = attempted to do in the error catalog service API at https://github.com/sdat= spun2/error-catalog-service/blob/master/ErrorResponseInErrorCatalog.md. These schemas are derived from rfc7807 and from J= SON Schema spec, section 10 respectively. We define something similar in the Microsoft API Guidelines https://github.com/microsoft/api-guidelines/blob/vNext/Guidelines.md#error-= -object An "error" object has a "details" property that is an array of "er= ror" objects. I'm not sure how much it is used though. RFC7807 could add "containedProblems" property (or some similar name) that = is an array of problem objects. That would be the spiritual equivalent. Darrel --_000_DM6PR00MB08453480DEAC88B5ACBC5076F0A49DM6PR00MB0845namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sanjay,

From: Sanjay Dalal <sanj= ay.dalal@cal.berkeley.edu>
 
Such a schema could be defined in a very generic fashion like what we = have attempted to do in the error catalog service API at https://github.com/sdatspun2/error-catalog-service/blob/master/ErrorRespons= eInErrorCatalog.md. These schemas are derived from rfc7807 and from JSO= N Schema spec, section 10 respectively.

We define something similar in the Microsoft API Guidelines 
https://github.com/microsoft/api-guidelines/blob/v= Next/Guidelines.md#error--object  An "error" object has = a "details" property that is an array of "error" objects.  I'm not sure how much it is used though.

RFC7807 could add "containedProblems" property (or some simi= lar name) that is an array of problem objects.  That would be the spir= itual equivalent.

Darrel
--_000_DM6PR00MB08453480DEAC88B5ACBC5076F0A49DM6PR00MB0845namp_-- From nobody Tue Jan 19 00:30: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 05DD33A131C for ; Tue, 19 Jan 2021 00:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=teamdigitale.governo.it 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 PvL3xOgZzNZD for ; Tue, 19 Jan 2021 00:30:32 -0800 (PST) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 8516A3A1314 for ; Tue, 19 Jan 2021 00:30:32 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id h16so20474085edt.7 for ; Tue, 19 Jan 2021 00:30:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamdigitale.governo.it; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0FdGvE1K9XveqUkSPjDcTUayPTZgBP7p7tK1bBQAyF0=; b=XlMrkuw05FxKWhLc9AJQvzn1dVau/kyC6bMLecp7qHwBq6LSMKseKhD/SQ5KdPdbx9 FTOPhIFEBxE/O+NFpUCjPqmI2KH8Y7MAaM3MLyLEUN9IAKDUpOXPNdQADeYaJxmpoOsS MiMPBrb3YpfsiMUHUS5BvOzAgnX8SNujW5LMc7Kg+IIZDQupvqyFyygFHBbdM2+VYq7P kptfM4h8ZiDRQk9bABocI4GFxCtQzXvKy7iDSiWoQE9i4jhhihPKpUaRku5hPaFPMcMf y3bA7QHsb9qmDuVf6nz0hjMjrSn+yC8JAgidnUPLF8nwe6+I2GvF2q9ViwIBKDa39IX/ BPxw== 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=0FdGvE1K9XveqUkSPjDcTUayPTZgBP7p7tK1bBQAyF0=; b=fs9Gu2y7ygsGUtTHCyAXuFuZ8Iy+xPUmfcCoL6kKd2vgD65VanEMhevyp7eSBnNQ11 g0tIsREd54ktmlzK5gSwuZgG/jZ1eJvc2dD2dDs2rE05ZZEi50Bem+baVTMscTsyE7Jz Ozb4fb7Cmb0Cncvh69Gfci6f/Qbkx9cDrPe/MxfoNigJjEmL/KvFZd+F61zEVZSvyHZB 84swRWqYck2Vwyx2bN/SaRGgh4nWAHeaBmKKzVb1TQ6rGK/SRTh2BQ6j3OG3reEpWN4s nbbGqKYtBbY7jQMbAHP9LIlLPDHQlX7gi/VsuPui+R0kF8dinMMIE8Z6C9AaGRQG8t0j E6jg== X-Gm-Message-State: AOAM532nry1WsWUv7g1SaYx4ltNi75L4z2ItTs0xMbyvzOhyA6ZlVvq9 ex1ZbZFWxh1T2AdnqCf7oKY9uV2SMCiRY+pV7Ox9JA== X-Google-Smtp-Source: ABdhPJzLTQ21elqh1eMCV11iVOvy0Bym94iPtisLGDCkbqJE1omK254pyPY+0t4jN2fYH6OjXiPesXuZrUhy/62t3Iw= X-Received: by 2002:a05:6402:1c0b:: with SMTP id ck11mr2535207edb.35.1611045030815; Tue, 19 Jan 2021 00:30:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roberto Polli Date: Tue, 19 Jan 2021 09:30:20 +0100 Message-ID: To: Darrel Miller Cc: "sanjay.dalal@cal.berkeley.edu" , "httpapi@ietf.org" , Erik Wilde Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [httpapi] rfc7807 errata or just "more" 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, 19 Jan 2021 08:30:37 -0000 Hi @all, Il giorno lun 18 gen 2021 alle ore 23:40 Darrel Miller ha scritto: > RFC7807 could add "containedProblems" property (or some similar name) that is an array of problem objects. > That would be the spiritual equivalent. I would like to find a convergent solution for both Problem and Content-Warning, eg. see https://github.com/dret/I-D/blob/master/http-warning/draft-cedik-http-warning-02.txt#L295 which proposes the use of a list of Problem.json which - imho - provide redundant information (eg. `status` should always be the same). Kind regards, R. -- Roberto Polli API Expert M. +39 3406522736 MID DIPARTIMENTO PER LA TRASFORMAZIONE DIGITALE Presidenza del Consiglio dei Ministri - Ministro per l'innovazione tecnologica e la digitalizzazione https://innovazione.gov.it/ From nobody Wed Jan 20 17:11:21 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 9F1563A0A12 for ; Wed, 20 Jan 2021 17:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 2dXhBRxfxBeM for ; Wed, 20 Jan 2021 17:11:19 -0800 (PST) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 09D6D3A09F5 for ; Wed, 20 Jan 2021 17:11:19 -0800 (PST) Received: by mail-oi1-x231.google.com with SMTP id n186so435792oia.5 for ; Wed, 20 Jan 2021 17:11:18 -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=gx6SHDHD88vDqqVjkDLwi3va1U6FNKXTWDZCxt6KdyI=; b=I9Im3RuXc6pDR38QtQuZOge/xniuK66j55Z9JwvXuXMRUMRDT3pCvLOn6nEw4+Alch R5W//U/cUzV8UEdR6FEtlDPXVqlemadMenl2+GMOHowXkcOD3ifaqv+dClHpmts7JFyM aanPEnqro3GgC6gwElVFwKfc6eVDplwyyx7G51MP3WWs5SpyeB3PpetcYR6RA1z41NOu s6iw2bmZI3BOsU86WoGtFtf330/ZXsyTBRffVF78b97zJt2XlA9Amxj8xciCxpcHlXhA /cmBncN7CZAjRSzg/BhbPB2GORx5Dcwt+VrVtRCDGzhlKcscuCrFCy+CgDODE1LDZ98p 893g== 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=gx6SHDHD88vDqqVjkDLwi3va1U6FNKXTWDZCxt6KdyI=; b=ClM5mEaTHOvcbm5bNps0wq5LJQdTYZS5s46DAazuyMOj5iyPUOuPgKnQCoOIBhfUTd +laVEb3oj3i+XJC6tEpUr6N9SYVrnGOWlLthmNxvTjauUHnUp0NLEfJSu7ygfCOM18B+ uF9ml/m1ZFpar/mZIFsoiSCd1MYPTs+r+iA1iZYqNdMUCdQeb8A8AanQe9XyBHPlj54f XmOxhV+OjLJr6f2ci0dTWtg9iKUjWtMwzZ2nM4Ti3ovi3Oqc/AFPtI0KyXWmiZnGLDWe LEBGtV2v43JT9FMCf8iMLRWHGaSfHnrPrG2vBGfMq8TDxLquaxPYKEjchDOxcvPz7ZAF 2IFw== X-Gm-Message-State: AOAM533rzRTiWYjD7po4Ay396FCTIppJggj4HcwURX483hccejyfXelC MmYa9O9W6827vsLenXdTXWfMH0xrw37KIvvb1gWjeOasF9CQEQ== X-Google-Smtp-Source: ABdhPJx7/QYHTjL/DSf3w5v71oRQwrtDidLmFTu0xL/JMxrmf1lqWkrM9a1S5jNuo1iFL4fYXH9k16spxs966M/hxdU= X-Received: by 2002:aca:5857:: with SMTP id m84mr4548774oib.29.1611191478391; Wed, 20 Jan 2021 17:11:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Sanjay Dalal Date: Wed, 20 Jan 2021 17:11:07 -0800 Message-ID: To: Roberto Polli Cc: Darrel Miller , "httpapi@ietf.org" , Erik Wilde Content-Type: multipart/alternative; boundary="000000000000bc183c05b95ebf55" Archived-At: Subject: Re: [httpapi] rfc7807 errata or just "more" 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, 21 Jan 2021 01:11:21 -0000 --000000000000bc183c05b95ebf55 Content-Type: text/plain; charset="UTF-8" >RFC7807 could add "containedProblems" property (or some similar name) that is an array of problem objects. Agree. What would be the next step? Should a repo be created so we can start working on a revision? >I would like to find a convergent solution for both Problem and Content-Warning This could broaden the scope of Problem Details and Content-Warning both which may not be desirable, imo. Would love to hear from other members of the group. https://github.com/dret/I-D/blob/master/http-warning/draft-cedik-http-warning-02 . "Note that this specification specifically targets warnings and not errors, meaning that while it may be useful for clients to understand the warning condition and act on it, they also may choose to ignore it and treat the response as a successful one." On Tue, Jan 19, 2021 at 12:30 AM Roberto Polli < roberto@teamdigitale.governo.it> wrote: > Hi @all, > > Il giorno lun 18 gen 2021 alle ore 23:40 Darrel Miller > ha scritto: > > RFC7807 could add "containedProblems" property (or some similar name) > that is an array of problem objects. > > That would be the spiritual equivalent. > > I would like to find a convergent solution for both Problem and > Content-Warning, eg. see > > https://github.com/dret/I-D/blob/master/http-warning/draft-cedik-http-warning-02.txt#L295 > which proposes the use of a list of Problem.json which - imho - > provide redundant information (eg. `status` should always be the > same). > > Kind regards, > R. > -- > Roberto Polli > API Expert > M. +39 3406522736 > MID > DIPARTIMENTO PER LA > TRASFORMAZIONE > DIGITALE > Presidenza del Consiglio dei Ministri - Ministro per l'innovazione > tecnologica e la digitalizzazione > https://innovazione.gov.it/ > --000000000000bc183c05b95ebf55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>RFC7807 could add "containedProblems" p= roperty (or some similar name) that is an array of problem objects.

= Agree. What would be the next step? Should a repo be created so we can star= t working on a revision?=C2=A0

>I would like to find a convergent= solution for both Problem and Content-Warning

This could= broaden the scope of Problem Details and Content-Warning both which may no= t be desirable,=C2=A0imo. Would love to hear from other members of the grou= p.


=
"Note that this specification specifically targets warnings= and not errors, meaning that while it may be useful for clients to underst= and the warning condition and act=C2=A0on it, they also may choose to ignor= e it and treat the response as a successful one."

=

On Tue, Jan 19, 2021 at 12:30 AM Roberto Polli <roberto@teamdigitale.governo.it> wro= te:
Hi @all,

Il giorno lun 18 gen 2021 alle ore 23:40 Darrel Miller
<Darrel.Miller=3D40microsoft.com@dmarc.ietf.org> ha scritto:
> RFC7807 could add "containedProblems" property (or some simi= lar name) that is an array of problem objects.
> That would be the spiritual equivalent.

I would like to find a convergent solution for both Problem and
Content-Warning, eg. see
https://git= hub.com/dret/I-D/blob/master/http-warning/draft-cedik-http-warning-02.txt#L= 295
which proposes the use of a list of Problem.json which - imho -
provide redundant information (eg. `status` should always be the
same).

Kind regards,
R.
--
Roberto Polli
API Expert
M. +39 3406522736
MID
DIPARTIMENTO PER LA
TRASFORMAZIONE
DIGITALE
Presidenza del Consiglio dei Ministri - Ministro per l'innovazione
tecnologica e la digitalizzazione
https://innovazione.gov.it/
--000000000000bc183c05b95ebf55-- From nobody Thu Jan 21 01:15:41 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 D08143A1851 for ; Thu, 21 Jan 2021 01:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=teamdigitale.governo.it 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 Q7dxH9tGtek6 for ; Thu, 21 Jan 2021 01:15:38 -0800 (PST) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 D8B493A1852 for ; Thu, 21 Jan 2021 01:15:37 -0800 (PST) Received: by mail-ej1-x631.google.com with SMTP id g12so1563071ejf.8 for ; Thu, 21 Jan 2021 01:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamdigitale.governo.it; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Nc8ZD3Iy5oONJfkdnU11ZbxFy+X74D3AjyGfwNXB4k4=; b=MR6IMQ03PS1DzEpVCWmUbVPpMtzR3cVFHRdCpnLZfK1QBjZlbmvNwhWPudHvW/E2Gy Q+iPsYvyfHStjx28O4bWb90f3gVZjPHehalOfj7+paFHG+DykZ8CTxhwilyCjKGerpwH EtuhBaIwrVBScoLs41napgMIBSysnTAH1ToOZhCig6mtT894J2qv4Wga7sozGmGjUrtP SR3sjDQJ/RtD/fb0wKOnGmhn3cXebekqzAWFIuC9+lvTVCH9r1AE4Rbt38tEtSvSgRG1 4we/MyMB31hbqS/9Vt151foAsc7GlfVZbumsfjAnEaPjJL7RUL69C9fPkfPATwpRfjhx bxsQ== 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=Nc8ZD3Iy5oONJfkdnU11ZbxFy+X74D3AjyGfwNXB4k4=; b=jia15GWlAYCOE4VuFwemz+Sm0UfB1IiVxHTbh/IOqNZ5k6ao8tHBpUBTBL6zlYFSCA HFcBz0lmAGlkK/e3wJRlE3EbCstaZ7O6yBTY8j3f58QRNu4VcUs6XsclK+1Wv5Y3c1dE YZVLS6MzgF0Fwb96CG0bCgjJDsWK5eD21vKY9z+OEeEANjs5yJWVoouYwjzjCvvwNkp7 l1ZwKlY/TOnRXR+IwQUhcyz0ZpOk2qmBbMjXvPtvNYSFC2l/SkZ4taPgHplhWjAwfQLx ueZB3Ch5HCLKzQ47VNC0EWAlZgs3E9l6YpJLA2WJ0duG+/ckOzha3KQG5y53stD/PgBt slaQ== X-Gm-Message-State: AOAM531maNXxEdQFctUbD+sgILempavnwe9PKgMt3X8+WPnoX9mJ4aZA uqCUsx0daVk8ZDWtG40wbd+IO6LWxOldvYLBJAP1hQ== X-Google-Smtp-Source: ABdhPJyL9Z4VqHHkOg6xGzoKRSAU6ZiorPu3EUl5guxA/CJ2/hC7WFo5y+YCfSSwMfQ53skQkkH4NdB7VAYGMHfTtPk= X-Received: by 2002:a17:906:1658:: with SMTP id n24mr8483540ejd.532.1611220535980; Thu, 21 Jan 2021 01:15:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roberto Polli Date: Thu, 21 Jan 2021 10:15:25 +0100 Message-ID: To: Sanjay Dalal Cc: Darrel Miller , "httpapi@ietf.org" , Erik Wilde Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [httpapi] rfc7807 errata or just "more" 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, 21 Jan 2021 09:15:40 -0000 Hi Sanjay, Il giorno gio 21 gen 2021 alle ore 02:11 Sanjay Dalal ha scritto: > >RFC7807 could add "containedProblems" property (or some similar name) that is an array of problem objects. > Agree. What would be the next step? Should a repo be created so we can start working on a revision? Before creating a repo, I'd start with a shared gdoc with a basic proposal. The content can be in markdown, if you like. > >I would like to find a convergent solution for both Problem and Content-Warning > This could broaden the scope of Problem Details and Content-Warning both which may not be desirable, imo. Would love to hear from other members of the group. > > https://github.com/dret/I-D/blob/master/http-warning/draft-cedik-http-warning-02. > "Note that this specification specifically targets warnings and not errors, meaning that while it may be useful for clients to understand the warning condition and act on it, they also may choose to ignore it and treat the response as a successful one." http-warning has a proposal for both warning notification (the headers) and warning serialization (how to convey the actual warnings). iiuc the sentence above refers to the headers part, not the warning serialization. My opinion is that we should investigate eventual convergence between the warning serialization and the "containedProblems". Looking forward to further comments, R. From nobody Sun Jan 24 01:46:10 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 30CEF3A11A4 for ; Sun, 24 Jan 2021 01:46:08 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 wZ7Oe603UZqs for ; Sun, 24 Jan 2021 01:46:05 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 CC8AF3A11D8 for ; Sun, 24 Jan 2021 01:46:04 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id f17so11606183ljg.12 for ; Sun, 24 Jan 2021 01:46:04 -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=7e+aGseYoPiOLtWCEDjwD35M8PUkHPVFZG5KS+u5Qkc=; b=sQqW9KBdDM41D5/C5VlDIEUNUGgEWcwKMPKUPgWNEGA0cKOSoizXqaY+OuvyM89SfM +6EKFjZvu6NoAS0BMMCJGOqz0JAbUaQlYffLRpfxJCm1W2xPBB1Z7iC8lPwVIAVS6kKV kbX2w9CEhrU4qE61qjnd86eWeGvdkFXLAAC+TOUE93iQ2w5SUJ6DjnF16OPMXGbrwjh6 ZMB+K7cVZa72Dxvp+bK3w0o75eK7lFDNduydzYCRrBcqQeBpj0KJGXB7lLglA753uWKW q3OHr0Psz//gJcgoaBwyXAszDLuVHgz4gBEOFl7uI0qukXivrNOiZ7kjMmEEtUSjjjfL zvog== 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=7e+aGseYoPiOLtWCEDjwD35M8PUkHPVFZG5KS+u5Qkc=; b=IgHwEy5wO4NkluxNfuQ9vobnpV1Thrbr2iQczPaTB+wWDVc0JaAyF1dRRachUGNnnr govWAgVDQ3R/0+Vl0tqlUDH+MlC8YOil54MAhzqUVeBFdnXc+VSCDxYdNO27pCUVT608 m2djdsRExwTvyVLoM2W4Mw3r33KhWnwoHfkNKLqBqq30VPZFKmo4V4g6YKSnQhBOz1aD YaL+9EB2wvdG76Je+4KXExPF0D0ChD3ZDTqhim647onkw8faRIuRFmUh1WziJzhW/PTy cA2q02aOCTQuTCpENYkQRTzkQdnd4e2vxqJOY/yAM13bA4+U27tcgk0IYKUfiD84QsO7 RYUg== X-Gm-Message-State: AOAM531dtQO+foDJJewKrItn5DtCo+gAlMo+Ko0ratFLfV8A4pqDYfNK MhptgnvX5TumNcjYeTPwmcnOkrTrYpWFSoPbB3eiAYwMylc= X-Google-Smtp-Source: ABdhPJxXtAym6aplDWo1WCchi/b82Toc1pA4oA0AQJctknNmsUCm5J5Wso2qjOKAwS68wZw2rJCw9CXb5fjrW+h8ui8= X-Received: by 2002:a2e:b5b5:: with SMTP id f21mr3126ljn.239.1611481562427; Sun, 24 Jan 2021 01:46:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Christoph Kappestein Date: Sun, 24 Jan 2021 10:46:02 +0100 Message-ID: To: "httpapi@ietf.org" Cc: Darrel Miller Content-Type: multipart/alternative; boundary="0000000000001738c005b9a24a2d" Archived-At: Subject: Re: [httpapi] Discussion about JSON payloads and code generation 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: Sun, 24 Jan 2021 09:46:08 -0000 --0000000000001738c005b9a24a2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thanks for the feedback. @Jason this is true and I totally understand your concern. I think the difficult part is to define a "core" which works for every use case i.e. code generation, validation, documentation, etc. We should ask what is the common ground of all these specs? In JSON Schema this is probably only the part how documents an= d types are referenced (JSON Path). But thanks for the offer and the great feedback which you have provided, I will also give you an answer at our github issue, if I find the time finally ;) @Darrel the idea sounds great to define the representation of data types. A= t TypeSchema we have defined the following primitive types: - date (rfc3339 full-date) - date-time (rfc3339 date-time) - time (rfc3339 full-time) - duration (ISO 8601) - binary (base64 encoded) We have found that most programming languages have internal object representations for these kinds of types. If we would have an official list with a fitting identifier for a type, then we could also use this identifier at the "format" in JSON Schema/TypeSchema to describe the type. I am wondering whether it would be also possible to describe complex types in such a specification, i.e. that we describe how a list, map or object/struct type could look and is defined through keywords. So I would totally support this effort, since this is basically the reason why we have developed TypeSchema and we would be happy to build upon such a specification. best regards Christoph Am Mo., 18. Jan. 2021 um 11:17 Uhr schrieb Asbj=C3=B8rn Ulsberg < asbjorn@ulsberg.no>: > s=C3=B8n. 17. jan. 2021 kl. 22:17 skrev Darrel Miller > : > > > In the spirit of "do one thing and do it well" we could have different > > specifications for specific use cases, which would be a much more > flexible > > framework than forcing every schema to be a vocabulary. A generator > could then > > support only specific schema types. > > Ulysse Carion has already created a schema language specifically > tailored for code generation with RFC 8927. > > https://www.rfc-editor.org/rfc/rfc8927.html > > -- > Asbj=C3=B8rn Ulsberg -=3D|=3D- asbjorn@ulsberg.no > =C2=ABHe's a loathsome offensive brute, yet I can't look away=C2=BB > --0000000000001738c005b9a24a2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for the feedback.

@Jason this is = true and I totally understand your concern. I think the difficult
part i= s to define a "core" which works for every use case i.e. code gen= eration,
validation, documentation, etc. We should ask what is the commo= n ground of all
these specs? In JSON Schema this is probably only the pa= rt how documents and
types are referenced (JSON Path). But thanks for th= e offer and the great
feedback which you have provided, I will also give= you an answer at our github
issue, if I find the time finally ;)
@Darrel the idea sounds great to define the representation of data types. = At
TypeSchema we have defined the following primitive types:
- date (= rfc3339 full-date)
- date-time (rfc3339 date-time)
- time (rfc3339 fu= ll-time)
- duration (ISO 8601)
- binary (base64 encoded)

We ha= ve found that most programming languages have internal object
representa= tions for these kinds of types. If we would have an official list with
a= fitting identifier for a type, then we could also use this identifier at t= he
"format" in JSON Schema/TypeSchema to describe the type.
I am wondering whether it would be also possible to describe complex t= ypes
in such a specification, i.e. that we describe how a list, map or o= bject/struct
type could look and is defined through keywords. So I would= totally support this
effort, since this is basically the reason why we = have developed TypeSchema and
we would be happy to build upon such a spe= cification.

best regards
Christoph


Am Mo., 18. = Jan. 2021 um 11:17=C2=A0Uhr schrieb Asbj=C3=B8rn Ulsberg <asbjorn@ulsberg.no>:
s=C3=B8n. 17. jan. 2021 kl. 22:17 skrev= Darrel Miller
<Darrel.Miller=3D40microsoft.com@dmarc.ietf.org>:

> In the spirit of "do one thing and do it well" we could have= different
> specifications for specific use cases, which would be a much more flex= ible
> framework than forcing every schema to be a vocabulary. A generator co= uld then
> support only specific schema types.

Ulysse Carion has already created a schema language specifically
tailored for code generation with RFC 8927.

https://www.rfc-editor.org/rfc/rfc8927.html

--
Asbj=C3=B8rn Ulsberg=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=3D|=3D-=C2= =A0 =C2=A0 =C2=A0 =C2=A0 asbjorn@ulsberg.no
=C2=ABHe's a loathsome offensive brute, yet I can't look away=C2=BB=
--0000000000001738c005b9a24a2d-- From nobody Mon Jan 25 10:02:41 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 17F743A1958 for ; Mon, 25 Jan 2021 10:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[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_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=gs1.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ozPKcOyg2mG for ; Mon, 25 Jan 2021 10:02:32 -0800 (PST) Received: from eu-smtp-delivery-175.mimecast.com (eu-smtp-delivery-175.mimecast.com [185.58.86.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BE13A194C for ; Mon, 25 Jan 2021 10:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gs1.org; s=mimecast20200207; t=1611597687; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=JBWdaqxTgbiZ6PbBuuSZ4DIemyKjM/2+y7NZzYqLJQA=; b=DHsz6fFBVvCKKzbqFQ5X4z+NDJsUjwZajXHj1x2fLkA8eVW8llWvoVl/CZT9JhTqmpYwX6 05OQzwfyAXChsE4iaUWiPFY+0vRXiOYyzx6RgErvbudK1Qp32uKt3m7M8byotfmOIZkRAM Z3SGxdqYkVXm9LgSsC7FoS359A8gskDyO2RpDr+W1DaziOtwIHhdcflDpmrNrNq2s5LfaI fFICOOP8333t/r5sqBbLamPDJ9Wl3Llnvdsq6NvSpC3NsfLNT8hd+xumFLdOvcIvxfB5LT scdfsCNxkZYkCAXjaBBuSgSeVzuj7iim6rMke6L45KfaU2h1mO/rZabRBAOYBA== Received: from mail.gs1.org (mail.gs1.org [194.78.55.38]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-207-TqLCl_LXMNqDqtwldWnPRA-3; Mon, 25 Jan 2021 18:01:11 +0000 Received: from gs1beecho13.gs1.org (192.168.100.29) by gs1beecho13.gs1.org (192.168.100.29) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 25 Jan 2021 19:01:03 +0100 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.109) by gs1beecho13.gs1.org (192.168.100.29) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Mon, 25 Jan 2021 19:01:03 +0100 Received: from DM6PR08MB4972.namprd08.prod.outlook.com (2603:10b6:5:4e::25) by DM6PR08MB3948.namprd08.prod.outlook.com (2603:10b6:5:88::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.12; Mon, 25 Jan 2021 18:01:00 +0000 Received: from DM6PR08MB4972.namprd08.prod.outlook.com ([fe80::88c0:1c8a:e754:9f9]) by DM6PR08MB4972.namprd08.prod.outlook.com ([fe80::88c0:1c8a:e754:9f9%7]) with mapi id 15.20.3784.017; Mon, 25 Jan 2021 18:01:00 +0000 From: Phil Archer To: "httpapi@ietf.org" , Erik Wilde , Herbert Van de Sompel CC: Nick Lansley Thread-Topic: GS1 implementation of linkset draft Thread-Index: AdbzQvM14id93rqGQo2Lt+fTcUWDmg== Date: Mon, 25 Jan 2021 18:01:00 +0000 Message-ID: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.174.116.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9b23b3a7-4654-4373-3cf6-08d8c15b2c9b x-ms-traffictypediagnostic: DM6PR08MB3948: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: fLtD/eariwfPpGbrgr/wz1kcP909WrO95HlP4x3GGWPf57e+2XP2L/iipw205C2ZPXE2rmmdSEV4r8nzWi84y24dJdDUg4h8ZtXpCF1QlqLkPx+MyK08rNJ0m06eifpxEwEsR4fTEk0rXffK0Fda5atapU+c5zeOii9Ad0B73ch5nU3beOL0rzhVGq3WTa52ZIBnr8mtiiIRBWUb0tgruyesBPNgh3NEb5CvADKHa2G0wwW/3IajAUiSrtofo93RH8+kIbckcgrDkTlfLyhBEZhi6GQ0X+q0Vkp89QosOsC0hqALbbmWKWocaJ8QlvpUEVA3TXr/W9Gq+ESu0y+XKqX/kbgEUFn2+TG2LasNrJhRH8wNX7WM064B/ciu0JtbIrvbLUkiw4MRLx6JKq/L63wKuPJhvoqptG+64FAxhvMw+JCcTn5gr7T+xJ9dJeXgE1UwHNuOpeOwG+6Qs4VkpQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB4972.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39840400004)(136003)(346002)(396003)(366004)(6506007)(2906002)(9686003)(5660300002)(52536014)(66556008)(55016002)(83380400001)(966005)(66946007)(76116006)(71200400001)(4326008)(44832011)(7696005)(478600001)(86362001)(26005)(110136005)(186003)(316002)(8676002)(64756008)(66446008)(66476007)(33656002)(8936002); DIR:OUT; SFP:1101 x-ms-exchange-antispam-messagedata: G9eAZH0rbIZzwo+HmuXiS8e9csIdm+MCFfUFcTYr+b3uvhs1Q5OhZyVn6/bV5Oy47iqqEhfC/551RlfkIfyCkAA7ZpY2NQFdScyQ5CbJ6krPVjrFSsZn811WxRQ3BAXkfPTCf1x9AnJ+6yXmc45DkW4KAJX4cUpmaaRigHofVPYUaW7cDgmkkLFc1Qx75MRlbOFODTu+PsaFzpGimZ7Oyj0AL9BCYCsh9f5oFDzSRa3FYg4/p/zSEkqnnzLoNTmeThVcIbMo4B7Rp5lHbqznySm+bAdIRzzB7cGIOtb4RlCVwdZezSZrD1Tumbc5Iko33L++6STxZqGQNrqQ+vJwfJBgNoeGJW+tjJN4dMD5dmJwZ6MjJt/RdjFCT11YlRQiw97Lb8hAP6nPdVw+7mReMi6VEEU2gG1HqifuD+agPVae/czF6rg7FXb6rmmUXn7xi8w05mbSglZ7L6IZ9nJleZTBDXRg1bbldEOfaKEspZSEsaM/8zo65IyX7RghB8pzy09tNkCpyz7S/iGBFzj5d5ECU4bOzqJB8Tt4hEVTQwVl7zypV1+a4vRJMigOzF6NQ7Rcm+21dHiarIp9wxYsDbMYzrJhay7VZPIB6U+5zeoTputI99UDGZm/1aBzum7ymge1WCqb0Fjhqs6kt04fCQvPa72KXcDF/wnoZsHshpO73eqqh59+rkgzRy2SxzggTa6g7VTLtvKmb2OWx4U5/4jgCNfaqt6qsmEt8bE3uflDINnpy3+s+weSvTRuwMbA x-mc-unique: TqLCl_LXMNqDqtwldWnPRA-3 x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: DM6PR08MB4972.namprd08.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 9b23b3a7-4654-4373-3cf6-08d8c15b2c9b x-ms-exchange-crosstenant-originalarrivaltime: 25 Jan 2021 18:01:00.6661 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 3197754b-b3a7-45b5-b82c-c8bc62c25b58 x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: /p0If/24uYjp7hZtPB4+66DxC9xZseVw7gSJtXPU3xAA+QUKfospoGoV0MTWzDUoSXbql50DDxmW+M1XIwrD3Q== x-ms-exchange-transport-crosstenantheadersstamped: DM6PR08MB3948 x-originatororg: gs1.org MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUK75A19 smtp.mailfrom=phil.archer@gs1.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: gs1.org Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: [httpapi] GS1 implementation of linkset draft 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, 25 Jan 2021 18:02:40 -0000 RGVhciBhbGwsDQoNCkl0IG1heSBoYXZlIGEgZmV3IGJ1Z3MsIGl0IG1heSBoYXZlIGEgZmV3IGVy cm9ycywgYnV0IHdlJ3JlIHB1c2hpbmcgb3VyIGltcGxlbWVudGF0aW9uIG9mIHRoZSBMaW5rc2V0 IGRyYWZ0IHRvIG91ciBwcm9kdWN0aW9uIGVudmlyb25tZW50IGxhdGVyIHRoaXMgd2VlayBhcyBh bm5vdW5jZWQgdG8gb3VyIGRldmVsb3BlciBjb21tdW5pdHkgdG9kYXkgWzFdLiBZb3UgY2FuIHNl ZSBhbiBleGFtcGxlIGF0IFsyXS4gSWYgeW91IGxvb2sgYXQgdGhlIHNvdXJjZSBjb2RlLCBvciBy ZXF1ZXN0IFsyXSB3aXRoICJhcHBsaWNhdGlvbi9saW5rc2V0K2pzb24iIGFzIHRoZSBBY2NlcHQg aGVhZGVyLCB5b3UnbGwgc2VlIHRoZSBKU09OIHNlcmlhbGl6YXRpb24gb2YgdGhlIHNldCBvZiBs aW5rcyBmb3IgdGhhdCAoZmljdGl0aW91cykgcHJvZHVjdC4NCg0KSWYgeW91IHdhbnQgbW9yZSBp bmZvIG9uIHRoaXMsIG9mIGNvdXJzZSwgSSdtIGhhcHB5IHRvIHByb3ZpZGUgaXQuDQoNCkFuZCBj YW4gSSByZWNvcmQgYSBiaWcgdGhhbmsgeW91IHRvIEVyaWsgYW5kIEhlcmJlcnQgZm9yIHRoaXMg d29yayAtIGl0J3MgZXhhY3RseSB3aGF0IHdlIG5lZWRlZCAoYXNzdW1pbmcgd2UgZ290IGl0IHJv dWdobHkgcmlnaHQhKQ0KDQpQaGlsDQoNClsxXSBodHRwczovL2dyb3Vwcy5nb29nbGUuY29tL2cv Z3MxLWRpZ2l0YWwtbGluay1kZXZlbG9wZXJzL2MvMkppcWNtQU0xNjQNClsyXSBodHRwczovL3Jl c29sdmVyLWR2MS5nczEub3JnLzAxLzA5NTA2MDAwMTM0MzUyP2xpbmtUeXBlPWFsbA0KDQoNClBo aWwgQXJjaGVyDQpEaXJlY3RvciwgV2ViIFNvbHV0aW9ucywgR1MxDQpodHRwczovL3d3dy5nczEu b3JnDQoNCk1lZXQgR1MxIERpZ2l0YWwgTGluayBEZXZlbG9wZXJzIGF0DQpodHRwczovL2dyb3Vw cy5nb29nbGUuY29tL2ZvcnVtLyMhZm9ydW0vZ3MxLWRpZ2l0YWwtbGluay1kZXZlbG9wZXJzDQoN Cmh0dHBzOi8vcGhpbGFyY2hlci5vcmcNCis0NCAoMCk3ODg3IDc2Nzc1NQ0KQHBoaWxhcmNoZXIx DQpTa3lwZTogcGhpbGFyY2hlcg0KDQpDT05GSURFTlRJQUxJVFkgLyBESVNDTEFJTUVSOiBUaGUg Y29udGVudHMgb2YgdGhpcyBlLW1haWwgYXJlICBjb25maWRlbnRpYWwgYW5kIGFyZSBub3QgdG8g YmUgcmVnYXJkZWQgYXMgYSBjb250cmFjdHVhbCBvZmZlciBvciBhY2NlcHRhbmNlIGZyb20gR1Mx IChyZWdpc3RlcmVkIGluIEJlbGdpdW0pLiANCklmIHlvdSBhcmUgbm90IHRoZSBhZGRyZXNzZWUs IG9yIGlmIHRoaXMgaGFzIGJlZW4gY29waWVkIG9yIHNlbnQgdG8geW91IGluIGVycm9yLCB5b3Ug bXVzdCBub3QgdXNlIGRhdGEgaGVyZWluIGZvciBhbnkgcHVycG9zZSwgeW91IG11c3QgZGVsZXRl IGl0LCBhbmQgc2hvdWxkIGluZm9ybSB0aGUgc2VuZGVyLiANCkdTMSBkaXNjbGFpbXMgbGlhYmls aXR5IGZvciBhY2N1cmFjeSBvciBjb21wbGV0ZW5lc3MsIGFuZCBvcGluaW9ucyBleHByZXNzZWQg YXJlIHRob3NlIG9mIHRoZSBhdXRob3IgYWxvbmUuIA0KR1MxIG1heSBtb25pdG9yIGNvbW11bmlj YXRpb25zLiANClRoaXJkIHBhcnR5IHJpZ2h0cyBhY2tub3dsZWRnZWQuIA0KKGMpIDIwMjAuDQo= From nobody Mon Jan 25 10:45: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 BA6063A1743 for ; Mon, 25 Jan 2021 10:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sullice-com.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 szhZqkMwRyQY for ; Mon, 25 Jan 2021 10:45:03 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 D24703A173F for ; Mon, 25 Jan 2021 10:45:02 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id d16so13369690wro.11 for ; Mon, 25 Jan 2021 10:45:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sullice-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=YiflArFzxSbvOiEtxkrNM9G74c6NclGAixIYB4ok6co=; b=fLXM05pJPCT0ZlsXjHY8bX03fnJI99c63GReNbyefMB2lbbuIg0T0UeWPuDEWQePLM stl/TlOiD7k11sF6jnPFXc2fF65NeDy8X2MV/lsJDvTCJ4B10yQoZJoVR27WngLcaWfF 9kMiJV3kngPtJvQ98AwcZ8s+kfWjStch935rP6RqfSP4mBUBAGrbtzNx92TvKv0kfM1J Au8DnjccCJ1CVlEuP9XfuM869JQ7GP5yhf087RxU44LxOXXhffMEFKpGPD6eoj3nDQI/ AkxO0NSbTTLY009jBMe0q0pbpP59ndGYF2ktGMApOUnEEwG/VJH6aiG3YqNU09venpeU wy0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YiflArFzxSbvOiEtxkrNM9G74c6NclGAixIYB4ok6co=; b=lGpKWChknvvCQmCEs30LbeLUlDrIjWaEid07bzCiJmRAHUc9sEgSbgL7GhiAiMOpCB GtnD/7duRyG0eE7srwTiKQdJKaigDYSTFmWy2yVLzVE0H5RtERHKRNfE3lBNpVL6IGGZ Vn9VYZ5GhEjD2Fct0lQ4vmLSH/w8r72WJIQApDbSGw3nXfYBtEc5JPlcvnZ0r4rri+IW NHFWgM7SO8gHkk8Yu7OtiDOSEpHv9O3FZWHZAhil4egERuCwMNzOFbdheDewCu6lR6yB LvHNaCgCks3XpeKH1GbM99lKwPaVBZEVAbBSIiPLCnLGbYrHrXemHm0nLxn9WS+5SY9v 7PPg== X-Gm-Message-State: AOAM533aWZ8FDjtWwEFw8+0Q1joYvfm6R3XmrSLAsNFZU9wRpV4WFKEf iWKUfNHVSi9Gf+It4m3z1jYr42DjBK712RA85PDQn/jij3MoEw== X-Google-Smtp-Source: ABdhPJwO4ctRz3ILPv4tbfHu/pN8rfBSjs2JLiQT/TkjzSOZaIf61XKbaZqmy77CPa8Gzd96CtVi+curF0DdQZyeLog= X-Received: by 2002:adf:eacc:: with SMTP id o12mr2477478wrn.202.1611600300707; Mon, 25 Jan 2021 10:45:00 -0800 (PST) MIME-Version: 1.0 From: Gabriel Sullice Date: Mon, 25 Jan 2021 13:44:49 -0500 Message-ID: To: httpapi@ietf.org Content-Type: multipart/alternative; boundary="00000000000071cb0e05b9bdefe3" Archived-At: Subject: [httpapi] Link relationship types for authentication 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, 25 Jan 2021 18:45:05 -0000 --00000000000071cb0e05b9bdefe3 Content-Type: text/plain; charset="UTF-8" Hello, Has this group considered working on this draft: Link relationship types for authentication Link rels for authentication, registration and user identification could be very useful for any HTTP API that may require authentication. It seems like a valuable thing to standardize to me. I see that Evert proposed it last October , but his email didn't receive any replies (unfortunately, I joined the list a few days too late). I think the group was busy with preparing an agenda for IETF 109 and/or his email may have been overshadowed by another proposal that had a lot of overlap with the Linkset draft. Is this something this group would like to work on, now or in the future? Kindly, Gabe --00000000000071cb0e05b9bdefe3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Has this group consid= ered working on this draft: Link relationship types for authentication=

Link rels for authentication, registration and user ide= ntification could be very useful for any HTTP API that may require authenti= cation. It seems like a valuable thing to standardize to me.

I see that Evert proposed it last October,= but his email didn't receive any replies (unfortunately, I joined the = list a few days too late). I think the group was busy with preparing an age= nda for IETF 109 and/or his email may have been overshadowed by another pro= posal that had a lot of overlap with the Linkset draft.

Is this something this group would like to work on, now or in the fut= ure?

Kindly,

Gabe

--00000000000071cb0e05b9bdefe3-- From nobody Mon Jan 25 18:52:30 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 E18F93A1B0D for ; Mon, 25 Jan 2021 18:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.45 X-Spam-Level: X-Spam-Status: No, score=-0.45 tagged_above=-999 required=5 tests=[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, RCVD_IN_MSPIKE_H2=-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=microsoft.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 axmZSn1JdFWS for ; Mon, 25 Jan 2021 18:52:27 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650107.outbound.protection.outlook.com [40.107.65.107]) (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 1BFB23A0C3A for ; Mon, 25 Jan 2021 18:52:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VWaVwzZppxOgjySamJ0/vhZVZILVvqZdiRskmtfUfon2ZEFWECunzxBDtaMzE+7hOYmO/9EOBAXvsOpm0F+2JzOaDhVLIXsf25PuoUY97yqwS9nws/eE5PIYaGK39wrDwq9R3TxBofWPuveEMvJSkbOOJ7uhfEZETOpY6x1ZufFXU5UWziqwexCkPrzRUQXlZ2wsH5cf20BfGICQbGQnZuLf6l1VjqcupxltM2koVNQzCzBP7yr2Ewm82gAVdTx6wn2JLcTfL3GOmMjXQEmZgPatOthr5QiA7S6l7BTkn+ZgnKU54HOK7nxWwbrWFrQcSM45gO8YPSej2pwqCYt68w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=09ODIcE3GfkG2RpB1YW53zoVC5douW7jO7ELrVsjrPA=; b=Tz8SF+WIZ+092iEx0vnl/KaseGt7XZMOrwIFULAXamSv6DZpk7B0WaJTBHP9u5CEi8HRheilj60KcPcoWcYdtbeWylbMcqoWKaAdd9pq4kqScDTW4UVdoLklWb+2xljBXm/JDZQR08wAF73ZAq5MtY3WRGEXdSkxL8VPgZKFVDaccvPTxSwlVUt7aD3LR8MIND39RyTBLZK+a+evcZglsp7exKO23pmv+ccI82WfEf+Uzz0QgeJ/m28koGVLxdSKP2+4DXFdlkxQQ7hLDYNJVzEm6XF/CR1rnsTK++ncNVjWmCLyTBm5dSabzI2i4kb3j5IvMWlaXZzos9ESSlEqPA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=09ODIcE3GfkG2RpB1YW53zoVC5douW7jO7ELrVsjrPA=; b=AtderLcEb4sWF8puLrS/TrTVRNQNInepih7rp23aGRkGl8/3K/XsvdY6D/RrJZg2YpHSFKRbH2ssqfhrLrY5ncNJDeoS6OekfUKqVctiWCFwfBQY9ptSojXip3T53PqhSedTUuV7QjAdA+oWmMTdWUv7sYGmazq6LZY+fpW6yIc= Received: from (2603:10b6:5:1bc::23) by DM6PR00MB0782.namprd00.prod.outlook.com (2603:10b6:5:1be::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3837.0; Tue, 26 Jan 2021 02:52:08 +0000 Received: from DM6PR00MB0845.namprd00.prod.outlook.com ([fe80::6450:8a43:1d66:8d3d]) by DM6PR00MB0845.namprd00.prod.outlook.com ([fe80::6450:8a43:1d66:8d3d%5]) with mapi id 15.20.3839.000; Tue, 26 Jan 2021 02:52:08 +0000 From: Darrel Miller To: "gabriel@sullice.com" , "httpapi@ietf.org" Thread-Topic: [httpapi] Link relationship types for authentication Thread-Index: AQHW80o3xHsPdJaWDkmC6ueoIIUivqo5M0Yh Date: Tue, 26 Jan 2021 02:52:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-01-26T02:52:08.174Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: sullice.com; dkim=none (message not signed) header.d=none;sullice.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [74.15.147.35] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f1b1d1fa-4c28-4ea5-7092-08d8c1a55f49 x-ms-traffictypediagnostic: DM6PR00MB0782: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sWvybKtrwndPQYAJQlmNQ+S8YZQ/wnvIS0kqaMqkar3OQmig9N63ZG1TWJd9dDWoIz8XOOe3h/5XMEWikDAMgk1lHVEsKRUINzTRT2ErwEqQaml5u6LhoGkW/K4kyhaafgEspj6Dxgr20f54VKHlyPfP15eoxAFV2zRI6M3JehcCtO8hVk6GEtTXb0Eh8iemLDihbNdK8SkO9wkjd+QVrMc7xqeACxHdC1TqGc3+AprMQru+ZprGEnkB4oWroPgy6t3qgv9F3XTpaJsVxpNVaIlwXvdqj/afc6dNPwTPSNVX/F26WHWv/LfBZWCfgJSRZ46GVqMBjy+C1fpSNGpr3HyNj5GqaftElltOS7cXtJeU3+nyVCrOpD5tVehNHc5Z4GqwCHS6Hvcf/KcaWJcYyqh3YJmkvZrWmFCr0Y/i5UIb4TmYTofope12grR3xluQHKM9fAKaGcUW4LT1yU/DOr6JYf0N74wzTPRTjbddT5Dj6IBaD+mYCK+nCV7EeYMo0uexCLoyioosiWuMlDuLkn3f1umrTb+4TWLNZCEu1cO9dUOz3rp89OL8mwHtcfuNvlhimoveSkB+EQGbqfAs4sf5GHSz0FBjOgEq1NVnlx8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0845.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(39860400002)(376002)(396003)(346002)(166002)(6506007)(66476007)(110136005)(316002)(8990500004)(10290500003)(19627405001)(7696005)(86362001)(76116006)(66946007)(186003)(33656002)(82960400001)(26005)(64756008)(82950400001)(66446008)(66556008)(2906002)(8936002)(9686003)(71200400001)(55016002)(966005)(52536014)(4744005)(5660300002)(8676002)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?v9qmSCY4YT3XKlmw7SXR9COMRkTdHCau0G2xpeZKND/6/Z6yMl5CRp8qKE?= =?iso-8859-1?Q?ZDktepNJe3Iwaj/xf+MeLWbA/6YEjDdcl5gL0VnIXvEv2iMn+og5C9Q2HE?= =?iso-8859-1?Q?bpvLpL3VGzf4Y6eIZr68LYSgbyl/6gbdFNKFSTw+DRm8FKXbek4pP9stlA?= =?iso-8859-1?Q?E09IW9cNdqHGjwAYxAQMDMl8Ymj/15LaKPp4qFb5RcqfdbNfKu1llZjfPu?= =?iso-8859-1?Q?MAz8cvqCB26H407y7vOB6Hyff+9gM5wP9h+wu5xCNXohsPyQKao2KCQQZn?= =?iso-8859-1?Q?Q9IGkM4FplUQ1NHCp6Jwt3Y70uNanHloweH3mGhzqMRphl719EdgBi3mKD?= =?iso-8859-1?Q?4dgQTQlADOZFVAkgjQJTCRRGnef/QHM96R2iptHUHZyIyJN1v11rcupnKu?= =?iso-8859-1?Q?gZUJ2wNDpd9F6O2Lb4eE1oJG//4ApJAFK+S0afFAIy7NayYDbwoU5WcF8b?= =?iso-8859-1?Q?/LANRyWS1U3SVF2iFOYOG0v0/mwOvuiYD5+Q+Yu0n16Z0vGnPjqWfzlPcc?= =?iso-8859-1?Q?O/GPqVbbjXs2+BO/lv6mbR+juAHz9k1ekClbCsYYn77yOkVujG4i8ZJbej?= =?iso-8859-1?Q?ADwpZfftaKIt/pVmIcBy8LVEVaevNjq3qHZxbzzjmcjfF8B5rRSwIYY5Gs?= =?iso-8859-1?Q?1WV7A4r33B81wYQdKLMX98oqS3snNPOq/hh9r84lPQ8fWdbrlDQrzSgbgj?= =?iso-8859-1?Q?JsHkgLVtmDKi19fIGKy5HZMw4Y0iV6O29g+CaSLl1AbQEbaK5VbGBCPy7z?= =?iso-8859-1?Q?ID4BNPzr87pYo8cJZ4xP/+3TsF4E5uK+veMToQgvF+k0N52yEZL+d+EF8f?= =?iso-8859-1?Q?js4WTIF8t2TQXwjSFgKOjNebFauetGqjyYThha+clWJNt8pMOteXp1Lg0p?= =?iso-8859-1?Q?EZmSPzwHcmwVKRwon6jJB8Me6YDWsZRn41Z2UdWartpocjZx2+TmovyQZ1?= =?iso-8859-1?Q?B437QjBccQUdHymi0gtHJ9LbKXGtz+iZ8IBYaGebHh8LdxP4RXmpglrSbF?= =?iso-8859-1?Q?Yii98RBosZ9iBQCiRVNR7jw++p/QUew/xc3CjwlFvgzioUuCYNAiQIsNqE?= =?iso-8859-1?Q?hUt1sokq2FI3VdNbgxFxFarX4tiLLhICZagdJccU3n7p?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB08458672E57AACC3BB8367EEF0BC9DM6PR00MB0845namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0845.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f1b1d1fa-4c28-4ea5-7092-08d8c1a55f49 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2021 02:52:08.4691 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: oEw1rfl1fa6DIk8Ifm+InA+x1LiDd4RmE+huH5cLubxgMQrcUYRBsc1768fpilZnfJ+YqekCbzLPRrzXvuA3uA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0782 Archived-At: Subject: Re: [httpapi] Link relationship types for authentication 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, 26 Jan 2021 02:52:29 -0000 --_000_DM6PR00MB08458672E57AACC3BB8367EEF0BC9DM6PR00MB0845namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hey Gabriel, From: httpapi on behalf of Gabriel Sullice Has this group considered working on this draft: Link relationship types fo= r authentication I missed this when Evert originally posted it. From a quick review they se= em like they would be useful additions to the Link Relation Types. Do you= know if Evert posted this to the Link Relations Type mailing list? https:= //mailarchive.ietf.org/arch/browse/link-relations/ They would seem like a good place to get feedback. Darrel --_000_DM6PR00MB08458672E57AACC3BB8367EEF0BC9DM6PR00MB0845namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hey Gabriel,


From: httpapi <httpapi-b= ounces@ietf.org> on behalf of Gabriel Sullice <gabriel@sullice.com>= ;
Has this group considered working on = this draft: Link relationship types for authentication


I missed this when Evert originally posted it.  From a quick revi= ew they seem like they would be useful additions to the Link Relation Types= .   Do you know if Evert posted this to the Link Relations Type m= ailing list?  https://mailarchive.ietf.org/arch/browse/link-relations/<= /a>

They would seem like a good place to get feedback.

Darrel
--_000_DM6PR00MB08458672E57AACC3BB8367EEF0BC9DM6PR00MB0845namp_-- From nobody Mon Jan 25 19:03: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 8D52F3A1ACC for ; Mon, 25 Jan 2021 19:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-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=microsoft.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 D3T4HWRoS6Cp for ; Mon, 25 Jan 2021 19:03:10 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640103.outbound.protection.outlook.com [40.107.64.103]) (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 F0CBF3A1B1A for ; Mon, 25 Jan 2021 19:03:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hTcOYMcs485K9ftCvG6S0TZZY/cTPT8Dggk2ETfkoTX9GMhaqTw+I5djsHdwuWNEyS/j3lCzzere3veNsJCfsX+SSpLn03mauAVuSbNzqogUcaAR9+WB8QNHiIu8ZgHKMGLHPzn36hUmh82a4jjTaM0YUyDpQV5Me3pO+P/MQ+GsyDsW8pVHJnXjEQClEg2LE+0hyMM3kf3um5MOSa+sbtfCiVQOVWQe+eWhEVuaFfo37D5MyikoSH/GUPJiJc5/GU+wbbjvSf8JNpWVoBZnRsRGWfbdBHeqWfi64W4AFKQAThi+BmXnFwO5F/t7ErdDcdZ+4FB8vyownOxuCDP44Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hq00xqhFmEcClUKEDhyYosuQnpY9RK8Cce5rOdIUTRo=; b=WviF/xWZyHPST0uZpGL1xOjVJ7wGCl2CjdpFl/QrB6ewi9oFcPGBjNQee3cPQIPDuYANcvatp7rsOmxZsA4UfKBGNE1O/Z2ca+78o7zSvJm9qcqVY/G1NMoDGiU/0s2iMSq2skA8AyKhVHKML8/FXHmA03Tt4tN6Exspm+BcVVKnA5Zj7GtBbK8MzbvYszaO7DOOOmpcbDinEWb6hM6sWPY6DhIKxDbr4kxdUtJhN5dnj9E0QLU7Cu8QBoyHtR7qDHqHBo5XPUYQU/LoKmA41IE8+MISvB1t3SB87vMIxzkoh6+7FcQY0kTp/F9rDsGyjj0486TvJul0zHp/WrnX/Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hq00xqhFmEcClUKEDhyYosuQnpY9RK8Cce5rOdIUTRo=; b=CFm1TlTg0JZZvZIXnMI6Y1k2ay+1dr6mfu1dVbUAesmLu1LePg2fSwI+vRWN9ERSdhtnf5sFfHjjzTymLfbYmyYuXFyCVitXVpvox/E73IROjoSXN1Rpizj4ctt+HoQf5KJTI8CIMsjnCmobf2vmbzYYYTm0rwqZTqsbPRsW6Ow= Received: from (2603:10b6:5:1bc::23) by DM5PR00MB0439.namprd00.prod.outlook.com (2603:10b6:4:a1::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3837.0; Tue, 26 Jan 2021 03:02:43 +0000 Received: from DM6PR00MB0845.namprd00.prod.outlook.com ([fe80::6450:8a43:1d66:8d3d]) by DM6PR00MB0845.namprd00.prod.outlook.com ([fe80::6450:8a43:1d66:8d3d%5]) with mapi id 15.20.3839.000; Tue, 26 Jan 2021 03:02:43 +0000 From: Darrel Miller To: "httpapi@ietf.org" Thread-Topic: Call for Agenda Items for IETF 110 Thread-Index: AQHW845ZOo9oXKB4h0+AsASCE+B+Xg== Date: Tue, 26 Jan 2021 03:02:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-01-26T03:02:43.616Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [74.15.147.35] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 08039e31-0ae5-48e9-7a86-08d8c1a6d9da x-ms-traffictypediagnostic: DM5PR00MB0439: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LmX2CN2nBghElnC1zb7AAAqMN5YLLAjW7//es3VFH99Yb2JJV9t5KcaQR7PqqCCEwAqbVyPdZu6dMlIWSnblrdjCJbC6BDCw3LVcXRNDpJtUNE5nPWiEbW/YazA9MG/0r7pXJVw3pj+LN/vXGM46dDrxitN6PjJqSIPPYrC9o0jAGhi4RO/8R2x3ntuUCXbEiyfZ4Iodf+ETgvZkq4k4Yb19eK/mjlKBapsVTwyEIzMQ/4XB2RMcTHkrHhUk9aJe3W/YxwQHeX1DEiIBd6OIG2J6cgE2kK7qP2TcIC9+wLVOsy5c01ngp4Y9Dxa6Esr4duFjoo15suSSpf2EAEgy1JCXk7uteiQOMdnT9bPq+blOMSeDz85ncJjE9lOy6xTRa3vgedxqFwd/17tyCxEURxQqXOWUYBWYd2e4DhefTOGqdUW5bTCOX84BSVtJC3FZoZ9Zk6Uy97RsBA/OMcEaVHVEO6LQmea5sJvU5VtJziJzxT0xKbnueyornacSQOet+N2PW0aQEBQ/Bu/YppMzTlhJIcSjmgyLxDaREG8cO8paQQI/RXwPCwt7DfXGEqLr4pub9fKO1d+4Jcgt5ztT17RJZhv5um9q9Ql0fdNq5jQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0845.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(396003)(136003)(366004)(39860400002)(10290500003)(5660300002)(66446008)(478600001)(66556008)(86362001)(4744005)(26005)(8936002)(2906002)(82960400001)(8990500004)(82950400001)(316002)(186003)(9686003)(76116006)(6506007)(55016002)(66476007)(6916009)(83380400001)(19627405001)(71200400001)(52536014)(7696005)(64756008)(966005)(8676002)(66946007)(166002)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?+WtgOJIKAep3zNr/MmF1uephdNZt0H/ltMLrJS/VTE/ZHusik7WeB2jpZb?= =?iso-8859-1?Q?jEkUUJtieHLzCfSMz2DTfhn/MMhAFn31ArfOwp9K2o9inczpMLXFQC2rPl?= =?iso-8859-1?Q?nlfsSitVxNrg3zXXqvzjSszFKivfHBuwHO3Wj8cZLwBRbv+6A7aDScuD7J?= =?iso-8859-1?Q?0o88Zpj7W0a1ZYnuzJzZrxqm84Itw1/Z1vuc1EOEwOA3TGMpXb3taOtijn?= =?iso-8859-1?Q?l005mx05u4A36pdVfdtNeQd8raG8XbCz1PJgOQCta84HPc7TZe43s1Gbv1?= =?iso-8859-1?Q?mCPQzRSwXYNBoljMEPZIt5zH9P1iaF4T7FO6iuCm48B5Xk3g7xwz8utgXW?= =?iso-8859-1?Q?Ex6Noh8N+3Vy0gW/1a1EwizioKTbcUVaHC8/HaWh1GMsZ8OUB1813qVCNu?= =?iso-8859-1?Q?AU/xyBFNa3wHE+ltkdTRxQ5J2naEdbizihp6CYC2zPxkdoR2JFtzzDp7Al?= =?iso-8859-1?Q?uS2jI3GS4gSOZQCAySVdRNUgbBkhLWuiLML+i7uhduQZTSSebND8m3a1F4?= =?iso-8859-1?Q?4B4CE1rkUmD/AeAerIMwCaHSj/5NDjOcLMpWgwyOEyN8119CE8Nu/k2sVW?= =?iso-8859-1?Q?Jy67sixyOGK4mzeIzMQHSAXcBgbRmNmJPbKPHfhvgbKVl0OnkuTX2JXxFe?= =?iso-8859-1?Q?b+2PbjAuK6oWUYWO4t832dSeHNiKRbCFkrRdO41CSnHcEjPL7h38RqhDJ0?= =?iso-8859-1?Q?vBCevq0y+gq1rshNI4taNw9rcm2gyKGoHkAzNwIsWihwWaD45a4H978V6O?= =?iso-8859-1?Q?ghrAlM3h2CD2TsFuF/Az0d/kWu9yeIv/x2Wc+ILISTTp0zPNEpR9DgNUVU?= =?iso-8859-1?Q?c/9giukfDDYsD3sfaNMCV0htxQ94pBiTcYIYFkdh5HGOhjaur16TBpeV+8?= =?iso-8859-1?Q?Qjqm6cOM4/iWgHiMCE3n2xQDlaYvPF7nz7FTeG9sI4k+B7rwrW0ZoMGBo6?= =?iso-8859-1?Q?ORzyLT5IdmrOtfi7kjxpaMs3JKXvt0m/Y+op7yOxBhLXWokA6Jcwq0hPby?= =?iso-8859-1?Q?8mNlwPvivwqNNExR8F9VQ1LbhiuqwkJVFyy0kMKeevEkUu7vHwc3kjglmy?= =?iso-8859-1?Q?8DhAnTiPH6wNVzhnuAEckSJzRt7Dqp5UC/4QlJXU3bSg?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0845A288154386E39431357CF0BC9DM6PR00MB0845namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0845.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 08039e31-0ae5-48e9-7a86-08d8c1a6d9da X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2021 03:02:43.5665 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tSgiwe3b2CyoptK704ZJ/+LabcKWFXrQ+XCQsvueE8k5G1CJ0FxOtQC+YDLrW+HGplAfutFcvHMzu09oJYYRpw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0439 Archived-At: Subject: [httpapi] Call for Agenda Items for IETF 110 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, 26 Jan 2021 03:03:12 -0000 --_000_DM6PR00MB0845A288154386E39431357CF0BC9DM6PR00MB0845namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear httpapi, We will be meeting online during the IETF-110 week (08 Mar 2021 - 12 Mar 20= 21). Please note that whilst this meeting will be online, there will be fee= s for attendance (though much lower than for in-person attendance): https:/= /registration.ietf.org/110/ . Note that there is a significant discount for= full-time students and fee waivers are available for those for whom these = fees pose a problem (everything is in the link). With this e-mail I would also like to call for agenda items for the meeting= . If you would like to present please express your intent on the mailing li= st or by contacting the chairs by 26 February. Due to the fairly compresse= d timeline of our last meeting, for this meeting we have scheduled 2 hours. Guidelines for presenters can be found here: https://github.com/ietf-wg-htt= papi/wg-materials Regards, Darrel --_000_DM6PR00MB0845A288154386E39431357CF0BC9DM6PR00MB0845namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear httpapi,

We will be meeting online during the IETF-110 week (08 Mar 2021 - 12 Mar 20= 21). Please note that whilst this meeting will be online, there will be fee= s for attendance (though much lower than for in-person attendance): https://registration.ietf.or= g/110/ . Note that there is a significant discount for full-time studen= ts and fee waivers are available for those for whom these fees pose a probl= em (everything is in the link).

With this e-mail I would also like to call for agenda items for the me= eting. If you would like to present please express your intent on the maili= ng list or by contacting the chairs by 26 February.  Due to the fairly= compressed timeline of our last meeting, for this meeting we have scheduled 2 hours. 

Guidelines for presenters can be found here: https://github.com/ietf-wg-httpapi/wg-materials

Regards,

Darrel
--_000_DM6PR00MB0845A288154386E39431357CF0BC9DM6PR00MB0845namp_-- From nobody Mon Jan 25 19:32:03 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 425793A1B4D for ; Mon, 25 Jan 2021 19:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.449 X-Spam-Level: X-Spam-Status: No, score=-0.449 tagged_above=-999 required=5 tests=[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_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=microsoft.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 PjIHdP6bM9bU for ; Mon, 25 Jan 2021 19:31:59 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06on0057.outbound.protection.outlook.com [104.47.54.57]) (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 8C8FC3A1B4A for ; Mon, 25 Jan 2021 19:31:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TDUvA8I1sWWxeWCi+KjuIZDryZqFqaG3v3dOEDJcucUuijhEDm/26gV+6l28SFHr+ij4XUHIcvFqKwb23y16oMi5Xi1ZhqK3bg0SNeCwO6L6KndtDHaQPE3XB+QcWWLtTYSJybPsnieq5cmPSvtXOd9cxVKZJyW2Y+5omBVcIofz9AVLJRQhwENHNCP6H4UQcCdE9wqg+QJ2XylRigWoglKvoDW3u9+/RdamSPYSxMoegwyhB1RYnxFIO0w3jsQb6cc8H8YBQNSKpD6HysQWcHxOT+/gVf+86hzy7x5GVSGlfhUpMt8qUfWpYfjUe+k18SMFtpMR9k8xtK4ox83X7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vfNzwhwD9Te4Ktrjs/M9mDye21CFl3Fk0pqrkpP4jgc=; b=Z7FZaVIVvXLZSYDpT4EcA0y2XTSYjgblvVeyReBFX0IbefRjwB/zsgykEhezmF1+QIecSQKlWuY7OQIQMQwl5DzkbdKcMzyZzhRBxADNAzZjlw/ZRqikNINOkSERsoie+q46WoUINjDLOvrTa2Srv2HrR5Ahk4i7m0fdSgIkuPhgQZk/iUjxHeLhtBADeLmvc2+hUqo8VXpZbkX53Y42sfcnBtfMBn5HI/pFBkd1qZdPkeascbIA77gaLAkgXGtXufZ0mxGxiHU0uUd4zTtOFWvn3XV2Kzsh09AKAAGfdBhSdeXaF64u3PF0sa7gcwk6HoGTM3Rqa8KpEsrMvbQtVA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vfNzwhwD9Te4Ktrjs/M9mDye21CFl3Fk0pqrkpP4jgc=; b=GseaRDhdjICNEME2CBry3xDB4F+Ev0jgvpBYaCxZcxnxMRRlGlA+2ZUTjtBIuGHhFDMPjzZEeFMSBBHhA8MZk/GV/7C6pD1Gh4P1D+3YiO6gYAnhfgJYSj9Ej7QKK47INXjfimH+BxushUHWYQb/WDLBXEQ7hBIYVsrieZJPNLA= Received: from (2603:10b6:5:1bc::23) by DM5PR00MB0296.namprd00.prod.outlook.com (2603:10b6:4:9e::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3829.0; Tue, 26 Jan 2021 03:31:37 +0000 Received: from DM6PR00MB0845.namprd00.prod.outlook.com ([fe80::6450:8a43:1d66:8d3d]) by DM6PR00MB0845.namprd00.prod.outlook.com ([fe80::6450:8a43:1d66:8d3d%5]) with mapi id 15.20.3839.000; Tue, 26 Jan 2021 03:31:37 +0000 From: Darrel Miller To: "christoph.kappestein@gmail.com" , "httpapi@ietf.org" Thread-Topic: [httpapi] Discussion about JSON payloads and code generation Thread-Index: AQHW7AmIPyJ32zvjfE6Ci8mHOwNnYKoqynhfgADqNICAAI74B4AA6lgAgAllZACAArdRjA== Date: Tue, 26 Jan 2021 03:31:37 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-01-26T03:31:36.881Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [74.15.147.35] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 27612f02-4696-414a-9e78-08d8c1aae329 x-ms-traffictypediagnostic: DM5PR00MB0296: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yofOKk2xXXwNYUMnS6qlnEyDBDbCtnhtCB9lr356qsLERiwndP+yON5L313p2nvfjeS2xpNajl9cyqGIJJaTkJ1jHnNDsUNPhrS8ptd5d57f7H14XtU+sco7W6hKbgTOFfArGG6GGLFhk2lHtUBwpaUS9VycbV4UEhNr7m1rwTrbZ9sIuphoZzh+kyGTHSG8mAXmmxtn+dEiYMtVrod6FgeWYXX/Tb1oD6Y3R8YF0Cyp53YehXqO0mPhMGWtOWAxk+MP1dsld/YynVCQewkKI6rBrx/B0JQA4PxgMEsER0aU2WkJtTT38poj5/EN0307Tx1r9S47m7gE0+hJCln5laT8N5v+iRIm7v7SJxPS6k4/TDfHHCEo0ONJMqQjYFaDASX3n+dvN0riPRmi5tprDvStUup4nOQwW8QJVurACfYJ9UsIM0bxY/EMXaN+Nk/4AR6sToIno1s/uFPDQr1z4M3/ksHpcsIqI/ZKhWKhJeSD/D2hGkiywRhXhCKQr5lznVC3cvFQcT3e9pAxg8yC84bXoEKGpX/UojYimK1ZfTmjtvagoYNfQ9v7b2Ws3QWQxdrVu8VGXWVMITxk7Neyet8o3KhT0nEhhzI1l2c/V6Y= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0845.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(366004)(136003)(376002)(346002)(7696005)(316002)(110136005)(2906002)(478600001)(86362001)(966005)(76116006)(10290500003)(52536014)(66476007)(66556008)(64756008)(66446008)(66946007)(55016002)(6506007)(19627405001)(71200400001)(186003)(26005)(33656002)(8936002)(9686003)(8676002)(8990500004)(82960400001)(82950400001)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?4FpVaJuCBaB0I4g/ujw8UK4ipQPXZKqT0XJGR0h189XAnOWBjdjlZFfWXO?= =?iso-8859-1?Q?q0y2Rd5e5TTStxWwn5tpezXQuVNsO25eEQjZcBMAqo0+ZtYcfi9Ye3r0a8?= =?iso-8859-1?Q?ftg/sLLPeg6wsPxAD3EgV01I4ADXLWyVFC+Gfonws5qr4rEPulyshznn7q?= =?iso-8859-1?Q?LBrojZ8zv3VllLIhbh8pjfpnjqNnSUKGF8d6yvUlOST4cZAwzB3wSEHdtL?= =?iso-8859-1?Q?hwJAXmDVwcMUjwvTiNwHtdQYrffUYfdFWFRyDCK9EP+PJWjx1tjfD6Nu3Z?= =?iso-8859-1?Q?FAR1YozqPAyzXJFKS8dUUQZOdzuEEz2bti4EpNa69h5fmU6vkz4RXVowRc?= =?iso-8859-1?Q?medNGNmeis1Avn9aNbkV5nakemxByuiV+8ZyYWaurGglagbl2XZAhSNi4o?= =?iso-8859-1?Q?HHVc1fvxXD41up3K5oi7K+g5eRi35p48g8U9k6vk3u2vCYipo1x25wUbNc?= =?iso-8859-1?Q?cS8BXsdKnbGE476hqSUooSTf9JLi28mAEqpdT75/u6CHKCGy/btl3Nh8Qv?= =?iso-8859-1?Q?2qIRCQ3mgcmEkc+qX1RlKdACkKlqpNfpsSHQHstVHBqxn4aoOPB5/zGvvx?= =?iso-8859-1?Q?CurpTFE3dAFlq3O1MHVJvEnPA5COmeAIFD4zVAe9Q46qmLTMziMt85aqAe?= =?iso-8859-1?Q?r7cR32zhkrGYLvJSFbWANmNwnKAmbuRDNw16NR7OvaUzmjffaMSZAbn3C+?= =?iso-8859-1?Q?aJc0fYhRLConRtRrJL7ENFhih64OzGNSdx9XwhRNEjwLhvYyLlga9Bq0Lo?= =?iso-8859-1?Q?N1gF4zfw+uaOX/RqE3ZoSGq3FIXfNQcIMu+Y+kNSCdelgb1I63F60fNxLL?= =?iso-8859-1?Q?zZCPNrKI2VNrHyUeliP8AjfmbmRRH66TLaVoZtLLtHOWZ/MAQC61TUiisd?= =?iso-8859-1?Q?TPkD8qkKP5rGD4eaNDCjYFu1bHwq7K7wHKcn/STsRWtKIBQHXwWDbaHTS0?= =?iso-8859-1?Q?QPZB3tJHzVQxt/SV8JdFzUlxeeF/rodSVtnG0lM7j2x7Yg6mZu+guRch17?= =?iso-8859-1?Q?rd77FuRVonEBhYVvCwaRf3BuZM/DDPan3FX9STcrAOt0TtYs2ABzdVWjIR?= =?iso-8859-1?Q?1RZ1hNntiyMMMcTf10YB07jMXG+5rU18aV6b4JJWVByf?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0845395CA1758BB99D2D4863F0BC9DM6PR00MB0845namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0845.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 27612f02-4696-414a-9e78-08d8c1aae329 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2021 03:31:37.2154 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /i6yTGLhITmAX0Zep0vrScg3KeNrbt2aN3Mj4tNm+9RWiKbZTgcqMC+XhQhGK/B4F18j54eOfbmVtXW1GnP6Tg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0296 Archived-At: Subject: Re: [httpapi] Discussion about JSON payloads and code generation 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, 26 Jan 2021 03:32:01 -0000 --_000_DM6PR00MB0845395CA1758BB99D2D4863F0BC9DM6PR00MB0845namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Christoph, From: Christoph Kappestein I am wondering whether it would be also possible to describe complex types in such a specification, i.e. that we describe how a list, map or object/st= ruct type could look and is defined through keywords. So I would totally support= this effort, since this is basically the reason why we have developed TypeSchema= and we would be happy to build upon such a specification. best regards Christoph If we added the constraint that complex types must be described using JSON = primitives, then I could imagine enabling a registry of "well known" types,= including complex types and their corresponding JSON serializations. One thing that appeals to me about a registry of well known types, is that = no particular serialization needs to win. People can just pick the one the= y want to use. Going back through the short history of this working group, we have the Lin= kset draft https://datatracker.ietf.org/doc/html/draft-wilde-linkset-07#sec= tion-4.2.3 that serializes a link as a map entry and Evert Pot's https://to= ols.ietf.org/html/draft-pot-json-link-02#section-2 serialization as an obje= ct. I've seen scenarios where both formats make sense. There is no reason= that "link-relation-map-entry" and "link-relation-object" could not both b= e registered. Darrel --_000_DM6PR00MB0845395CA1758BB99D2D4863F0BC9DM6PR00MB0845namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Christoph,

From: Christoph Kappestein = <christoph.kappestein@gmail.com>
I am wondering whether it would be al= so possible to describe complex types
in such a specification, i.e. that we describe how a list,= map or object/struct
type could look and is defined through keywords. So I would totally support= this
effort, since this is basically the reason why we have developed TypeSchema= and
we would be happy to build upon such a specification.

best regards
Christoph

If we added the constraint that complex types must be described using = JSON primitives, then I could imagine enabling a registry of "well kno= wn" types, including complex types and their corresponding JSON serial= izations.

One thing that appeals to me about a registry of well known types, is = that no particular serialization needs to win.  People can just pick t= he one they want to use.

Going back through the short history of this working group, we have th= e Linkset draft https://datatracker.ietf.org/doc/html/draft-wilde-linkset-07#section-4.2.3<= /a> that serializes a link as a map entry and Evert Pot's ht= tps://tools.ietf.org/html/draft-pot-json-link-02#section-2 seriali= zation as an object.  I've seen scenarios where both formats make sens= e.  There is no reason that "link-relation-map-entry" and "link-relation-object" could not both be registered. 

Darrel
--_000_DM6PR00MB0845395CA1758BB99D2D4863F0BC9DM6PR00MB0845namp_-- From nobody Tue Jan 26 00:38:48 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 A36E73A1D3E for ; Tue, 26 Jan 2021 00:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 hLMXou4ws1hA for ; Tue, 26 Jan 2021 00:38:46 -0800 (PST) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (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 07DCC3A1D33 for ; Tue, 26 Jan 2021 00:38:45 -0800 (PST) Received: from 77.128.78.83.dynamic.wline.res.cust.swisscom.ch ([83.78.128.77]:51637 helo=dretpro.home) by postoffice.gristmillmedia.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1l4Js3-0000SP-Kl; Tue, 26 Jan 2021 03:38:43 -0500 To: Darrel Miller , "httpapi@ietf.org" References: Cc: =?UTF-8?Q?Andr=c3=a9_Cedik?= , Sanjay Dalal , Herbert Van de Sompel From: Erik Wilde Message-ID: Date: Tue, 26 Jan 2021 09:38:41 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [httpapi] Call for Agenda Items for IETF 110 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, 26 Jan 2021 08:38:48 -0000 hello darrel. thanks for getting us started for IETF 110! On 2021-01-26 04:02, Darrel Miller wrote: > With this e-mail I would also like to call for agenda items for the > meeting. If you would like to present please express your intent on the > mailing list or by contacting the chairs by 26 February.  Due to the > fairly compressed timeline of our last meeting, for this meeting we have > scheduled 2 hours. like at IETF 109, i'd like to request slots for three drafts: - https://datatracker.ietf.org/doc/draft-ietf-httpapi-deprecation-header/ has been adopted as a group draft since the last meeting and i am not aware of open issues around it. maybe we can simply bring it up and provide the group with a last chance to give their feedback. if no new issues are raised, this draft probably can go to last call. or is that even something we can do on the list and then use IETF 110 as a place to wrap things up? - https://datatracker.ietf.org/doc/draft-ietf-httpapi-linkset/ also has been adopted as a group draft since the last meeting. we still have a few minor issues we need to add to the repo. but as you've seen from phil archer's message, we now have a major implementation out, so it would be great to try to wrap it up and maybe use IETF 110 as a last opportunity to give feedback and raise issues. - https://datatracker.ietf.org/doc/draft-cedik-http-warning/ was proposed as a group draft last time and has been mentioned on the list in a variety of messages (in the context of discussing possible refinements/additions to the RFC 7807 model). maybe it would be good to bring up the draft again (even though there hasn't been a new version since IETF 109) to once again gauge interest, and to also see if/how it can be aligned with ongoing efforts around exposing warning/error conditions. i may or may not be presenter for these slots. all three drafts have co-authors, and i'd be more than happy to step back and let the co-authors present. thanks and cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Tue Jan 26 07:04:55 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 ED34E3A0B58 for ; Tue, 26 Jan 2021 07:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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=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 3aegj1Bnk1GO for ; Tue, 26 Jan 2021 07:04:51 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 A05183A0B53 for ; Tue, 26 Jan 2021 07:04:51 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id h11so34026226ioh.11 for ; Tue, 26 Jan 2021 07:04:51 -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=DKM4rnW1lbBJs+HsvVrY6Z8bDPu/YJXnrTupmCTYWf8=; b=YI+alq9hShDfYoeTbs9yq0+EhQFODeee5ni+14+xuwtl1YIkK8S95skP5wk1PwjR/P tQWeGOPbhEk02Ct61BsaJNpQ+g6N1tgqmUYwHc6ODLqVAeXP8I7+E7JS+3ppzLxf68ge v4jvC2TQ8uUm3E5i08HPS67AxLzW1LMW/h3wAJGyYGbim4hRLaVv3+DQxIQxTFp2MGKT vM1i7R8Ag3Stx9HMYYoJqhpgv0ENQvCynwLyU5+Q5cDhkMVsRDfQFJi4ofvNMswJ3+yj 4z5E6yDaeI0HlalTCtJkvRUHgUGDvVxnOZ1XgmOdJaD3GKnMf6/4z+29dTCx+nfSFwEs d0sg== 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=DKM4rnW1lbBJs+HsvVrY6Z8bDPu/YJXnrTupmCTYWf8=; b=cCaCaBw/x+O5Wi5WNEx8aZs1CE8nTqfZxszvmoC2UbUL3CloCv3uny7GuKBFoKd8XO oT1HVxhZjekDrB4U6zkXVlvGG9fvClPWo1g8dA1onv5H6SgibQHJlAaPAucMlyXL2uRU 7Gf+ENCfgAFCCVYxOMyh78CvAdb4gAIrYeTrexJdyXdc8YZsbkPiDVN0Zzx7cEwDJYr2 gEyPYkWhBt1gFpyy2Ql/gYfHxdMSoF7k0LZUEFARGAFCojCSu8tTD4yj6KWiEtbyyQtL a8jGD2Im7/bMvuqxw9ejisBs8v9btolerfADdwfzJjbm/JJTrZFlM7YXpTTAOJFrLczR nujg== X-Gm-Message-State: AOAM531wggx4f704Wjc7HRDUA6fBkNVrBQEqEL5ZFUbwYwstFqxFFnWg WpkkdigNN49ZPz3+jw8aBWBSoKn9mFru4Ls84anXsNuM8pM= X-Google-Smtp-Source: ABdhPJy0z4jVvcKLjLTIebqdJLFKdbXoKvKUJmnJK25DLhePpHGPh8ZKDesBIATZmFhqBjKsqBR/pcK3CPmlU0fI4yk= X-Received: by 2002:a92:6a10:: with SMTP id f16mr5011645ilc.146.1611673490618; Tue, 26 Jan 2021 07:04:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roberto Polli Date: Tue, 26 Jan 2021 16:04:39 +0100 Message-ID: To: Darrel Miller Cc: "gabriel@sullice.com" , "httpapi@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [httpapi] Link relationship types for authentication 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, 26 Jan 2021 15:04:53 -0000 Hi, Il giorno mar 26 gen 2021 alle ore 03:52 Darrel Miller ha scritto: >Do you know if Evert posted this to the Link Relations Type mailing list? > https://mailarchive.ietf.org/arch/browse/link-relations/ Maybe the OAuth workgroup could be interested or working on something like this, too. Pax, R. From nobody Tue Jan 26 12:55:15 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 2B78A3A0E8E for ; Tue, 26 Jan 2021 12:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.22 X-Spam-Level: X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=evertpot.com header.b=HYU5wWVt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MrAeD8dB 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 R2DnKNURGZUa for ; Tue, 26 Jan 2021 12:55:11 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B01573A0E8D for ; Tue, 26 Jan 2021 12:55:11 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id AD1C9B06 for ; Tue, 26 Jan 2021 15:55:10 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 26 Jan 2021 15:55:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=mesmtp; bh=LO0VDwDGuS3cC0EnWm2TAuRY Vb+VP/K/jCz2lZ1U0ts=; b=HYU5wWVtFVI6Ph8lDGeWedl7U4UAQO1C9uE5jxrW P3PCHPEWc3i31t2JpoRW9qnUTCKRZtOWILKmsV6K6DvVGLt/wTx320B9ajwFVE42 j2bTHCgdHaLarTZBkX6puZqIIzSM1G9EG2Am9bWXHEalO8OZx6HVHi4v1ANc4p74 /gA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=LO0VDw DGuS3cC0EnWm2TAuRYVb+VP/K/jCz2lZ1U0ts=; b=MrAeD8dBp+2+WZTAAmUMFP 6KN4VOqRCyiOYC2+Oiy+BPTyf33h3/Y71mUiBO57JG+sDuRD1H72avkmMe4AUV56 Z2Pvur2NH8sB61aYM6hteybKf/HF0lJYzA06GgojauuUVQobdubUQ8fABMQNVsdS Wpksnlq5SinGbrlVXj4357u6bpvu36clxyvrtEJ6qXywt1ZIXjGAgxBlKWknAYhz 70htcU1Byu2qGoL14khHq9EkIxoL5si3P2ND7NLuet7T4YbCCmA8y+0s1fwipGVd MwPgScQDCTpX+IUudeVSiRtIDSbGqitn83axqiG3GCz2/xedPBGhCv9wkDl4aGSg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeigdekudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtsegrtderre dtfeehnecuhfhrohhmpefgvhgvrhhtucfrohhtuceomhgvsegvvhgvrhhtphhothdrtgho mheqnecuggftrfgrthhtvghrnhepvddtleelteevledvvdeigeeggefgfffhvdffheejue eitdeuheeftedufeeiuefgnecuffhomhgrihhnpehouhhtlhhoohhkrdgtohhmpdhivght fhdrohhrghdpghhithhhuhgsrdgtohhmnecukfhppedugedvrdduvdeirdduieeirddvtd ejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgv segvvhgvrhhtphhothdrtghomh X-ME-Proxy: Received: from [192.168.2.63] (unknown [142.126.166.207]) by mail.messagingengine.com (Postfix) with ESMTPA id A686924005D for ; Tue, 26 Jan 2021 15:55:09 -0500 (EST) To: httpapi@ietf.org References: From: Evert Pot Message-ID: <8e3c40c3-7256-c905-6003-d7860543b0de@evertpot.com> Date: Tue, 26 Jan 2021 15:55:06 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4CC429F7C1D2AAB566F34E83" Content-Language: en-US Archived-At: Subject: Re: [httpapi] Link relationship types for authentication 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, 26 Jan 2021 20:55:13 -0000 This is a multi-part message in MIME format. --------------4CC429F7C1D2AAB566F34E83 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Darrel, On 2021-01-25 9:52 p.m., Darrel Miller wrote: > Hey Gabriel, > > > *From:* httpapi on behalf of Gabriel > Sullice > Has this group considered working on this draft: Link relationship > types for authentication > > > > I missed this when Evert originally posted it.  From a quick review > they seem like they would be useful additions to the Link Relation > Types.   Do you know if Evert posted this to the Link Relations Type > mailing list? https://mailarchive.ietf.org/arch/browse/link-relations/ > > > They would seem like a good place to get feedback. Thanks! I just opened an issue here: https://github.com/protocol-registries/link-relations/issues/24 Evert --------------4CC429F7C1D2AAB566F34E83 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Darrel,


On 2021-01-25 9:52 p.m., Darrel Miller wrote:
Hey Gabriel,


From: httpapi <httpapi-bounces@ietf.org> on behalf of Gabriel Sullice <gabriel@sullice.com>
Has this group considered working on this draft: Link relationship types for authentication


I missed this when Evert originally posted it.  From a quick review they seem like they would be useful additions to the Link Relation Types.   Do you know if Evert posted this to the Link Relations Type mailing list?  https://mailarchive.ietf.org/arch/browse/link-relations/

They would seem like a good place to get feedback.


Thanks! I just opened an issue here:
https://github.com/protocol-registries/link-relations/issues/24


Evert
--------------4CC429F7C1D2AAB566F34E83-- From nobody Tue Jan 26 13:05:39 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 4FD8F3A0EEF for ; Tue, 26 Jan 2021 13:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=evertpot.com header.b=itDtbkY5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QWJ9iJ7n 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 gsZdJURVosNi for ; Tue, 26 Jan 2021 13:05:32 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13CB23A0F04 for ; Tue, 26 Jan 2021 13:05:32 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 2CC47B06 for ; Tue, 26 Jan 2021 16:05:31 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 26 Jan 2021 16:05:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=mesmtp; bh=wbuzFTw3TXXnbYBth0UZVK5VFYWUdP6E5uZwrW6ePes=; b=itDtbkY5CbZ7 MeGkrfhVwSIUz6P/lx432rX1hIqsgy1ggzwVPYsjJTdkxCphJgrk7TINAXsEBjSc SX9RgerWezULH0X7UNhxs1hM3CvTHaqkcvZNG4aDOjzCS/gHwx9jTQfh/wbMyv3R ia2EWliWybhGE01gD+vIvnsqF4MzXnw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=wbuzFTw3TXXnbYBth0UZVK5VFYWUdP6E5uZwrW6eP es=; b=QWJ9iJ7ndwwbE/qvpDW0dWc0vsQ8xaPPkb6z2U0UWuB6SfizKJTDz59nI FymnT2UxMT2l0Ntd+8v+tMpORySN/AuD4jGclK+FSPuZT6b+XqAgM/RpEF5sWP8L PSt0gwUoiaoc0U2Ob1MHRYv4HXoqpTMuqfp+l67fBZ0hLfWnvLGBlTiOTfbvOXTn UE69n/FLBY5AyvsYpBmMnaIYhkJk0FzK1FM+x1GYsKLlbTefpxd40RxACppAwrdF mSHqSwvlrpdcWjpzGe/ITw3UAGKIK0/siNiBZQ33H77rnlVoy2TcVm5d1zUAYN1r v5l8AmvVGsgj9MR+UPQ/TMp6/p2LA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeigdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthejre dttdefjeenucfhrhhomhepgfhvvghrthcurfhothcuoehmvgesvghvvghrthhpohhtrdgt ohhmqeenucggtffrrghtthgvrhhnpedtvedtleekudeuuedvgffhheeivddvveekfffgle dtfedthfetieffgffgudejleenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedu gedvrdduvdeirdduieeirddvtdejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepmhgvsegvvhgvrhhtphhothdrtghomh X-ME-Proxy: Received: from [192.168.2.63] (unknown [142.126.166.207]) by mail.messagingengine.com (Postfix) with ESMTPA id 768FC240067 for ; Tue, 26 Jan 2021 16:05:30 -0500 (EST) To: httpapi@ietf.org References: From: Evert Pot Message-ID: Date: Tue, 26 Jan 2021 16:05:27 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [httpapi] Link relationship types for authentication 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, 26 Jan 2021 21:05:39 -0000 On 2021-01-26 10:04 a.m., Roberto Polli wrote: > Hi, > > > Il giorno mar 26 gen 2021 alle ore 03:52 Darrel Miller > ha scritto: >> Do you know if Evert posted this to the Link Relations Type mailing list? >> https://mailarchive.ietf.org/arch/browse/link-relations/ > Maybe the OAuth workgroup could be interested or working on something > like this, too. > Pax, > R. I've sent an email to their list a while back. There was some feedback, but nothing really substantial: https://mailarchive.ietf.org/arch/msg/oauth/SqVD1YBqq-XCUREEVu9YXjKmrto/ So, I'm not sure if there's more to be done there(?). For what it's worth, in the years since I've published the first draft, I've had more than a few people tell me they use (some of) these link relationships in their system, usually after it was found with a google search. I think oauth2 adoption would be great. One of it's failings I think is the fact that user agents can't discover anymore how to authenticate a user after getting a 401, so this is a nice step in the direction of potentially solving that. Evert From nobody Tue Jan 26 13:24:49 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 9E6883A0F06 for ; Tue, 26 Jan 2021 13:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=grahamcox-co-uk.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 33ofy9b80OL3 for ; Tue, 26 Jan 2021 13:24:43 -0800 (PST) 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 D5B533A0FED for ; Tue, 26 Jan 2021 13:24:40 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id p72so36666936iod.12 for ; Tue, 26 Jan 2021 13:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=grahamcox-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=cpmOL7YEtIfE0P3uaDyK+guB+lGyAqgCyt/CInP/fgk=; b=tNAsyS4wewhVG4fw+bzseBt8kd8vQopW5+kQFd4u+IZzg5YU+RhwkwI/xgSFoM/RI/ onnN7SavRoKRATU+lxbCVhe1jQWBSa6V++y+UYirNfs/NmTbP1Q6IpEddB5cCr1bGMj6 kptYCF0YV5qxqj3JtAcQxLNjZf4cKunqfhImY9XYVBiLE/rO88IzkD8SOc29lM5fFgKq 1eq2PrV5tbRwHf+wqfhiFMOdaDVPdOCbTRb/AGq+z6j48CaLaOMzI4zwVB+xriXIWvQl jRmBF7s8OgGdCDIvYinis7Ysvfsau87S4caLrkzwMYks0bBikZLwGlDo2JntMuMrK0VO lYiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=cpmOL7YEtIfE0P3uaDyK+guB+lGyAqgCyt/CInP/fgk=; b=VzKz10jGpGgLIL6TgvpP0+zQA4efwHMDEelxLb11ED215tRMRfd7koXhXWG8YtMY7G U3DHV84q0qK/WqXk6JCD7Kj4W+iB8ZcIlpML9NRhEniCVrt7CVNe5abZltBv5PRWzi/u ZETQdx8GNP2PFQuBg7ws+1DODXHgPm7LGqpFInvMac47ZaWbKE8aZM11UqjBeC78fuxt jmmSe3xkgryd6P7OONmlk6Umdbf3EANNT4d5mQIgqLM5WupohtoyLMwGsslTdrlQqQ1z N2pPTzEuGo3h5Ccci6qGEL/xB1NlENhHNJfl77RBOPNvxjwO5JtGdFajPxCqt8CSxbvy MVfQ== X-Gm-Message-State: AOAM532oPOfcrEv9qydaq+WdK2ivl9agcCtbdeHVLHQZo4LEqDFz1eCN t9LefHl77jPfOqOZuFZV9JtUUV2Z/FmeqfPA8ISn+aBX8l25/w== X-Google-Smtp-Source: ABdhPJz+pC4v2JpFOqJqQujagKXSS5zVOrlli+5ck8Y09cCGBgcqfVrmkJOjLEJNZjLu2ZHsRp3KNXIKw0AML4dQqbU= X-Received: by 2002:a05:6e02:1787:: with SMTP id y7mr5997970ilu.233.1611696279711; Tue, 26 Jan 2021 13:24:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Graham Cox Date: Tue, 26 Jan 2021 21:24:26 +0000 Message-ID: To: httpapi@ietf.org Content-Type: multipart/alternative; boundary="0000000000003d102905b9d448c4" Archived-At: Subject: Re: [httpapi] Link relationship types for authentication 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, 26 Jan 2021 21:24:48 -0000 --0000000000003d102905b9d448c4 Content-Type: text/plain; charset="UTF-8" Apologies if this has already been covered, but have you looked into the overlap between this and OpenID Connect? I'm far from an expert, but it seems that some - though not all - of the relations defined here correspond well with the actions that OIDC offer, though obviously they work in notably different ways. (The *authenticated-as* relation doesn't have any direct mapping in OIDC that I can think of, but they others all map on to *something*) Cheers -- Graham Cox On Tue, 26 Jan 2021 at 21:05, Evert Pot wrote: > On 2021-01-26 10:04 a.m., Roberto Polli wrote: > > Hi, > > > > > > Il giorno mar 26 gen 2021 alle ore 03:52 Darrel Miller > > ha scritto: > >> Do you know if Evert posted this to the Link Relations Type mailing > list? > >> https://mailarchive.ietf.org/arch/browse/link-relations/ > > Maybe the OAuth workgroup could be interested or working on something > > like this, too. > > Pax, > > R. > > I've sent an email to their list a while back. There was some feedback, > but nothing really substantial: > > https://mailarchive.ietf.org/arch/msg/oauth/SqVD1YBqq-XCUREEVu9YXjKmrto/ > > So, I'm not sure if there's more to be done there(?). > > For what it's worth, in the years since I've published the first draft, > I've had more than a few people tell me they use (some of) these link > relationships in their system, usually after it was found with a google > search. > > I think oauth2 adoption would be great. One of it's failings I think is > the fact that user agents can't discover anymore how to authenticate a > user after getting a 401, so this is a nice step in the direction of > potentially solving that. > > Evert > > -- > httpapi mailing list > httpapi@ietf.org > https://www.ietf.org/mailman/listinfo/httpapi > --0000000000003d102905b9d448c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies if this has already been covered, but have = you looked into the overlap between this and OpenID Connect? I'm far fr= om an expert, but it seems that some - though not all - of the relations de= fined here correspond well with the actions that OIDC offer, though obvious= ly they work in notably different ways. (The authenticated-as relati= on doesn't have any direct mapping in OIDC that I can think of, but the= y others all map on to *something*)

Cheers
--
Graham Cox

On Tue, 26 Jan 2021 at 21:05, = Evert Pot <me@evertpot.com> wr= ote:
On 2021-01-= 26 10:04 a.m., Roberto Polli wrote:
> Hi,
>
>
> Il giorno mar 26 gen 2021 alle ore 03:52 Darrel Miller
> <Darrel.Miller=3D40microsoft.com@dmarc.ietf.org> ha scritto:
>> Do you know if Evert posted this to the Link Relations Type mailin= g list?
>>=C2=A0 =C2=A0https://mailarchive.iet= f.org/arch/browse/link-relations/
> Maybe the OAuth workgroup could be interested or working on something<= br> > like this, too.
> Pax,
> R.

I've sent an email to their list a while back. There was some feedback,=
but nothing really substantial:

https://mailarchive.ietf.org= /arch/msg/oauth/SqVD1YBqq-XCUREEVu9YXjKmrto/

So, I'm not sure if there's more to be done there(?).

For what it's worth, in the years since I've published the first dr= aft,
I've had more than a few people tell me they use (some of) these link <= br> relationships in their system, usually after it was found with a google search.

I think oauth2 adoption would be great. One of it's failings I think is=
the fact that user agents can't discover anymore how to authenticate a =
user after getting a 401, so this is a nice step in the direction of
potentially solving that.

Evert

--
httpapi mailing list
httpapi@ietf.org<= br> https://www.ietf.org/mailman/listinfo/httpapi
--0000000000003d102905b9d448c4-- From nobody Tue Jan 26 14:12: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 E35113A017E for ; Tue, 26 Jan 2021 14:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-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=evertpot.com header.b=axamcusc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ecWo4/9a 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 xRTFAWfJa87o for ; Tue, 26 Jan 2021 14:12:03 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAEB23A00D2 for ; Tue, 26 Jan 2021 14:12:03 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id AFD439F0 for ; Tue, 26 Jan 2021 17:12:02 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 26 Jan 2021 17:12:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=mesmtp; bh=oDC1AzZ3wjTvYzjI+mdrSvI9 2QIGogVA3QhYDjCVCgs=; b=axamcuscruckul+2jCA2OEbvKFDXjZaQzdXobreL UlkStBtfrW3ZKpKZ5Fga3hDvH7NcRQudpKb0BZ3aWhKCFhZb58mnORQZ+fmSzwGI 3lxnEgjKYS8LqnL6CTFzsDH6tTDBuiNDHHpvM51Q1dRDxcw+tk/XcEhWiIvRiip6 c+w= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=oDC1Az Z3wjTvYzjI+mdrSvI92QIGogVA3QhYDjCVCgs=; b=ecWo4/9ax2OdwaepbTa5/n NxakQi3TL4kwdCatNv+T/AfPq68qDv/vxwqilE1UX4HTkz6Cf+4l5WRIXlnDRGDJ FKnILnfV0nOkFGoPRvh3VCcJzQevLfDsRyIVkW+GhgPypLBGIb2gAQqlZLcQsQHj J3saBpKmJfRniA4qYjNEBvIFkvKPdOJmv5V3K2sXWinRsBommsahgPumIbxbe/aZ vLVus7JVRhUgQ5dAQDiso8f75LwifI+9zI66K7aGDJX/Fved/Teu4sQSewsWgyT1 PG50wnaDOtNbOES8JdPX95cjuC7Uc+iF/LXGcBr2I9v64d4Us7ZJQqqA1EHi6EdA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeigdeliecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtsegrtderre dtfeejnecuhfhrohhmpefgvhgvrhhtucfrohhtuceomhgvsegvvhgvrhhtphhothdrtgho mheqnecuggftrfgrthhtvghrnheptefhkeefledvjeduueegueeggfetieehiedvvddttd ehledvtdegudfhleehiedtnecukfhppedugedvrdduvdeirdduieeirddvtdejnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgvsegvvhgvrh htphhothdrtghomh X-ME-Proxy: Received: from [192.168.2.63] (unknown [142.126.166.207]) by mail.messagingengine.com (Postfix) with ESMTPA id B8DAE240064 for ; Tue, 26 Jan 2021 17:12:00 -0500 (EST) To: httpapi@ietf.org References: From: Evert Pot Message-ID: <4e8f45e7-298f-ac3d-4dd6-66dcadb1479a@evertpot.com> Date: Tue, 26 Jan 2021 17:11:57 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------00BA34B850CD300D08F71512" Content-Language: en-US Archived-At: Subject: Re: [httpapi] Link relationship types for authentication 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, 26 Jan 2021 22:12:05 -0000 This is a multi-part message in MIME format. --------------00BA34B850CD300D08F71512 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2021-01-26 4:24 p.m., Graham Cox wrote: > Apologies if this has already been covered, but have you looked into > the overlap between this and OpenID Connect? I'm far from an expert, > but it seems that some - though not all - of the relations defined > here correspond well with the actions that OIDC offer, though > obviously they work in notably different ways. (The /authenticated-as/ > relation doesn't have any direct mapping in OIDC that I can think of, > but they others all map on to *something*) I'm somewhat aware of the specifications and general plumbing. The link relations I'm hoping to register are extremely general though, and don't impose any sort of protocols or media types. For example, a browser extension might find a a link with rel="logout", and render a logout button in a toolbar. It would be good to know if this is fundamentally incompatible with protocols like OpenID Connect, but I'm also not the person to say anything about this with confidence. Evert --------------00BA34B850CD300D08F71512 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 2021-01-26 4:24 p.m., Graham Cox wrote:
Apologies if this has already been covered, but have you looked into the overlap between this and OpenID Connect? I'm far from an expert, but it seems that some - though not all - of the relations defined here correspond well with the actions that OIDC offer, though obviously they work in notably different ways. (The authenticated-as relation doesn't have any direct mapping in OIDC that I can think of, but they others all map on to *something*)
I'm somewhat aware of the specifications and general plumbing. The link relations I'm hoping to register are extremely general though, and don't impose any sort of protocols or media types.

For example, a browser extension might find a a link with rel="logout", and render a logout button in a toolbar. It would be good to know if this is fundamentally incompatible with protocols like OpenID Connect, but I'm also not the person to say anything about this with confidence.

Evert
--------------00BA34B850CD300D08F71512-- From nobody Wed Jan 27 00:03: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 48EF03A109A for ; Wed, 27 Jan 2021 00:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 MGaBQoXj5DEY for ; Wed, 27 Jan 2021 00:03:24 -0800 (PST) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (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 8788A3A084D for ; Wed, 27 Jan 2021 00:03:24 -0800 (PST) Received: from 77.128.78.83.dynamic.wline.res.cust.swisscom.ch ([83.78.128.77]:55079 helo=dretpro.home) by postoffice.gristmillmedia.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1l4fnO-00058J-KM; Wed, 27 Jan 2021 03:03:22 -0500 To: Evert Pot , httpapi@ietf.org References: <4e8f45e7-298f-ac3d-4dd6-66dcadb1479a@evertpot.com> From: Erik Wilde Message-ID: Date: Wed, 27 Jan 2021 09:03:21 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <4e8f45e7-298f-ac3d-4dd6-66dcadb1479a@evertpot.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [httpapi] Link relationship types for authentication 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, 27 Jan 2021 08:03:26 -0000 hello. On 2021-01-26 23:11, Evert Pot wrote: > On 2021-01-26 4:24 p.m., Graham Cox wrote: >> Apologies if this has already been covered, but have you looked into >> the overlap between this and OpenID Connect? I'm far from an expert, >> but it seems that some - though not all - of the relations defined >> here correspond well with the actions that OIDC offer, though >> obviously they work in notably different ways. (The /authenticated-as/ >> relation doesn't have any direct mapping in OIDC that I can think of, >> but they others all map on to *something*) > I'm somewhat aware of the specifications and general plumbing. The link > relations I'm hoping to register are extremely general though, and don't > impose any sort of protocols or media types. ideally, that's the case for *all* registered link relation types. it's not what happens in practice, but good design would imply that link relation types are agnostic of implementation details, and these details then are established by using link relation types in a specific context, such as a protocol that has certain media types for passing messages around. > For example, a browser extension might find a a link with rel="logout", > and render a logout button in a toolbar. It would be good to know if > this is fundamentally incompatible with protocols like OpenID Connect, > but I'm also not the person to say anything about this with confidence. if OIDC doesn't have the model of generally applicable link relation types, then another possible way forward would be to change that and make the OIDC link relation types reusable (and register them), but that of course depends on the details of OIDC and how interested that community is to create reusable building blocks as part of their spec. cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Wed Jan 27 07:05: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 E1E5C3A08ED for ; Wed, 27 Jan 2021 07:05:44 -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 d-F8liKqXGyc for ; Wed, 27 Jan 2021 07:05:43 -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 14BF93A08D6 for ; Wed, 27 Jan 2021 07:05:42 -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 10RExIh2022616 for ; Wed, 27 Jan 2021 15:05:41 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=t73OYMYSlHClrv7/yn1PEW1PiHpPbF5adphIEs7SfkE=; b=nzICteuNsHag5gyAb7OQyFpm71pTJqlAyFyfA7ipfqoxudAVR2ZR7wvRF5ZHm1yHaEpl RM+TK9RW7vfB/y8NolMN6qxCYdmaHf+T2czJRibsGHLkXI1K/5lWk4javi7yWpZlfcHz JDVBJ3S19MvOpByVywRVHfKv/gGgg/+TZ6/uKyNEWZNQTTwQz6ppzK2Lh+T4QxAbvjRU g/SeKcMuYWFrr6hH+X7YtdYg/zVUBTCc3fuJ12/NnnlLrq1oLPknKSpiHcekFXU7a19R e633bwup3rTI+0NtHPgT297rumzxikgrA/aLxzITEq+BYdah2ZLdG0GIdd+gJlulYfmx TA== 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 3689rt39ch-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 27 Jan 2021 15:05:41 +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 10RF4mb2006265 for ; Wed, 27 Jan 2021 10:05:41 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint3.akamai.com with ESMTP id 36b7ha99ud-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 27 Jan 2021 10:05:41 -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; Wed, 27 Jan 2021 09:05:40 -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; Wed, 27 Jan 2021 09:05:40 -0600 From: "Salz, Rich" To: "httpapi@ietf.org" Thread-Topic: Updating RFC7807 (Problem Details for HTTP APIs) Thread-Index: AQHW9L3fbm8/xXRZwEKoVilcpeXXeQ== Date: Wed, 27 Jan 2021 15:05:39 +0000 Message-ID: <1BB83A7C-842F-475D-9426-BB767D8AE93E@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.118.139] Content-Type: multipart/alternative; boundary="_000_1BB83A7C842F475D9426BB767D8AE93Eakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-27_05:2021-01-27, 2021-01-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=741 bulkscore=0 mlxscore=0 adultscore=0 phishscore=0 spamscore=0 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101270083 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-27_05:2021-01-27, 2021-01-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 mlxlogscore=663 phishscore=0 spamscore=0 bulkscore=0 suspectscore=0 mlxscore=0 malwarescore=0 clxscore=1015 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101270083 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] Updating RFC7807 (Problem Details for HTTP APIs) 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, 27 Jan 2021 15:05:45 -0000 --_000_1BB83A7C842F475D9426BB767D8AE93Eakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmFycnkgKG91ciBBRCkgc2FpZCB0aGF0IHVwZGF0aW5nIHRoaXMgaXMgd2l0aGluIG91ciBjaGFy dGVyLg0KDQpUaGUgcGxhbiBpcyBmb3IgU2FuamF5IERhbGFsIHRvIHN0YXJ0IGFuIHVwZGF0ZSBk b2N1bWVudCAoY2FsbGVkIDc4MDdiaXMgaW4gSUVURiB0ZXJtcykgYW5kIHdvcmsgd2l0aCBNYXJr IGFuZCBFcmlrLiAgRGlzY3Vzc2lvbiBjYW4gdGFrZSBwbGFuIG9uIHRoaXMgbWFpbGluZyBsaXN0 LiBPbmNlIHRoZXJl4oCZcyBhIGRyYWZ0IGluIHBsYWNlLCB3ZeKAmWxsIGFzayB0aGUgd29ya2lu ZyBncm91cCB0byBhZG9wdCBpdC4NCg0KU2FuamF5LCB5b3Ugc2hvdWxkIGV4cGVjdCB0byBiZSBv biB0aGUgYWdlbmRhIGZvciBvdXIgbmV4dCBtZWV0aW5nLiA6KQ0KDQo= --_000_1BB83A7C842F475D9426BB767D8AE93Eakamaicom_ 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 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0 eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkJhcnJ5 IChvdXIgQUQpIHNhaWQgdGhhdCB1cGRhdGluZyB0aGlzIGlzIHdpdGhpbiBvdXIgY2hhcnRlci48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBwbGFuIGlzIGZv ciBTYW5qYXkgRGFsYWwgdG8gc3RhcnQgYW4gdXBkYXRlIGRvY3VtZW50IChjYWxsZWQgNzgwN2Jp cyBpbiBJRVRGIHRlcm1zKSBhbmQgd29yayB3aXRoIE1hcmsgYW5kIEVyaWsuJm5ic3A7IERpc2N1 c3Npb24gY2FuIHRha2UgcGxhbiBvbiB0aGlzIG1haWxpbmcgbGlzdC4gT25jZSB0aGVyZeKAmXMg YSBkcmFmdCBpbiBwbGFjZSwgd2XigJlsbCBhc2sNCiB0aGUgd29ya2luZyBncm91cCB0byBhZG9w dCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNhbmpheSwg eW91IHNob3VsZCBleHBlY3QgdG8gYmUgb24gdGhlIGFnZW5kYSBmb3Igb3VyIG5leHQgbWVldGlu Zy4gOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1BB83A7C842F475D9426BB767D8AE93Eakamaicom_-- From nobody Wed Jan 27 10:49: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 924543A0D04 for ; Wed, 27 Jan 2021 10:49:04 -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 xUjsNMsOdEfC for ; Wed, 27 Jan 2021 10:49:02 -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 DF5643A0CFE for ; Wed, 27 Jan 2021 10:49:02 -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 10RIYCnK013810 for ; Wed, 27 Jan 2021 18:49:02 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=wX+SaLRv1CT2R9KaHhWXYenoYU/5AdNtZP/TVdDWTg0=; b=LAEQTskLvGR78aOg/y6jycRjrPz7EfBUH+D7c2QKjzYbUlLUiivYAjocTSBRohEqxz4m y5298IOJYf3q08V5kInNJNoFotQlOikLc/twwcyL4qbuARhF+fqcMwy6lBesDLyyhkxH mY+udgm/qWErMt4s1hg2tVSt4L8Ek9HKqMCFZUTQTSXyHgS8GZMPDnTmV2+yMCB1/ZHl 0cPDX+NlU4iL7aA4tSr9i5fuRiEPXBJI1cQcYeMWJb0jgsUVyPLefynQEPq6N0E6/V2j /bzqf5ElAByyS+tj2QxrPY2jsi4LjThs2awGTvUuP9qrW4kv5bTNIXYx8/S9Tl0YtSd3 GQ== Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 368mkura0p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 27 Jan 2021 18:49:02 +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 10RIZj85010983 for ; Wed, 27 Jan 2021 13:49:01 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint8.akamai.com with ESMTP id 36b7gb34kb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 27 Jan 2021 13:49:01 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.165.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 27 Jan 2021 12:49: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; Wed, 27 Jan 2021 12:49:00 -0600 From: "Salz, Rich" To: "httpapi@ietf.org" Thread-Topic: Copied over some issues Thread-Index: AQHW9N0Sakt9CDcHcU22MxZChZHFew== Date: Wed, 27 Jan 2021 18:48:59 +0000 Message-ID: <18DB782B-8FC5-4415-A13C-F7F7ACCA5003@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.118.139] Content-Type: multipart/alternative; boundary="_000_18DB782B8FC54415A13CF7F7ACCA5003akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-27_06:2021-01-27, 2021-01-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=664 phishscore=0 malwarescore=0 adultscore=0 bulkscore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101270092 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-27_06:2021-01-27, 2021-01-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=557 bulkscore=0 spamscore=0 lowpriorityscore=0 mlxscore=0 malwarescore=0 suspectscore=0 adultscore=0 clxscore=1015 priorityscore=1501 impostorscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101270092 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: [httpapi] Copied over some issues 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, 27 Jan 2021 18:49:05 -0000 --_000_18DB782B8FC54415A13CF7F7ACCA5003akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgd2VyZSBqdXN0IGZvdXIsIHNvIEkgY29waWVkIHRoZSB0ZXh0IG92ZXIgZnJvbSBFcmlr 4oCZcyByZXBvLCBodHRwczovL2dpdGh1Yi5jb20vZHJldC9JLUQvaXNzdWVzIHRvIHRoZSBXRyBy ZXBvIGh0dHBzOi8vZ2l0aHViLmNvbS9pZXRmLXdnLWh0dHBhcGkvbGlua3NldC9pc3N1ZXMNCg0K VGhhbmtzLg0KDQo= --_000_18DB782B8FC54415A13CF7F7ACCA5003akamaicom_ 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 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFw OmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGVyZSB3ZXJlIGp1c3QgZm91 ciwgc28gSSBjb3BpZWQgdGhlIHRleHQgb3ZlciBmcm9tIEVyaWvigJlzIHJlcG8sDQo8YSBocmVm PSJodHRwczovL2dpdGh1Yi5jb20vZHJldC9JLUQvaXNzdWVzIj5odHRwczovL2dpdGh1Yi5jb20v ZHJldC9JLUQvaXNzdWVzPC9hPiB0byB0aGUgV0cgcmVwbw0KPGEgaHJlZj0iaHR0cHM6Ly9naXRo dWIuY29tL2lldGYtd2ctaHR0cGFwaS9saW5rc2V0L2lzc3VlcyI+aHR0cHM6Ly9naXRodWIuY29t L2lldGYtd2ctaHR0cGFwaS9saW5rc2V0L2lzc3VlczwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_18DB782B8FC54415A13CF7F7ACCA5003akamaicom_-- From nobody Wed Jan 27 11:19: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 9F5913A0DF4 for ; Wed, 27 Jan 2021 11:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 a-ESeAlgTnAJ for ; Wed, 27 Jan 2021 11:19:09 -0800 (PST) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (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 0DDEF3A0DEB for ; Wed, 27 Jan 2021 11:19:08 -0800 (PST) Received: from 77.128.78.83.dynamic.wline.res.cust.swisscom.ch ([83.78.128.77]:63159 helo=dretpro.home) by postoffice.gristmillmedia.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1l4qLJ-0008Bz-TM; Wed, 27 Jan 2021 14:19:06 -0500 To: "Salz, Rich" , "httpapi@ietf.org" References: <18DB782B-8FC5-4415-A13C-F7F7ACCA5003@akamai.com> From: Erik Wilde Message-ID: <5559efe2-82c8-e898-7911-f218a1094830@dret.net> Date: Wed, 27 Jan 2021 20:19:04 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <18DB782B-8FC5-4415-A13C-F7F7ACCA5003@akamai.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [httpapi] Copied over some issues 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, 27 Jan 2021 19:19:11 -0000 On 2021-01-27 19:48, Salz, Rich wrote: > There were just four, so I copied the text over from Erik’s repo, > https://github.com/dret/I-D/issues > to the WG repo https://github.com/ietf-wg-httpapi/linkset/issues > thanks rich, that's very helpful. i closed all the issues in the old repo so that the only remaining open ones are in the new WG repo. thanks and cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Wed Jan 27 22:23:37 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 53B063A12C2 for ; Wed, 27 Jan 2021 22:23:36 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=L3vMLUu8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KPk2wHS4 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 ThHb9Z4qTWEq for ; Wed, 27 Jan 2021 22:23:35 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B5A3A12C3 for ; Wed, 27 Jan 2021 22:23:34 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 113E2A1E; Thu, 28 Jan 2021 01:23:32 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 28 Jan 2021 01:23:32 -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=4 5H16ckAcIqzVC2GiGe3hS8scRl4dLu8y6UAyh0FF/c=; b=L3vMLUu8FpbWs4Vef mjpuB2hwHRkdj4SLdah1rTzAn5UtjqgRYSVODFtcSU3XtfH4AwSYxra12OtFNNy0 EZ5r9AMHNoynfUGRsG2mctxH4Cqs3zNdm/guPoiuGSkSLAM69OivOHJWkuDs8Lq9 S+eFo31mkuCueUnc25pzU7rDfkf70kKn+4239y/2jHb9oHVQIlfpqTmElZFlLRgg wRED8jcnzdS6R/X+GweG+Zo6dRMvOwQ8UOCj9zhO6D64qEYM+s+RYlnVhHcQSpAj X/ftHwIUyUxOBjSbCJK9TolNBoNJmvke3qAI/T694rgn62pvawnbeTVlnBPicjgY JC98Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=45H16ckAcIqzVC2GiGe3hS8scRl4dLu8y6UAyh0FF /c=; b=KPk2wHS4FZmadiMZOqrl8NzDd2yqVvOiXtWj+Q/K/9H+qjjBcgAPPKs2S 3Va1zEzu2cYODgQOXOeZRSNQvb1RabiArly/eOxOEHMiyf83uxEAmlEiEOfjkGm/ 1L1A2QaEBBV3Ib/JFJurQihfPeJezP8YKCbejFKwDuj9vQaethWunj0UVwlzc/g6 peDjMgK3U/05GKP2z2ehpIJ1TEmpHWM7iZn31Hn1LVkrHjbz0RXLMKwi1DaEQzG1 kck69JkLMJHfYgjW6G0FRWch58Vo2FZF1QaGAKXMRG1ZzAmye4z3mUFKEAtx5jWX 73P1faJPwovJ+5STKI9QzJHlKJOzQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdelgdelvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekuddvleejgeethfevkefhtdevkeelve ekfeegleduiefhudegvdeiuefftddthfenucffohhmrghinhepihgvthhfrdhorhhgpdhm nhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhedunecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgv th 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 ACEF724005A; Thu, 28 Jan 2021 01:23:27 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Mark Nottingham In-Reply-To: Date: Thu, 28 Jan 2021 17:23:23 +1100 Cc: "gabriel@sullice.com" , "httpapi@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <529C556A-1270-4B10-80F8-3D51FFEB8356@mnot.net> References: To: Darrel Miller X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [httpapi] Link relationship types for authentication 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, 28 Jan 2021 06:23:36 -0000 Just to clarify -- that list can give advice about the details of = registration and whether or not the use 'fits' link relations, but the = discussion of the proposal should happen in the relevant community -- = i.e., here. Cheers, > On 26 Jan 2021, at 1:52 pm, Darrel Miller = wrote: >=20 > Hey Gabriel, >=20 >=20 > From: httpapi on behalf of Gabriel Sullice = > Has this group considered working on this draft: Link relationship = types for authentication >=20 >=20 > I missed this when Evert originally posted it. =46rom a quick review = they seem like they would be useful additions to the Link Relation = Types. Do you know if Evert posted this to the Link Relations Type = mailing list? https://mailarchive.ietf.org/arch/browse/link-relations/ >=20 > They would seem like a good place to get feedback. >=20 > Darrel > --=20 > httpapi mailing list > httpapi@ietf.org > https://www.ietf.org/mailman/listinfo/httpapi -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jan 27 22:39:20 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 106D63A1363 for ; Wed, 27 Jan 2021 22:39:19 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=CkpH1MPI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DD0Yc/B0 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 x7PSiSOsXjq4 for ; Wed, 27 Jan 2021 22:39:16 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB9763A1395 for ; Wed, 27 Jan 2021 22:39:05 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 293D69C4; Thu, 28 Jan 2021 01:39:05 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 28 Jan 2021 01:39:05 -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=H t9Zj9yAUO9O41YHD8v+Hppy/4pjU72AfWNDA6DLAKw=; b=CkpH1MPIBu2xVvq4E zPOeGLUcoi9nrWgnWK7Wr0nOXLClwLzq41h0M+LXXKnVdzF6pn00km0InZk4bbHJ u5FqHCwkoMWzUgwcmndf4LaIlW9Gs1HK4kOTgGXmtXcLlOkeWup6o5LqojS3Qj/3 XqxH47j1emi4i6MilbmWAUIUg+SFWKsuG/6LO+qosmPOYoCcq2vDus5AyiXrqfiO iBJQ4hhF1gIsvu+rwyzXx+VEtR9AklNJgHcmVW3UVSOt+EogxJaC0K+IwjQTCbih C98d0EMEeN802ezffJB2QWHbzNUak7oHUp9uN48yS4mNBceG6honu8ao2G0ptTzK 7L/uQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=Ht9Zj9yAUO9O41YHD8v+Hppy/4pjU72AfWNDA6DLA Kw=; b=DD0Yc/B0n+jPe/Mc9TKcfr7S0iyLFxJ+rhLSdgr5seWTHttoW7u4j1YdG Sts/6dh62GJsCz8Z/mxkWFmFi0rSJV2botONJ11rhgxGqIRs/eOCW0Roa/JMtFXv 4gKy6+hQhxlwKKj5++MTEIGyUEf5JfEzfR4WJVm/Dm0i2ZcjRo8Oe0X45MVRYCw/ vAcx7y/U9xopyx76rDS3qMIU5ZaWRJn2IoWn2POk88QXitdPgWC7eWZvYqEIoWoo GaMvUDpa3qJ9CY1ls0ocDXMz+9cQoV5NEg6clYtrmw+OXWjRcp5Ip2ESBi5wXy8c xjvfAeZ65NtH6E9f7P/9JFMvV7huw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdelgdelhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtjeenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeefgedvgfejgedvteeuudekveefhfehle eiveejjeekhfffheekjeeikeejtdehjeenucffohhmrghinhepihgvthhfrdhorhhgpdhm nhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhedunecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgv th 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 1D761240057; Thu, 28 Jan 2021 01:39:01 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Mark Nottingham In-Reply-To: <88ED49DB-E081-4C97-9FB9-080A1C585435@akamai.com> Date: Thu, 28 Jan 2021 17:38:58 +1100 Cc: "httpapi@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <88ED49DB-E081-4C97-9FB9-080A1C585435@akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [httpapi] Discussion of adopting Content-Warning header 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, 28 Jan 2021 06:39:19 -0000 Hi, I've re-read this draft.=20 I don't understand what the use case is -- specifically, what benefit = exposing this information in a header field brings. The JSON format described can already be used, and is identified with a = distinct media type; that should be enough to indicate to a recipient = that the content of the message is a problem. Are there cases where it's expected that generic HTTP software (e.g., an = intermediary) separate from the application in question is going to need = to know this information? That's the usual reason for standardising a = header field (the other being that the format doesn't accommodate that = information in question, but that doesn't seem to be the case here). Cheers, > On 11 Dec 2020, at 3:07 am, Salz, Rich = wrote: >=20 > At our meeting at IETF 109, we discussed > = https://tools.ietf.org/html/draft-cedik-http-warning-02 > =20 > Let=E2=80=99s discuss this (we didn=E2=80=99t have enough time at the = virtual). Feel free to use this thread or start new ones. > --=20 > httpapi mailing list > httpapi@ietf.org > https://www.ietf.org/mailman/listinfo/httpapi -- Mark Nottingham https://www.mnot.net/ From nobody Thu Jan 28 00:22:08 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 0390C3A145E for ; Thu, 28 Jan 2021 00:22:00 -0800 (PST) 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=googlemail.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 u180LfoBXcdI for ; Thu, 28 Jan 2021 00:21:57 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 744AE3A1411 for ; Thu, 28 Jan 2021 00:21:55 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id i9so3853108wmq.1 for ; Thu, 28 Jan 2021 00:21:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=boaeTK0jlz5lgViGB4/K1PXQ/Bm4NatSevy2KaVsekw=; b=ghYuv4zN6t4ZjFhaLV80xQmG1iVFHIIGzF8odZcEUdiNms4BjnvPhfqSWVpMHiFcc+ x2WY0oHYjuFb8hI3o4lEvB68OJSou7+2lCJRBKgCi25aFqtQB2AXpFsfgIuqszEHt4wq K9gynQfkLzsEjZ9R1oRplhNeclY5rdgabUkijHxVXmSvW15sRGHZRpHa9NHSx9NSlxyY XOf5AG4uZat5QM9EJ1pQbw9BRm3CfC+fiJi5XIajRxwJAG9u8iOjexmDzw8eiygzQcKi TlCnhuyY/TGkTdjdio8MOpMqBvTqt2oLUvEFr6d6tTttHgxAu996bizDCZRCWD5IsXGG 9HZg== 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=boaeTK0jlz5lgViGB4/K1PXQ/Bm4NatSevy2KaVsekw=; b=Je0cGPNl8yNe8L1iSOWSWgLxLJcQfsDhJQVLxqKZNyZ7PkdA/GDuyGHLLOFy5lknFN SohyFQyca+i6WaM8q9WfYCYbjBvw+O/9E3v67j9MMLsae3Kd4XpH0bpqtwN3cb7numty MgcnUOCxUuEdvfWz6UPQK4LkgmVqnyAKp3jW+fR+F+ksOwmb8ohRP+cfful1bB2i+mFI HpSAManSWd0S4VdOyJzjJmpN1tb7nOcXpSxCklF7dXLVt1BS2DnJK01TIMziCy1//lZw QAjbqLS+BLtPEyzre5jo6iC5DasrDdAhxsFMAsQbLrKmssg8l1HZPWknKzAqbgjymNyO 6/tg== X-Gm-Message-State: AOAM5318gKjAoCBzK1tAmASgFcS2bjYgDOK99kwf5fKZoz/ZpqzZzKdC 62vdX+HAIZ8cIeo7CrcfESCOFaKnnVhZz7voLrtQVeELBDKLaw== X-Google-Smtp-Source: ABdhPJzPRS2HfH7KvZQ1QK56jHCMBj2edgkMnnRm+MApndXQmBavxZp265c3BelcefkXfA7ceWpPYnJFny0WSxsmKnE= X-Received: by 2002:a1c:4303:: with SMTP id q3mr7568724wma.3.1611822113465; Thu, 28 Jan 2021 00:21:53 -0800 (PST) MIME-Version: 1.0 References: <88ED49DB-E081-4C97-9FB9-080A1C585435@akamai.com> In-Reply-To: From: =?UTF-8?B?QW5kcsOpIENlZGlr?= Date: Thu, 28 Jan 2021 09:21:42 +0100 Message-ID: To: Mark Nottingham Cc: "Salz, Rich" , "httpapi@ietf.org" Content-Type: multipart/alternative; boundary="00000000000083a81205b9f1947c" Archived-At: Subject: Re: [httpapi] Discussion of adopting Content-Warning header 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, 28 Jan 2021 08:22:06 -0000 --00000000000083a81205b9f1947c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for the reply Mark. Let me take a step back and explain where I'm coming from. Maybe this can clear up things. For those who don't know shipcloud.io we're a so-called shipping service provider. So just like e.g. Stripe who's connecting you to payment providers, we're aggregating the (web) services of shipping providers (carriers) like UPS, FedEx, etc. into a single API and are making them available via a SaaS business model. Since every carrier is handling things "a little bit" differently it's not always so easy to communicate certain things back to our (API) users. Especially when it comes to what I would call "outcomes of internal automation/knowledge". One of those examples would be the automatic correction of addresses. To create a shipping label at a carrier, we of course have to send them the recipients' and senders' addresses. Based on their services' knowledge of address data, they may change an address to something that they know is (more) correct. This is done on their side and when the return gets back to us, we are also getting the information that they've changed something while processing our request. So now we basically receive a set of data that doesn't match the original request. To be able to convey to (API) users that something has changed and they should have a look at it before just accepting the fact, is my main goal because they will be charged for the shipping label that has been created nonetheless. What I would like to achieve is something that Erik already was able to do by introducing application/problem+json with RFC 7808, creating a standard people can use without having to reinvent the wheel. This would make API adoption easier because consumers of an API wouldn't have to figure out how warnings are transported for a specific API. The challenge with warnings from my point of view is the fact that the original request was successful - in our case, a shipping label has been created - but there were "side effects" that may need to be addressed. If it would only boil down to this I'd say "let's create a content-type application/warnings+json" or something similar. But I would make the assumption that there are use cases where warnings and errors can both happen with one request. Maybe because something happened at an intermediary and the destination server which is processing the request is throwing e.g. a server error. This is one of the reasons why we opted to make it a header field. The other being that there might be other use cases where an "embedded-warning" doesn't make sense. This is why the concept of a registry was introduced to create other warning types. I'm sure there are other use cases similar or exactly like ours since the feedback we received so far has been positive towards creating a standard for warning information. Just let me know if I was able to clear things up a bit, or if you need more information. On Thu, Jan 28, 2021 at 7:39 AM Mark Nottingham wrote: > Hi, > > I've re-read this draft. > > I don't understand what the use case is -- specifically, what benefit > exposing this information in a header field brings. > > The JSON format described can already be used, and is identified with a > distinct media type; that should be enough to indicate to a recipient tha= t > the content of the message is a problem. > > Are there cases where it's expected that generic HTTP software (e.g., an > intermediary) separate from the application in question is going to need = to > know this information? That's the usual reason for standardising a header > field (the other being that the format doesn't accommodate that informati= on > in question, but that doesn't seem to be the case here). > > Cheers, > > > > On 11 Dec 2020, at 3:07 am, Salz, Rich 40akamai.com@dmarc.ietf.org> wrote: > > > > At our meeting at IETF 109, we discussed > > > https://tools.ietf.org/html/draft-cedik-http-warning-02 > > > > Let=E2=80=99s discuss this (we didn=E2=80=99t have enough time at the v= irtual). Feel > free to use this thread or start new ones. > > -- > > httpapi mailing list > > httpapi@ietf.org > > https://www.ietf.org/mailman/listinfo/httpapi > > -- > Mark Nottingham https://www.mnot.net/ > > -- > httpapi mailing list > httpapi@ietf.org > https://www.ietf.org/mailman/listinfo/httpapi > --00000000000083a81205b9f1947c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the reply Mark.
Let me take a step back = and explain where I'm coming from. Maybe this can clear up things.

For those who don't know shipcloud.io we're a so-called shipping service provider. So= just like e.g. Stripe who's connecting you to payment providers, we= 9;re aggregating the (web) services of shipping providers (carriers) like U= PS, FedEx, etc. into a single API and are making them available via a SaaS = business model.

Since every carrier is handling th= ings "a little bit" differently it's not always so easy to co= mmunicate certain things back to our (API) users. Especially when it comes = to what I would call "outcomes of internal automation/knowledge".= One of those examples would be the automatic correction of addresses. To c= reate a shipping label at a carrier, we of course have to send them the rec= ipients' and senders' addresses. Based on their services' knowl= edge of address data, they may change an address to something that they kno= w is (more) correct. This is done on their side and when the return gets ba= ck to us, we are also getting the information that they've changed some= thing while processing our request. So now we basically receive a set of da= ta that doesn't match the original request.

To= be able to convey to (API) users that something has changed and they shoul= d have a look at it before just accepting the fact,=C2=A0 is my main goal b= ecause they will be charged for the shipping label that has been created no= netheless.

What I would like to achieve is somethi= ng that Erik already was able to do by introducing application/problem+json= with RFC 7808, creating a standard people can use without having to reinve= nt the wheel. This would make API adoption easier because consumers of an A= PI wouldn't have to figure out how warnings are transported for a speci= fic API.=C2=A0

The challenge with warnings from my= point of view is the fact that the original request was successful - in ou= r case, a shipping label has been created - but there were "side effec= ts" that may need to be addressed. If it would only boil down to this = I'd say "let's create a content-type=C2=A0application/warnings= +json" or something similar. But I would make the assumption that ther= e are use cases where warnings and errors can both happen with one request.= Maybe because something happened at an intermediary and the destination se= rver which is processing the request is throwing e.g. a server error. This = is one of the reasons why we opted to make it a header field. The other bei= ng that there might be other use cases where an "embedded-warning"= ; doesn't make sense. This is=C2=A0why the concept of a registry was in= troduced to create other warning types.

I'm su= re there are other use cases similar or exactly like ours since the feedbac= k we received so far has been positive towards creating a standard for warn= ing information.

Just let me know if I was able t= o clear things up a bit, or if you need more information.

On Thu, Jan = 28, 2021 at 7:39 AM Mark Nottingham <mn= ot@mnot.net> wrote:
Hi,

I've re-read this draft.

I don't understand what the use case is -- specifically, what benefit e= xposing this information in a header field brings.

The JSON format described can already be used, and is identified with a dis= tinct media type; that should be enough to indicate to a recipient that the= content of the message is a problem.

Are there cases where it's expected that generic HTTP software (e.g., a= n intermediary) separate from the application in question is going to need = to know this information? That's the usual reason for standardising a h= eader field (the other being that the format doesn't accommodate that i= nformation in question, but that doesn't seem to be the case here).

Cheers,


> On 11 Dec 2020, at 3:07 am, Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org> wrote:
>
> At our meeting at IETF 109, we discussed
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-cedik-http-warning-02
>=C2=A0
> Let=E2=80=99s discuss this (we didn=E2=80=99t have enough time at the = virtual). Feel free to use this thread or start new ones.
> --
> httpapi mailing list
> httpapi@ietf.org=
> https://www.ietf.org/mailman/listinfo/httpapi<= br>
--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

--
httpapi mailing list
httpapi@ietf.org<= br> https://www.ietf.org/mailman/listinfo/httpapi
--00000000000083a81205b9f1947c-- From nobody Thu Jan 28 00:29: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 EA6A63A13E8 for ; Thu, 28 Jan 2021 00:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_H2=-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=mnot.net header.b=KZd9pqxV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HUYEbbi7 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 7nHlO96OZeDX for ; Thu, 28 Jan 2021 00:29:01 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C95A3A13E3 for ; Thu, 28 Jan 2021 00:29:01 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 25826B7F; Thu, 28 Jan 2021 03:29:00 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 28 Jan 2021 03:29:00 -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=K qs20OhCZ5InPxAWqjf8ELF8yq69jiixI8lQQ9Fq+4o=; b=KZd9pqxVyImXlhbp9 AOddm6yOKvm4feFH3DMA7j4NElsFQrU9NxEXUFvXzFS7UPsBXHUvR7cF5ZLutH20 DZA9ZKcCArGPN9ydX6aOjOOSMkSTMh3eFni0aXa0G68tIdjyFRL9agZ6PwZPF0qo VFX1adK4tRdV2W2Tt48zXXWZrT11X1m1hhlR7I8p/vS+nl7n2wPAirviJkHIR74w 4YaAZix3ulPKMxzU8JY9Vc2FCCKqzEK5wRR9g8zs/VrnsumxRziblRfuPOSM2ZQt Dkj6anHeGqtc7TlRfjN+05n/RrhHjzE30HhWl7R1aWBqliBNvS5/ojWPt7EMktAH YnsZg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=Kqs20OhCZ5InPxAWqjf8ELF8yq69jiixI8lQQ9Fq+ 4o=; b=HUYEbbi7llJ+Ww437DFhG6B++Dsu6+LpeJDxIkhYTGW9oN3b8SBa9VO2w iVlOgc5h2Pm+uP6QWY0CyX0fhRykzx/qoBQvC+W4UanZwx62/Iix9SMjnjlJ7X/H dW9Zz4KgqFt/OuuBlxWzk6uLLzlXLgvX9KgW/SOOLGdGhlX+ImZ08wtgPCK/EOjX RzXvvHwOQUQdMF6Pl3AcJnE2sbwu9aee7aAdJNX7B4918rJxOwIEamkTjrqLUeam YXRxOkTbsbu/35vv40kWt90tN5NYs9jo5lXw99oSTRLAxA3igkurqa8H0FwLDob2 9rDXfAOlnbrSfsb71Y/9QEtYL+0sQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdelgdduudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeetfeelffejfffhheehfeefgedulefgueejudekieegvdeghefffedvheffieel keenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvd ehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm nhhothesmhhnohhtrdhnvght 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 821B224005C; Thu, 28 Jan 2021 03:28:56 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Mark Nottingham In-Reply-To: Date: Thu, 28 Jan 2021 19:28:53 +1100 Cc: "Salz, Rich" , "httpapi@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <88ED49DB-E081-4C97-9FB9-080A1C585435@akamai.com> To: =?utf-8?Q?Andr=C3=A9_Cedik?= X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [httpapi] Discussion of adopting Content-Warning header 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, 28 Jan 2021 08:29:03 -0000 Hi Andr=C3=A9, > On 28 Jan 2021, at 7:21 pm, Andr=C3=A9 Cedik = wrote: >=20 > The challenge with warnings from my point of view is the fact that the = original request was successful - in our case, a shipping label has been = created - but there were "side effects" that may need to be addressed. = If it would only boil down to this I'd say "let's create a content-type = application/warnings+json" or something similar. But I would make the = assumption that there are use cases where warnings and errors can both = happen with one request. Maybe because something happened at an = intermediary and the destination server which is processing the request = is throwing e.g. a server error. This is one of the reasons why we opted = to make it a header field. The other being that there might be other use = cases where an "embedded-warning" doesn't make sense. This is why the = concept of a registry was introduced to create other warning types. I'm not sure that assumption holds. There may indeed be other use cases = for warnings in APIs that justify a header, but without seeing them, = it's hard to tell if the design you've proposed will address them. Your = use case can be addressed by using RFC7807, so why not just use that? Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Thu Jan 28 00:50:16 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 AFE803A13FB for ; Thu, 28 Jan 2021 00:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=teamdigitale.governo.it 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 uEWqWuFahoAL for ; Thu, 28 Jan 2021 00:50:13 -0800 (PST) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 E81403A13F8 for ; Thu, 28 Jan 2021 00:50:12 -0800 (PST) Received: by mail-ej1-x62a.google.com with SMTP id r12so6534800ejb.9 for ; Thu, 28 Jan 2021 00:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamdigitale.governo.it; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=a9YB9Cuux9lucByP751cd3HEyg/OOdd59BeS0elojrQ=; b=QzVO8nU7O1I1M+FGZMVFa0GDWju6Tpm0mWfO4YNqDHktrAvWhm0e/Vq332CxIB0OXf 3UtK0813lhdpQl7iWns61/tTOVmRLHuwFSqOH3H5Bsp95z+DeWRpVCHERV66Iovlm3hP QKOh4nk0HZ3H6MFv+Mp1vPBlDraE98YNZEZ0e8yXPhmF6O0aBMC1usdVuxhgHn8nCAO+ mDeqr3Izr0RK1TsBxuDFwYZsmHXRuGlKgnZ0fHu78DnBMlkLd5EEzqwJwatPgzH3Aow7 XmYBEzthiFPTRrZqHA7i2zq9eeQpQQIawWvtdGWJn2FyCnowd+gt4uJT3iYN5yeXp0cm fbcA== 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=a9YB9Cuux9lucByP751cd3HEyg/OOdd59BeS0elojrQ=; b=KzvufzQdfm/zgiu283bB1kb29fR3mZCT+k+PHeSCNdGPossC8QPiv9ji70UrR2NBQf q7f7JExaBM23TxLuF/4IBf++RkYYwaGY4+CmEPlG/fUgUoUYgur1mspXKE0gPABUmRCa pew466aZ2j4K1WPfO+xy/DB6rwO54hlWGEKDHFalgkWYwfvAjuDIejHrLfpMW7FRUmoM SIRHadEIlnGByWAEdONnbwFBebm2YP4H/S20S1BJ+TjJ6QsVZfqY9r9xMuFWQnXKdnFN QiCv5XisyUllI4B787nSQAjuk61BPFGSLpx9P5edkSE2fgxqdNgc6GrkD3lXPmrnEEMa IWCg== X-Gm-Message-State: AOAM531mvCVfGx3Ie+yGZy+BOywck0diq66bAD0O/z73H79g5JjkXuc6 +Ml6Gzg3p2rdwQGXWpYt7bE5vArjqsC3vMqKOmlb/g== X-Google-Smtp-Source: ABdhPJyNbwNcwibWkt2nV28FXihUE0bq1jGv/1M+b+pTIqaOagYpXv4nbbqxUcDZM786iHWAMp+osPf+kSxhWgjnK4U= X-Received: by 2002:a17:906:40ca:: with SMTP id a10mr10412934ejk.295.1611823809618; Thu, 28 Jan 2021 00:50:09 -0800 (PST) MIME-Version: 1.0 References: <88ED49DB-E081-4C97-9FB9-080A1C585435@akamai.com> In-Reply-To: From: Roberto Polli Date: Thu, 28 Jan 2021 09:49:58 +0100 Message-ID: To: Mark Nottingham Cc: =?UTF-8?B?QW5kcsOpIENlZGlr?= , "httpapi@ietf.org" , "Salz, Rich" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [httpapi] Discussion of adopting Content-Warning header 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, 28 Jan 2021 08:50:15 -0000 Hi @all, Il giorno gio 28 gen 2021 alle ore 09:29 Mark Nottingham ha scritto: > There may indeed be other use cases for warnings in APIs that justify a h= eader, but without seeing them, it's hard to tell if the design you've prop= osed will address them. imho there is a general interest in a replacement of the `Warning` header (eg. to set alerts in payload-agnostic monitoring systems). I agree that a strong relationship with the payload data raises various issues, including Mark's ones. My suggestion to Andr=C3=A9 - that may still not address Mark's concerns - = is to: 1- dis-entangle his proposal from the `Content` (eg. `Api-Warning`) 2- retain the "warning-type" registry, which can specify the type of warning including content-warning my 2=C2=A2, R. --=20 Roberto Polli API Expert M. +39 3406522736 MID DIPARTIMENTO PER LA TRASFORMAZIONE DIGITALE Presidenza del Consiglio dei Ministri - Ministro per l'innovazione tecnologica e la digitalizzazione https://innovazione.gov.it/ Il Dipartimento per la Trasformazione Digitale, salvo eccezioni, comunica con le altre Amministrazioni via posta elettronica ordinaria e non posta elettronica certificata, in conformit=C3=A0 a quanto previsto dall=E2=80=99art.47 del Codice dell=E2=80=99Amministrazione Digitale. From nobody Thu Jan 28 01:35:36 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 073C03A147B for ; Thu, 28 Jan 2021 01:35:34 -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, 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=ulsberg.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 cpgXbyDpA3TG for ; Thu, 28 Jan 2021 01:35:30 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 071DD3A1466 for ; Thu, 28 Jan 2021 01:35:29 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id a7so4600035qkb.13 for ; Thu, 28 Jan 2021 01:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ulsberg.no; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=P6rdE0Nkg4p/wbwi72VQ0D+WHQbrhtnlswkL55x9VJk=; b=lanfa6xMavLJD66nhzQ0az/hbg3emq3TXF0nwQzCmdXi/8s/u9fvOc0nXNGDNZkzGr AQOLMkyFZZMwMzosrtfd1SpinCwyeP06touBLS10kGxOaQxXiWURPAfl6cVcCPQiwsy9 sm8imGT10xs2QUSkhFfklsrFvoWNego5H8cj3qr9cCcS+ufx9WuaOLY01ApBlhWf15A7 aWKpBye+yjKsDu4IepQ77WCUgM/Xr1keud3n75EYt9DrTBYcyuwFLwoEWP7n5jBZrXt1 hD4+nSLixbvOxoTsm1c2m6LCT/Ao38WzlLMV2eW18tRAhrHew5oZWcDdwbe3vN4qUetY s+/w== 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=P6rdE0Nkg4p/wbwi72VQ0D+WHQbrhtnlswkL55x9VJk=; b=QlrCokiGs7XpfiUv+fnviwDu+Wil22t8qmWz9S6eycsCM7LAYoNYB74NDp3Q+I53MX PoVkAobNgt8z2DkEp71sHsPDH/dEBvXyi+/9qpsyOP/6K9lmaHnGOfhlhEsXctyX7kGN mVcdG55RmRc76zPWS/0yEodZzCKIwy0E4s2Uw3OpqLISgxOz5sqB+Qn659l3X2tZ3EjW gcDSefrUj/gDPjL7l7s0U7IBdkst6BAHxhmn5pSF2/kzfHHqDAzD1IxA5xMlgTa9tzj/ ByoXdLT6kPPwVJWiavJhrcMRs/HjtWFKzswEw3bwzYMJjiq+hXkg1gBUC/BrIrrX/NdV ttHg== X-Gm-Message-State: AOAM531a4AFGs2uWhmGUtliZzJL63Ig2vYM+NbZfyNkOT3ujkuFlKTDA T7aTfTx19VPRrm+mQ177/3NuDEfv3jxRRQ== X-Google-Smtp-Source: ABdhPJwSN1URUKaaJHTkz2NoaJcRMboGCyX2xUW5pz8LxQeWzBG/TO1ujwodso2GFSj4KcTR5+KVFQ== X-Received: by 2002:a37:6848:: with SMTP id d69mr10259422qkc.257.1611826528655; Thu, 28 Jan 2021 01:35:28 -0800 (PST) Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com. [209.85.219.175]) by smtp.gmail.com with ESMTPSA id 196sm3124828qkl.4.2021.01.28.01.35.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 Jan 2021 01:35:27 -0800 (PST) Received: by mail-yb1-f175.google.com with SMTP id k4so4832210ybp.6 for ; Thu, 28 Jan 2021 01:35:27 -0800 (PST) X-Received: by 2002:a5b:410:: with SMTP id m16mr23222857ybp.451.1611826527284; Thu, 28 Jan 2021 01:35:27 -0800 (PST) MIME-Version: 1.0 References: <88ED49DB-E081-4C97-9FB9-080A1C585435@akamai.com> In-Reply-To: From: =?UTF-8?Q?Asbj=C3=B8rn_Ulsberg?= Date: Thu, 28 Jan 2021 10:35:16 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Roberto Polli Cc: Mark Nottingham , "httpapi@ietf.org" , =?UTF-8?B?QW5kcsOpIENlZGlr?= , "Salz, Rich" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [httpapi] Discussion of adopting Content-Warning header 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, 28 Jan 2021 09:35:34 -0000 3 tor. 28. jan. 2021 kl. 09:50 skrev Roberto Polli : > imho there is a general interest in a replacement of the `Warning` > header (eg. to set alerts in payload-agnostic monitoring systems). I also envision the utility of intermediaries adding Content-Warning to indicate trouble understanding the request or response in one way or another, which may lead to a much better developer experience when these intermediaries are added to a request or response pipeline. > My suggestion to Andr=C3=A9 - that may still not address Mark's concerns = - is to: > 1- dis-entangle his proposal from the `Content` (eg. `Api-Warning`) +1. I think "Warning" is a good name, but think it has greater utility in being general and content type agnostic. Think about a reverse proxy being configured to perform CSS minification, for instance; if it fails parsing the CSS, it can leave the CSS untouched but add a Warning in the response regarding the syntax error it encountered. > 2- retain the "warning-type" registry, which can specify the type of > warning including content-warning On first skimming of the draft, I actually thought the "type" was equal to "type" in RFC 7807, i.e. a URI. I was both surprised and a bit disappointed to learn that was not the case. I think having a registry for different warning types adds needless friction and bureaucracy, without providing much benefit. Using a URI like in RFC 7807 allows the same types already minted for problem+json to be reused, allows for distributed and friction-free creation of types and makes it possible for type URIs to be dereferenced directly in order to read more about why the warning occurred and how it can be remedied. --=20 Asbj=C3=B8rn Ulsberg -=3D|=3D- asbjorn@ulsberg.no =C2=ABHe's a loathsome offensive brute, yet I can't look away=C2=BB From nobody Thu Jan 28 23:06: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 6DF0D3A0D05 for ; Thu, 28 Jan 2021 23:06:37 -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=CQFbLgD5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=D8AJ+801 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 BMiAw2IsM9EV for ; Thu, 28 Jan 2021 23:06:35 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 700053A0D04 for ; Thu, 28 Jan 2021 23:06:35 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 88D551286 for ; Fri, 29 Jan 2021 02:06:31 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 29 Jan 2021 02:06:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:to; s=fm1; bh=jmI5hSGUq9cfgEdlqMe/UKs255CC7xNCa pfp7HRhUwQ=; b=CQFbLgD5x5+MpQiaN2ix+WrAlpPM2o+r9F2tAu03+9MMxekIP Lqc98gSMG7Lzk1vZgrI+GN7r41LIz4E/pJWXNtgj8sc6vGxeErj6yzi1zHjGUn/c V0MZ9sWX3Ez79q7ivE2aMYEnlRYW4I6HRC2/JFuZXjCuMDLgDSHArl2jw0ePJT/E Nsrnaa1L106r13ezPBV6eROBjYXqKNakDh+iCJVGmyZ0mi5FrfsQFUILWY0BLrZj cB5mxk5HeN2MkH4rQ2NRn4n2bqD3SzD/gyYCnUJMB6XY1+x9c/X0Q/peCEBtxO2g +G8oeLevMr2eNEbpIvpuTVDaAO8IzFRf8aNLw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=jmI5hS GUq9cfgEdlqMe/UKs255CC7xNCapfp7HRhUwQ=; b=D8AJ+801t8ODml4RjkV520 Q7RZU2CqZzFfJx65y7/FA7pJOWjdY1smyxjnfIfe9zVGsxLReyBGAeOLXX45PLGT Yy/30CVFx/pUubi/dRQjeQA97O8H+L/3479XCxlUS8kzbavy3YA+P8M13ipn1sYl /m5t5cDPu73U/zy0TDnE7aOFD1BXqnu59kTXtiupjWNod02RbAVV13tjKJ8Q5Jti 3yooq+sL56cTZu1ax3fCWA3of63mfIcmFiwSERUE6K3B90CCR6UXQ6CjLBPXOQbp qx7n0YH3hfpIdnJe2DYdvtb5p3W3m8tSojhG8lptDL95xHyx9fNfe7m+jPyzs8DQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedugdellecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephfgtgfgguffkfffvofesthhqmhdthh dtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohht rdhnvghtqeenucggtffrrghtthgvrhhnpeejheegfedvfeeifeegffekiefhkeduvdegud evuefgjeehffejvedvffekvdekveenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhm nhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhedunecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgv th 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 21F07108005B for ; Fri, 29 Jan 2021 02:06:28 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Message-Id: Date: Fri, 29 Jan 2021 18:06:20 +1100 To: httpapi@ietf.org X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: [httpapi] RFC7807bis (HTTP Problems) 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, 29 Jan 2021 07:06:38 -0000 Hi everyone, Rich says that a Call for Adoption is not necessary in this case, after = discussion with the AD, so he asked us to go ahead and create a = repository: https://github.com/ietf-wg-httpapi/rfc7807bis We'll submit the -00 version shortly; it doesn't contain any significant = changes from 7807, so that we can verify the diff before we start work. I've already created a few issues; please start discussion there / add = new issues as you see fit. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Fri Jan 29 06:32: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 F1D2B3A0D75 for ; Fri, 29 Jan 2021 06:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 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, RCVD_IN_MSPIKE_H2=-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=microsoft.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 cmAHfE9Sq82G for ; Fri, 29 Jan 2021 06:32:03 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650099.outbound.protection.outlook.com [40.107.65.99]) (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 9F6123A0D74 for ; Fri, 29 Jan 2021 06:32:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cbYzgswwD5Ytop2w/TJaYqmyS454otXkoQEfXXOJQRg1l4du1EjP9ZpovmUYJh7tgFKgh5omXEVNAgRBuUYwhLHaxObs2O66OqdV7og64Ydo+oNwgu21y1KAAmKOBDYBFyZm+8bXwihD5FhhAYpbgsUoad29l86sCnIvVLGnLaqUEo8sXMUMPrgAHPAdIiITnLMzqTC3Ie/JCK0cSocYqbvCO8rIj6LaU/ZSF7dWZ6dwmVseVtf7s1sH/BjHU42H6GDAgEfQggSfRtBDx8i8WTrImr+sx08cXnWYm/RwxDyXXGP5L6seN9DTZIAZASzf5VDjSFod/4ctrwfD5RfJ+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n+RDV8WmVq9fIUsUajVACaRFR/RPd8Pm5/NokbIP538=; b=mwZwMowB1gAMojldKzaNfBcSwUCrOaMBxu5MZEGJ146oEhpGts1UM43dT91TfXl2SWmq90GjRqc3sRNdjeuSsJsZ6KQwbwxRR/l6WXva5epNPilac0GLAPTmotEemAWQhZQP4uFMkhz/NhIX5pBGOWuTPJ3fiFrMuR9GlJ5nDLWQKJOKHw3LTm6C00fASleID4gydSo1FemsNvw0qZY3o21dzvR4vQlMiMpoFgATBOfyevNnQLLT2c/snoO6BLf4ULedYjrJIDqm7OWVBQNfmgXQ+9d3SRQdOMWDNp76ic8FQnzRAtSQKTTNqncybfBZVh1E8Hhe0R+8OKSd03KSMg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n+RDV8WmVq9fIUsUajVACaRFR/RPd8Pm5/NokbIP538=; b=HTsH98gaTLnfiv6vBBcY9EjGxFQvUdIHLgZFnupTEV7LDCB6mghfqnHVZxqvvzPXu3I/tqLeaIvyNndWu+Z+u0hKzm0TcUm2AcjJ+SkYRx3392K/CfdCafRIb6XfclZgFRfVc1vqNjIDozfvnWRwbAWDN/K8asGQF2zwzgdQ/X0= Received: from (2603:10b6:610:6f::7) by CH2PR00MB0843.namprd00.prod.outlook.com (2603:10b6:610:6f::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3842.0; Fri, 29 Jan 2021 14:31:49 +0000 Received: from CH2PR00MB0842.namprd00.prod.outlook.com ([fe80::b534:62e7:e26e:ed4c]) by CH2PR00MB0842.namprd00.prod.outlook.com ([fe80::b534:62e7:e26e:ed4c%9]) with mapi id 15.20.3848.000; Fri, 29 Jan 2021 14:31:49 +0000 From: Darrel Miller To: "mnot@mnot.net" CC: "gabriel@sullice.com" , "httpapi@ietf.org" Thread-Topic: [httpapi] Link relationship types for authentication Thread-Index: AQHW80o3xHsPdJaWDkmC6ueoIIUivqo5M0YhgANiToCAAhp/bQ== Date: Fri, 29 Jan 2021 14:31:49 +0000 Message-ID: References: , <529C556A-1270-4B10-80F8-3D51FFEB8356@mnot.net> In-Reply-To: <529C556A-1270-4B10-80F8-3D51FFEB8356@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-01-29T14:31:48.818Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: mnot.net; dkim=none (message not signed) header.d=none;mnot.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [74.15.147.35] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f7fbda40-b3f0-430a-e5a1-08d8c4629d45 x-ms-traffictypediagnostic: CH2PR00MB0843: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JISa6BfYdbl9xcw+2Pza3LgzvxPELWWSslVMybZz9XX/26alqDk71uzJRWVJPz7cpBNMNR7fqzlvTbAZFkD/imlHCveL5h86Uv/95Dgyy5r25Wm1jv/LEAP52BWE72etwgqwLjC5JzREWeKXIZEQaLXeZG9gLf/+1eSGURa1k5O5fHe9mXCcwEkamvIEeBVYc2000hl8o3kpuiEHKfb1CRZ0IK1y9QVKPZUQFRxy0eVw+JezsdQTE8kcaw/2njkbvgtZsWCZSu+rxYsidLi/OLSp3cVQeM6Wsku0r+9sna1ly9pc72+LtAD+NoQ/NXvBkCqcfclVBcgUFinLcn4bC0NENjpBS+Owc3O+GPDkz4xW2N6KmJFulW1KGJxUCzY3Ak4nybR2hPCBjNGJ8hqEY9ESL1t1KWDI+VE7QsLPR1lQel8WDOE7MHKaM2aW45mxfKLlbYfwg/36LRcIuYTmvH088zb28+V+jEj8a4tVk1ieA69yyB+KpbXYmm/0b8rHWLCoIcAlk4ySsdXy4ajXpQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0842.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(39860400002)(366004)(396003)(136003)(316002)(4326008)(26005)(66446008)(33656002)(52536014)(186003)(54906003)(86362001)(6506007)(82960400001)(66556008)(66946007)(64756008)(8990500004)(66476007)(55016002)(19627405001)(9686003)(76116006)(6916009)(10290500003)(7696005)(82950400001)(2906002)(5660300002)(478600001)(4744005)(8936002)(71200400001)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?oxKP5Xe9cjEFsTBN9a/upJJ1Bw3R2mUjiytg0+vlMPYVrQY63iEx5wGG1h?= =?iso-8859-1?Q?t07hOrr8yU0IYtJDyV2yWcVUvWAFocG0XbJOJWNiRjvNtn2QvPZWMaLR2D?= =?iso-8859-1?Q?BdB172hJSPDouLCibGelTdPRwX6K1KzX6dgsM+wRJoxDEhfvwnLB+iucx6?= =?iso-8859-1?Q?9c58dSh7bLKbNiH9yYohydvOepQWXD61ELmiwx1tA7i5Co32jv+Kxe971q?= =?iso-8859-1?Q?lCecZpZ17U7oNvpA5n1dYSsmYEiRQzgH+PY7N2axvYyDgOS5hsV0mXKiGX?= =?iso-8859-1?Q?rISpNZ4nx3QNcgkvfJNlrQLZhdadLOgEz8D7Zf9EKVaBfYg3SR/l5Qo0Yt?= =?iso-8859-1?Q?vxYg52ySZwdBhAo1503BrDlR7H4tPaIrpLObQy0U1szGHpU2BwwLUorX8F?= =?iso-8859-1?Q?S9sCWV7t7MuPQZixO7/tsGGFiM9wEt0vZM7ZSVqSnAaa3LP8J7qQ6KLxLZ?= =?iso-8859-1?Q?Jutv/mWHCFuaCwIiBcTqopriRSFP0qIL9DzMYIXf8ILG/NvSXGhwcEvU4q?= =?iso-8859-1?Q?Kvw+j8fI35a9Q4SQQIvvfJoVVAsS43OejJcw6BwGjoSjqeym9WKtJbqjDj?= =?iso-8859-1?Q?MaVYIw49qKVOMZ75kZoAnq5g7KUt8kqF7ez/OSCq2yH/VdjvOnuNt68d2h?= =?iso-8859-1?Q?niE0JrAxO7BV4WzttlU9T4xz8mHUttBoaJEZLRCPx86ph9SVBHkeso96No?= =?iso-8859-1?Q?Rra7BqtI6fXUfriUu+qkCWbjU8h7UjNskdL+Bygm2K9KoIn6RVgPFAnPT3?= =?iso-8859-1?Q?aeDh85vtrcYYq3uyOUJsdiUqyMUNO64CfRxn31QH9ryj7WETQYxzAm7jbb?= =?iso-8859-1?Q?5lF4y2WXC0G9BSX9FPh7SDoB7QG764ZUWfQprbmY5cWQ+FJM09G3b/7OLp?= =?iso-8859-1?Q?SGcnX2vthcqYj6PXdNbzoZ2YhhKZh9KYGHtti9WT+V8aCPUncyJLZ8/sG7?= =?iso-8859-1?Q?2V6VmsVO00cTKk9qX2Vbrh1DQ9hGMLrjj9rGFasxfuhOlkssxJajIPTH/t?= =?iso-8859-1?Q?tC3KqO1N+Ke88cjEQxJLTMZnzSt8++1AaYp8CGJG1Y7P8W95pWX+U3ZgSb?= =?iso-8859-1?Q?CjUICEG4cES9eca/hN8waYt6BxIBl71CjlH9bbX9eaHOIIL5VGDKLlf/c+?= =?iso-8859-1?Q?WVkAr/IHU7CtYu739bJIL1FRzvvvOzisjIRSqEUJFsK/Bc+3fW25xFPw9C?= =?iso-8859-1?Q?96sv5bkD+g6hj7RiIs/DG7u2vE0W77nQzwakIm7stTCulOpgA+sQ1d6eZ/?= =?iso-8859-1?Q?PrW0QKjOAQQThmZc56faJQcqF20EY7M2Rn5WKFpbwjyYfFLScr+OTUIe1/?= =?iso-8859-1?Q?iB56L+HoyydFoofS30PWkuDRYfBNjy3ir2sjCC1FamJQAvc=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB084261832C2DD85A056D49B9F0B99CH2PR00MB0842namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0842.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f7fbda40-b3f0-430a-e5a1-08d8c4629d45 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2021 14:31:49.4968 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: K+QyAorxgmL8fnoJR7BDHpwOGwGAFcxAEAxTpa/xisdAbR5Q0i14qA/nB3hDevy8BKBlNV2pVyA5+Eoz21J1iQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0843 Archived-At: Subject: Re: [httpapi] Link relationship types for authentication 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, 29 Jan 2021 14:32:05 -0000 --_000_CH2PR00MB084261832C2DD85A056D49B9F0B99CH2PR00MB0842namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mark, From: Mark Nottingham Just to clarify -- that list can give advice about the details of registrat= ion and whether or not the use 'fits' link relations, but the discussion of= the proposal should happen in the relevant community -- i.e., here. Thanks for the clarification, I wasn't sure about that. Darrel --_000_CH2PR00MB084261832C2DD85A056D49B9F0B99CH2PR00MB0842namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Mark,
From: Mark Nottingham <m= not@mnot.net>
 
Just to clarify -- that list can give advice about= the details of registration and whether or not the use 'fits' link relatio= ns, but the discussion of the proposal should happen in the relevant commun= ity -- i.e., here.

Thanks for the clarification, I wasn't sure about that.

Darrel

--_000_CH2PR00MB084261832C2DD85A056D49B9F0B99CH2PR00MB0842namp_-- From nobody Fri Jan 29 09:10:15 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 024F33A118C for ; Fri, 29 Jan 2021 09:10:14 -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, RCVD_IN_DNSWL_BLOCKED=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 yFgld0mov52Q for ; Fri, 29 Jan 2021 09:10:12 -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 B625D3A118B for ; Fri, 29 Jan 2021 09:10:12 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 10TGxiso020242; Fri, 29 Jan 2021 17:10:11 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 : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=LqPBk6AXOvlG7zQmDttvWN4hRr+aHBORtvGOrtGumQg=; b=flVbFbbSZ5uZ4bU8APuDn+W5pBcWMrFAoBh+zVLQkuiReSc72K64z8uh4yRBbvD4U25H zYPW5M+X+s/sRZvx0U+YL3c5GRebAZEQ+3XU5MBpIMPdTMPIQFcjdMxsM3LOx03YKcJK G/d6T7C3n7z0LFr+WMplJQwLgJVkIjOeenFuqkRl6pPn4lDEmcD6wqUCVVEABZLEqxAx SaEXM0La/2rfLva0/K+QFa7eWadu9DvYhClkwO6vD9yBSMtDBt3lZSuxeBqdISBHdNkV UYs1/58gQDgoYXcauXJfXjH7HGyw8ITLNeIDHi5y32bPWsgjsJOHIZl8PiCH/e/mz124 kg== Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 369e7gtbsb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 29 Jan 2021 17:10:11 +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 10TH3wmn023623; Fri, 29 Jan 2021 12:10:05 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.118]) by prod-mail-ppoint3.akamai.com with ESMTP id 36b7haw4tp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 29 Jan 2021 12:10:05 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 29 Jan 2021 11:10:05 -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, 29 Jan 2021 11:10:04 -0600 From: "Salz, Rich" To: Mark Nottingham , "httpapi@ietf.org" Thread-Topic: [httpapi] RFC7807bis (HTTP Problems) Thread-Index: AQHW9g1OYIFbXz3XjkO8Nlf/2rznhqo+59OA Date: Fri, 29 Jan 2021 17:10:04 +0000 Message-ID: <6A7A29B5-9425-4633-B4B1-B2490770E64E@akamai.com> References: In-Reply-To: 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-01-29_06:2021-01-29, 2021-01-29 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 bulkscore=0 mlxscore=0 adultscore=0 phishscore=0 spamscore=0 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101290083 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.737 definitions=2021-01-29_06:2021-01-29, 2021-01-29 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 clxscore=1015 lowpriorityscore=0 spamscore=0 suspectscore=0 impostorscore=0 mlxlogscore=999 bulkscore=0 mlxscore=0 adultscore=0 phishscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101290083 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] RFC7807bis (HTTP Problems) 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, 29 Jan 2021 17:10:14 -0000 SnVzdCB0byBiZSBjbGVhcjogdGhlIGNvbmZ1c2lvbiBhYm91dCAiY2FsbCBmb3IgYWRvcHRpb24i IHZlcnN1cyBhIGNhbGwgbm90IG5lY2Vzc2FyeSB3YXMgb25lIEkgY3JlYXRlZC4NCg0KUGxlYXNl IGRpc2N1c3Mgb24gdGhlIGxpc3QgaWYgc3Vic3RhbnRpdmUsIG9wZW4gZ2l0aHViIGlzc3VlcyBh bmQgUFIncyBhcyBhcHByb3ByaWF0ZS4NCg0K77u/T24gMS8yOS8yMSwgMjowNiBBTSwgIk1hcmsg Tm90dGluZ2hhbSIgPG1ub3RAbW5vdC5uZXQ+IHdyb3RlOg0KDQogICAgSGkgZXZlcnlvbmUsDQoN CiAgICBSaWNoIHNheXMgdGhhdCBhIENhbGwgZm9yIEFkb3B0aW9uIGlzIG5vdCBuZWNlc3Nhcnkg aW4gdGhpcyBjYXNlLCBhZnRlciBkaXNjdXNzaW9uIHdpdGggdGhlIEFELCBzbyBoZSBhc2tlZCB1 cyB0byBnbyBhaGVhZCBhbmQgY3JlYXRlIGEgcmVwb3NpdG9yeToNCiAgICAgIGh0dHBzOi8vZ2l0 aHViLmNvbS9pZXRmLXdnLWh0dHBhcGkvcmZjNzgwN2Jpcw0KDQogICAgV2UnbGwgc3VibWl0IHRo ZSAtMDAgdmVyc2lvbiBzaG9ydGx5OyBpdCBkb2Vzbid0IGNvbnRhaW4gYW55IHNpZ25pZmljYW50 IGNoYW5nZXMgZnJvbSA3ODA3LCBzbyB0aGF0IHdlIGNhbiB2ZXJpZnkgdGhlIGRpZmYgYmVmb3Jl IHdlIHN0YXJ0IHdvcmsuDQoNCiAgICBJJ3ZlIGFscmVhZHkgY3JlYXRlZCBhIGZldyBpc3N1ZXM7 IHBsZWFzZSBzdGFydCBkaXNjdXNzaW9uIHRoZXJlIC8gYWRkIG5ldyBpc3N1ZXMgYXMgeW91IHNl ZSBmaXQuDQoNCiAgICBDaGVlcnMsDQoNCiAgICAtLQ0KICAgIE1hcmsgTm90dGluZ2hhbSAgIGh0 dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5tbm90Lm5ldC9fXzshIUdqdlR6 X3ZrIUEtLTdlUHVmdENIa0UycXdzM1B5UVFZZHROdVJHeXJlUmE1dU9RLU9QODNNX1pKblJoMkRr R3g3aE9fYSQgDQoNCiAgICAtLSANCiAgICBodHRwYXBpIG1haWxpbmcgbGlzdA0KICAgIGh0dHBh cGlAaWV0Zi5vcmcNCiAgICBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9odHRwYXBpX187ISFHanZUel92ayFBLS03ZVB1ZnRD SGtFMnF3czNQeVFRWWR0TnVSR3lyZVJhNXVPUS1PUDgzTV9aSm5SaDJEa09fX1g2SDgkIA0KDQo=
Hi Darrel,

On Tue, Jan 5, 2021 at 4:17 PM Darrel Mille= r <Darrel.Miller@microsof= t.com> wrote:

My assertion is that if we discouraged API providers from punishin= g consumer for reaching a rate limit, and we promote the use of the retry-a= fter as a signal to the client to back-off before making another call, then= there are fewer scenarios where a client is required to constantly monitor= "the number of calls left before reaching the limit".=C2=A0 Retu= rning and monitoring "calls remaining" is potentially an expensiv= e operation, especially when multiple clients can consume the same quota, e= .g. in the case of calls per user that is using multiple applications.
<= /blockquote>

That's a valid observation. That's = why clients receiving these headers should consider them a hint and the nex= t request they perform could be responded with new data in the headers that= would make little sense if taken in isolation without further knowledge of= what could be consuming the quotas. Service specific policies specified in= the headers could help reduce that uncertainty, but those are too broad an= d diverse, so there's been little discussion on the topic other than al= lowing people to specify those so service specific clients can make use of = those extra bits of information.
=C2=A0
> The immediate benefit of these headers to service providers is being a= ble to signal expectations
> to clients so they can adapt.

The question I have is with the existing non-standard headers, how many peo= ple have actually bothered to write this adaptive client code?=C2=A0 Do we = believe that lack of standardization has been sufficient to discourage peop= le from writing that code?=C2=A0 Are the only people writing that code the = ones who are trying to avoid punitive behavior?=C2=A0 If so, maybe a best p= ractices document that recommends not doing that would be more constructive= .

Yes, I believe that because there is = no standardization there's been little to no effort in writing such ada= ptive code in generic HTTP clients, but this is pure speculation. I think i= t is very likely that most people doing so are the ones writing service spe= cific clients, and in many cases they could be the same people that wrote t= he service in the first place, unless the service happens to see lots of us= age across the board with many independent clients. At a minimum, retry-aft= er could be used to signal generic clients that no request should be perfor= med for a while, but that falls short of the minimum information that gener= ic clients could use with these headers.
=C2=A0
>=C2=A0 Sometimes it is just a matter of adjusting to some specific rate= of
> resource consumption. Some other times the only way to adapt is just t= o stop using a service
> entirely for a while or use another endpoint, and that's more usef= ul than just returning a 403
> or 50X without further information, ie. during a maintenance window yo= u can use the headers
> to signal that window with 0 quota units and avoid useless traffic.
Why would a 503 with a retry-after header with a period that matches the ma= intenance window not be sufficient here?

You are right, the immediate effect is the same. That said, you would be = lacking some extra information about the nominal quota units and duration o= f the current window and the windows applying after this one is elapsed (ie= . after recovery you'd have information about the expected rates, and t= hose could also signal some sort of punitive policy), though that informati= on might be next to useless in the current window since the intended effect= is to stop traffic altogether for a while. Yet it would not work in a clos= ely related scenario in which you would have some partial maintenance work = but keeping the ability to serve clients in a degraded service manner -- th= at is, unless you kept giving clients shorter no-service windows interleave= d with service responses as usual, hence generating a lot more wasteful tra= ffic.

Cheers,
=C2=A0 Alex
<= /div>