glasgow-ipl/draft-mcquistin-augmented-ascii-diagrams

Support for remapping bits/fields

Opened this issue · 1 comments

Fields are often remapped, either within the same document, or across documents. That is, bits that are part of a field in a header, may become part of another field later (e.g., because the header is specialised, or the header itself is respecified).

Example/proposed syntax:

2.  Long Header Packets

   A long header packet is formatted as follows:
       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+
      |1|1| T |   X   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Version                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    DCID Len   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Destination Connection ID                 ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    SCID Len   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Source Connection ID                   ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

   Header Form (HF): 1 bit; HF == 1.  The most significant bit (0x80) of
      byte 0 (the first byte) is set to 1 for long headers.

   Fixed Bit (FB): 1 bit; FB == 1.  The next bit (0x40) of byte 0 is set
      to 1.  Packets containing a zero value for this bit are not valid
      packets in this version and MUST be discarded.

   Long Packet Type (T): 2 bits.  The next two bits (those with a mask
      of 0x30) of byte 0 contain a packet type.

   Type-Specific Bits (X): 4 bits.  The lower four bits (those with a
      mask of 0x0f) of byte 0 are type-specific.

...

   A Version Negotiation packet is formatted as follows:

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               :
      :                          Long Header                          :
      :                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      [Supported Versions]                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

   Header Form (HF): 1 bit; HF == 1.  The most significant bit (0x80) of
      byte 0 (the first byte) is set to 1 for long headers.

   Fixed Bit (FB): 1 bit; FB == 1.  The next bit (0x40) of byte 0 is set
      to 1.  Packets containing a zero value for this bit are not valid
      packets in this version and MUST be discarded.

   Unused: 6 bits.  These bits are unused in the version negotiation
      packet.

...

In this example, the Long Header format is specified, with "Long Packet Type" and "Type-Specific Bits" fields. In the Version Negotiation packet, which extends the Long Header format, these two fields are remapped to the "Unused" field. There is no explicit syntax to show this: it is sufficient to express this in the description list.

From call: be more explicit about remapped fields. In the example, unroll "Long Header" and show the fields.