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

[Carsten Bormann <[e-mail]>]

On 2022-06-24, at 16:23, Harald Alvestrand <[e-mail]> wrote:
> 
> Apologies for being slow in responding ....
> 
> Two main points:
> 
> - Tag 38 in its own document or not:
> My worry isn't that RFCs go away. They don't.
> My worry is instead that the problem-details doc will be updated. New RFC number. But no change to the tag 38 section.
> It can't "obsolete" the old one, because there is no change to the tag 38, and the reference still points to it.

That’s not what we do: 
When we obsolete an RFC by a new one, we update the pointer in the registry.
E.g., see all those pointers to RFC 8949 in [1], these pointed to RFC 7049 before (and one still does, fully knowing that RFC 7049 is obsoleted by RFC 8949).

[1]: https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml

> It will either have to "update" it, or "obsolete" it and move all pointers to the definition for tag 38 to the new document. That is a pain that makes things hard to follow. A stable tag 38 document would be a greater benefit to the community.

I think any opportunity to republish that tag38 part will be useful, if only to update the references.  So I really don’t see a problem.  Yes, people might have to adjust to the fact that the entry point for finding out something about CBOR tag xx is the registry [1], not an RFC number they might have memorized.

> - Language tag grammar:
> If you want to have a copy of the grammar, that's pain on your head. I don't see the point, but your decision. If you want it, you need to add a prominent paragraph that says "This grammar represents the BCP XX grammar for language tags. If there are any differences found between this document and BCP XX, BCP XX is authoritative."
> This is commonly done in ITU documents that describe things in two places, for instance. Not important which one is authoritative, very important that only one of them is.

As we have merged PR #40 [2], this argument is moot.
[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})* is already a rather lenient framework spec.  
Nothing else to do.  
(And, if i18n people come up with a language-tag that doesn’t fit this pretty wide envelope, we do have to update the RFC, but we probably do need to do this anyway.)

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

Grüße, Carsten