idnits 2.17.00 (12 Aug 2021) /tmp/idnits31197/draft-mcquistin-augmented-ascii-diagrams-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 628 has weird spacing: '...r eq-op bool...' == Line 629 has weird spacing: '...rd-expr bool-...' == Line 630 has weird spacing: '...dd-expr ord-o...' == Line 632 has weird spacing: '...ul-expr add-o...' == Line 633 has weird spacing: '... mul-op expr...' -- The document date (8 July 2019) is 1047 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SeqFieldFixedXRef' is mentioned on line 507, but not defined == Outdated reference: draft-ietf-quic-transport has been published as RFC 9000 -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. McQuistin 3 Internet-Draft V. Band 4 Intended status: Informational C. Perkins 5 Expires: 9 January 2020 University of Glasgow 6 8 July 2019 8 Fully Specifying Protocol Parsing with Augmented ASCII Diagrams 9 draft-mcquistin-augmented-ascii-diagrams-00 11 Abstract 13 This document describes a machine-readable format for fully 14 specifying the process by which a protocol can be parsed. This 15 format combines a consistent ASCII packet diagram format with the use 16 of structured text, maintaining human readability while enabling 17 support for machine parsing. This document is itself an example of 18 how this format can be used. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 9 January 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Limitations of current ASCII packet diagrams usage . . . 3 56 2.2. Formal languages in standards documents . . . . . . . . . 6 57 3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 6 58 4. Augmented ASCII Packet Header Diagrams . . . . . . . . . . . 8 59 4.1. Fixed-width Field Format . . . . . . . . . . . . . . . . 8 60 4.2. Variable-width Field Format . . . . . . . . . . . . . . . 10 61 4.3. Cross-referencing and Sequences Format . . . . . . . . . 11 62 4.4. Optional Field Format . . . . . . . . . . . . . . . . . . 12 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 66 8. Informative References . . . . . . . . . . . . . . . . . . . 13 67 Appendix A. ABNF specification . . . . . . . . . . . . . . . . . 14 68 A.1. Constraint Expressions . . . . . . . . . . . . . . . . . 14 69 A.2. Augmented ASCII diagrams . . . . . . . . . . . . . . . . 14 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 ASCII packet header diagrams have become the de-facto format for 75 describing the syntax of binary protocols. In otherwise largely 76 textual documents, they allow for the visualisation of packet 77 formats, reducing human error, and aiding in the implementation of 78 parsers for the protocols that they specify. Given their widespread 79 use, and relatively structured form, ASCII packet header diagrams 80 provide a good base from which to develop a format that supports the 81 automatic generation of parser code from protocol standards 82 documents. 84 There are two broad issues with the existing ASCII packet header 85 diagrams that need to be addressed to enable machine-readability. 86 First, their use, while sufficiently consistent for human 87 readability, contains enough variation to make machine parsing 88 difficult: different documents tend to use subtly different formats 89 and conventions. Second, ASCII packet header diagrams alone do not 90 fully capture the parsing process for protocols, requiring 91 supplementary text. To support machine parsing, this supplementary 92 text must be consistently structured. 94 This document describes a consistent ASCII packet header format and 95 accompanying structured text constructs that allow for the parsing 96 process of protocol headers to be fully specified. This provides 97 support for the automatic generation of parser code. Broad design 98 principles, that seek to maintain the primacy of human readability 99 and flexibility in authorship, are described, before the format 100 itself is given. 102 This document is itself an example of the approach that it describes, 103 with the ASCII packet diagrams and structured text format described 104 by example. 106 This draft describes early work. As consensus builds around the 107 particular syntax of the format described, both a formal ABNF 108 specification and code that parses it (and, as described above, this 109 document) will be provided. 111 2. Background 113 This section begins by considering how ASCII packet header diagrams 114 are used in existing documents. This exposes the limitations that 115 the current usage has in terms of machine-readability, guiding the 116 design of the format that this document proposes. 118 While this document focuses on the machine-readability of packet 119 header diagrams, this section also discusses the use of other 120 structured or formal languages within IETF documents. Considering 121 how and why these languages are used provides an instructive contrast 122 to the relatively incremental approach proposed here. 124 2.1. Limitations of current ASCII packet diagrams usage 126 ASCII packet header diagrams are commonplace in the IETF standards 127 documents for binary protocols. While there is no standard for how 128 these diagrams should be formatted, they have a broadly similar 129 structure, where the layout of a protocol data unit (PDU) or 130 structure is given in an ASCII diagram, and a description list of the 131 fields that it contains are given immediately below. An example of 132 this format is given in Figure 1. 134 The RESET_STREAM frame is as follows: 136 0 1 2 3 137 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Stream ID (i) ... 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Application Error Code (16) | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Final Size (i) ... 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 RESET_STREAM frames contain the following fields: 148 Stream ID: A variable-length integer encoding of the Stream ID of 149 the stream being terminated. 151 Application Protocol Error Code: A 16-bit application protocol 152 error code (see Section 20.1) which indicates why the stream is 153 being closed. 155 Final Size: A variable-length integer indicating the final size 156 of the stream by the RESET_STREAM sender, in unit of bytes. 158 Figure 1: QUIC's RESET_STREAM frame format (from [QUIC-TRANSPORT]) 160 However, these diagrams, and their accompanying descriptions, are 161 formatted for human readers rather than for machine parsing. As a 162 result, while there is broad consistency in how ASCII packet diagrams 163 are formatted, there are a number of limitations that are prohibitive 164 to machine parsing: 166 Inconsistent syntax: There are two classes of consistency that are 167 required for parsability: internal consistency, within a document 168 or diagram, and external consistency, across all documents. Given 169 that ASCII packet diagrams are formatted for human readers, rather 170 than for machine parsing, there is sufficient variability in how 171 they are formatted that parsing is difficult. 173 The format of the "Relay Source Port Option" is shown below: 175 0 1 2 3 176 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | OPTION_RELAY_PORT | Option-Len | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Downstream Source Port | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Where: 184 Option-Code: OPTION_RELAY_PORT. 16-bit value, 135. 186 Option-Len: 16-bit value to be set to 2. 188 Downstream Source Port: 16-bit value. To be set by the IPv6 189 relay either to the downstream relay agent's UDP source port 190 used for the UDP packet, or to zero if only the local relay 191 agent uses the non-DHCP UDP port (not 547). 193 Figure 2: DHCPv6's Relay Source Port Option (from [RFC8357]) 195 Figure 1 gives an example of internal inconsistency. Here, the 196 ASCII diagram shows a field labelled "Application Error Code", 197 while the accompanying description lists the field as "Application 198 Protocol Error Code". The use of an abbreviated name is suitable 199 for human readers, but makes parsing the structure difficult for 200 machines. Figure 2 gives a further example, where the description 201 lists a field "Option-Code" that does not appear in the ASCII 202 diagram. In addition, the description list describes each field 203 as being 16 bits in length, while the diagram shows the 204 OPTION_RELAY_PORT as 13 bits, and Option-Len as 19 bits. Another 205 example of this -- where the diagram and accompanying text 206 disagree -- is in [RFC6958], where the packet header diagram 207 showing the structure of the Burst/Gap Loss Metrics Report Block 208 shows the Number of Bursts field as being 12 bits wide but the 209 corresponding text describes it as 16 bits. 211 Comparing Figure 1 with Figure 2 exposes external inconsistency 212 across documents. While the ASCII diagrams themselves are broadly 213 similar, the text surrounding the diagrams is formatted 214 differently. If machine parsing is to be made possible, then this 215 text must be structured consistently. 217 Ambiguous constraints: The constraints that are enforced on a 218 particular field are often described ambiguously, or in a way that 219 cannot be parsed easily. In Figure 2, each of the three fields in 220 the structure is constrained. The first two fields ("Option-Code" 221 and "Option-Len") are to be set to constant values (note the 222 inconsistency in how these constraints are expressed in the 223 description). However, the third field ("Downstream Source Port") 224 can take a value from a constrained set. This constraint is 225 expressed in prose that can easily be parsed by humans, but not by 226 machines. 228 Poor linking between sub-structures: Protocol data units and other 229 structures are often comprised of sub-structures that are defined 230 elsewhere, either in the same document, or within another 231 document. Chaining these structures together is essential for 232 machine parsing: the parsing process for a protocol data unit is 233 only fully expressed if all elements can be parsed. 235 Figure 1 highlights the difficulty that machine parsers have in 236 chaining structures together. Two fields ("Stream ID" and "Final 237 Size") are described as being encoded as variable-length integers; 238 this is a structure described elsewhere in the same document. 239 Structured text is required both alongside the definition of the 240 containing structure and with the definition of the sub-structure, 241 to allow a parser to link the two together. 243 2.2. Formal languages in standards documents 245 A small proportion of IETF standards documents contain structured and 246 formal languages, including ABNF [RFC5234], ASN.1 [ASN1], C, CBOR 247 [RFC7049], JSON, the TLS presentation language [RFC8446], YANG models 248 [RFC7950], and XML. While this broad range of languages may be 249 problematic for the development of tooling to parse specifications, 250 these, and other, languages serve a range of different use cases. 251 ABNF, for example, is typically used to specify text protocols, while 252 ASN.1 is used to specify data structure serialisation. This document 253 specifies a structured language for specifying the parsing of binary 254 protocol data units. 256 3. Design Principles 258 The use of structures that are designed to support machine 259 readability may potentially interfere with the existing ways in which 260 protocol specifications are used and authored. To the extent that 261 these existing uses are more important than machine readability, such 262 interference must be minimised. 264 In this section, the broad design principles that underpin the format 265 described by this document are given. However, these principles 266 apply more generally to any approach that introduces structured and 267 formal languages into standards documents. 269 It should be noted that these are design principles: they expose the 270 trade-offs that are inherent within any given approach. Violating 271 these principles is sometimes necessary and beneficial, and this 272 document sets out the potential consequences of doing so. 274 The central tenet that underpins these design principles is a 275 recognition that the standardisation process is not broken, and so 276 does not need to be fixed. Failure to recognise this will likely 277 lead to approaches that are incompatible with the standards process, 278 or that will see limited adoption. However, the standards process 279 can be improved with appropriate approaches, as guided by the 280 following broad design principles: 282 Most readers are human: Primarily, standards documents should be 283 written for people, who require text and diagrams that they can 284 understand. Structures that cannot be easily parsed by people 285 should be avoided, and if included, should be clearly delineated 286 from human-readable content. 288 Any approach that shifts this balance -- that is, that primarily 289 targets machine readers -- is likely to be disruptive to the 290 standardisation process, which relies upon discussion centered 291 around documents written in prose. 293 Authorship tools are diverse: Authorship is a distributed process 294 that involves a diverse set of tools and workflows. The 295 introduction of machine-readable structures into specifications 296 should not require that specific tools are used to produce 297 standards documents, to ensure that disruption to existing 298 workflows is minimised. This does not preclude the development of 299 optional, supplementary tools that aid in the authoring machine- 300 readable structures. 302 The immediate impact of requiring specific tooling is that 303 adoption is likely to be limited. A long-term impact might be 304 that authors whose workflows are incompatible might be alienated 305 from the process. 307 Canonical specifications: As far as possible, machine-readable 308 structures should not replicate the human readable specification 309 of the protocol within the same document. Such structures should 310 form part of a canonical specification of the protocol. Adding 311 supplementary machine-readable structures, in parallel to the 312 existing human readable text, is undesirable because it could 313 create the potential for inconsistency. 315 As an example, program code that describes how a protocol data 316 unit can be parsed might be provided as an appendix within a 317 standards document. This code would provide a specification of 318 the protocol that is separate to the prose description in the main 319 body of the document. This has the undesirable effect of 320 introducing the potential for the program code to specify 321 behaviour that the prose-based specification does not, and vice- 322 versa. 324 Expressiveness: Any approach should be expressive enough to capture 325 the syntax and parsing process for the majority of binary 326 protocols. If a given language is not sufficiently expressive, 327 then adoption is likely to be limited. At the limits of what can 328 be expressed by the language, authors are likely to revert to 329 defining the protocol in prose: this undermines the broad goal of 330 using structured and formal languages. Equally, though, 331 understandable specifications and ease of use are critical for 332 adoption. A tool that is simple to use and addresses the most 333 common use cases might be preferred to a complex tool that 334 addresses all use cases. 336 Minimise required change: Any approach should require as few changes 337 as possible to the way documents are formatted, authored, and 338 published. Forcing adoption of a particular structured or formal 339 language is incompatible with the IETF's standardisation process: 340 there are very few components of standards documents that are non- 341 optional. 343 4. Augmented ASCII Packet Header Diagrams 345 The design principles described in Section 3 can largely be met by 346 the existing uses of ASCII packet header diagrams. These diagrams 347 aid human readability, do not require new or specialised authorship 348 tools, do not split the specification into multiple parts, can 349 express most binary protocol features, and require no changes to the 350 existing publication processes. 352 However, as discussed in Section 2.1 there are limitations to how 353 ASCII diagrams are used that must be addressed if they are to be 354 parsed by machine. In this section, an augmented ASCII packet header 355 diagram format is described. 357 The concept is first illustrated by example. This is appropriate, 358 given the visual nature of the language. In future drafts, these 359 examples will be parsable using provided tools, and a formal 360 specification of the augmented ASCII packet diagrams will be given in 361 Appendix A. 363 In the augmented ASCII packet diagrams, each protocol data unit is 364 described in its own section of the document. This enables cross- 365 referencing between data units using section numbering. In this 366 specification-by-example, each element of the format will be 367 described as part of a separate PDU. 369 4.1. Fixed-width Field Format 371 The simplest PDU is one that contains only a set of fixed-width 372 fields in a known order, with no optional fields or variation in the 373 packet format. 375 A Fixed-width Field Format packet is formatted as follows: 377 0 1 2 3 378 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 |F2 | Field30 | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | | 383 + Field64 + 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | | 387 + Field48 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Field8 | 391 +-+-+-+-+-+-+-+-+ 393 where: 395 Field2 (F2): 2 bits This is a short field, and the diagram cannot 396 show its full label. A short label (F2) is used 397 in the diagram, and this short label is 398 provided, in brackets, after the full label in 399 the description list. The field's width -- 2 400 bits -- is given in the label of the description 401 list, separated from the field's label by a 402 colon. 404 Field30: 30 bits This is a longer field whose full label can be 405 shown in the diagram. 407 Field64: 8 bytes This is a field that spans multiple rows. Where 408 fields are an integral number of bytes in size, 409 and start and end on a byte boundary, the field 410 length can be given in bytes rather than in 411 bits. 413 Field48: 48 bits This is another multi-row field. As 414 illustrated, fields are not required to end of a 415 32-bit boundary. 417 Field8: 1 byte This field has been drawn on the next line, 418 where it would have fit on the previous line. 419 Where possible, the formatting of the diagram 420 should be flexible to meet the needs of human 421 readers. 423 4.2. Variable-width Field Format 425 Some packet formats include variable-width fields, where the size of 426 a field is either derived from the value of some previous field, or 427 is unspecified and inferred from the total size of the packet and the 428 size of the other fields. A packet can contain only one unspecified 429 length field, to ensure there is no ambiguity. 431 A Variable-width Field Format packet is formatted as follows: 433 0 1 2 3 434 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Field8 | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | FieldVar - single row ... 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | : 441 : FieldVar - multi-row : 442 : | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | : 445 : FieldVar - multi-row, unspecified length : 446 : | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 where: 451 Field8 (F): 8 bits This is a fixed-width field, as described 452 previously. As shown, while this field has a short label (F), 453 this does not need to be used in the diagram. 455 FieldVar - single row: 2^F bits This is a variable-length field, 456 whose length is defined by the value of the field with short label 457 F (Field8). Constraint expressions can be used in place of 458 constant values: the grammar for the expression language is 459 defined in Section a.1. Where fields labels are used in a 460 constraint, the field being referred to must have been defined 461 before its label is used. Short variable-length fields are 462 indicated by "..." instead of a pipe at the end of the row. 464 FieldVar - multi-row: 2^F bits This is a multi-row variable-length 465 field, again constrained by the value of field F. Instead of the 466 "..." notation, ":" is used to indicate that the field is 467 variable-length. The use of ":" instead of "..." indicates the 468 field is likely to be a longer, multi-row field. However, 469 semantically, there is no difference: these different notations 470 are for the benefit of human readers. 472 FieldVar - multi-row, unspecified length This is a variable-width 473 field whose length is implied by the lengths of the other fields. 474 At parsing time, the length of the PDU is known, and this can be 475 used to determine the length of fields whose length is undefined. 476 Each PDU can only leave a single field's length undefined: all 477 other fields must be fixed-length, or have their widths 478 constrained. 480 4.3. Cross-referencing and Sequences Format 482 A Cross-referencing and Sequences Format packet is formatted as 483 follows: 485 0 1 2 3 486 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Field8 | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | | 491 + + 492 | | 493 + FieldFixedXRef + 494 | | 495 + + 496 | | 497 + +-+-+-+-+-+-+-+-+ 498 | | : 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 500 : : 501 : FieldVarXref : 502 : | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | | 505 + + 506 | | 507 + [SeqFieldFixedXRef] + 508 | | 509 + + 510 | | 511 + +-+-+-+-+-+-+-+-+ 512 | | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 where: 517 Field8 (F): 8 bits This is a fixed-width field, as described 518 previously. 520 FieldFixedXRef: 1 Fixed-width Field Format This is a field whose 521 structure is a previously defined PDU format. To indicate this, 522 the width of the field is given in units of the cross-referenced 523 structure (here, Fixed-width Field Format). 525 FieldVarXref: 1 Variable-width Field Format This field references a 526 variable-width structure. It can be drawn to any width as 527 appropriate, but must use a variable-width notation. Where 528 multiple variable-width field format structures are referenced, 529 the requirement that only one field's length can be unspecified 530 applies to the enclosing structure. 532 SeqFieldFixedXRef: 2 Fixed-width Field Format Where a field is 533 comprised of a sequence of previously defined structures, square 534 brackets can be used to indicate this in the diagram. The length 535 of the sequence can be defined using the constraint expression 536 grammar as described earlier. 538 4.4. Optional Field Format 540 An Optional Field Format packet is formatted as follows: 542 0 1 2 3 543 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Field8 | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | OptionalField | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 where: 552 Field8 (F): 8 bits This is a fixed-width field, as described 553 previously. 555 OptionalField: 4 bytes Present only when F > 3. This is a field 556 whose presence is predicated on an expression 557 given in the constraint expression grammar 558 described earlier. Optional fields can be of 559 any previously defined format (e.g., fixed- 560 or variable-width). Optional fields are 561 indicated by the presence of a "Present only 562 when [expr]." as the first line in their 563 description 565 5. IANA Considerations 567 This document contains no actions for IANA. 569 6. Security Considerations 571 Poorly implemented parsers are a frequent source of security 572 vulnerabilities in protocol implementations. Structuring the 573 description of a protocol data unit so that a parser can be 574 automatically derived from the specification can reduce the 575 likelihood of vulnerable implementations. 577 7. Acknowledgements 579 The authors would like to thank David Southgate for preparing a 580 prototype implementation of some of the ideas described here. 582 This work has received funding from the UK Engineering and Physical 583 Sciences Research Council under grant EP/R04144X/1. 585 8. Informative References 587 [ASN1] ITU-T, "ITU-T Recommendation X.680, X.681, X.682, and 588 X.683", ITU-T Recommendation X.680, X.681, X.682, and 589 X.683. 591 [QUIC-TRANSPORT] 592 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 593 and Secure Transport", draft-ietf-quic-transport-20 (work 594 in progress), 23 April 2019, 595 . 598 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 599 Specifications: ABNF", RFC 5234, January 2008, 600 . 602 [RFC6958] Clark, A., Zhang, S., Zhao, J., and Q. Wu, "RTP Control 603 Protocol (RTCP) Extended Report (XR) Block for Burst/Gap 604 Loss Metric Reporting", RFC 6958, May 2013, 605 . 607 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 608 Representation (CBOR)", RFC 7049, October 2013, 609 . 611 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", 612 RFC 7950, August 2016, 613 . 615 [RFC8357] Deering, S. and R. Hinden, "Generalized UDP Source Port 616 for DHCP Relay", RFC 8357, March 2018, 617 . 619 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 620 Version 1.3", RFC 8446, August 2018, 621 . 623 Appendix A. ABNF specification 625 A.1. Constraint Expressions 627 cond-expr = eq-expr "?" cond-expr ":" eq-expr 628 eq-expr = bool-expr eq-op bool-expr 629 bool-expr = ord-expr bool-op ord-expr 630 ord-expr = add-expr ord-op add-expr 632 add-expr = mul-expr add-op mul-expr 633 mul-expr = expr mul-op expr 634 expr = *DIGIT / field-name 636 field-name = *ALPHA 638 mul-op = "*" / "/" / "%" 639 add-op = "+" / "-" 640 ord-op = "<=" / "<" / ">=" / ">" 641 bool-op = "&&" / "||" / "!" 642 eq-op = "==" / "!=" 644 A.2. Augmented ASCII diagrams 646 Future revisions of this draft will include an ABNF specification for 647 the augmented ASCII diagram format described in Section 4. Such a 648 specification is omitted from this draft given that the format is 649 likely to change as its syntax is developed. Given the visual nature 650 of the format, it is more appropriate for discussion to focus on the 651 examples given in Section 4. 653 Authors' Addresses 655 Stephen McQuistin 656 University of Glasgow 657 School of Computing Science 658 Glasgow 659 G12 8QQ 660 United Kingdom 662 Email: sm@smcquistin.uk 664 Vivian Band 665 University of Glasgow 666 School of Computing Science 667 Glasgow 668 G12 8QQ 669 United Kingdom 671 Email: vivianband0@gmail.com 673 Colin Perkins 674 University of Glasgow 675 School of Computing Science 676 Glasgow 677 G12 8QQ 678 United Kingdom 680 Email: csp@csperkins.org