cleanup

Author: pavel-kirienko

specification/introduction/introduction.tex

@@ -132,47 +132,13 @@ \section{Capabilities}
 
 \section{Management policy}
 
-The Cyphal maintainers are tasked with maintaining and advancing this specification and
-the set of public regulated data types\footnote{%
-    The related technical aspects are covered in chapters~\ref{sec:basic} and~\ref{sec:dsdl}.
-} based on their research and the input from adopters.
+The Cyphal maintainers are tasked with maintaining and advancing this specification
+based on their research and the input from adopters.
 The maintainers will be committed to ensuring long-term stability and backward compatibility of
 existing and new deployments.
 The maintainers will publish relevant announcements and solicit inputs from adopters
 via the discussion forum whenever a decision that may potentially affect existing deployments is being made.
 
-\section{Referenced sources}
-
-The Cyphal specification contains references to the following sources:
-
-\begin{itemize}
-    \item CiA 103 --- Intrinsically safe capable physical layer.
-    \item CiA 801 --- Application note --- Automatic bit rate detection.
-
-    \item IEEE 754 --- Standard for binary floating-point arithmetic.
-    \item IEEE Std 1003.1 --- IEEE Standard for Information Technology --
-          Portable Operating System Interface (POSIX) Base Specifications.
-
-    \item IETF RFC~768 --- User Datagram Protocol.
-    \item IETF RFC~791 --- Internet Protocol.
-    \item IETF RFC~1112 --- Host extensions for IP multicasting.
-    \item IETF RFC~2119 --- Key words for use in RFCs to Indicate Requirement Levels.
-    \item IETF RFC~2365 --- Administratively Scoped IP Multicast.
-    \item IETF RFC~2474 --- Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers.
-    \item IETF RFC~8085 --- UDP Usage Guidelines.
-    \item IETF RFC~8900 --- IP Fragmentation Considered Fragile.
-    \item IETF RFC~8837 --- Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS.
-
-    \item ISO 11898-1 --- Controller area network (CAN) --- Part 1: Data link layer and physical signaling.
-    \item ISO 11898-2 --- Controller area network (CAN) --- Part 2: High-speed medium access unit.
-    \item ISO/IEC 10646 --- Universal Coded Character Set (UCS).
-    \item ISO/IEC 14882 --- Programming Language C++.
-
-    \item \href{http://semver.org}{semver.org} --- Semantic versioning specification.
-
-    \item ``Consistent Overhead Byte Stuffing'', Stuart Cheshire and Mary Baker.
-\end{itemize}
-
 \section{Revision history}
 
 \subsection{v1.1-alpha -- DRAFT}
@@ -189,7 +155,7 @@ \subsection{v1.0 -- May 2025}
 \begin{itemize}
     \item The maximum data type name length has been increased from 50 to 255 characters.
 
-    \item The default extent function has been removed (section \ref{sec:dsdl_composite_extent_and_sealing}).
+    \item The default extent function has been removed.
     The extent now has to be specified explicitly always unless the data type is sealed.
 
     \item The constraint on DSDL namespaces being defined in a single folder was removed. Namespaces can be hosted
@@ -211,12 +177,11 @@ \subsection{v1.0-beta -- Sep 2020}
     \item The subject-ID range reduced from $[0, 32767]$ down to $[0, 8191]$.
     This change may be reverted in a future edition of the standard, if found practical.
 
-    \item Added support for delimited serialization; introduced related concepts of \emph{extent} and \emph{sealing}
-    (section \ref{sec:dsdl_composite_extent_and_sealing}).
+    \item Added support for delimited serialization; introduced related concepts of \emph{extent} and \emph{sealing}.
     This change enables one to easily evolve networked services in a backward-compatible way.
 
     \item Enabled the automatic runtime adjustment of the transfer-ID timeout on a per-subject basis
-    as a function of the transfer reception rate (section \ref{sec:transport_transfer_reception}).
+    as a function of the transfer reception rate.
 \end{itemize}
 
 \subsection{v1.0-alpha -- Jan 2020}

specification/transport/can/can.tex

@@ -6,36 +6,10 @@ \section{Cyphal/CAN}\label{sec:transport_can}
 Throughout this section, ``CAN'' implies both Classic CAN 2.0 and CAN FD, unless specifically noted otherwise.
 CAN FD should be considered the primary transport protocol.
 
-\begin{CyphalSimpleTable}{Cyphal/CAN transport capabilities}{|l X l|}
-    \label{table:transport_can_capabilities}
-    Parameter & Value & References \\
-
-    Maximum node-ID value &
-    127 (7 bits wide). &
-    \ref{sec:basic} \\
-
-    Transfer-ID mode &
-    Cyclic, modulo 32. &
-    \ref{sec:transport_transfer_id} \\
-
-    Number of transfer priority levels &
-    8 (no additional levels). &
-    \ref{sec:transport_transfer_priority} \\
-
-    Largest single-frame transfer payload &
-    Classic CAN -- 7~bytes, CAN FD -- up to 63~bytes. &
-    \ref{sec:transport_transfer_payload} \\
-
-    Anonymous transfers &
-    Supported with non-deterministic collision resolution policy. &
-    \ref{sec:transport_route_specifier} \\
-\end{CyphalSimpleTable}
-
 \subsection{CAN ID field}
 
 Cyphal/CAN transport frames are CAN 2.0B frames.
-The 29-bit CAN ID encodes the session specifier\footnote{Section~\ref{sec:transport_session_specifier}.}
-of the transfer it belongs to along with its priority.
+The 29-bit CAN ID encodes the addressing and priority information of the transfer it belongs to.
 The CAN data field of every frame contains the transfer payload
 (or, in the case of multi-frame transfers, a fraction thereof), the transfer-ID, and other metadata.
 
@@ -283,8 +257,7 @@ \subsubsection{Source node-ID field in anonymous transfers}\label{sec:transport_
 
     The described principles make anonymous transfers highly non-deterministic and inefficient.
     This is considered acceptable because the scope of anonymous transfers is limited to a very narrow set of use
-    cases which tolerate their downsides. The Cyphal specification employs anonymous transfers only for the
-    plug-and-play feature defined in section~\ref{sec:application_functions}.
+    cases which tolerate their downsides.
     Deterministic applications are advised to avoid reliance on anonymous transfers completely.
 
     None of the above considerations affect nodes that do not transmit anonymous transfers.
@@ -316,7 +289,7 @@ \subsubsection{Layout}
                                                       section~\ref{sec:transport_can_toggle_bit}. \\\hline
         4   &                           & \multicolumn{2}{c|}{} \\
         3   &                           & \multicolumn{2}{c|}{Modulo 32 (range [0, 31])} \\
-        2   & \textbf{Transfer-ID}      & \multicolumn{2}{c|}{section~\ref{sec:transport_transfer_id}} \\
+        2   & \textbf{Transfer-ID}      & \multicolumn{2}{c|}{} \\
         1   &                           & \multicolumn{2}{c|}{} \\
         0   &                           & \multicolumn{2}{c|}{\footnotesize{(least significant bit)}} \\
         \hline
@@ -353,7 +326,6 @@ \subsubsection{Transfer payload decomposition}
     Usage of padding bytes implies that when a serialized message is being deserialized by a receiving node,
     the byte sequence used for deserialization may be longer than the actual byte sequence generated by the
     emitting node during serialization.
-    This behavior is compatible with the DSDL specification.
 
     The weak MTU requirement for CAN FD is designed to avoid compatibility issues.
 \end{remark}
@@ -370,14 +342,15 @@ \subsubsection{Transfer CRC}\label{sec:transport_can_transfer_crc}
     This is the native byte order for this CRC function.
 }.
 
-The transfer CRC function is \textbf{CRC-16/CCITT-FALSE} (section~\ref{sec:appendix_crc16ccitt_false}).
+The transfer CRC function is \textbf{CRC-16/CCITT-FALSE}:
+polynomial $0x1021$, initial value $0xFFFF$, no input or output reflection, no final XOR.
 
 \subsection{Examples}
 
 \begin{remark}[breakable]
-    Heartbeat from node-ID 42, nominal priority level,
-    uptime starting from 0 and then incrementing by one every transfer, health status is 0,
-    operating mode is 1, vendor-specific status code 161 ($A1_{16}$):
+    A periodic 7-byte status message from node-ID 42 at nominal priority level.
+    The four consecutive transfers differ only in the first payload byte and in the transfer-ID
+    field of the tail byte:
 
     \begin{CyphalCompactTable}{|l l|}
         CAN ID (hex)      & CAN data (hex)          \\
@@ -387,9 +360,10 @@ \subsection{Examples}
         \texttt{107D552A} & \texttt{03 00 00 00 00 01 A1 E3} \\
     \end{CyphalCompactTable}
 
-    \verb|uavcan.primitive.String.1.0| under subject-ID 4919 ($1337_{16}$) published by an anonymous node,
-    the string is ``\verb|Hello world!|'' (ASCII); one byte of zero padding can be seen between
-    the payload and the tail byte:
+    A 14-byte payload under subject-ID 4919 ($1337_{16}$) published by an anonymous node.
+    The payload is a two-byte little-endian length prefix ($000C_{16}$) followed by the ASCII
+    string ``\verb|Hello world!|'';
+    one byte of zero padding can be seen between the payload and the tail byte:
 
     \begin{CyphalCompactTable}{|l l|}
         CAN ID (hex)      & CAN data (hex)                                           \\
@@ -399,8 +373,9 @@ \subsection{Examples}
         \texttt{11133775} & \texttt{0C 00 48 65 6C 6C 6F 20 77 6F 72 6C 64 21 00 E3} \\
     \end{CyphalCompactTable}
 
-    Node info request from node 123 to node 42 via Classic CAN, then response;
-    notice how the transfer CRC is scattered across two frames:
+    A zero-payload service request from node 123 to node 42 via Classic CAN,
+    followed by a multi-frame response carrying a variable-length descriptive string;
+    notice how the transfer CRC is scattered across the last two frames:
 
     \begin{CyphalCompactTable}{|l l l X|}
         CAN ID (hex)      & CAN data (hex)                                  & ASCII             & Comment \\
@@ -442,8 +417,9 @@ \subsection{Examples}
         Transfer CRC, LSB. \\
     \end{CyphalCompactTable}
 
-    \verb|uavcan.primitive.array.Natural8.1.0| under subject-ID 4919 ($1337_{16}$) published by node 59,
-    the array contains an arithmetic sequence $\left(0, 1, 2, \ldots{}, 89, 90, 91\right)$;
+    A 92-byte payload under subject-ID 4919 ($1337_{16}$) published by node 59.
+    The payload is a two-byte little-endian length prefix ($005C_{16}$) followed by the
+    arithmetic sequence $\left(0, 1, 2, \ldots{}, 89, 90, 91\right)$;
     the transport MTU is 64 bytes:
 
     \begin{CyphalCompactTable}{|l X[2] X|}
@@ -479,8 +455,8 @@ \subsubsection{Ordered transmission}
 \subsubsection{Transmission timestamping}
 
 \begin{remark}[breakable]
-    Certain application-level functions of Cyphal may require the driver to timestamp outgoing transport frames,
-    e.g., the time synchronization function.
+    Some applications may require the driver to timestamp outgoing transport frames,
+    e.g., to measure end-to-end transmission latency or to support time synchronization.
     A sensible approach to transmission timestamping is built around the concept of \emph{loop-back frames},
     which is described here.
 

specification/transport/transport.tex

@@ -147,10 +147,8 @@ \subsection{Redundancy}
 
 An exception to the above rule applies if the payload of the transfer is a function of
 the identity of the transport instance that carries the transfer\footnote{%
-    An example of such a special case is the time synchronization algorithm documented
-    in section~\ref{sec:application_functions}.
+    Specific examples include time synchronization algorithms or diagnostic probes.
 }.
 
 % Please keep \clearpage in front of every section to enforce clear separation!
 \clearpage\input{transport/can/can.tex}
-\clearpage\input{transport/udp/udp.tex}