Hi Martin,
On 10/29/25 9:58 PM, Martin J. Dürst wrote:
Hello Jean, others,
Just some small additional comments below inline.
On 2025-10-30 07:48, Jean Mahoney wrote:
Hi all,
Given the amount of feedback already posted here, apologies if I'm
repeating anything --
Section 3:
Characters in an RFC will generally appear in Normalization Form C
(NFC) as defined in [UnicodeNorm]. If the RFC would be more correct
and more understandable with particular characters not in NFC, the
RPC can use unnormalized text. In such a case, a text note should be
included to describe why unnormalized text was used.
Operational notes: the RPC would need a tool to assess if NFC was
used, or would they rely on the authors and stream to add a note to
the document before it enters the queue?
It should not be too difficult to integrate such a test into the RPC
process, either with a separate tool or with an addition to an existing
tool. All major programming languages (including Python, which I
understand the RPC is mostly using) provide functionality or have
libraries for converting a text to NFC. Please feel free to contact me
for further details.
[JM] Thanks! The RPC currently has a script that looks for non-ASCII
characters and another tool that we use for inspecting Unicode, which
does show decomposition, but doesn't say anything about NFC. I'll follow
up with you separately regarding tool pointers.
Nit: Change "text note" to "note"
Section 3.1:
The RPC policy should be that authors'
preferences for display of their names be honored.
Nit: This could be trimmed to say "Authors' preferences for display
of their names should be honored."
Section 3.1:
Company names and geographic names generally do not need ASCII
interpretations, but they can be included at the discretion of the
author and the RPC.
Current RPC operational procedure: Postal addresses are not required
in RFCs; however, if one is provided, the RPC will update a country
name to match the English short name for the country found here:
https:// www.iso.org/obp/ui/#search. This is specified in the RFC
Style Guide:
https://www.rfc-editor.org/rfc/rfc7322#section-4.12
I believe there was already feedback to also include the ASCII
equivalent here.
To be exact, this should be a Latin script equivalent, not an ASCII
equivalent.
[JM] Ack
Section 3.2:
RFCs are often displayed on systems that use only black and white,
particularly when printed.
Fairly sure most screens show color, but printers typically print in
gray scale. We do want to support clear text when printing.
Side note to Paul: Didn't spot this earlier, but "displayed when
printed" feels a bit awkward, so what about e.g.
"RFCs may be viewed using only black and white or grayscale,
particularly when printed."
Operational note: The RPC would need to assess whether any color used
in examples printed well in black and white.
I think that will depend on what printer is used. I don't think the RPC
can do too much here. What you should do is to check whether the RFC is
still understandable even without the colors.
Color is only mentioned with regard to examples, which seems to be a
good limitation. The RPC has concerns about authors choosing color to
emphasize normative text (e.g., MUST NOT in red) or format terms
(e.g., in both fixed-width font and blue).
I hope we can agree that this is an issue for the RPC to decide, and to
mention in the respective Web page(s) or an update to the Style Guide if
necessary.
[JM] Thanks!
Jean
Section 3.2:
If so, those examples need to also include the "U+NNNN"
syntax.
It's been covered in the thread, but providing names for the Unicode
characters in addition to the U+ notation would be helpful to the reader.
Yes, in addition or instead of.
Regards, Martin.
Best regards,
Jean
--
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
