Re: Meaning of invalid but well-formed dates

Brian Smith wrote:
> Everything is clearly specified, but you need to navigate a circuitous route
> to find the definitions. HTTP-date time is defined in terms of RFC 1123's
> date construct. RFC 1123's date construct is just RFC 822's date-time

Actually, it's not. At least it's not intended to. The reference to RFC 
1123 is to explain where it comes from, and is informative.

> extended to support four-digit years. RFC 822 already restricted date-time
> constructs to semantically valid dates. RFC 2822 obsoleted RFC 822 and RFC
> 5322 obsoleted 2822. RFC 5322 clearly specifies the meaning of each
> component of the date-time construct, including four-digit years.
> 
> The HTTP spec. shouldn't be referencing RFC 1123 anymore. RFC 1123's date
> construct isn't really the same as what HTTP calls rfc1123-date so the name
> is misleading; "date-time" could be a better name. If the components of
> HTTP-date were renamed to match the names in RFC 5233 then the specification
> could then say:
> 
>    The semantics of <date-time>, <day-name>, <day>,
>    <month-name>, <year>, and <time-of-day> are the
>    same as the semantics of the RFC 5322 constructs
>    with the corresponding name.

That sounds like a good idea.

> Also, the statement "[...]; it MUST be sent in rfc1123-date format" should
> be removed from section 8.3 (Date), because section 3.2.1 already says:

As a matter of fact, 8.3 already refers to RFC5322 for semantics. 
Probably that should just be moved up to Section 3.2.1.

Also, the duplication was introduced in RFC 2616 (it's not present in 
<http://tools.ietf.org/html/rfc2068#section-14.19>).

>    [Implementations] MUST only generate the RFC 1123 format for
>    representing HTTP-date values in header fields.
> 
> It is straightforward to replace the other RFC 1123 references with RFC 5322
> references.

Best regards, Julian

Received on Monday, 4 May 2009 07:05:08 UTC