--On Friday, October 31, 2025 17:26 +0900 "Martin J. Dürst"
<[email protected]> wrote:
>...
Just the things on which I have further comments that might
conceivably be useful.
>...
>> 3. Whether the policy is aimed "for the reader" or "for the
>> author": Consensus seems to me that the doc should say something
>> about authors. Some explicit support from Brian's suggestion in
>> <https://
>> mailarchive.ietf.org/arch/msg/rswg/zF2-lBMYYDPj-igQivMo3O5ivWo>.
>> Might also want something saying, "The RPC style guide will
>> define which characters authors may use and how."
>
> As long as the style guide is an RFC, or something with similar
> change rate, I think this is way too inflexible. We already have
> successful use of non-ASCII characters at least in the Latin script
> that where used without any explicit guidance.
I think the plan is to make the Style Guide more of a web page or set
of them, rather than publishing it as an RFC. I hope the RPC (or
Style Guide approval mechanism if something else) will recognize that
too-frequent changes can cause general confusion and harm to authors
but, otherwise, I agree. More about this below.
>> 7. Distinguishing "individual characters" from "strings" in
>> section 3 ff: No particular takers on this (other than JCK
>> himself who posted about it). Would like to hear more. (Chair hat
>> off: Sounds like something for the style guide, not policy.)
>
> My take is that JCK has a point, but that having separate sections
> on individual characters and on strings is most probably overkill.
> I'd propose that we solidify the content, and then give it another
> reading to tweak things so that they aren't wrong (just
> occasionally changing "character" to "characters" or so may go a
> long way).
If the document were consistent about that, this would work for me.
And, again, I have no problem pushing the whole discussion to the
Style Manual as long as (as you indicated) it isn't too static _and_
whatever is said in this document not be misleading or confuse
things. For this case in particular, I'd rather see the whole
name/example distinction go to the Style Guide because there are some
special nuances there, ones that might evolve as understanding
increases.
>> 8. JCK's 4(a) - 4(c) on NFC, directionality, naming: No discussion
>> so far, but again, with chair hat off, this sounds like style
>> guide material, not policy.
>
> In particular with respect to (4c), I'd argue that there's *nobody*
> with a name such as Cyrillic "раураӏ".
>
> (Just in case there were, it would be required to also have a Latin
> script equivalent (most probably something like "Raupai"), at which
> point it would be clear that it's not Latin script, and any
> interested user could cut-and-paste it into a tool that would
> reveal the exact code points if needed.)
The Cyrillic paypal example was chosen, not because it was a
realistic name but because it is extremely familiar to many of those
who might be reading this discussion and/or the final document.
However, and probably sadly, you have just made my point (or three of
them):
(i) The document says "names", While it distinguishes
between names of authors and names of companies and
geographic entities, it does not draw further distinctions.
I.e., it does not clearly distinguish among, e.g., personal
(or family, etc.) names of authors or editors (of documents
and maybe in references), organization names in those
contexts, section titles and document titles in references,
or even names in examples or running text or quotations.
Increasingly broad readings of "names" along those lines
increase the odds of just such a string appearing. Such
lack of precision abut the category is a problem and, in
particular, "раураӏ" (with or without something like
"Raurai") might plausibly occur in some of them, even if not
the first. "paypal" (ASCII) is certainly a company name and
"раураӏ" (Cyrillic) might be too, but the document
makes the presence or absence of an ASCII interpretation a
matter of discretion of the author (I trust the RPC there,
but your separate comments suggests that you see the point).
In particular, see the overlap between this and your comment
about company names in your other note, so we might be close
to agreement on the subject after all.
(ii) A construction like "name (something)" does not imply
only "'name' not in Latin script" but could also be, e.g.,
"'string that might be a name' followed by a pronunciation
hint or explanation". Consider, e.g., "King Charles II (of
France)". Because many people get the pronunciation wrong, I
might even want to write "Klensin" in text followed by a
phonetic alphabet presentation. So that construction does
not automatically imply that the name is other than Latin
script.
(iii) "раураӏ" (or, worse, "раүраӏ") is immediately
recognizable as Cyrillic (or not) depending on
the renderer's choice of display type styles or
fonts (something over which we have little control) and, even
then, far more easily by those are sensitive to such things
than those who are not (reader distinctions over which we
have even less control). Obvious to you and me might not be
obvious to a reader and, depending on the script, might not
even be obvious to the RPC.
And, of course, none of that addresses the directionality issues.
All of this could be taken as strong arguments for moving far more of
the discussion to the Style Guide but then to be sure this document
and the Style Guide do not diverge (or even appear to do so) and
probably to include explicit pointers to the Style Guide for details.
>> 9. JCK's 5 on making a list of scripts and languages: No
>> discussion. Silence is not a good basis on which to judge
>> consensus.
>
> Already said so above, but I think this makes things too
> inflexible. If the RPC really feels it would help them, they can
> always start such a list, but there's also a danger this would be
> interpreted as exclusionary (somebody claiming somewhere "RFCs can
> be written by Chinese and Japanese, but not Koreans" just because
> the RPC didn't yet have a case of a Korean author and therefore
> didn't yet put Korean/Hangul in the list).
I'm not sure I understand the lack of flexibility you are seeing. I
did not propose making that list part of an RFC, nor even of a more
easily updated Style Guide, but simply a list, updated whenever the
RPC considers that appropriate. Under any circumstances I can easily
imagine, it would be updated only by adding languages and/or scripts,
not removing them (unless, I suppose, a language or script about
which they thought they were confident turned out to be more
problematic than they had assumed, but, while I wouldn't want to
prohibit that, I'd expect it to be so rare as to be irrelevant). You
seem to have inferred a "you can't write text in something that is
not on the list" situation. I never intended that. Instead, think
about it as a convenience for authors and reviewers, especially
document shepherds. If a language/script combination, or, where
relevant, just a script, are on the list, people in the document
development process can have reasonable assurance that the text will
be handled smoothly and efficiently. If it isn't, then that should
serve as a recommendation to consult with the RPC earlier in the
process than handoff from the stream. If that recommendation were
ignored, the authors and stream should expect the possibility of
delays in processing as the RPC checks the text strings and finds
advice about them if needed.
Of course, if that function is not explained clearly, it might be
misinterpreted in the way you suggest, but I think that would be a
problem with the explanation, not the mechanism.
Maybe it is a useless idea if neither the community nor the RFC
Editor System care about long and seemingly unpredictable delays in
handling some documents, delays that unnecessarily make average
processing times longer. Personally, I think predictability is A
Good Thing and that the perception of relatively rapid processing for
most documents is too, but perhaps I'm in the minority.
> Please add the issues from my mail today (Date: Fri, 31 Oct 2025
> 16:57:49 +0900) to Paul and the WG.
FWIW, I think we are in general agreement about all of those issues
except possibly about the boundary between this document and RPC
choices about the Style Guide. Your final comment (about names and
initials) may suggest something else entirely, which is that this WG
and/or the RSAB, ought to have a mechanism for making strong,
community-consensus, recommendations to the RPC (and the RPC should
have a mechanism for asking questions and getting such
recommendations) without needing to republish an updated version of
this document or other Editorial Stream RFCs.
thanks,
john
--
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
