Dear RFC-Ed,
Please note that the following issues relating to Arch were not dealt
with in the cluster answer sent to the RFC Editor, but specifically
relate to improving consistency with draft-ietf-taps-arch:
1. Could you please add this definition to the ARCH draft to be
consistent with other I-Ds in this cluster:
Transport Services API:The abstract interface [REF-RFC9662] to
aTransport Services Implementation [REF-RFC9663].
---
2. Please could you also please also change:
OLD:
Transport Services architecture
NEW:
Transport Services Architecture
Throughout, although leaving the first usage as lower case, if you wish,
since it is not defined until the terminology section?
---
Best wishes,
Gorry
On 03/12/2024 21:43, Megan Ferguson 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
