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
