- From: Éric Vyncke via Datatracker <noreply@ietf.org>
- Date: Mon, 17 Feb 2025 00:58:47 -0800
- To: "The IESG" <iesg@ietf.org>
- Cc: draft-ietf-httpbis-rfc6265bis@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, mnot@mnot.net, mnot@mnot.net, pspacek@isc.org
Éric Vyncke has entered the following ballot position for draft-ietf-httpbis-rfc6265bis-19: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-httpbis-rfc6265bis-19 CC @evyncke Thank you for the work put into this document, like other ADs I find it easy to read (for most parts). Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Mark Nottingham for the shepherd's write-up including the WG consensus *and* the justification of the intended status. Please note that Petr Špaček is the DNS directorate reviewer and you may want to consider this dns-dir review as well when it will be available (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/reviewrequest/21332/ I hope that this review helps to improve the document, Regards, -éric ## DISCUSS (blocking) As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics: ### Section 2.1 Trivial to fix: please use the actual BCP14 template include RFC 8174 reference. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS (non-blocking) ### Section 1 & abstract Having some text about the difference with RFC 6265 would be helpful. As a non-English speaker, I had to check the meaning of `infelicities`... I.e., I share Warren's view on unusual words. ### Section 2.1 Unsure whether using "conformance" is the right word to be used in an IETF document. The BCP14 template has also little to do with conformance. Suggest using some wording related to "interoperation" rather than "conformance". Section 3.2 uses "compatible", which is more appropriate. ### Section 3 I am far from being an HTTP expert, but can CDN/proxies also set cookies ? It does not seem so when reading `a way for an origin server to send state`, if so, then suggest adding text clarifying whether CDN/proxies can also Set-Cookie ### Section 3.1 As there are some text about deleting a cookie by sending a Expires date in the past, then the choice of `09 Jun 2021` for a valid cookie does not seem correct in 2025 ;-) Suggest adding some text in the 'valid' example stating that the request is sent in May 2021 or something similar. ### Section 4.1.2.7 To be honest and probably because I am not an HTTP expert, I was unable to understand the specification of SameSite... ### Sections 4.2 and 4.1 Suggest adding "HTTP Header" to the section title, especially for section 4.2 as I read it first about a section about cookies and not about the Cookie header. ### Section 5.2.1 Who is the "We" in `We'll define this origin,`? The authors ? The HTTPBIS WG ? The IETF ? Please refrain from using the ambiguous "we", also applicable in other places ### Section 5.3 What are the consequences of bypassing the "SHOULD" in this section ? Also applicable to many SHOULD (e.g., section 6.1), recommended may be more appropriate. ### Section 5.5 Any justification for the 400 days ? Also, please explain the consequences of bypassing the "SHOULD". ### Section 9.3 Good idea to create such a registry for easier extensions.
Received on Monday, 17 February 2025 08:58:52 UTC