Jean,
On 11-Feb-25 10:30, Jean Mahoney wrote:
Hi all,
On 2/9/25 7:07 PM, John C Klensin wrote:
Carsten,
Apologies for the drift. I was responding to Michael's comment/
suggestion and Joel's response to it, not whatever might have been
elsewhere on the thread or list.
An observation about your main concern, with which I agree. I have
found over the years (starting long before "RPC" entered our
vocabulary) that, when I am preparing a document and discover that
there are different ways one might do/present the same information, a
quick note to rfc-edi...@rfc-editor.org mentioning the issue or
choices and asking for their preference almost always gets a
relatively quick, and always helpful, response.
[JM] Authors should feel free to send questions to
rfc-edi...@rfc-editor.org.
Right now, only 21 of the documents in the queue have any sort of SVG,
so there's not a huge uptake of this artwork format. In my skim of the
artwork, I think most would only garner a few minor questions and
updates during AUTH48.
However, that situation could change significantly if it becomes easier
to create acceptable SVG.
Many of the diagrams are fairly basic because authors try to keep the
ASCII-art and SVG consistent. There is only one RFC so far where the SVG
was too complex for ASCII-art equivalents
(https://www.rfc-editor.org/rfc/rfc9633.html).
I can't imagine why anyone would want to use the .txt version of that
RFC anyway. I suspect that making it easier to generate acceptable
SVG will be the beginning of the end for ASCII art.
Brian
Thanks!
Jean
I have always
believed those responses are because those involved are nice and
helpful, but they could equally well be justified on the basis of
saving time later that would go into cleaning up the messes I might
otherwise make.
That approach would solve many of the types of problems and late
surprises to which you refer... at least it has for me. It would
probably not work for first-time authors or others who might be
hesitant to approach the RPC. But we could, with little trouble,
tell them and encourage it: notes in the advice to authors, in any
tutorials, and maybe in the introductory text to the submission tool
might go a long way. And the costs would almost certainly be much
lower than injecting any sort of new formal process into the system
-- especially since, at least AFAICT, the comparison to the IANA
review doesn't quite work because IANA only needs to review one
(often, but not always, short) section while, to prevent surprises,
the RPC would need to go through the whole document, possibly even
looking at interactions among sections.
We could also debate whether the IANA reviews are cursory and/or
whether a cursory early review followed by a later one that involves
a big surprise and requests for many changes is optimal, but that is
probably another discussion for another list.
john
--On Sunday, February 9, 2025 23:32 +0100 Carsten Bormann
<c...@tzi.org> wrote:
On 9. Feb 2025, at 22:23, John C Klensin <john-i...@jck.com> wrote:
RPC review
The discussion is definitely drifting away from what I was pointing
out.
It's true that we haven't managed to pull off a way for the RPC
to help improving document quality earlier in the process.
But that is not what I was talking about.
My observation was that there is a need to avoid late surprises in
a gating function that likely to remain obscure for authors, even
if words are spent writing up RPC principles for executing it that
cannot take into account each individual situation.
I don't mind having a separate discussion about RPC early
reviews, and how Deepthink makes that less necessary, etc., but
I'd like to focus the discussion of my observation that an
IANA-like cursory preview at the WG document/WGLC level and a more
thorough checking at the IESG evaluation level would help avoiding
late surprises.
A "how do I get good graphics into my document" help desk of
the RPC would also be a nice thing, but is unrelated.
Grüße, Carsten
--
rswg mailing list -- rswg@rfc-editor.org
To unsubscribe send an email to rswg-le...@rfc-editor.org
