Hi Martin,
Thanks for the reply. Only quoting the things you had concerns with:
On 31 Oct 2025, at 8:26, Martin J. Dürst wrote:
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'm not sure what your proposal is here. Are you asking for a policy
that the style guide no longer be an RFC and instead be a more dynamic
and regularly updated document? Are you saying that we simply do not
want to include text that says that the RPC may limit characters used?
It seemed like some people were indicating that they wanted some
guidance for authors saying what would and would not be acceptable.
6. Searching requirement being too expansive: Brian provided some
possible text, others suggested reverting to 7997 language, Brian
suggested maybe to remove it entirely. Not quite clear consensus.
It really depends on what kind of search we talk about. Search engines
shouldn't be a problem at all, they easily deal also with spelling
mistakes. Search in a text editor or with a command such as grep is
more difficult. But copy-paste is really your friend here.
The 7997 language was about tools to search for documents on the RFC
Editor web site. Is that what you are leaning toward?
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).
I'll leave it to Paul to come up with some changes and maybe communicate
with you offline.
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.)
Indeed, I failed to include in my reasoning the early discussion between
John K., John L., Paul, and Carsten. I'd say there was not silence, and
with your comment it seems that the rough consensus was against doing
these.
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).
Yes, and as above, the discussion seemed to be against doing these.
I hope that is useful. Let me know if I've missed/misconstrued
anything.
Please add the issues from my mail today (Date: Fri, 31 Oct 2025
16:57:49 +0900) to Paul and the WG.
Answered there.
pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
--
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
