Dear all, As always, many thanks to the RFC Editor team for their great work and all their help! We have now come to agreement about the first three questions in this email. Please find our answers below:
> On 3 Dec 2024, at 22:43, Megan Ferguson <mfergu...@amsl.com > <mailto: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) [TAPS Authors] All of these changes are fine with us. > 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 [TAPS Authors] Please use multistream (with no dash). > 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? The style should stay as it is (<tt> in draft-ietf-taps-interface, quoted in draft-ietf-taps-impl), but there is a different mistake here: the text in draft-ietf-taps-interface should refer to the name of the property, not the name of the section. So, please apply the following replacement in draft-ietf-taps-interface: OLD: As an alternative to specifying an interface name for the Local Endpoint, an application can express more fine-grained preferences using the Interface Instance or Type Selection Property; see Section 6.2.11. NEW: As an alternative to specifying an interface name for the Local Endpoint, an application can express more fine-grained preferences using the interface Selection Property; see Section 6.2.11. … where, in the new version, the second occurrence of “interface” should be enclosed in <tt>. Here it is again with the <tt> inserted at the right place: NEW: As an alternative to specifying an interface name for the Local Endpoint, an application can express more fine-grained preferences using the <tt>interface</tt> Selection Property; see Section 6.2.11. Due to your suggestion to take care of item 4) after other updates, we will get back to you on 4) and 5) below later. Best regards, The authors of the TAPS Cluster (508) > 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
