Re: [httpapi] Last Call: <draft-ietf-httpapi-rfc7807bis-04.txt> (Problem Details for HTTP APIs) to Proposed Standard

Erik Wilde <erik.wilde@dret.net> Thu, 03 November 2022 09:36 UTC

Return-Path: <erik.wilde@dret.net>
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 143B6C14CF0E; Thu, 3 Nov 2022 02:36:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.608
X-Spam-Level:
X-Spam-Status: No, score=-2.608 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_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 pXzBgH3oQTSY; Thu, 3 Nov 2022 02:36:42 -0700 (PDT)
Received: from mxout014.mail.hostpoint.ch (mxout014.mail.hostpoint.ch [IPv6:2a00:d70:0:e::314]) (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 D3F98C14F72A; Thu, 3 Nov 2022 02:36:39 -0700 (PDT)
Received: from [10.0.2.44] (helo=asmtp014.mail.hostpoint.ch) by mxout014.mail.hostpoint.ch with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from <erik.wilde@dret.net>) id 1oqWeK-000Los-1y; Thu, 03 Nov 2022 10:36:36 +0100
Received: from [185.132.19.16] (helo=[192.168.1.167]) by asmtp014.mail.hostpoint.ch with esmtpa (Exim 4.95 (FreeBSD)) (envelope-from <erik.wilde@dret.net>) id 1oqWeJ-000LKj-Pi; Thu, 03 Nov 2022 10:36:35 +0100
X-Authenticated-Sender-Id: erik.wilde@dret.net
Message-ID: <4754b49e-2aac-1059-c401-4ec3275ac46c@dret.net>
Date: Thu, 03 Nov 2022 10:36:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.0
Content-Language: en-US
To: Carsten Bormann <cabo@tzi.org>, Last Call <last-call@ietf.org>
Cc: draft-ietf-httpapi-rfc7807bis@ietf.org, httpapi@ietf.org
References: <166627224606.10641.5749459667185024591@ietfa.amsl.com> <A98333C4-1FBB-4212-A378-818BCF61F093@tzi.org>
From: Erik Wilde <erik.wilde@dret.net>
In-Reply-To: <A98333C4-1FBB-4212-A378-818BCF61F093@tzi.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/httpapi/tlekcHTZ43mZGdVKWhG41RsH7Tk>
Subject: Re: [httpapi] Last Call: <draft-ietf-httpapi-rfc7807bis-04.txt> (Problem Details for HTTP APIs) to Proposed Standard
X-BeenThere: httpapi@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Building Blocks for HTTP APIs <httpapi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/httpapi>, <mailto:httpapi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/httpapi/>
List-Post: <mailto:httpapi@ietf.org>
List-Help: <mailto:httpapi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpapi>, <mailto:httpapi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2022 09:36:46 -0000

hello carsten.

thanks for your review!

On 2022-11-02 22:32, Carsten Bormann wrote:
> # Major:
> 
> There seems to be an expectation that IANA will make
> https://iana.org/assignments/http-problem-types#foo resolvable.
> I'm not sure IANA is in a position to do this today.

there is no such expectation, but i think i understand where you're 
coming from. on the one hand, we (hopefully) make it clear that "type" 
URIs should be used as identifiers and should not be dereferenced 
automatically.

on the other hand, we recommend that locator-type URIs should be 
resolvable. so while our recommendation/option to use 
https://iana.org/assignments/http-problem-types# as prefix for 
registered types is technically ok even when those URIs do not 
dereference, we're not following our own recommendation.

but it could be argued that even though 
https://iana.org/assignments/http-problem-types#foo may not dereference 
(because i think IANA is not in a position to manage fragment 
identifiers for registry pages), at least you'd end up on the registry 
page where finding the right entry is an easy thing to do. do you think 
that's good enough or do you think that not properly managing fragment 
identifiers is a problem?

thanks and cheers,

dret.

-- 
Erik Wilde | mailto:erik.wilde@dret.net    |
            | https://youtube.com/ErikWilde |