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

[Ira McDonald <[e-mail]>]

Hi Carsten,

OK - you need to get this CORE document published quickly.

But I still think that detailed CDDL would be a long-term mistake, for the
reason
that Martin cited - i.e., copying/transforming grammars among RFCs is
fragile.

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*

*Chair - SAE Trust Anchors and Authentication TF*
*Co-Chair - TCG Trusted Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*








*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: [e-mail]
<[e-mail]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*


On Thu, Jun 23, 2022 at 7:03 AM Carsten Bormann <[e-mail]> wrote:

> Hi Ira,
>
> before we send our detailed response for his excellent comments to Martin,
> I would like to set an accent here.
>
> > I agree that a separate draft for CBOR language tags would be
> preferable, to
> > raise the visibility of internationalization in other RFCs and in other
> SDOs.
>
> Frankly, raising visibility for internationalization requirements is not
> our job here.  Making sure that these requirements are addressed in our
> documents is, and a nice side effect is that more people will learn about
> them in the process.
>
> We saw that we have a protocol that is likely to often have at least one,
> but rarely two constrained nodes talk to each other (hence the extended
> validation potentials for less-constrained nodes — but not every node has
> to validate on the fly!).
> We wanted to use existing tag 38 for this, but noted the lack of the
> indication of a writing direction.
> This was fixed, at considerable peril of delaying the process.
>
> Tag 38 does not have the intention to take over all forms of
> human-readable strings; as we noted, expressing the additional data that
> need to go with a Unicode string *is* an active subject of discussion among
> the experts (*).  (Our spec immediately triggered discussion on how to
> solve this in an even more general way, which is a great discussion the
> results of which we cannot wait for.)
>
> > I suggest that CORE or other IETF WGs specifically focused on constrained
> > devices are the wrong places to write and publish such a language tag
> RFC,
> > because CBOR is certainly *not* primarily for constrained devices
> anymore.
>
> It is true that tag 38 can be versatile enough to be used outside the
> constrained protocol space (i.e., communication that has to arrange for the
> possibility of at least one constrained peer).  But that was not the
> intention of this draft.  The intention was to create a concise problem
> details format, and in the process we noticed that we have to fix up
> registered tag 38 a bit, because some of the content of the problem details
> format is human-readable.
>
> > I would prefer to see the separate RFC developed in the CBOR WG.
>
> I’d prefer to get this document published!
>
> We accelerated the work on this to get it done within the 3GPP rhythm, and
> are grateful for a lot of feedback that allowed us to make this a better
> document really fast.
> Opening up a debate about life, the universe, and internationalization at
> this time is not going to help with that.
>
> Or, in other words: There is indeed a good argument for bottom-up projects
> that cover a certain problem statement (but which still should be driven by
> requirements of actual protocols!), but this is not one of them.
>
> > In many IETF WGs (RATS, SACM, TEEP, etc.) and many other SDOs, CBOR
> > is being heavily used for the entire spectrum of computing devices
> (especially
> > routers and switches for telecom networks and servers for enterprise
> networks).
> > CBOR is simply a better mousetrap, IMO.
>
> I certainly agree with that.
>
> And I’m looking forward to doing the extensive work that will be needed to
> complete [1].  But not for the concise problem details specification.
>
> Grüße, Carsten
>
> (*) And, while not being one of the foremost experts here, I still have a
> chip on the table [1], which needs to be revived and could be a home for
> more considerations on human-readable text.
> [1]:
> https://datatracker.ietf.org/doc/draft-bormann-dispatch-modern-network-unicode/
>
>