Re: [http-state] cookie-date syntax and algorithm

[Adam Barth <[e-mail]>]

On Fri, Jan 22, 2010 at 9:07 AM, NARUSE, Yui <[e-mail]> wrote:
> I sent this from [e-mail] but it seems not accepted,
> so I post this again.
>
> Anyway,
> draft-ietf-httpstate-cookie-02 says in 4.1.1. Syntax,
>
>   cookie-date       = <rfc1123-date, as defined in RFC 2616>
>
> But you know, cookie-date is not rfc1123-date.
> It's a original exotic date format.
>
>   rfc1123-date = <Wdy, DD Mon YYYY HH:MM:SS GMT>
>   rfc850-date  = <Weekday, DD-Mon-YYYY HH:MM:SS GMT>
>   asctime-date = <Wdy, Month dd HH:MM:SS YYYY>
>   cookie-date  = <Wdy, DD-Mon-YYYY HH:MM:SS GMT> ; not RFC 2822
>
> Current description causes misunderstanding.

If you read the requirements in Section 4.1.1, you'll see that we
recommend (but do not require) servers use this syntax.  User agents
are required to process the exotic format.

> = 5.1.1.  Dates
>
> Why it needs such a complex definition?

This complex definition is required so that user agents can
interoperate with servers that send dates in exotic formats.

> Its demerit is clear in ticket #7.

Ticket 7 is about testing.  We're aiming to test everything in the spec.

> It seems to intend to change cookie-date from current exotic format
> to exact rfc-1123-date or something in future, but why?

We're recommending that servers use a sane date format even though
user agents are required to process insane date formats.  This advice
appears sound to me.

> Recently, many specs are using ISO 8601 Date and Time format (or other
> related specs).
> So formats they really needed are only exotic and ISO 8601.
> Current algorithm make things too complex but still can't express timezone.
> So I object this.

As distasteful as we might find the exotic date format, it's a sad
reality that user agents encounter insane dates on a regular bases.
Unlike some of the other instances where I push for precise error
handling, in this case, we have ample examples of servers sending
insane dates.  To wit:

http://github.com/abarth/http-state/blob/master/notes/2009-08-11-Dan-Winship.txt

To respond to your statement with a finer point: user agents who use
ISO 8601 dates will be unable to interoperate with a large number of
servers.  Therefore, the ISO 8601 dates are unacceptable for our
purpose here.

Adam