Draft: draft-ietf-quic-transport

Commentary: 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 I would like the spec to specify the error code . I do n't care which it is . 
  was declared on this PR a couple of days ago . Can we get this merged , and deal with the error code requested by and as part of ? 
 In the context of deciding what code to use for badly formatted frames : Originally posted by in 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 . 
 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 . 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 points out ) , while requiring stacks to have the check implemented . 
 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 do n'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 here . A stateful implementation could for example generate tokens by drawing random numbers between 0 and ( a big value of )   , this will result in small token lengths , without compromising on the desired privacy properties . 
 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 . 
 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 is n'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 do n't imply invalidation . We 'd have to explicitly say that if = = 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 .
Paragraph (version A):
An opaque blob that the client may use with a future Initial
packet.
Paragraph (version B):
An opaque blob that the client may use with a future Initial
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.