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

[Robert Sparks <[e-mail]>]

On 9/15/22 1:54 PM, Peter Saint-Andre via Rpat wrote:
> 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).

Speaking from instinct and a general knowledge of the code, not a dive 
into trying to make this particular change. This is likely to involve 
structural changes with subtle opportunities for unintended consequences 
to creep in - the existing codebase is made with an assumption that 
we'll need to change, and build appropriate tests around. It might be 
possible to _hack around_ the code that is in the way to let 9290 out 
quickly, but that will likely have more costs in the long run.

In short, I don't expect this is a "fix it in a one or two day 
turnaround" kind of thing.

>
> 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
>