Packet header fields cannot be omitted

[dtikhonov]

At the top of page 66 of the transport draft, we read:

   Every QUIC packet that is coalesced into a single UDP datagram is
   separate and complete.  Though the values of some fields in the
   packet header might be redundant, no fields are omitted.  The
   receiver of coalesced QUIC packets MUST individually process each
   QUIC packet and separately acknowledge them, as if they were received
   as the payload of different UDP datagrams.  For example, if
   decryption fails (because the keys are not available or any other
   reason), the receiver MAY either discard or buffer the packet for
   later processing and MUST attempt to process the remaining packets.

The second sentence seems to imply that a field could be omitted.

Does this sentence sound odd to anyone else?

[RyanTheOptimist]

While it is perhaps technically redundant, I think it is actually quite helpful. The first sentence says, "complete" but that might be open to interpretation. The second sentence makes it clear what that means. I like it.

YMMV :)

[dtikhonov]

My issue is not with the redundancy of the second senteance, but rather with its meaning. The specification that "no fields be omitted" implies that fields could be omitted -- but they can't be: There are no optional fields in packet headers.

[nibanks]

Maybe change the second sentence to something like:

Though the values of some fields in the header might be redundant, it is
not possible to omit any fields.

[dtikhonov]

@RyanatGoogle writes:

The first sentence says, "complete" but that might be open to interpretation. The second sentence makes it clear what that means. I like it.

The third sentence clarifies the first sentence well, too.

I would just drop the second sentence altogether.

[janaiyengar]

I can't remember now, but we did have an intermediate design where redundant fields were absent. This sentence may have crept in around then. I agree with @dtikhonov : it does seem redundant now.