Hi Michael, Thanks for the reply/update.
We are very happy to have your expertise in updating the capitalization to appear as intended (thank you!). We have you marked as not approved at the AUTH48 status page and will await further word from you before moving anything forward. Thanks! RFC Editor/mf > On Dec 16, 2024, at 6:46 PM, Michael Welzl <mich...@ifi.uio.no> wrote: > > Hi Megan / RFC Editor team, > > I can confirm that all desired updates appear as intended, but I don’t want > to voice my approval to go ahead yet because there’s still one missing item: > fixing the capitalization (which really applies to all three documents). > > I am halfway (or perhaps a bit more) through your extremely long list of > terms (and I’m very thankful for the work you’ve put into this: *creating* > this list must have been a terrible task!). Some of them require careful > manual inspection. I’m doing my very best to finish this as quickly as > possible. > > I make direct edits to the XML; once these are done I’ll be happy to give my > go-ahead. > > Cheers, > Michael > > >> On Dec 17, 2024, at 1:55 AM, Megan Ferguson <mfergu...@amsl.com> wrote: >> >> Greetings, >> >> Tommy - Thanks for sending along your approvals for each of the RFCs to be >> in this cluster. We have updated the AUTH48 status pages accordingly. >> >> Just a reminder to everyone that the AUTH48 status pages for this cluster >> can be viewed at https://www.rfc-editor.org/auth48/C508. >> >> In looking through the AUTH48 status pages, it appears as though we’ve >> received approvals at some point in the process from each author of >> RFC-to-be 9622. >> >> Michael - can you please confirm that all desired updates appear as intended >> in RFC-to-be 9622 and reconfirm your approval? Once we receive this, we can >> change the state to AUTH48-DONE while it awaits the other two docs in this >> cluster. For the other authors, we will assume your approvals stand unless >> we hear otherwise. >> >> Thank you. >> >> RFC Editor/mf >> >> >> >> >> >>> On Dec 13, 2024, at 10:30 AM, Tommy Pauly <tpa...@apple.com> wrote: >>> >>> Hello, >>> >>> Thanks for all of these updates! I approve this latest version of RFC 9622. >>> >>> Best, >>> Tommy >>> >>>> On Dec 12, 2024, at 1:13 PM, Megan Ferguson <mfergu...@amsl.com> wrote: >>>> >>>> Hi Michael, >>>> >>>> Thank you for sending these along. We have updated on our end to post >>>> these versions and ensure that changes that may have been submitted >>>> simultaneously are represented. >>>> >>>> We have sent replies to each RFC-to-be thread (9622 and 9623) and copied >>>> them below for everyone’s convenience. >>>> >>>> Please have a look and let us know if any further updates are necessary. >>>> >>>> Thank you. >>>> >>>> RFC Editor/mf >>>> >>>> RFC-to-be 9622: >>>> Michael, >>>> >>>> Thank you for sending along the files. We have synced our files with >>>> those you submitted. >>>> >>>> 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/rfc9622.txt >>>> https://www.rfc-editor.org/authors/rfc9622.pdf >>>> https://www.rfc-editor.org/authors/rfc9622.html >>>> https://www.rfc-editor.org/authors/rfc9622.xml >>>> >>>> The relevant diff files have been posted here (please refresh): >>>> https://www.rfc-editor.org/authors/rfc9622-diff.html (comprehensive diff) >>>> https://www.rfc-editor.org/authors/rfc9622-auth48diff.html (AUTH48 changes >>>> only) >>>> https://www.rfc-editor.org/authors/rfc9622-lastdiff.html (last to current >>>> version only) >>>> >>>> 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/rfc9622 >>>> >>>> Thank you. >>>> >>>> RFC Editor/mf >>>> >>>> RFC-to-be 9623: >>>> Michael, >>>> >>>> Thank you for sending along the files. We have synced our files with >>>> those you submitted (including making sure the updates that may have come >>>> in while you were working appear as expected). >>>> >>>> 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/rfc9623.txt >>>> https://www.rfc-editor.org/authors/rfc9623.pdf >>>> https://www.rfc-editor.org/authors/rfc9623.html >>>> https://www.rfc-editor.org/authors/rfc9623.xml >>>> >>>> The relevant diff files have been posted here (please refresh): >>>> https://www.rfc-editor.org/authors/rfc9623-diff.html (comprehensive diff) >>>> https://www.rfc-editor.org/authors/rfc9623-auth48diff.html (AUTH48 changes >>>> only) >>>> https://www.rfc-editor.org/authors/rfc9623-lastdiff.html (last to current >>>> version only) >>>> >>>> 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/rfc9623 >>>> >>>> Thank you. >>>> >>>> RFC Editor/mf >>>> >>>> >>>> >>>>> On Dec 12, 2024, at 12:32 AM, Michael Welzl <mich...@ifi.uio.no> wrote: >>>>> >>>>> Dear all, >>>>> >>>>> This is about question 5. >>>>> >>>>> I am attaching updated xml files for the RFC-to-be-9622 and 9623 that >>>>> address this question. >>>>> I am also attaching the originals so you can make sure which version I >>>>> worked with - a diff between these files and the very last version could >>>>> indicate some very minor changes that you have applied after I made the >>>>> change. >>>>> >>>>> I downloaded the original XML files and made these updates on December >>>>> 10, and gave the other authors until now to comment (two have, and said >>>>> they were fine with these changes). >>>>> >>>>> Cheers, >>>>> Michael >>>>> >>>>> = = = = = >>>>> >>>>> Please feel free to ignore the following text - but in case of doubt, >>>>> when looking at my version, perhaps these notes that I took when doing >>>>> the changes are useful: >>>>> >>>>> >>>>> The name of the "final" property is "final", and using it marks a message >>>>> as Final. I changed one "Final" to lowercase to account fo this. Also, >>>>> both "final" and "Final" are <tt> marked in such sentences. >>>>> >>>>> One occurrence of "Final" seemed odd, and rather than discussing whether >>>>> it should be "final", "<tt>Final</t>" or "<tt>final</tt>", I renamed it >>>>> to "last". >>>>> >>>>> In one place, removed "()" after "Initiate", "Listen" and "Rendezvous". >>>>> Removed one "()" after "Set". >>>>> >>>>> Another thing: strange - I think we corrected this before, but perhaps >>>>> this was something similar in the -impl draft? Anyway, I replaced >>>>> "Interface Instance or Type" and "interface instances and types" with >>>>> "interface" (two occurrences). Both of these cases seem to be left-over >>>>> references to a heading of a property rather than the actual property >>>>> name. >>>>> >>>>> It's the same for "Timeout for aborting the Connection" in one place >>>>> where it should instead be "connTimeout" (so I replaced it). >>>>> >>>>> Also, we had this kind of thing in the TCP user timeout text; fixed. >>>>> >>>>> We have one occurrence of "multipath aware" and one occurrence of >>>>> "multipath-aware". I made this uniform, using the version with the dash. >>>>> >>>>> Fixed capitalization of "unidirectional send" and "unidirectional >>>>> receive" to make it uniform (capital "U"). >>>>> >>>>> "MessageContext" and "Message Context" appear only in RFC 9622, not the >>>>> others; messageContext appears also in RFC 9623. It made sense to use the >>>>> capital words in RFC 9622 though, but these should at least be uniform. I >>>>> chose MessageContext (before: 27 occurrences, whereas "Message Context" >>>>> has 11). >>>>> >>>>> For RFC-to-be-9623, I tried to use <tt> style wherever we refer to API >>>>> elements from RFC 9622. >>>>> >>>>> >>>>> >>>>> >>>>> <rfc9622_updateMW.xml><rfc9623_updateMW.xml><rfc9622.xml><rfc9623.xml> >>>>>> On Dec 4, 2024, at 3:13 AM, Megan Ferguson <mfergu...@amsl.com> wrote: >>>>>> >>>>>> Greetings, >>>>>> >>>>>> While reviewing this cluster of documents*, please review the questions >>>>>> below regarding consistency across the cluster. These questions are in >>>>>> addition >>>>>> to the document-specific questions sent for each RFC-to-be. >>>>>> >>>>>> Your reply will likely impact two or more of the documents in the >>>>>> cluster, so >>>>>> please discuss off-list as necessary and then let us know how to >>>>>> proceed. >>>>>> >>>>>> * Cluster 508 (C508) currently in AUTH48 state: >>>>>> https://www.rfc-editor.org/authors/rfc9621.html >>>>>> https://www.rfc-editor.org/authors/rfc9622.html >>>>>> https://www.rfc-editor.org/authors/rfc9623.html >>>>>> (In addition, the .pdf, .txt, .xml, and diff files are available.) >>>>>> >>>>>> You may track the progress of all documents in this cluster through >>>>>> AUTH48 at: >>>>>> https://www.rfc-editor.org/auth48/C508 >>>>>> >>>>>> 1) The following terms were used inconsistently in this group of >>>>>> documents. >>>>>> We chose to use the latter forms and have already incorporated these >>>>>> changes >>>>>> (we raise them here simply for awareness). Please let us know any >>>>>> objections. >>>>>> >>>>>> Connection properties (1 instance) / Connection Properties (>70 >>>>>> instances) >>>>>> >>>>>> Pre-Establishment Phase (1 instance in text) / pre-establishment phase >>>>>> (6 instances in text) >>>>>> Note - we also closed this compound per the dictionary use. >>>>>> >>>>>> protocol stack(s) (7 instances) / Protocol Stack(s) (~130 instances) >>>>>> >>>>>> remote Endpoint Identifier (1 instance) / Remote Endpoint Identifier >>>>>> (~21 instances) >>>>>> >>>>>> selection properties (1 instance) / Selection Properties (~47 instances, >>>>>> along with ~26 instances of "Selection Property") >>>>>> >>>>>> sockets API (1 instance) / socket API (1 instance) / Socket API (14 >>>>>> instances) >>>>>> >>>>>> transport services (4 instances) / Transport Services (>300 instances) >>>>>> >>>>>> Transport Services Architecture (1 instance in text) / Transport >>>>>> Services architecture (8 instances in text) >>>>>> >>>>>> Transport Services implementation (5 instances) / >>>>>> Transport Services Implementation (~70 instances) >>>>>> >>>>>> >>>>>> 2) The following term appears to be hyphenated inconsistently in this >>>>>> group of documents. >>>>>> Please let us know if/how these uses may be made consistent. >>>>>> Notes: >>>>>> a.) the hyphenated compound is more prevalent in published RFCs and >>>>>> b.) the closed compound is used in a proper noun in RFC-to-be 9622. >>>>>> >>>>>> multi-stream / multistream >>>>>> >>>>>> 3) We see that draft-ietf-taps-interface uses the unquoted form >>>>>> Interface Instance >>>>>> or Type (enclosed in <tt> in the XML file), but draft-ietf-taps-impl >>>>>> uses the quoted form "Interface Instance or Type". Which style is >>>>>> preferred? >>>>>> >>>>>> >>>>>> 4) Please verify that the capitalization of terms appears as desired for >>>>>> the cluster. >>>>>> >>>>>> NOTE: Due to the large number of terms as well as the nature of their >>>>>> use, we suggest that >>>>>> authors make any edits directly to the XML files (instead of via email) >>>>>> for ease of use and >>>>>> to avoid any possible confusion. Further, we suggest getting any other >>>>>> substantive changes >>>>>> made to the documents prior to implementing these updates for ease of >>>>>> review in diff files >>>>>> (this is likely directed mostly toward RFC 9623 at this point). >>>>>> >>>>>> A list of these terms has been posted here: >>>>>> >>>>>> https://www.rfc-editor.org/authors/clusterC508caps.txt >>>>>> >>>>>> Notes about the list: >>>>>> >>>>>> -we have grouped the list according to topic instead of alphanumerically >>>>>> to aid in showing >>>>>> possible discrepancies. >>>>>> >>>>>> -we have marked the terms with “c” that we have already identified as >>>>>> likely impacting more >>>>>> than one document in the cluster (this may not be exhaustive). Note >>>>>> also that the list may >>>>>> include terms we made consistent in our question 1 above (for >>>>>> completeness). >>>>>> >>>>>> -we have included some comments and questions in the list itself. >>>>>> Please review. >>>>>> >>>>>> At a minimum, we suggest making identifiable patterns consistent >>>>>> throughout >>>>>> the document set with regard to capitalization (of both the name itself >>>>>> and the label). >>>>>> >>>>>> For example: >>>>>> >>>>>> properties: >>>>>> examples: >>>>>> preferred properties vs. Preferred properties >>>>>> Protocol Selection Property vs. interface Selection Property >>>>>> Message Properties vs. Message Contexts vs. Message Context Property >>>>>> >>>>>> actions: >>>>>> example: termination action vs. Abort action >>>>>> >>>>>> objects: >>>>>> example: Listener object vs. ErrorCode Object >>>>>> >>>>>> events: >>>>>> example: receive event vs. Receive event (vs. Received event) >>>>>> Note - events have been made consistent with regard to the use of <> in >>>>>> RFC-to-be 9622. >>>>>> >>>>>> 5) We have already sent some document-specific queries related to the >>>>>> use of <tt>. For your convenience, we have also created a cluster-wide >>>>>> list that is sorted alphanumerically and marked by RFC number: >>>>>> >>>>>> https://www.rfc-editor.org/authors/clusterC508tt.txt >>>>>> >>>>>> Please verify that the use of <tt> appears as desired both within the >>>>>> documents and across the cluster. Again, any desired updates are best >>>>>> communicated through updates to the XML file itself. >>>>>> >>>>>> Thank you. >>>>>> >>>>>> RFC Editor/mf >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
