[http-state] [Technical Errata Reported] RFC6265 (4044)

[RFC Errata System]

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

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6265&eid=4044

--------------------------------------
Type: Technical
Reported by: Pierre Lepropre <plep...@gmail.com>

Section: 5.3

Original Text
-------------
Otherwise:

Set the cookie's persistent-flag to false.

Set the cookie's expiry-time to the latest representable
date.


Corrected Text
--------------
Otherwise:

Set the cookie's persistent-flag to false.

Set the cookie's expiry-time to the latest representable
date. This is a best-effort approach to ensure that the cookie
will effectively expire when "the current session is over"
(as defined by the user agent) and not anytime before.

Notes
-----
The second action item isn't necessarily obvious for an implementer/reader. If I got the intention right, then I believe it might improve the "user-friendly" rating of this document. Otherwise, it might still be beneficial to explicit a bit the reasoning behind that action.

Instructions:
-------------
This errata 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 (IESG)
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

[Adam Barth]

I don't think we should accept this errata. This errata adds
non-normative text that isn't strictly correct.

Adam

[Barry Leiba]

The point of errata, though, is to record errors in the documents... not to suggest improvements.  I don't see that either of these is reporting an error.  Do you?

There is an issue here: we need a way to record comments and suggestions, and we don't have that.

But given what errata are meant for, my inclination is to mark both of these as "rejected", much as I appreciate the value of your comments.

Barry, Applications AD

On Sunday, July 6, 2014, Pierre Lepropre <plep...@gmail.com> wrote:

Hello Adam,

As I stated in the notes, whether I got it right or wrong doesn't really matter in my opinion.

In either case, the second action item might seem a bit surprising.

If it is stated that way, it's probably because there is a reason behind it. Basically, I'm just suggesting to enhance a bit the explanation behind it.

Regards,

Pierre.

[Pierre Lepropre]

Hello Barry,

I guess you're right on this one; this is clearly a comment/suggestion of improvement. The RFC isn't in error there. My mistake, sorry.

Taking this comment into consideration, I'm a bit hesitating regarding my other request (ID 4043) because I still think there might still be some room for it to be valid.

Well, anyway, I'm not the one who decides :).

Regards,

Pierre.