--On Monday, October 27, 2025 17:49 +0000 Paul Hoffman <[email protected]> wrote:
> On Oct 27, 2025, at 8:42 AM, Russ Housley <[email protected]> > wrote: >> >> Dear RSWG: >> >> Section 3, 1st para says: >> >> The policy for the RFC Series is that all displayable text is >> allowed as long as the reader of an RFC can interpret that text. >> >> The closest thing in RFC 7997 appears in Section 6, which says: >> >> The ability to use non-ASCII characters in RFCs in a clear and >> consistent manner will improve the ability to describe >> internationalized protocols and will recognize the diversity of >> authors. However, the goal of readability will override the use >> of non-ASCII characters within the text. >> >> I find the text in RFC 7997 to be more clear policy language; >> however, I think two changes are appropriate: >> >> 1) It should recognize the diversity of both authors and readers. >> 2) The final sentence should say that the readability takes >> priority over the character choice. > > Earlier discussion indicated that we are much less concerned about > the authors than of readers. It is up to the streams to tell the > RPC if an author's requirements for particular displayable text > should be considered. Hmm. If it comes to an actual choice, I agree that, in the long term, readers are more important than authors. That said, we've had repeated discussions about delays in RFC Editing and the non-transparency of changes made after IESG approval in the IETF stream (and equivalent for the others). I think those things argue for having documents as complete as possible before going into RPC processing and having decisions the RPC will make be predictable to authors very early in the authoring process, not turn into surprises during Last Call (or equivalent) or later. Even using your formulation, the streams should know which displayable text (characters and strings of them) are likely to be issues so that they can have that conversation with the RPC in a timely fashion rather than assuming things will go through smoothly because the author asserts the text is displayable. > Isn't this a place where, again, we can let the RPC make their best > judgement? The current sentence doesn't (or shouldn't) restrict > them. But the RPC best judgment should be as informed as possible and authors, approval bodies, and groups such as IETF WGs responsible for the documents should not be surprised by that judgment ... and the document does not say, or even hint at, that. The Stream Managers, in particular, should not be making up their own per-stream rules if those rules would cause the RPC to insist on changes to a document or even to force a conversation about document contents if that is avoidable. If the RPC identifies what can be handled easily and the streams want to argue for something else, that is another matter entirely. I don't see anyone here (especially not me) questioning the RPC using their best judgment once a document gets to them although, again, I worry about that judgment being well-informed, partially about issues that might affect readability, if we really believe "all displayable text" anywhere an author feels like putting it. However, I see authors (and streams) being important in this matter. avoiding unnecessarily surprising them is key to that, probably even to the extent Carsten suggested of surprises convincing some people that they don't want to take on author roles. If we care about authors at all, then "no unnecessary surprises, especially late ones" is an important principle whether the document spells that out or not. john -- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
