Code change:
store arbitrary data in a cookie-value SHOULD encode that data, for example, using Base64 RFC4648. <del> The domain-value is a subdomain as defined by RFC1034, Section 3.5, and as enhanced by RFC1123, Section 2.1.  Thus, domain-value is a string of USASCII characters, such as one obtained by applying the "ToASCII" operation defined in Section 4 of RFC3490. </del> Per the grammar above, the cookie-value MAY be wrapped in DQUOTE characters.  Note that in this case, the initial and trailing DQUOTE characters are not stripped.  They are part of the cookie-value, and will be included in Cookie header fields sent to the server. <ins> The domain-value is a subdomain as defined by RFC1034, Section 3.5, and as enhanced by RFC1123, Section 2.1.  Thus, domain-value is a string of USASCII characters, such as one obtained by applying the "ToASCII" operation defined in Section 4 of RFC3490. </ins> The portions of the set-cookie-string produced by the cookie-av term are known as attributes.  To maximize compatibility with user agents, servers SHOULD NOT produce two attributes with the same name in the same set-cookie-string.  (See storage-model for how user agents handle this case.) <ins> NOTE: The name of an attribute-value pair is not case sensitive.  So while they are presented here in CamelCase, such as "HttpOnly" or "SameSite", any case is accepted.  E.x.: "httponly", "Httponly", "hTTPoNLY", etc. </ins> Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name.  (See set-cookie for how user agents handle this case.)

Related discussion:
text: Maybe this super elegant solution (but the above ABNF would have to be tweaked):
FWIW nameless and valueless cookies are no longer RFC compliant after URL Up until then only Set-Cookie strings with empty names and empty values weren't accepted, but there were ways around this to get empty-name-empty-value cookies into user agents' cookie jar using the CookieStore API.
There are nameless cookies and there are valueless cookies (and, as you said, there are no nameless-and-valueless cookies). FWIW, the syntax in section 4.1.1 where is defined is a SHOULD, not a MUST, on the server's part. I think one issue is that reusing it to define makes that also implicitly a SHOULD, if I'm reading this correctly: Edit: To clarify, I'm thinking there's no accuracy issue with the spec as written, since if the server does things as recommended (and sends a cookie with name=value), then the user agent will respond as given by . But that is still totally confusing, at least to me, so I think we should still define this better.
(love the ambiguities of english -- thanks for the explicit callout and pointer to NAME
In the nameless cookie case, it seems that an unhandled edge case arises because of the following, from the section: To illustrate the problem with some examples: if is empty and is , the algorithm above works - the resulting cookie line would be if is empty and is , though, the resulting cookie line would be , which would be interpreted as a cookie with name and value . One solution for this, which is currently specified by the , is to forbid cookies with an empty name and a value containing '=' from being set. Limiting from containing a '=' is not mentioned in the section or the section of RFC6265bis, though. It seems like using the following in the section would be a better approach: This would fix the issue in the example above (the resulting cookie lines would be and respectively, both of which would be interpreted correctly). If we want to allow to be produced in the first case, we could replace step 2 above with something like: I'll submit a PR for this change.
The empty-name-but-nonempty-value case is serialized as and not for historical/compat reasons. There's some earlier discussion in .