Telechat Review of draft-ietf-httpbis-rfc6265bis-19
review-ietf-httpbis-rfc6265bis-19-artart-telechat-allocchio-2025-02-15-00
Request | Review of | draft-ietf-httpbis-rfc6265bis |
---|---|---|
Requested revision | No specific revision (document currently at 20) | |
Type | Telechat Review | |
Team | ART Area Review Team (artart) | |
Deadline | 2025-02-18 | |
Requested | 2025-01-23 | |
Authors | Steven Bingler , Mike West , John Wilander | |
I-D last updated | 2025-03-19 (Latest revision 2025-03-17) | |
Completed reviews |
Dnsdir Telechat review of -19
by Petr Špaček
(diff)
Artart Telechat review of -19 by Claudio Allocchio (diff) Secdir Telechat review of -19 by Valery Smyslov (diff) Genart IETF Last Call review of -19 by Dale R. Worley (diff) |
|
Assignment | Reviewer | Claudio Allocchio |
State | Completed | |
Request | Telechat review on draft-ietf-httpbis-rfc6265bis by ART Area Review Team Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/art/-jOxJvUWyEFzYq9wtQcfbcFxeOA | |
Reviewed revision | 19 (document currently at 20) | |
Result | Ready w/issues | |
Completed | 2025-02-15 |
review-ietf-httpbis-rfc6265bis-19-artart-telechat-allocchio-2025-02-15-00
Dear all, I was assigned the ART review for this draft. The document is close to be ready, however there are some fixes or clarification in the specification needed. Issues: * it is always quite complex to handle syntax when we engage parsing white spaces. Along the document the handling is specified in details in many sections; however, given cookies content often uses "natural language style" (if I may say so), the issue on how and where to ignore white spaces may lead to ambiguity: how to we parse something like ? e x a m p l e ; ? I suggest to revise specifically various sections and try to ensure there is no abiguity. * security and privacy it is well known that cookies can be unsecure and pose risk to privacy; the document reminds often about existing issues, but does not seem to update a lot the considerations which were there already in the previous version of this specification. Shall we try to add some more considertions we learned during the time from the previous specification until this new one? It is not a blocking issue of course, but I would consider this occasion to do it. * nits: update the reference for MAY, SHALL, MUST... to the latest version :-) * final considerations: it is a very well done revision of the previous specification, but (it can be understood) in such a huge documents some final issues should be fixed before publication; this specification is likely going to be on duty for a long number of years, before a new update is done. all the best! Claudio