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

Thomas Fossati <tho.ietf@gmail.com> Wed, 29 June 2022 16:48 UTC

Return-Path: <tho.ietf@gmail.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 1EBB4C147921; Wed, 29 Jun 2022 09:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 zal8_sC4yCgH; Wed, 29 Jun 2022 09:48:26 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 9D1C1C14F74C; Wed, 29 Jun 2022 09:48:26 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id bi22-20020a05600c3d9600b003a04de22ab6so5056795wmb.1; Wed, 29 Jun 2022 09:48:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yXnaue3/rJMf2L5PVQb4KkGJ2Hnmiv+O+WDUNtMJSIs=; b=Yb3RSnCqKzfdB1mke8+Xmm2Wxam80kl+zFux7oKxgJWZzOxH8DAz2uv6H7Jq9qxjv+ sa7V+4sb9Re6E02tzq3GI/IvVlgXS0cbovmN7uKEjiBaf126frxddVjUqvnlFTTXQLLK xYXMSYxTEwgzzrTbvV5oStqegtwBANtfwHn0Tj1auf25kLdJmmwbqOsD+p3ZQ2206Ku5 j2JF+ukfFH5y5Kfsd+ATtlw/BE59OWKjARSmcCvSZC9vDjCbXE9ffL0mjMQNLNzVtB2v u5lEg/Uf6P1+aYODcHl+xO01H+wobt8o/NokLQKr5FzAnBcyGTdGxj9Fy24/9Wz8FGaL /bwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yXnaue3/rJMf2L5PVQb4KkGJ2Hnmiv+O+WDUNtMJSIs=; b=2EUXPLbF84Rrzlux4xrarxQ+xQ689buxkVTgGJyI365D1ECGrmIQINdfD/ZB4tAgNj N9Oi6MbCH3H8ZOKjcqKuz7j58k1+0znH128KWyye5c6vvwrE4TUYU7Nx4h4NDoTPhRUD PWGOwgajRve7hMLrvIYHYQVkeY4nPEQvnl/r33Afp3/AATmEum+4E1fKbZcoxCDZ00Nl g+qNKPfeESU1OwkxXnriafSaVMRzmNRFKazsV549luQvoD1EzJHP6KmaE4t7u+KCVdIP MGISxSST1hxUV/85bckp1kr6pk1n1edYFbA3l6R5uWzPZ0DryMa9mNDC1TKMTK5T11nB Uw8A==
X-Gm-Message-State: AJIora+opZzeipJmQyfhTH+B43YrZWT/3TtVfmf/I3GOqK7UYvcIpPNQ pcGl42HVLmaUEkV1ZcK+xCERg6VAAgCmetl6afw=
X-Google-Smtp-Source: AGRyM1t5KAnEMj04pvMVQoUdDU1/HKqXo457zWnosNei6ZRFhgrOhZrvknDmToMNIzH2FaH5gBrinJuU6lgEAdzy7ZQ=
X-Received: by 2002:a7b:c196:0:b0:3a0:3d46:4620 with SMTP id y22-20020a7bc196000000b003a03d464620mr6787342wmi.26.1656521304426; Wed, 29 Jun 2022 09:48:24 -0700 (PDT)
MIME-Version: 1.0
References: <165511479760.19573.12671700576299137749@ietfa.amsl.com> <63D13796-758D-469B-AFA8-3050C9F87819@tzi.org> <AS1PR07MB86169230F0D43E82CB2BCA1698AC9@AS1PR07MB8616.eurprd07.prod.outlook.com>
In-Reply-To: <AS1PR07MB86169230F0D43E82CB2BCA1698AC9@AS1PR07MB8616.eurprd07.prod.outlook.com>
From: Thomas Fossati <tho.ietf@gmail.com>
Date: Wed, 29 Jun 2022 17:48:11 +0100
Message-ID: <CAObGJnO7kdhO6tzLx2GZH3FVj2iedCU=fWH-w608OAStMMGeLA@mail.gmail.com>
To: Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org>
Cc: Carsten Bormann <cabo@tzi.org>, Harald Alvestrand <harald@alvestrand.no>, "art@ietf.org" <art@ietf.org>, "core@ietf.org" <core@ietf.org>, "draft-ietf-core-problem-details.all@ietf.org" <draft-ietf-core-problem-details.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/dwOPjaZc4tSD0JXpTt5brJPKKLk>
Subject: Re: [core] [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: Wed, 29 Jun 2022 16:48:27 -0000

Hi Francesca,

On Thu, Jun 16, 2022 at 2:33 PM Francesca Palombini
<francesca.palombini=40ericsson.com@dmarc.ietf.org> wrote:
> [...] you do suggest this document be split in two, the error format
> and the internationalized string format. I considered that too, but
> seeing that the CBOR tag is already registered, and this document
> merely updates that definition and the reference, I evaluated that it
> was ok to have it in one document; moreover in this way you have both
> the tag and one example of the tag in usage in the same doc, I think
> that is valuable. If you think Appendix is considered less important,
> I would not object to moving it into a main section of the document.

I've been silent on this thread because I don't have the
internationalisation expertise to be able to debate with competence on
the finer points.  So I stood back while trying to learn a thing or two
in the process :-)

However, on this more procedural / editorial point I'd like to chime in
as co-editor of the spec to say that I very much agree with all the
points you make above about keeping the two things in one lump.  Also,
I'd be happy to move Tag38 from the appendix to a "proper" section if
that helps increasing its "status", though I don't think that'd make a
substantial difference.

In hindsight, I reckon that it may have been (much) better to split the
work and progress it in parallel with the right communities.  This is a
lesson I've learned the hard way here and I'm sure I have now developed
the immune response that will allow me to identify the early signals to
make sure similar patterns do not resurface.  But we can't rewrite the
past, so here we are at the end of a pretty messy process that we still
managed to make work thanks to the crucial help and active engagement
of wonderful experts, which I consider a success of this organisation.

That said I don't think the risks that Harald and Martin see with
bundling Tag38 and PD together WRT any future update process are going
to hurt us (or our children's children) because ultimately the CBOR tag
registry is the SOA here and the right RFC will be dispatched from
there.  Personally, I am open to the suggestion made by John to add some
clarifying text to that purpose.

Cheers and thanks all for pushing me up this steep but enjoyable
learning curve.
--
Thomas