Draft: draft-ietf-quic-transport

Commentary: Some advice . 
 The spec currently says Assume now that the client does store a transport parameter it does n't understand . At the time when it actually establishes a 0 - RTT connection , the implementation was updated ( or new extensions were activated ) , and now it understands the TP . This would lead to unintended consequences , especially if this was a TP that it was prohibited from saving in the first place . I think the sentence would be clearer if it said MUST NOT . Not sure if that is an editorial change though . 
 There is an unstated assumption here : that the client does n't change its opinion about transport parameters between two connections . This applies to other transport parameters . For instance , a client might like a stream limit it is given when initially connecting , but might change its mind when trying 0 - RTT ( maybe the limit is too small to bother with 0 - RTT ) . A MUST NOT in this case is worse than not answering the question . Let 's say that the client initially does n't support maxudppayload_size as it always sends 1200 byte datagrams . As it can not process this when it first connects , it does n't store the value . Later , when it attempts to connect it has been updated to understand this transport parameter . As it has been prohibited from storing the value , it ca n't read the value that it might have otherwise saved as an opaque value . So it attempts 0 - RTT and assumes that it can send 1400 byte packets safely , when it should know that it ca n't . Generally , this does n't happen because defaults for transport parameters are the least permissive value . New transport parameters generally have defaults that are safe to use in 0 - RTT in case the original value was not remembered . However , we do n't require that . ( This is a bad example , as we explicitly do n't worry about violating the datagram size limit in 0 - RTT , but I did n't have a more evocative example . ) 
 with explanation , does anything need to be done still in your opinion ? 
 example seems to be an argument for requiring clients to store unknown TPs , and checking their status ( should have been saved for 0 - RTT or should n't have been saved ) when restoring them . Is that something we should require ? 
 Or it is an argument for you to throw out resumption information if you have new capabilities that might depend on stuff you previously threw out . 
 I think it 's an argument for discarding resumption information when adding new capabilities . FWIW ,  does n't persist resumption information to disk for security reasons , but this has the side benefit that this information does not persist across restarts , including binary updates . One exception I can imagine is a client which gets an experiment config push that does n't require a restart , enabling or disabling a new extension feature . However , in that case , not saving unknown TPs still seems safest , since if the extension depended upon the unknown TP , then it 's just not activated . I 'm worried maxudppayload_size is a bad example because it 's part of the core spec and it 's not similar to extensions which add new frames or change the behavior of existing frames . 
 Either interpretation fixes the issue , but I would agree that resumption information should n't be used when the implementation changes behavior . But it could store all unknown TPs , and then reinterpret later . The current text allows both , which seems adequate . This is n't important enough to warrant a design change . I 'm fine with the current text , but I 'd be open to an editorial fix if someone sent a PR . 
 If the client stores the value , then gains the capability to interpret it , it also gains the capability to know it should be ignoring any cached value . I 'm not too concerned about that variant . If the client does n't store the value but the server is still enforcing it , that 's handled by making the default the least permissive value . If we do n't state that assumption , perhaps we should . 
 I 'd be happy with an editorial PR here to clarify some of this , but I 'm not feeling confident enough to write it .
Paragraph (version B):
A client that does not understand a transport parameter can discard
it and attempt 0-RTT on subsequent connections.  However, if the
client adds support for a discarded transport parameter, it risks
violating the constraints that the transport parameter establishes if
it attempts 0-RTT.  New transport parameters can avoid this problem
by setting a default of the most conservative value.