Re: [core] [Last-Call] [art] Artart last call review of draft-ietf-core-problem-details-05

Harald Alvestrand <harald@alvestrand.no> Fri, 24 June 2022 14:23 UTC

Return-Path: <harald@alvestrand.no>
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 EF90AC15D49F; Fri, 24 Jun 2022 07:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.785
X-Spam-Level:
X-Spam-Status: No, score=-3.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.876, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 DBcDHNKjuNeB; Fri, 24 Jun 2022 07:23:37 -0700 (PDT)
Received: from smtp.alvestrand.no (smtp.alvestrand.no [65.21.189.24]) (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 E33DDC15CF25; Fri, 24 Jun 2022 07:23:34 -0700 (PDT)
Received: from [192.168.3.110] (unknown [78.156.11.215]) by smtp.alvestrand.no (Postfix) with ESMTPSA id D83264856F; Fri, 24 Jun 2022 16:23:31 +0200 (CEST)
Message-ID: <648d2bfe-3b54-8cd8-a8cb-8b163d1a194a@alvestrand.no>
Date: Fri, 24 Jun 2022 16:23:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0
Content-Language: en-US
To: Carsten Bormann <cabo@tzi.org>, Ira McDonald <blueroofmusic@gmail.com>
Cc: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Applications and Real-Time Area Discussion <art@ietf.org>, Core WG mailing list <core@ietf.org>, draft-ietf-core-problem-details.all@ietf.org, last-call@ietf.org
References: <165511479760.19573.12671700576299137749@ietfa.amsl.com> <63D13796-758D-469B-AFA8-3050C9F87819@tzi.org> <dde9d36c-61e5-afcc-e15a-787c99d5fba9@it.aoyama.ac.jp> <CAN40gSuhSAOH3WRPETXU4s1468eXb_g-=sfWFmXXTvekEddqYQ@mail.gmail.com> <034DDF0F-FEF2-456B-B9ED-76B8F2B6C4BF@tzi.org>
From: Harald Alvestrand <harald@alvestrand.no>
In-Reply-To: <034DDF0F-FEF2-456B-B9ED-76B8F2B6C4BF@tzi.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/cXh8QPAg_Tunt3nGb1t-smHqews>
Subject: Re: [core] [Last-Call] [art] Artart last call review of draft-ietf-core-problem-details-05
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: Fri, 24 Jun 2022 14:23:41 -0000

Apologies for being slow in responding ....

Two main points:

- Tag 38 in its own document or not:
My worry isn't that RFCs go away. They don't.
My worry is instead that the problem-details doc will be updated. New 
RFC number. But no change to the tag 38 section.
It can't "obsolete" the old one, because there is no change to the tag 
38, and the reference still points to it.
It will either have to "update" it, or "obsolete" it and move all 
pointers to the definition for tag 38 to the new document. That is a 
pain that makes things hard to follow. A stable tag 38 document would be 
a greater benefit to the community.

- Language tag grammar:
If you want to have a copy of the grammar, that's pain on your head. I 
don't see the point, but your decision. If you want it, you need to add 
a prominent paragraph that says "This grammar represents the BCP XX 
grammar for language tags. If there are any differences found between 
this document and BCP XX, BCP XX is authoritative."
This is commonly done in ITU documents that describe things in two 
places, for instance. Not important which one is authoritative, very 
important that only one of them is.

I'm sure the rest is details, and can be dealt with.

Harald