Re: #375: Most Conservative (caching and date parsing)

Dear Mark and Amos,

2012/7/16 Mark Nottingham <mnot@mnot.net>:
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/375>
>
>> If an HTTP header field incorrectly carries a date value with a time zone other than GMT, it must be converted into GMT using the most conservative possible conversion.
>
> What does "most conservative" mean?
>
> "Earliest" makes sense for Expires and Date, but Last-Modified it would seem that "latest" is the most conservative.

For Expires, I agree.  For the latter two cases it seems to be
depending on further application contexts.

Also, I argue how to determine possible choices from which the
"conservative" one is chosen.
If some implementers are willing to follow the "must be" request,
should they have
tables of all possible time-zone conversions and conflicts like below?

CST: American Central Standard Time (-6) or China Standard Time (+8)
and two more
EST: American Eastern Standard Time (-5) or Australian Eastern
Standard Time (+10)
(much more conflicts exist)

# http://www.timeanddate.com/library/abbreviations/timezones/ lists up
# 4 different offsets for CST, 3 for IST, CDT and WST, and 2 for many symbols.

My personal proposal is instead of adding any examples, state it like "it may be
converted to GMT using whatever methods they think appropriate", emphasizing
senders' responsibility for sending GMT times.  This text still allows
implementers
to convert CST to either -5 or -6 or +8 or +9.30 according to their
applications'
nature or request IP address or whatever information available,
or to choose the "appropriately conservative" one between -5 and +9.30.

-- 
Yutaka OIWA, Ph.D.              Leader, Software Reliability Research Group
                             Research Institute for Secure Systems (RISEC)
   National Institute of Advanced Industrial Science and Technology (AIST)
                     Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

Received on Monday, 16 July 2012 13:48:00 UTC