Hi,
lovely work, thank you.
Sandy Ginoza writes:
Authors,
While reviewing this document during AUTH48, please resolve (as
necessary) the following questions, which are also in the XML
file.
1) <!-- [rfced] It appears as though "the JMAP server" is
introduced twice - once in Section 3 and again in Section 4.
Please consider whether any updates are needed.
Section 3 original:
The JMAP session resource that allows access to the same
messages is called "the JMAP server" below.
Section 4 original:
The server/mailstore at that location is
referenced as "the JMAP server" in this document.
-->
Best to keep only the sentence in section 3.
(This is an unintentional duplication, added when we discovered some
disgustingly buggy software very late.)
2) <!-- [rfced] Will readers easily recognize "IMAP4rev1" and
"IMAP4rev2"? If not, may we add citations to RFCs 3501 and
9051?
Readers are familiar with those. There are citations to both documents a
little earlier, and that's enough.
3) <!-- [rfced] In section 5, would you like "Example X." to
stand out more for easier identification? For example, they
could be included as a bulleted list. We bulletized the
examples 3 and 4 so you could see what it would look like.
Please let us know your preference.
-->
My personal preference is that whatever you do usually is best. That is to
say, "common RFCism" beats "what arnt prefers" IMO.
4) <!-- [rfced] Will readers understand "JMAP alter ego"? Note
that this phrase is used twice in Section 5.
Intentionally.
Original:
It knows that the
client used Oauth, and that it and its JMAP alter ego use the same
Oauth backend subsystem.
...
The server sees that the password is accepted, knows that it and its
JMAP alter ego use the same password database, and issues a
JMAPACCESS capability:
-->
5) <!-- [rfced] Should "Oauth" be "OAUTH" throughout? -->
The headline in RFC 6749 uses "OAuth".
6) <!-- [rfced] We are having trouble parsing this text. Please clarify.
Original:
However, in this case information is revealed to an authenticated
client, the revealed URL can usually be found via JMAP autodiscovery,
and an attacker would only need to try the credentials it has with an
autodiscovered JMAP URL (a matter of a second or two). Therefore, it
is believed that this document does not benefit an attacker
noticeably, and its value for migration far outweighs its risk.
Possibly?
In this case, information is revealed to an authenticated
client. The revealed URL can usually be found via JMAP autodiscovery,
and an attacker would only need to try its own credentials with an
autodiscovered JMAP URL (a window of a second or two). Therefore, it
is believed that this document does not benefit an attacker noticeably,
and its value for migration far outweighs its risk.
-->
Is it possible to use a bulleted list in RFCs? I don't know the correct XML
syntax.
What I aimed for is "Howver, in this case [three arguments here].
Therefore, it is believed [text goes on]". I think a bulleted list makes
sense. If you can tell me the syntax, I'll try to write one.
7) <!-- [rfced] We tagged some text as sourcecode. C: and S:
lines have been tagged as <sourcecode type=""> as was done in
RFC 9051. Please review all sourcecode tags and consider
whether these are correct and whether the “type" attribute
should be set and/or has been set correctly.
type="" is better that any of the types on the list.
8) <!-- [rfced] Please review the "Inclusive Language" portion
of the online
Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
Your script did not flag any words because I took care to avoid the problem
;) Incidentally, I think that occurences of non-inclusive language in IMAP
documents often also confuse the human user with client code.
Arnt
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
