Draft: draft-ietf-quic-qlog-h3-events

Commentary: I have checked the CDDL syntax with this command most definitions are unused though at this time command output 
 Hey Thanks for the work and the cool one - liner to extract CDDL from the draft . Some initial feedback : ' ve found that the CDDL tool does n't really properly validate the " unused rules " so you need to make sure they are referenced somewhere . For the main schema I 've forced this with kind of an ugly hack by adding the rules manually to a debugging definition ( ) . It 's probably best to have that here as well ( can even be in the draft for now imo ) . the ends up with slightly different generated HTML than the main schema where I use the . Your version generates while mine does . I do n't really care which method we use , as long as it creates consistent output . 're not totally consistent about how we use string " enums " . E.g. , you 've a separate , but HTTP3PushResolved has an inline . I 'd prefer having separate types for these things ( have done this in the main schema as well ) . ' ve prefixed the HTTP/3 type names with instead of . My idea was that tools can eventually generate the qlog event name from the type names ( i.e. , can be transformed to ) . In this case , the category name is and not , so your events should be called not . At least for now ... maybe we should discuss renaming the category to instead ... ( now I assumed it would be implied by the field ) cc and see . think now in CDDL you can indeed have a single definition for FrameParsed and FrameCreated and have both alias to that . also run the command ( at least for the final PR commit ) . This did n't have glaring errors , but a few trailing whitespaces ( fixed with ) . 
 Thanks Very valuable feedback and advice . I 'll try to fix the generated HTML and use . For the time being I admit that I cut corners to get a quick continuous CDDL validation :) As far as using the  prefix instead of HTTP I thought that it was valuable to distinguish between HTTP/3 and HTTP/2 especially around Frames ( e.g. HTTP/2 Frames have flags ? ) but I 'll revert to using HTTP and we can discuss further for future versions . I 'll have a second iteration ready soon . 
 I addressed almost all the comments . I can use some guidance on how to address having shared types for Parameters and Frames . I also created a PR for the full CDDL file in case you want to link it all together 
 Hey Thanks for the updates and the very useful script , which I was also able to use for the QUIC events draft ! I have a new commit that primarily adds some overall consistency with the other two drafts ( e.g. , in terms of the code block ids , nothing major ) . I also noticed you were using and to wrap your enums , which is n't necessary ( it works without as well , so I removed the brackets ) . 4 main things though : stated that  should become HTTPMessage , but it seems to me that should be HTTPField instead ? Reading , it seems that the Message is -everything- ( headers , content , trailers ) , while the HEADERS frame ( and similarly QPACK ) only deals with the headers / trailers  ? I have n't kept up enough with the new HTTP semantics documents or the QPACK rewording , but  does seem to be the proper term if I look at those documents ( e.g. , and and ) . As such , I 've renamed to . makes it even clearer however that the QPACK event terminology is woefully out of date and we have to rename a lot of that to align with the newest QPACK draft text . I do propose we keep that for the draft after this however ( -02 , as the new one we 're now preparing will be -01 ) , as that would take us too much time and be too error prone to get done by Monday . found a relatively clean way to have re - usable , though it does require a new piece of CDDL syntax called the " unwrap operator " , which is . Essentially , that just takes the contents of the unwrapped type and puts them at the unwrap location , extending the target type . I do feel that will not be very clear for qlog readers , so we should explain that ( better than what I tried atm ... ) . Alternatively though , since they are just a few fields and only re - used at two locations , I wonder if it would n't make more sense to just keep it as it was ( define them twice ) , to improve readability . , while I understood what you meant by reuse for the ( see point 3 above ) , I was n't sure what you meant with " shared types for Frames " ? Could you clarify ? Maybe my approach for the works for that as well and you can adapt it ? With that , I believe this draft is ( 99 % ) ready for submission on Monday , so please review and let me know if you find any issues 
 thanks for the fixes and comments . You are right that  is the most updated terminology to refer to headers . However , my comment about using HTTPMessage instead of HTTPHeaders is pointing to the fact that  alone are not representing a full message and that Method and Target for a request and status code for a response would be good to have . Also , Trailers should be considered . All of these are QPACK - encoded in HTTP/3 and HPACK - encoded in HTTP/2 . I was thinking that we could even use the Known - length binary HTTP Message representation ? 
 on a second thought the binary representation is not needed at all . And for a request we can use the pseudo - headers to represent method / scheme / authority / path , and status pseudo - header for a response . 
 I 'm not entirely sure I follow what you 're saying wrt representation of full HTTPMessage here . However , I do get the impression that that is something that goes ( way ) beyond simply updating to CDDL here , and so I 'd propose you open a new issue describing this ( with ideally a concrete example / proposal ) so we do n't hold up this PR on that . Would you agree ? 
 absolutely , not related to the CDDL conversion . It 's a separate discussion . Sorry for the noise
Paragraph (version A):
The examples and data definitions in ths document are expressed in a
custom data definition language, inspired by JSON and TypeScript, and
described in QLOG-MAIN.
Paragraph (version B):
The event and data structure definitions in ths document are
expressed in the Concise Data Definition Language CDDL and its
extensions described in QLOG-MAIN.
Paragraph (version B):
Note: we use the CDDL unwrap operator (~) here to make HTTPParameters
into a re-usable list of fields.  The unwrap operator copies the
fields from the referenced type into the target type directly,
extending the target with the unwrapped fields.  TODO: explain this
better + provide reference and maybe an example.