IETF Logo Mail Archive

Re: [core] [Last-Call] Call for comments on draft-ietf-core-problem-details-07

Carsten Bormann <cabo@tzi.org> Thu, 30 June 2022 11:53 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED71BC15AE2D; Thu, 30 Jun 2022 04:53:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 KduoPJRRbtbO; Thu, 30 Jun 2022 04:53:05 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (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 781D9C14F739; Thu, 30 Jun 2022 04:53:04 -0700 (PDT)
Received: from smtpclient.apple (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4LYcCg2MFZzDCrn; Thu, 30 Jun 2022 13:53:03 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <62BD8990.9080502@btconnect.com>
Date: Thu, 30 Jun 2022 13:53:02 +0200
Cc: Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org>, Applications and Real-Time Area Discussion <art@ietf.org>, Core WG mailing list <core@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-core-problem-details.all@ietf.org" <draft-ietf-core-problem-details.all@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F721308D-3DF2-4C7E-A3DF-F7989FF6A393@tzi.org>
References: <165511479760.19573.12671700576299137749@ietfa.amsl.com> <63D13796-758D-469B-AFA8-3050C9F87819@tzi.org> <dde9d36c-61e5-afcc-e15a-787c99d5fba9@it.aoyama.ac.jp> <0012F049-354A-4450-B923-857D24AB9459@tzi.org> <90b785ef-934b-da9d-7d89-7018bdebbb75@it.aoyama.ac.jp> <B96E980A-72E3-4678-B214-8464958845BB@tzi.org> <ff5f8ff1-67fc-eead-6b38-62c8d64ebf45@it.aoyama.ac.jp> <4207E390-270A-463B-A38A-063AD2436370@tzi.org> <16D5BCD8-769A-41C0-A178-6893678CB526@tzi.org> <PA4PR07MB86244C52223D7BE9F1886BE598B89@PA4PR07MB8624.eurprd07.prod.outlook.com> <AS1PR07MB86160DEF13089FF61CD4B55598BB9@AS1PR07MB8616.eurprd07.prod.outlook.com> <62BD8990.9080502@btconnect.com>
To: tom petch <daedulus@btconnect.com>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/J1Sz4oost-bHgyTsqkjcPDNt_pk>
Subject: Re: [core] [Last-Call] Call for comments on draft-ietf-core-problem-details-07
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jun 2022 11:53:10 -0000

On 30. Jun 2022, at 13:31, tom petch <daedulus@btconnect.com> wrote:
> 
> Common practice is for a Normative Appendix, of which there are a few, to be explicitly labelled as such but I would see that as a poorer alternative.

All appendices in the document are normative, in the sense that they are referenced from the normative IANA registrations and supply their respective semantics.
(They do in turn contain examples, which are not normative.)

If the IESG or the RFC-editor wants to establish a convention requesting that appendices can only be non-normative, that can be done, but please do that after the present document has been published.  (That convention would neither be common nor good, I might add.)

Grüße, Carsten

v2.23.0 | Report a Bug | By Email