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

["Martin J. Dürst" <[e-mail]>]

Hello Francesca, Carsten, others,

On 2022-07-05 02:00, Carsten Bormann wrote:
> Hi Francesca,
> 
> On 2022-07-04, at 18:06, Francesca Palombini <francesca.palombini=[e-mail]> wrote:
>>
>>   Updates to this document need to be clear about what is being altered,
> 
> This is getting into the “brush your teeth” twilight zone.

I already had a "brush your teeth" feeling when I saw the original text 
of the pull request in question. I thought that text was saying the 
obvious and was therefore unnecessary.

However, after looking at the example below, I became really concerned 
and had to radically change my opinion.

>> and ought not discard this appendix without publishing it as a separate document.
> 
> (As I mentioned in the github issue, we actually did this when we updated RFC 7049 to RFC 8949.  Tag 35 remains defined in RFC 7049, which as the CBOR specification is obsoleted by RFC 8949.  This is all transparent via the tag registry, which is why the existing text proposal points to it.

Looking at the RFCs, it's not that RFC 8949 updated RFC 7049. RFC 8949 
*obsoleted* RFC 7049. The IANA registry for CBOR Tags now points at an 
obsoleted document.

I hope I'm not alone in thinking that this is an unacceptable situation. 
My understanding of *obsolete* is that the whole of the document is no 
longer relevant. I think that's in line with the general understanding 
of the word "obsolete".

If somebody has a pointer to an official IETF definition of "obsoletes" 
that differs from this general understanding, I'd appreciate it.


> Yes, we discussed this quite a bit as a WG.)

If you discussed leaving dangling references to obsolete documents in 
the IANA registry, and came to the conclusion above, I think the IESG or 
IANA or somebody else should clearly have stopped you.

You don't free memory that still has active pointers to it, and you 
don't obsolete a document that still has active pointers to it.


> I don’t think this document *can* prevent us from at some point deciding we want to stop updating Tag 38 and address its use cases by something shiny and new — even if this seems a bit far-fetched now.  It certainly shouldn’t try to.

I don't think that's the issue at hand. CBOR has all the mechanisms to 
define some new kind of Tag for human language strings if that's seen as 
a good idea.

There are two other things we have to worry more:

1) Even if a new, better idea comes along, we can't obsolete the 
definition of Tag 38 because there's still data out there with Tag 38.

2) If core-problems needs to be updated, and it's done in the way CBOR 
was "updated" in RFC 8949, leaving a dangling reference from the IANA 
CBOR Tag registry to an *obsoleted* first version of core-problems, then 
we easily might get into the following situation:
- CBOR "user" to I18N expert: What would you use for
   human language strings in CBOR?
- I18N expert to CBOR user: Go for Tag 38, that will do it.
- CBOR "user" to I18N expert: That's in RFC XXXX, so it's obsolete.
- I18N expert to CBOR user: Well, actually not.
- CBOR "user" to I18N expert: Should I believe you or the RFC editor?

It often takes quite some time and effort to talk people into doing the 
right thing for I18N. We don't want this to be more difficult and 
tedious than necessary because of references to *obsolete* documents.


> So half of this addition isn’t needed, and the other half isn’t quite the right recommendation about the evolution of this document.

My conclusion now is that while the specific language may benefit from 
some tweaking, some strong statements are clearly needed because some 
people indeed don't know how to brush their teeth (or manage references 
to documents).

Regards,    Martin.