Original text:
bytes. An opaque blob that the client may use with a future Initial <del> packet. </del>  An endpoint might receive multiple NEW_TOKEN frames that contain the same token value.  Endpoints are responsible for discarding duplicate

Reviewer comments:
If we allow empty NEW_TOKEN frames, the receiver would have to check that the token is not empty before saving and reusing it, so it seems slightly easier to forbid this nonsensical edge case.
Like NAME I would like the spec to specify the error code. I don't care which it is.
Consensus was declared on this PR a couple of days ago. Can we get this merged, and deal with the error code requested by NAME and NAME as part of ?
In the context of deciding what code to use for badly formatted frames: Originally posted by NAME in URL I tend to agree with this. Let's go through and try to apply some sort of consistency. Maybe even try to be principled about it.
How does this principle sound: If you can detect an error while parsing the frame, and without consulting any connection state, it should be a FRAMEENCODINGERROR. For everything that happens after frame parsing, we use the more concrete error types (or PROTOCOL_VIOLATION).
+1. To rephrase, as the name suggests, FRAMEENCODINGERROR indicates a syntactic (i.e., encoding) error. But nothing else.
I'd like to see a PR, but that seems like a good principle.
NAME I prepared a PR, just waiting for to get merged to apply the principle there.
Can we call this editorial?
It changes functional requirements about what error codes to send, so not really.
Discussed in Cupertino. Will be consensus-called.
It makes absolutely no sense to allow NEW_TOKEN to be empty, but we never really said that explicitly. So let's do that. NAME opened for that. Unfortunately, this is technically a design change, and we are that point. So let's do this by the book.
Would a token of length 1 be any better? We already have that tokens must be unique and different from other token types.
Yes. At least then we have a clear signal that a token was provided. Now, it's probably still awful (though it might be stateful and so not completely awful), but absent some strong signal about how short things can be we're in much the same state we are with connection IDs. We now allow those to be 1 byte long, with similar results.
My weak preference is to not forbid 0-byte tokens, as it would be something that stacks would be forced to implement, just to pass the conformance tests. It does not provide us any benefit (as NAME points out), while requiring stacks to have the check implemented.
NAME I see the point. There is already text in initial packets stating "Token Length: A variable-length integer specifying the length of the Token field, in bytes. This value is zero if no token is present. "
Allowing 0-length token requires the receiver to filter them out before saving them to their token store (however that is implemented) for reuse in a connection in the future. If you don't do this, you might go and retrieve a token from the token store, use it on an Initial packet, just to end up in the situation that you're actually not using a token at all. I disagree with NAME here. A stateful implementation could for example generate tokens by drawing random numbers between 0 and (a big value of) N. Occasionally, this will result in small token lengths, without compromising on the desired privacy properties.
NAME there is nothing to disagree with, or thumbsdown - it was a question.
Fair enough, that's a legitimate question, and I hope that I could provide a satisfying answer. Removed my thumbsdown.
NAME That's a good point. That makes sense - I can see the value of using "0" as a signal to indicate the "absence" of the token throughout the specification, considering the fact that it is used that way at some parts of the spec.
I'm not sure why you'd want to do this, but an empty NEW_TOKEN could be used to indicate the past tokens are no longer valid, but the peer isn't getting a new one(at least yet). That is the practical implication of the way it's written today(later tokens are likely better than earlier, etc).
Yeah, that's just confusing. The semantics of NEWTOKEN don't imply invalidation. We'd have to explicitly say that if URL == 0, all previous tokens are invalid. And then you have to also address the case of reordering and retransmissions of old NEW_TOKEN frames that arrive after the empty one. Let's not go there.

Revised text:
bytes. An opaque blob that the client may use with a future Initial  <ins> packet.  The token MUST NOT be empty.  An endpoint MUST treat receipt of a NEW_TOKEN frame with an empty Token field as a connection error of type FRAME_ENCODING_ERROR. </ins> An endpoint might receive multiple NEW_TOKEN frames that contain the same token value.  Endpoints are responsible for discarding duplicate