Draft: draft-ietf-quic-transport

Commentary: When we prohibited the use of application - layer CONNECTION_CLOSE in these packets , we should have updated the text in the description of the packets also . 
 I think the spec is ambiguous when it says in section 17.2 : and : Handshake packets MAY contain CONNECTIONCLOSE frames . But CONNECTION_CLOSE can mean 0x1c or 0x1d . Are both permitted during the handshake ? 
 In this case , the intent is to allow both . Unless explicitly specified , I would read the text to mean both types of CONNECTION_CLOSE frames . 
 Okay , if more people think that way , we can close with no action . 
 So on the surface , there is no inconsistency : the two sections permit CONNECTIONCLOSE . But the question about the different types of CONNECTIONCLOSE is more relevant than response might imply . We currently require that CONNECTIONCLOSE of type 0x1d ( application close ) is not sent in Initial or Handshake packets . So that 's a drafting error , and we might reasonably take this as an editorial issue . However , if the question is about what a reaction to receiving an application CONNECTIONCLOSE in one of those packets , we might consider a different posture . If you get an application CONNECTIONCLOSE in an Initial packet that is otherwise valid , you probably want to drop the connection . And you probably do n't want to start sending CONNECTIONCLOSE in response every time , because that leads to madness . But this is a general problem : if you detect and error and that error keeps being repeated , it probably is n't a good idea to generate a CONNECTION_CLOSE in response to every infraction . 
 ( removing my comment as posted what needs to be said couple of seconds earlier ) . 
 I 'm going to re - close the can of worms I half - opened in my earlier comment and take this as editorial . From memory , the larger question of how to deal with junk is something we 've discussed several times . If anyone wants to take that up , I 'm happy to do that , but let 's at least correct the obvious error . 
 It does make sense that we only allow 0x1c during the handshake . 
 : Apologies , I misspoke -- I was speaking to interpretation of text , rather than the actual question itself .
Paragraph (version A):
The payload of an Initial packet includes a CRYPTO frame (or frames)
containing a cryptographic handshake message, ACK frames, or both.
PING, PADDING, and CONNECTION_CLOSE frames are also permitted.  An
endpoint that receives an Initial packet containing other frames can
either discard the packet as spurious or treat it as a connection
error.
Paragraph (version B):
The payload of an Initial packet includes a CRYPTO frame (or frames)
containing a cryptographic handshake message, ACK frames, or both.
PING, PADDING, and CONNECTION_CLOSE frames of type 0x1c are also
permitted.  An endpoint that receives an Initial packet containing
other frames can either discard the packet as spurious or treat it as
a connection error.
Paragraph (version A):
The payload of this packet contains CRYPTO frames and could contain
PING, PADDING, or ACK frames.  Handshake packets MAY contain
CONNECTION_CLOSE frames.  Endpoints MUST treat receipt of Handshake
packets with other frames as a connection error.
Paragraph (version B):
The payload of this packet contains CRYPTO frames and could contain
PING, PADDING, or ACK frames.  Handshake packets MAY contain
CONNECTION_CLOSE frames of type 0x1c.  Endpoints MUST treat receipt
of Handshake packets with other frames as a connection error.