RE: Issue 163, was: Meaning of invalid but well-formed dates

Julian Reschke wrote:
> Brian Smith wrote:
> > ...
> > I think that does make the grammar more readable.
> >
> >>     The semantics of day-name, day, month, year, and time-of-day are
> >>     the same as those defined in the RFC 5322 constructs with the
> >>     corresponding name ([RFC5322], Section 3.3).
> >
> > This wording is a little off. Try:
> >
> >       The semantics of day-name, day, month, year, and time-of-day
> are
> >       the same as semantics of the RFC 5322 constructs with the
> >       corresponding name ([RFC5322], Section 3.3).
> 
> That doesn't sound better to me, but that may be caused by me not being
> a native English speaker.

"...defined in the RFC 5322 constructs..." means the definition is inside
the construct. I thnk you meant "...defined in RFC 5322 for the
constructs...".

> > Note that this change resolves the issue for rfc1123-date but not for
> > the obsolete forms.
> 
> Yes, I already pointed that out. Do you have a proposal how to get
> there (which would to consider existing implementations)?

The only instances of this problem are one-digit days in asctime-date (just
prepend a zero to get a day), day-name-l (just drop all characters after the
first three to get a day-name), and two-digit years. I doubt there is an
interpretation of two-digit years commonly accepted by all implementations.
Probably the most common implementation is to either ignore dates using
rfc850-date format and/or return (400) errors when rfc850-date is
encountered. That is what all my implementations do. Accordingly, I don't
think support for rfc850-date should be a MUST- or even SHOULD- level
requirement.

Regards,
Brian

Received on Monday, 18 May 2009 16:22:39 UTC