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

Carsten Bormann <cabo@tzi.org> Fri, 24 June 2022 09:21 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE103C15CF2D; Fri, 24 Jun 2022 02:21:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=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 qP3OcI1kalN2; Fri, 24 Jun 2022 02:21:01 -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 64175C157B3F; Fri, 24 Jun 2022 02:21:01 -0700 (PDT)
Received: from [192.168.217.118] (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 4LTs6y5lFszDCcp; Fri, 24 Jun 2022 11:20:58 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <6602a838-0d44-482c-2daa-47755db5af69@it.aoyama.ac.jp>
Date: Fri, 24 Jun 2022 11:20:58 +0200
Cc: Ira McDonald <blueroofmusic@gmail.com>, 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
X-Mao-Original-Outgoing-Id: 677755258.259275-4f4bdca617f35bc7abd8a71ed8c1adbf
Content-Transfer-Encoding: quoted-printable
Message-Id: <68C78F7D-6BC7-4F64-AC5B-9BE1A65F6B04@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> <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> <6602a838-0d44-482c-2daa-47755db5af69@it.aoyama.ac.jp>
To: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/7I_0uOU1zmKs6B3G0-P9OEwjHWw>
Subject: Re: [art] [Last-Call] Artart last call review of draft-ietf-core-problem-details-05
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jun 2022 09:21:08 -0000

Hi Martin,

thank you for the quick response.  I gather your reply means that we can go ahead with the pull request [1] as proposed now.

[1]: https://github.com/core-wg/core-problem-details/pull/40

So the following points are just for potential future documents in this space:

> Well, you actually didn't just make a copy. You replaced a production name ('grandfathered' -> 'legacy’),

Yes.  Time marches on…
(No semantic change.)

> you removed the comments from the 'irregular' and 'regular' productions to make them take less space,

(No semantic change.)

> and you added productions for ALPHA and DIGIT.

Of course; the ABNF is incomplete without these snippets from RFC 5234, so this was a required addition.
(No change from the semantics as I would expect they were intended — the import is only implied in RFC 5646.)

> I don't think you introduced any errors, but it's changes like these that may start a slippery slope or introduce subtle errors.

Indeed; getting these changes/additions (if required, as with ALPHA/DIGIT) right is likely to be one interesting job for the RFC-referencing mechanism in CDDL 2.0.

>> What got us to now propose blunting that grammar is the strong impression that there may be less consensus about the grammar defined by RFC 5646 than we thought.  So it seems the grammar in RFC 5646 is fragile, not the act of copying it out...
> 
> There's a wide gap between "fragile" and "not set in stone". The grammar in RFC 5646 is not set in stone, but to call it "fragile" is overstating the issue.

In other specifications, we often distinguish a “framework” grammar from a “validation” grammar, where the first one is the total envelope for extensions, and the second one has the current structure (so that one doesn’t accidentally include extensions).

PR #40 is essentially switching from a validation to a framework grammar (which we steal from the XML spec, as suggested). [The validation grammar is enshrined in -06, which can be dug out by implementers or if we ever want to use it in another document.]

CDDL also is able to do both functions within the same grammar (using RFC 9165 “.feature”), but the somewhat anaphylactic reaction to using the RFC 5646 ABNF indicated to me that this wasn’t the direction we wanted to take here.

> But what's important is that technologies, in the IETF as well as elsewhere, should only be linked as strongly as needed, not more strongly. That way, technology can evolve more independently and freely, with less needs for implementation or specification changes.

That is easier to do if the referenced specification indicates which parts of it are intended to be malleable (and which are “invariants”, as in RFC 8999).  I read RFC 5646 as exposing a clear set of extension points so there would not be a need to change the grammar, but I have now learned to read this differently.

> [One of the main places where the I18N community learned this was that in the mid 1990es, at one point everybody was very happy to get certain specs (e.g. HTML) to cite Unicode. But when a year later Unicode was updated, we started to get questions about whether the spec in question also could be used with the newly added characters. The answer should have been "yes, of course", but the specs were not written that way. After hashing things out, Unicode now provides reference examples for both versioned and versionless references (see https://www.unicode.org/versions/index.html#References).]

Definitely a problem that we have with every single normative reference to a document that still has life in it…

>> https://github.com/core-wg/core-problem-details/pull/40/commits/bbe72e2
>> (I’m making a point about copying here as I believe copying out snippets of CDDL from RFCs and other specifications will be a significant part of CDDL 2.0.)
> 
> I don't know enough about CDDL to be able to say whether that is a good thing or not.

It’s intended to be a good thing, but it is nonetheless hard to get right (see one example above).

Thank you again for your input!

Grüße, Carsten