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

Amanda Baber <amanda.baber@iana.org> Thu, 10 November 2022 13:55 UTC

Return-Path: <amanda.baber@iana.org>
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 271E1C1522DF; Thu, 10 Nov 2022 05:55:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 zWGS40Uctygk; Thu, 10 Nov 2022 05:55:32 -0800 (PST)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11BDAC1522A9; Thu, 10 Nov 2022 05:55:32 -0800 (PST)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa3.lax.icann.org (8.17.1.5/8.17.1.5) with ESMTPS id 2AADtQLF023949 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Nov 2022 13:55:26 GMT
Received: from MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.15; Thu, 10 Nov 2022 05:55:25 -0800
Received: from MBX112-W2-CO-2.pexch112.icann.org ([10.226.41.130]) by MBX112-W2-CO-2.pexch112.icann.org ([10.226.41.130]) with mapi id 15.02.1118.015; Thu, 10 Nov 2022 05:55:25 -0800
From: Amanda Baber <amanda.baber@iana.org>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Carsten Bormann <cabo@tzi.org>, Erik Wilde <erik.wilde@dret.net>
CC: Last Call <last-call@ietf.org>, "draft-ietf-httpapi-rfc7807bis@ietf.org" <draft-ietf-httpapi-rfc7807bis@ietf.org>, "httpapi@ietf.org" <httpapi@ietf.org>
Thread-Topic: [Ext] Re: [Last-Call] [httpapi] Last Call: <draft-ietf-httpapi-rfc7807bis-04.txt> (Problem Details for HTTP APIs) to Proposed Standard
Thread-Index: AQHY72fTc/4xzWla80CSUeGSiKwSjK4tbeWAgAA5rACAAAK7AIAAAtcAgAACsQCAARtdAIAJ9EQA
Date: Thu, 10 Nov 2022 13:55:25 +0000
Message-ID: <9A5D3E4F-C633-46A4-AF07-9E9136E61714@iana.org>
References: <166627224606.10641.5749459667185024591@ietfa.amsl.com> <A98333C4-1FBB-4212-A378-818BCF61F093@tzi.org> <4754b49e-2aac-1059-c401-4ec3275ac46c@dret.net> <CFE79F91-1D2E-4733-A513-9DF6D71A3E52@tzi.org> <fb6f0eb5-177b-2b5d-73e4-7fecd2e8cf69@dret.net> <C4C39022-F299-4D3A-922E-481B1FBB5960@tzi.org> <5ffcf5ad-a530-a36d-14c4-5cb5cf8afce2@dret.net> <E73ED1FB-54A0-4E43-8E23-F926F3073BC5@tzi.org> <c70e846a-5668-60ef-cb60-1ea644642262@it.aoyama.ac.jp>
In-Reply-To: <c70e846a-5668-60ef-cb60-1ea644642262@it.aoyama.ac.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.63.22070801
x-originating-ip: [192.0.32.234]
x-source-routing-agent: True
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3750933324_1187747339"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-10_08,2022-11-09_01,2022-06-22_01
Archived-At: <https://mailarchive.ietf.org/arch/msg/httpapi/VRov6t3s26yeERL4fWQ0A_POAPg>
Subject: Re: [httpapi] [Ext] Re: [Last-Call] 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, 10 Nov 2022 13:55:36 -0000

Hi Martin, all,

[AB] below. 

On 11/4/22, 6:55 AM, "last-call on behalf of Martin J. Dürst" <last-call-bounces@ietf.org on behalf of duerst@it.aoyama.ac.jp> wrote:

    Hello Erik, Carsten, others,

    On 2022-11-03 23:00, Carsten Bormann wrote:
    > On 3. Nov 2022, at 14:50, Erik Wilde <erik.wilde@dret.net> wrote:
    >>
    >> hello carsten.
    >>
    >> On 2022-11-03 14:40, Carsten Bormann wrote:
    >>>> either we remove the guidance, or we can add a note saying that for those URIs, fragment identification will not work. my preference is for the latter, because it would be useful to end up on the registry page.
    >>> Yes, we can take away the surprise by saying that.
    >>
    >> just making sure we're properly addressing your review feedback: if we leave the recommendation to use the URIs, but explicitly add a note saying that those URIs (for now) are not fully resolved as they ideally should be, that addresses your issue?
    > 
    > Yes, it does.
    > 
    > IANA may have additional thoughts on this, though.

    I very much agree here. It would be a good idea to contact IANA and ask 
    them if or how they might be able to provide better guarantees. At the 
    worst, it's another gentle push in the direction we want IANA to go, 
    even if they won't do it this time.

[AB] While we don't have an obvious mechanism to provide stable URLs with this level of precision today, we do have the intention to provide permanent links to registries and registrations in our roadmap for our next-generation registry system, currently under development. Within our current system,  we can't provide links to specific registrations, and cannot guarantee that links to registries within a registry group (e.g. https://www.iana.org/assignments/core-parameters#content-formats within the CORE Parameters group) won't end up defaulting to the larger group (https://www.iana.org/assignments/core-parameters) With that said, if there are unique considerations for individual registries, please talk to us about potential interim approaches until we have something holistic in place.

Thanks,
Amanda

    Regards,   Martin.


    > Grüße, Carsten
    > 

    -- 
    last-call mailing list
    last-call@ietf.org
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!PtGJab4!8us7ni7wZJL2sRlQ7WqbQH20P3e71XR9MCiDZx-graT1zIei4RPMN1kcCVTR82bNUY2ahcT3UcZGTpEcLdNlsXg55eWfBA$  [ietf[.]org]