Cookies: HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-22

Many thanks to Valery Smyslov for his secdir review.

Section 5:  (Recognizing that this is from the original RFC) The nested numbered lists are difficult to parse.  For example Section 5.7, #6 has 3 sets of sub numbered lists that appear to be distinct.  If these sub numbered lists are necessary (and when there is merely a #1 without a #2, one might argue it isn't 'necessary') then perhaps characters other than numbers might be clearer.

Section 8:  I agree with Valery that this section picks and chooses some example issues ('more salient issues').  I wonder if it isn't possible to give a 1-2 sentence overview of the general security issues associated with cookies.  Something to set the stage, where what follows are examples of issues that have been seen over time (with or without mitigations).  Sadly, I do not have proposed text, and indeed, it may not be possible/feasible.  

Section 10.1:  Most (all?) of the WHATWG documents can be referenced as a snapshot to make them immutable.  There might be other ways to do this, but this is the one I've seen used.

Thanks for clearing my 'easy to fix' DISCUSS kept in the archive:

https://mailarchive.ietf.org/arch/msg/httpbisa/CanH8icaNg-hZV7IfD7L5DJsWTI/

Thanks to the authors for their work! I found this to be a well-written draft. It’s a long document, but the differences between this -bis version and the original RFC6265 were really helpful. Keeping much of the original text while adding clarifications made it much easier to follow.

** Thank you to Dale R. Worley for the GENART review on -19.  Please review https://datatracker.ietf.org/doc/review-ietf-httpbis-rfc6265bis-19-genart-lc-worley-2025-02-10/.  Specifically, review the clarify of the ABNF definition on handling whitespace in addition to the other pointers where the text would benefit from clarity.

** Please cite the whatwg.org documents the same:

   [DOM-DOCUMENT-COOKIE]
              WHATWG, "HTML - Living Standard", 18 May 2021,
              <https://html.spec.whatwg.org/#dom-document-cookie>.

   [FETCH]    van Kesteren, A., "Fetch", n.d.,
              <https://fetch.spec.whatwg.org/>.

   [HTML]     Hickson, I., Pieters, S., van Kesteren, A., Jägenstedt,
              P., and D. Denicola, "HTML", n.d.,
              <https://html.spec.whatwg.org/>.

   [SAMESITE] WHATWG, "HTML - Living Standard", 26 January 2021,
              <https://html.spec.whatwg.org/#same-site>.

-- [SAMESITE] and [DOM-DOCUMENT-COOKIE] use a date, but not [HTML] and [FETCH].  As I recollect, using the date was the resolution when this issue was last raised on a ballot from an HTTP document ballot.

-- Why is [SAMESITE] and [HTML] cited differently despite being the same spec.  [HTML] includes author names, but [SAMESITE] does not

# Internet AD comments for draft-ietf-httpbis-rfc6265bis-19
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S4.1.2.7

* Is there anything noteworthy about a Set-Cookie header that has both
  SameSite and Domain attributes?  How could they interact (if at all)?

### S5.1.3

* Does the canonicalization referred to here mean that described in S5.1.2?
  If so, S5.1.2 does not state that canonicalized form will be lower case.

## Nits

### S3.2.2

* "users agents" -> "user agents"?

I, too, am a fan of "infelicities" -- the word, its use in this document, and most of all, your care in illustrating several of said infelicities.

I echo the kudos from others about a very good work product here.

I support Eric's DISCUSS position.

Some of the SHOULD [NOT] instances in Section 4.1.1 could benefit from either conversion to MUST [NOT] or an explanation of the choice that's being left to implementers.  Same point in Section 5.8.3.

== Comments from Andy Newton, incoming ART AD ==

I agree with Gunter’s comment. This is a very well-written document, and many thanks go to the authors for their effort and commitment.

I do have one small observation. Section 5.7 has an ordered list with sub-lists. There seems to be an inconsistency in the “Otherwise:” sub-list between item 18 and the other items where an “Otherwise:” is embedded in a sub-list (for example items 9 and 10).

# Orie Steele, ART AD, comments for draft-ietf-httpbis-rfc6265bis-19 
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-httpbis-rfc6265bis-19.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

Thank you to Claudio Allocchio for the ARTART review.

### What year is it?

I suspect I'm about to embarrass myself with ABNF yet again...

```
598	   NOTE: Some existing user agents differ in their interpretation of
599	   two-digit years.  To avoid compatibility issues, servers SHOULD use
600	   the rfc1123-date format, which requires a four-digit year.
```

later:

```
911	      year            = 2*4DIGIT [ non-digit *OCTET ]
```

https://datatracker.ietf.org/doc/html/rfc1123#page-55

Perhaps a better reference than "rfc1123-date"

Would be: https://datatracker.ietf.org/doc/html/rfc6265#section-5.1.1 ?

I tripped on this ABNF, because:

https://www.rfc-editor.org/rfc/rfc3339.html#section-5.6

```
date-fullyear   = 4DIGIT
```

https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.1.1

```
year         = 4DIGIT
```

https://datatracker.ietf.org/doc/html/rfc9110#section-5.6.7

```
year         = 4DIGIT
```

https://datatracker.ietf.org/doc/html/rfc9165#section-3-7

```
date-fullyear   = 4DIGIT
```

Is "2*4DIGIT [ non-digit *OCTET ]" the correct way to signal the decimal numbers expected in cookies for year?

I suspect this is leftover from the 2 digit year case.

which was:

https://datatracker.ietf.org/doc/html/rfc822#section-5.1


```
date        =  1*2DIGIT month 2DIGIT
```

And was updated to:

```
date = 1*2DIGIT month 2*4DIGIT
```

But why is it not one of these:

```
date = 1*2DIGIT month 1*4DIGIT
date = 1*2DIGIT month 4DIGIT
``` 

## Nits

### BCP14 update

```
216	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
217	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
218	   document are to be interpreted as described in [RFC2119].
```

vvvv

```
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
```

Thanks for this clear update. My only nit is that "infelicities" is not a word I knew, and I'm a fairly decent english-not-my-first-language speaker. I recommend rephrasing the sentences where this word is used.

I would like to second Gunter's comments. This is a nicely written and easily understandable document.

I do have one comment, which you can feel free to ignore -- while "infelicities" is a perfectly cromulent word, I suspect many readers will not be familiar with it. This may not be an issue - most readers will likely be on a computer and so can easily look it up (and learn a cool new word at the same time).
If I were an author, I'd leave it as is, but then again, I'm a fan of Pratchett's Dictionary of Eye-Watering Words...

Thanks for working on this specification. 

I have following comments, I believe it would improve the specification if they are addressed -

# The following two normative behaviors could easily be part of section 3 overview. Is there any particular reason to put these in the introduction section ?

     To maximize interoperability with user agents, servers SHOULD limit themselves to the well-behaved profile defined in Section 4 when generating cookies.

     User agents MUST implement the more liberal processing rules defined in Section 5, in order to maximize interoperability with existing servers that do not conform to the well-behaved profile defined in Section 4.

# Who are "we" in section 5.2.2 's Note?

# Can we be more specific on how section 5.2.2.2 is related to set-cookies and cookies header specification? It was obvious that service worker implementation should follow the w3c specification, but how it that related to this specification? Is there any specifics that the implementer's of this specification must consider?