Re: [Rpat] [Xml-sg-cmt] [AD] <u>: Re: AUTH48: RFC-to-be 9290 <draft-ietf-core-problem-details-08> for your review

[Peter Saint-Andre <[e-mail]>]

On 9/13/22 5:11 AM, Carsten Bormann wrote:
> 
>> I’ve reread RFC 7997
> 
> Thank you!
A message from Carsten offlist has prompted me to re-read this thread, 
so I'm replying to this message.

>>> Heather's indication 20 Jul 2019: Isn't this already required by 7997??
> 
> That is really the point here — the RPC should have tools to look at the use of beyond-ASCII characters in the documents they receive.

Yes, they should.

> <u plays an important role here, as it communicates the intent by the author.

In an ideal world, I don't think we'd need the <u> element (I create 
HTML files all the time putting non-ASCII text wherever I please), but I 
don't see that it causes any harm.

> Once a document is is RFC mode, this work presumably has been done, and any further interference by xml2rfc is form 27B/6 type bureaucracy/paternalism.

I don't know what that means.

> (If you want to retain <u, which is not actually needed any more as the intent has been communicated, you simply have to allow values for the “format” attributes that do not generate gratuitous and unwanted additions.)
> 
> As an aside, xml2rfc has zero bureaucracy on the contents of <artwork.
> This creates the workaround of putting everything beyond-ASCII into <artwork.
> This destroys the formatting, but otherwise works well.
> The present of this (damaging, but workable) workaround serves to further highlight the foolishness of the current situation.
> 
> None of this is required by RFC 7997.

Likely not.

Carsten, in his offlist message, mentioned that we simply have an 
xml2rfc bug and it should be fixed. I'm not sure which bug this is.

As I understood the state of play, the authors wanted RFC 9290 published 
as soon as possible. This is partly what drove me to suggest that we not 
try to make changes to xml2rfc in order to get this document published, 
since I *thought* we had agreement that the <artwork> workaround was 
"good enough". However, we seem to be going back on forth on whether it 
really *is* good enough.

If there's a simple bugfix then let's identify what it is, figure out 
how much time it would take, and understand the implications (if any).

I've been advocating for internationalized text in RFCs for many years 
(and authored some of the first RFCs to use it), so I am by no means 
opposed to progress!

However, with all that said, I always worry about anything related to 
i18n because there are so many ways to go astray. Thus I have been 
counseling that we be cautious and understand any implications (and 
that's not necessarily consistent with "we need to publish this RFC ASAP").

Peter