> John and Jon have updated syslog-sign:
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-12.txt
[[Grrr]]. Every time I continue on implementing draft-N, J&J come
up with draft-<N+1>. I never catch up, that way :-)
However, I will switch to draft-12 now. And will comment it as soon I
find thing "hard" to implement.
The first one's are found:
sec 2.2 TIMESTAMP(3339)
=======================
Are the following timestamps allows/wanted?
(1) 2003-08-26T12:01:00-00:00
(2) 2003-08-26T12:02:00.+02:00
(3) 2003-08-26T12:03:00.12345678901Z
Ad 1. This an UTC time, but with an offset of zero instead of a "Z"
to denote UTC. I have implemented this, while it easy to do.
(less code) and it seams to be allowed.
Ad 2. Currently this is not allowed. There should be at least 1
digit after the (fracseconds) dot. ("1*DIGIT")
I can live with this. But I often see a construction like
this; e.g. to denote "the fraction is unknown/unaccurate".
Possible we should allow it (but I'm NOT asking for it)
Ad 3. When a TZ offset is used, there is only "space" for
6 secfrac digits ("millisecond"). When UTC is used (with "Z")
the resolution can be increased with 3 digit ("microseconds").
I think we should not "allow" that. And change the syntax to
allow upto 6 digits, for all timezones.
Then, the limit 'upto 32 positions' for the complete timestamp
is met, always.
sec 2.1 PRI
===========
As Chris explained, syslog-sign is/will be the "official standard" for
syslog, not rfc3164. It's improved. So we can also remove "historical
limits". The upper value of "191" for PRI (local7.debug) is such a limit.
Without changing the protocol (which has space for 3 digits ("999"), we
can extent this. It's not simple to add severities, but we can add
facilities with out braking anything.
999 happens to be 124*8+7. So I propose to extent the allowed facilities
to 124.
This gives a lot of possibilities for new numbers. Here, we have the
four options:
First, simply add "local8" to "local108".
Second, assign some `new numbers' to 'new, modern items' (e.g. Web, ssh,
virus, database,..)
Third, we make it "assigned numbers" (like ports etc), and define the
"outside this rfc". Then, it is possible to extent syslog-numbers, as
needed. Possible, this can/must be done by IANA.
Last, we can assign some numbers, and define the rest as "reserved" (but
allowed).
Personally, I would vote for option 3.
To extent the facilities, we only have to add 1 of 2 paragraphs to
section 2.1. When requested, I'm willing to propose one.
NOTE: I Agree, this remark is late. I was always on the track "keep in
inline with rfc3164", but the mail of Chris has shown me we are allowed
to improve syslog. I think this simple change is a big improvement! (Let
face it, the current "name/numers" are old)
--ALbert Mietus
Send prive mail to: [EMAIL PROTECTED]
Send business mail to: [EMAIL PROTECTED]
