Michael, Bernie, and Tim Combining a few author responses here to close these topics out:
1) Regarding the text Michael pointed out: > I have read the 9915 top to bottom. > I think the phrasing at 18.2.12: > >> A client not detected as having moved to a new link SHOULD initiate > > is still pretty awkward. > The new phrasing, seems to suggest that an external entity is going to detect > the client has moved. But, it's the client has to do the detection. > I think the problem is that the sentences are too long/too few. > I can live with this, but maybe someone else has a suggestion here. > We have updated to use Bernie’s suggestion (with a few editorial tweaks related to tense and punctuation) as that seemed to be the consensus of the messages. Please review and let us know if any further updates are necessary. 2) To address the “non-issues” in Michael’s mail: > ---- non-issues: > > A question about the many minor changes where a list item has a : added. > The colon appears in the <dt> as text, it's not produced by xml2rfc. > Someone did s,</dt>,:</dt>,g right? [rfced] Right. > So that seems like a stylistic thing that (authors) should just be more aware > of. It seems like it aught to be something xml2rfc "enforces" [rfced] There is not a requirement that the term in a definition list be followed by a colon. Sometimes a term is followed by other punctuation or a line break (if newline="true"). From our perspective, this is a style choice that should not be enforced by the tool. > > I'm also curious about the how/why IA_PD-options got hyphen wrapped (section > 21.22), but in our text it was just moved to a new line. > [rfced] The submitted XML file contained a non-breaking hyphen in that instance. We did not keep the non-breaking hyphen, as typically words that "naturally" contain hyphens can contain line breaks in RFCs. If you want that particular term to be kept together, please let us know and we will insert the entity (&nbhy;) 3) With regard to the header question from Bernie: > At least from the headers in this document: > > Internet Engineering Task Force (IETF) T. Mrugalski > Request for Comments: 9915 ISC > Obsoletes: 8415 B. Volz > Category: Standards Track Individual Contributor > ISSN: 2070-1721 M. Richardson > SSW > S. Jiang > BUPT > T. Winters > QA Cafe > December 2025 > > I’m not seeing any difference from headers on 8415 that indicate this would > be an IETF Full Standard document? > > RFC8200 has “STD: 86”. [rfced] Thank you for bringing this to our attention. This document has been assigned a new STD number (102). Please let us know if this is not correct (i.e., it should be part of an existing STD). See the complete list of Internet Standards here: https://www.rfc-editor.org/standards Please review the files carefully as we do not make changes after publication. The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9915.txt https://www.rfc-editor.org/authors/rfc9915.pdf https://www.rfc-editor.org/authors/rfc9915.html https://www.rfc-editor.org/authors/rfc9915.xml The relevant diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9915-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9915-rfcdiff.html (comprehensive side by side) https://www.rfc-editor.org/authors/rfc9915-auth48diff.html (AUTH48 changes only) https://www.rfc-editor.org/authors/rfc9915-auth48rfcdiff.html (AUTH48 side by side) https://www.rfc-editor.org/authors/rfc9915-lastdiff.html (last version to this) https://www.rfc-editor.org/authors/rfc9915-lastrfcdiff.html (last to this side by side) Please contact us with any further updates/questions/comments you may have. We will await approvals from each of the parties listed on the AUTH48 status page prior to moving forward to publication. The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9915 Thank you. Megan Ferguson RFC Production Center > On Dec 15, 2025, at 2:41 PM, Michael Richardson <[email protected]> wrote: > > > I have read the 9915 top to bottom. > I think the phrasing at 18.2.12: > >> A client not detected as having moved to a new link SHOULD initiate > > is still pretty awkward. > The new phrasing, seems to suggest that an external entity is going to detect > the client has moved. But, it's the client has to do the detection. > I think the problem is that the sentences are too long/too few. > I can live with this, but maybe someone else has a suggestion here. > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
