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

John C Klensin <john-ietf@jck.com> Fri, 24 June 2022 15:16 UTC

Return-Path: <john-ietf@jck.com>
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 B3623C15D484; Fri, 24 Jun 2022 08:16:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 yyDBBd5JDtL5; Fri, 24 Jun 2022 08:16:46 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04DCC15D867; Fri, 24 Jun 2022 08:15:19 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1o4l1Z-000B5v-H6; Fri, 24 Jun 2022 11:15:09 -0400
Date: Fri, 24 Jun 2022 11:15:04 -0400
From: John C Klensin <john-ietf@jck.com>
To: Ira McDonald <blueroofmusic@gmail.com>, tom petch <daedulus@btconnect.com>
cc: Carsten Bormann <cabo@tzi.org>, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Harald Alvestrand <harald@alvestrand.no>, 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
Message-ID: <66AB2D10BCCF16DD7C9AC4F1@PSB>
In-Reply-To: <CAN40gSsg+nbDejC2d34wpLhecUnGTEZL6RAHjT5UUKTJWRS7Uw@mail.gmail.com>
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> <CAN40gSuGJOChjAY9fFD5Gwqn9CaLH09-m5MKb5Gfg8HH9WYjvA@mail.gmail.com> <0359E066-79F3-4AAB-92A5-30B5E01D16CE@tzi.org> <CAN40gSuR12WE=NC-MqGvCX1z+XNVn+5X94VFH1qHE373gbQR_w@mail.gmail.com> <62B57BC0.9080706@btconnect.com> <CAN40gSsg+nbDejC2d34wpLhecUnGTEZL6RAHjT5UUKTJWRS7Uw@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/BolPJcUkGSKAfIw-25uKI8Yn3No>
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 15:16:46 -0000


--On Friday, June 24, 2022 06:20 -0400 Ira McDonald
<blueroofmusic@gmail.com> wrote:

>...
> CORE - please delete *all* of your CDDL details for language
> tags and just use one of the several excellent libraries that
> correctly parse language tags, when needed.
>...

Two problems with that.  The general one is that IETF standards
track specs rarely (I wish I could say "never") say "go use that
library" if only because libraries change and are hence not
stable references.  If this were intended to be an Informational
document, then maybe.  But, as a Proposed Standard, I don't
think that flies.  The one more specific to this spec is that,
because there is no standard way to specify directionality in a
language tag itself, either that functionality gets lost (and
must hence still be included in those CDDL details) or we need
to extend BCP 47 to include a language tag specification
mechanism.  The CORE effort explicitly decided to not use/depend
on such a change and no one (yet) has challenged that decision.
There are also substantive arguments why such an addition would
not be a good idea.

    john


If those libraries actually