Re: [xml2rfc] Evolving RFC 7997 (Re: [Tools-discuss] [Rfc-markdown] Move beyond RFC 7997)

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

Hello Carsten,

On 2023-01-21 09:49, Carsten Bormann wrote:
> Hi Martin,
> 
> I don’t really like to defy Robert’s request for a break in this thread, but you do raise a subject not yet covered, which is how we should evolve RFC 7997.

Sorry, I didn't see that, and can't find it. It's possible that this 
went only to one of the lists and not the others.

> Ultimately, this discussion needs to run in RSWG, but we can prepare for that with a tools perspective.
> 
>> On 21. Jan 2023, at 01:08, Martin J. Dürst <[e-mail]> wrote:
>>
>> […]
>>
>> My guess is that Carsten meant that RFC 7997 didn't go far enough.
> 
> Well, RFC 7997 was a weird attempt to slice up the new cake while forbidding you to eat most of the slices.
> It sure went too far in this forbidding…
> It’s really hard for me to look at this document and consider we (collectively) were at this state of mind nearly a decade ago.
> Thus can only considered from context: After nearly 50 years of pure ASCII, going Unicode was a radical step.
> People though we’d need to cushion the impact.
> Which is probably true, but not to that level.
> The wording sounds like a poor compromise between the people that did want to enter this century and those who simply wanted to stick with ASCII.

 From my point of view, we got the most important things in 
(names/addresses and examples), but it was definitely a tough compromise.

> After another decade of device evolution, the argument that people’s devices might not understand Unicode is pretty much moot now.

It was pretty much moot in the last round, but quite a few people didn't 
understand that then. One of the problems is that people don't read text 
being conscious about each and every actual letter, so they may easily 
miss things that actually already work in front of their eyes.

> (Yes, one can do weird things in Unicode, just like one could use backspaces and bare CRs in ASCII.
> Let’s disregard weird things for now, and just talk about normal Unicode use.
> Some guidance may be needed for what is normal use.
> We may want to put up guidance such as “use NFC as much as possible”.
> For general weirdness, the rule “I know it when I see it” is much better than putting up some hard boundaries based on lack of imagination.)
> 
>> - Formulæ: Using Greek letters, symbols,... in formulæ would make many
>>   of them easier to understand. But RFC　7997 currently doesn't allow
>>   that. I personally would fully support that.
> 
> Yes, this has to be done.
> Preferably before some I-Ds that rely on this happening get published as RFCs.
> 
>> - High quality quotes, hyphens, and the like. I think this is a
>>   worthwhile goal, but it requires quite a bit of thought because this
>>   is an area where differences between characters are indeed sometimes
>>   minuscule, and not all authors are alert enough to these differences.
> 
> That is fine.  Let the authors determine the level of quality they want to achieve.
> Some of our RFCs are not much more than office memos, and typewriter look is fine for those :-)

That's an interesting point of view. It definitely has some policy 
implications because it goes against the uniform appearance of the 
series (imagine a scientific journal doing that). But that aspect needs 
to be discussed in the RSWG. What I'm going to wonder here is whether 
that would simplify or complicate tools and the job of the RFC.

My guess is that both tools and the RFC's job would become more 
complicated, because we wouldn't want a "free for all" (e.g. author 
using French quotation marks in odd sections, and Swedish ones in even 
sections; see e.g. 
https://jakubmarian.com/map-of-quotation-marks-in-european-languages/, 
although your mileage may vary).

So we would need a few (e.g. 2) styles and a way to declare intent 
(which style does the author choose) and tools to help the authors get 
it (close to) right and to help the RFC check it.

>>   Also, we'd need to have (at least a pointer to) a style guide, we
>>   don't want different RFCs to use different quotation conventions.
> 
> I do not agree with this at all.
> Just as with British English: If authors want typewriter quotes, that’s fine.
> 
>>   While I think that in general for non-ASCII characters (examples,
>>   formulæ,...), the authors/editors/reviewers/approvers will do 95%
>>   of the job of making sure they use the right characters, and the
>>   RPC will just do an additional check, I fully expect that some
>>   authors/editors (including probably myself) will submit rfcs-to-be
>>   with ASCII quotes and hyphens, and will rely on the RPC to fix
>>   that.
> 
> That is another way to approach this that is fine *if authors request that*.
> (Tools like kramdown-rfc will do 95 % of the work here.

It's good to know that there's already tool support around.

> It is not without irony that we had to disable typography support by default for v3!
> v2 allowed using normal quotes and dashes and down-translated this for ASCII plaintext, while rendering the real thing in HTML.)

Does that mean that there are RFCs in HTML that actually use non-ASCII 
quotes/dashes? Can you give an example?

Regards,   Martin.

>> Anyway, for the two points above, and possibly others, we need a policy change, and so we need to move the discussion to the RSWG. I hope we can do that soon.
> 
> Yes, but maybe we can discuss the tools side of how we would support such a transition here, first, so we are prepared to deal with arguments of the form “the tools can’t do that”.
> 
> Grüße, Carsten
>