Hi Arnt, We have made some of the updates described below, but we have a couple of followup comments/questions. Please see our comments in-line below.
The current files are available here: https://www.rfc-editor.org/authors/rfc9698.xml https://www.rfc-editor.org/authors/rfc9698.txt https://www.rfc-editor.org/authors/rfc9698.pdf https://www.rfc-editor.org/authors/rfc9698.html AUTH48 diff: https://www.rfc-editor.org/authors/rfc9698-auth48diff.html Comprehensive diffs: https://www.rfc-editor.org/authors/rfc9698-diff.html https://www.rfc-editor.org/authors/rfc9698-rfcdiff.html Note that we have cut items that have already been resolved. >> 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. Point taken on “common RFCism” — after reviewing the examples in the referenced documents again, we updated the list so that “Example X: appears on its own line as was done in RFC 9051. >> 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". Good catch - we updated the text to refer to “OAuth” consistently. >> 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. We updated the XML to use <ul> and <li> to create bullets. Even with a bulleted list, this last part isn’t quite clear to me - what is a matter of a second or two? Also, I may be misreading this, as I read this as an attacker would do some minimal thing to attempt to make something bad happen. Perhaps “could only” is meant instead of “would only”. >> and an attacker would only need to try the credentials it has with an >> autodiscovered JMAP URL (a matter of a second or two) Thanks! RFC Editor/sg -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
