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

From: "NARUSE, Yui" <[email-masked]>
Date: Sat, 23 Jan 2010 02:07:46 +0900

I sent this from [email-masked] 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.

= 5.1.1.  Dates

Why it needs such a complex definition?
Its demerit is clear in ticket #7.

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

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.

If make cookie-date exotic or RFC 3339 (ISO 8601 related RFC),
the syntax would be following:

  cookie-date      = rfc3339-datetime / obs-cookie-date
  rfc3339-datetime = <date-time, as defined in RFC 3339>
                   ; YYYY-MM-DDTHH:MM:SSZ
                   ; YYYY-MM-DDTHH:MM:SS+09:00
  obs-cookie-date  = <Wdy, DD-Mon-YYYY HH:MM:SS GMT> ; not RFC 2822

-- 
NARUSE, Yui  <[email-masked]>

-- 
NARUSE, Yui
[email-masked]

---

From: Adam Barth <[email-masked]>
Date: Fri, 22 Jan 2010 09:33:11 -0800

> 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.

> 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.

> 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.

> Current algorithm make things too complex but still can't express timezone.

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