From: Rainer Gerhards (rgerhards@hq.adiscon.com)
Date: Thu Oct 02 2003 - 12:24:55 CEST
> Rainer Gerhards wrote:
> > As you probably know, the IETF has recently created some
> new RFCs and
> > Intnet Drafts (to become RFCs) on syslog. This work
> includes additional
> > header format and specifically an enhanced timestamp format.
>
> Could you quote the relevant paragraphs and also add a link to the
> draft?
Sorry for omiting the links.
The IETF workgroup activity in general is detailled here:
http://www.employees.org/~lonvick/index.shtml
The syslog-sign draft with the updated TIMESTAMP format is here:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-12.txt
The relevant quote is in section 2.2, starting on page 7:
####
The TIMESTAMP field is either a timestamp as defined in RFC 3164
denoted as TIMESTAMP-3164, or as a formalized timestamp as taken from
RFC 3339 [20]. A sender SHOULD format the timestamp as a RFC 3339
timestamp described below as TIMESTAMP-3339. A receiver MUST accept
both formats.
A single space character MUST follow the TIMESTAMP field regardless
of the format used.
The TIMESTAMP-3164 is the local time and is in the format of "Mmm dd
hh:mm:ss" (without the quote marks) where:
Mmm is the English language abbreviation for the month of the year
with the first character in uppercase and the other two characters
in lowercase. The following are the only acceptable values:
Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
dd is the day of the month. If the day of the month is less than
10, then it MUST be represented as a space and then the number.
For example, the 7th day of August would be represented as "Aug
7", with two spaces between the "g" and the "7".
hh:mm:ss is the local time. The hour (hh) is represented in a
24-hour format. Valid entries are between 00 and 23, inclusive.
The minute (mm) and second (ss) entries are between 00 and 59
inclusive.
The following syntax MUST be used when using a TIMESTAMP-3339. This
is specified using the syntax description notation defined in [ABNF].
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap
; second rules
time-secfrac = "." 1*DIGIT
time-numoffset = ("+" / "-") time-hour ":" time-minute
time-offset = "Z" / time-numoffset
partial-time = time-hour ":" time-minute ":" time-second
[time-secfrac]
full-date = date-fullyear "-" date-month "-" date-mday
full-time = partial-time time-offset
date-time = full-date "T" full-time
RFC 3339 makes allowances for multiple syntaxes for a timestamp to be
used in various cases. This document mandates a single syntax. The
primary characteristics of TIMESTAMP-3339 used in this document are
as follows.
o the "T" and "Z" characters in this syntax MUST be upper case.
o usage of the "T" character is mandatory. It MUST NOT be replaced
by any other character (like a space character).
o the sender SHOULD include time-secfrac (fractional seconds) if its
clock accuracy permits.
o the entire length of the TIMESTAMP-3339 field MUST NOT exceed 32
characters.
Two samples of this format are:
1985-04-12T23:20:50.52Z
1985-04-12T18:20:50.52-06:00
The first represents 20 minutes and 50.52 seconds after the 23rd hour
of April 12th, 1985 in UTC. The second represents the same time but
expressed in the Eastern US timezone (daylight savings time being
observed).
Messages containing Signature Blocks and Certificate Blocks as
described in this document SHOULD use the TIMESTAMP-3339 format in
the TIMESTAMP field. It is not mandated that they do so at this time
since most of the receivers in use today will not be able to
understand that format and may modify those packets in accordance
with Section 4.3 of RFC 3164.
A single space character MUST follow the TIMESTAMP field.
Receivers parsing the date format SHOULD check if the TIMESTAMP is a
TIMESTAMP-3339. The "T" character at position 11 of the string can be
used as a rough indication for this. However, the receiver MUST NOT
rely solely on the "T" character but also parse the other data for
validity. A receiver SHOULD check for TIMESTAMP-3339 format first
and, if unsuccessful, assume a TIMESTAMP-3164. If it is also not a
TIMESTAMP-3164 format, the receiver MUST NOT try any other timestamp
format but consider the TIMESTAMP to be invalid or missing from the
received syslog message.
If a relay receives a TIMESTAMP-3164, it SHOULD forward the message
with a TIMESTAMP-3164 but MAY reformat it to a TIMESTAMP-3339 if
configured to do so. Relays should be aware that the TIMESTAMP-3339
may be longer than the TIMESTAMP-3164 and a replacement of the
TIMESTAMP-3164 with a TIMESTAMP-3339 may increase the length of the
entire packet beyond 1024 bytes. If a relay receives a
TIMESTAMP-3339 it MUST forward the message with a TIMESTAMP-3339. It
MUST NOT reformat it to a TIMESTAMP-3164.
####
This is not yet a RFC, but has undergone considerable peer review and to
the best of my knowledge, it is very unlikely that the timestamp format
will change before it finally becomes an RFC. There are already
implementations of this out, on Windows our MonitorWare product line and
on *NIX SDSC syslogd. I think Albert Mietus has also upgraded the BSD
syslogd to support the new format - he already has added syslog-sign
support to it, so it probably supports the timestamp, too.
Just as a reminder: if you dislike anything that is written in the
Internet Draft, simply go the IETF syslog-sec workgroup mailing list and
post your concerns there. After all RFC means "Request For Comment" ;)
I hope this posting now makes more sense.
Thanks,
Rainer
This archive was generated by hypermail 2.1.7 : Thu Oct 02 2003 - 12:25:09 CEST