From nobody Wed Feb 15 01:27:45 2023 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 81659C14CF0C; Wed, 15 Feb 2023 01:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcDuiL8-n-Cd; Wed, 15 Feb 2023 01:27:39 -0800 (PST) Received: from mxout013.mail.hostpoint.ch (mxout013.mail.hostpoint.ch [IPv6:2a00:d70:0:e::313]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04500C14CF05; Wed, 15 Feb 2023 01:27:37 -0800 (PST) Received: from [10.0.2.45] (helo=asmtp012.mail.hostpoint.ch) by mxout013.mail.hostpoint.ch with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1pSE4X-0007J4-SM; Wed, 15 Feb 2023 10:27:29 +0100 Received: from [85.62.128.83] (helo=[192.168.191.106]) by asmtp012.mail.hostpoint.ch with esmtpa (Exim 4.95 (FreeBSD)) (envelope-from ) id 1pSE4X-000EVX-KB; Wed, 15 Feb 2023 10:27:29 +0100 X-Authenticated-Sender-Id: erik.wilde@dret.net Message-ID: <15243c47-9145-27da-2eb7-d462714a8929@dret.net> Date: Wed, 15 Feb 2023 09:27:27 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Content-Language: en-US To: Mark Nottingham , Lars Eggert , Pete Resnick Cc: gen-art@ietf.org, HTTP APIs Working Group , Last Call , Sanjay Dalal References: <166690880800.46780.14432111778502052910@ietfa.amsl.com> <0119F2EA-3353-46D9-9496-B115B9655A92@eggert.org> <5F1069BD-3BF8-4D5D-82CB-0AA40EC646F5@mnot.net> From: Erik Wilde In-Reply-To: <5F1069BD-3BF8-4D5D-82CB-0AA40EC646F5@mnot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [httpapi] [Gen-art] Genart last call review of draft-ietf-httpapi-rfc7807bis-04 X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2023 09:27:41 -0000 hello mark. On 2023-02-15 05:08, Mark Nottingham wrote: > I like the suggestion below; anyone else have an issue with incorporating it? > >>> If an extension member (see Section 3.2) occurs in the Problem field, >>> its name MUST be compatible with the syntax of Dictionary keys (see >>> Section 3.2 of [STRUCTURED-FIELDS]) and the defining problem type >>> MUST specify a Structured Type to serialize the value into. looks good to me. but what about replacing "Structured Type" (which is a term that's never used in that spec) with "Structured Data Type (see Section 3 of [STRUCTURED-FIELDS])"? thanks and cheers, dret. -- Erik Wilde | mailto:erik.wilde@dret.net | | https://youtube.com/ErikWilde |