Éric Vyncke's Discuss on draft-ietf-httpbis-rfc6265bis-19: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

É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.