[http-state] [Editorial Errata Reported] RFC6265 (6093)

[RFC Errata System]

The following errata report has been submitted for RFC6265,
"HTTP State Management Mechanism".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6093

--------------------------------------
Type: Editorial
Reported by: Attila Gulyas <tora...@gmail.com>

Section: 3

Original Text
-------------
Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field. The usual mechanism for folding HTTP headers fields (i.e., as defined in [RFC2616]) might change the semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding.



Corrected Text
--------------
Origin servers SHOULD NOT combine multiple Set-Cookie header fields into a single header field. The usual mechanism for combining HTTP headers fields (i.e., as defined in [RFC2616]) might change the semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such actions.

Notes
-----
RFC 6265 currently uses the verb "folding" when it refers to combining multiple header fields into one, which is ambiguous in the context of the HTTP/1 specs (both by RFC2616 and RFC 7230) where "folding" consistently refers to line folding, and the verb "combine" is used to describe merging same headers. Having a light HTTP knowledge, I naively started looking up "folding" in the HTTP specs, and was immediately confused by the results, others will probably be as well (especially is English is not their native tongue).

Examples to prove this consistency:
+ RFC 2616, Section 4.2, Message Headers, but searching for the for the word "combine" will bring up special cases.
+ RFC 7230, Section 3.2.2, Field Order
+ RFC 2616, Section 2.2, Basic Rules
+ RFC 7230, Section 3.2.4, Field Parsing

Thank you!

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC6265 (draft-ietf-httpstate-cookie-23)
--------------------------------------
Title : HTTP State Management Mechanism
Publication Date : April 2011
Author(s) : A. Barth
Category : PROPOSED STANDARD
Source : HTTP State Management Mechanism
Area : Applications
Stream : IETF
Verifying Party : IESG

_______________________________________________
http-state mailing list
http-...@ietf.org
https://www.ietf.org/mailman/listinfo/http-state