Chris,
> Rainer is saying that no one is following the timestamp as
> described in 3164 anyway so we should take this opportunity
> to standardize upon something suitable to the community.
> Making this change will entail the
> following:
>
> - Text will have to be provided.
>
> - A note will have to be appended in the syslog-sign ID to
> state that relays should be liberal in what they receive.
>
> - Another note will have to tell people deploying syslog-sign
> that will have to ensure that no relay will modify messages
> between the device and the collector.
>
> - RFC-3195 may have to be revised to state that it will
> accept additional time formats.
>
> Is there any violent opposition to doing this? If none,
> would someone propose some suitable text?
>
I have tried to provide some new text for syslog-sign, section 2.2 where
the TIMESTAMP is described. It is my first try in RFCish style, so all
please bear with me ;-)
------ begin of proposed text -----
The TIMESTAMP field is either a RFC3164-TIMESTAMP or a
RFC3339-TIMESTAMP. A sender SHOULD format the timestamp as a
RFC3339-TIMESTAMP. A receiver MUST accept both formats.
The RFC3164-TIMESTAMP 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 RFC3339-TIMESTAMP is as specified in [RFC3339]:
The following syntax MUST be used when using a RFC3339-TIMESTAMP. 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
Other than in RFC3339
- the "T" and "Z" characters in this syntax MUST be in upper case.
- usage of the "T" character is mandatory. It MUST NOT be replaced by
any other character (like a space character).
- the sender SHOULD include time-secfrac (fractional seconds) if its
clock accuracy permits so
- the timestap SHOULD be formatted in UTC format ("zulu" time)
A sample of this format is:
1985-04-12T23:20:50.52Z
This represents 20 minutes and 50.52 seconds after the 23rd hour of
April 12th, 1985 in UTC.
For complete details and samples see RFC3339.
A single space character MUST follow the TIMESTAMP field.
Receivers parsing the date format SHOULD check if the TIMESTAMP is a
RFC3339-TIMESTAMP. 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 RFC3339-TIMESTAMP format first and, if
unsuccessful, assume a RFC3164-TIMESTAMP. If it is also not a
RFC3164-TIMESTAMP the receiver MUST NOT try any other timestamp format
but consider this message to be invalid.
A relay MUST NOT reformat the time stamp. This could create a wrong
concept of time accuracy at the next receiver. If a relay receives a
RFC3164-TIMESTAMP, it MUST forward the message with a RFC3164-TIMESTAMP
and similarly if a relay receives a RFC3339-TIMESTAMP it MUST forward
the message with a RFC3164-TIMESTAMP.
------ end of proposed text -----
There besides section 2.2, there are is other wording to be changed in
syslog-sign if the spirit of above proposal is accepted. I am not
providing any suggestion for that by now, as I guess we will need to
reach consensus on the above first before going any further...
Please note that I myself have not totally made up my mind if the
suggestion to use UTC is really a good one. On the pro side, this will
make log analysis (of stored text file logs) much easier. On the other
hand, we loose the information of the time zone the exact device is in.
Looking forward to all comments,
Rainer
