Rephrase size requirement for Initial packets

[janaiyengar]

Closes #2519.

[kazuho]

To me this looks like an outdated text that was written before the TLS handshake design in draft-12.

Now that the server responds with an Initial packet, my understanding is that a client in required to send full-sized datagrams until it receives an Initial packet from the server.

[ianswett]

I think we should stick with the simplest text possible and we should remove the second sentence. Once you've received an ACK for a handshake packet, you should be done sending INITIAL packets anyway, so it feels like an unnecessary optimization.

[tfpauly]

Agreed with @ianswett since the time when you receive the ACK for the Handshake packet is exactly when you stop sending Initial frames, so this sentence feels like its pointing out a subtlety that doesn't exist.

If the point of the sentence is to say that, while UDP datagrams containing Initial packets MUST be >= 1200 bytes, all others may or may not be padded (at the implementation's discretion), it would be clearer to say:

Any UDP datagram that does not contain any Initial packets MAY be smaller than 1200 bytes.

[dtikhonov]

This change does two things:

1. Clarify that if UDP datagram contains Initial packets, it must be at least 1200 bytes in size; and
2. Rule out padding the UDP datagram with junk (the "padding packets" part) as @nibanks suggested earlier.

Issue #2519 is only about (1). Not that I am against (2), but this is just so that we are clear.

[martinthomson]

I think that the reinterpretation of the text here has introduced the second problem @dtikhonov mentions. This also has the unfortunate consequence of disallowing small acknowledgment datagrams (for HelloRetryRequest in particular). This might need to be more carefully phrased.

[martinthomson]

A potential friendly amendment, but then we should proceed. I would say after confirming with chairs, because there was a pretty strong design decision involved here, but technically this is only an editorial change.

[janaiyengar]

As @martinthomson said, this is an editorial change, so I'm going to merge. The substantive one is in @2523.

[janaiyengar]

@dtikhonov -- you're right, but I think this was unintentional earlier. I think if we want to make a case for allowing junk, that should be discussed separately. The proposed text captures what I believe our intent was.