Hi all,
Here are some textchanges for the optional XHDR field of syslog.
This text can be "inserted" into the draf-04 version of syslog-sign.
As discussed before, it is both a "fix" of syslog (optional, and
describing actual behaviour) and "required" for syslog-sign. Due
to these changes, some sections in the draft rfc will be changed,
e.g. a renumbering.
Those changes are mentioned below; but I haven't included a diff/patch :-)
When "major" changes are proposed, I have include the (sometimes trimmed)
original (04) text first, then the improved/proposed text, and then a few
lines about the "about".
Hope this makes this mail useful and readable.
Section 1, NEW subsection (at the end of section 1)
1.1 Terminology
Within syslog-sign there are three kind of messages. First, each device
will send logmessages that contain information about the application
sending it. Below these messages will be called "normal syslog" messages,
or "application messages".
Besides these normal messages, a device will also generate 2 kinds of
special, auxiliary messages. These do not carry applicationlog, but
contain
information to facilitate the "sign" part. The are called "syslog-sign
special messages". There are two kind of special messages: "signature
blocks"
and "certificate blocks". See below for an explanation.
Whenever syslog messages outside the scope of syslog-sign are mentioned,
the
are denoted asd syslog-syslog messages.
ABOUT this text,
By a strict definitions of these 3 kind of messages, the text below
becomes
more simple.
Section 2, 3rd paragraph (which is on page 5) WAS: (it ends at "===")
The definitions of the fields are slightly changed in this document
from RFC 3164. [...]
better if the TAG field were to become a part of
the HEADER part rather than the CONTENT part. [...]
NEW proposed text:
The definitions of the fields are slightly changed in this document
from RFC 3164. While the format described in RFC 3164 is correct for
packet formation, the Working Group evaluating this work determined
that it would be better if the TAG field were to become a part of
the HEADER part rather than the CONTENT part. While IETF
documentation does not allow the specification of an API, people
developing code to adhere to this specification have found it
helpful to think about the parts in this format.
I Also, a new optional XHDR part is defined. As the daytime and host
field in the header have only limited resolution, a lot of devices
insert an extended version of these fields in the CONTENT field.
In section 2.3 the XHDR part is defined as RECOMMENDED for all normal
syslog (-sign) application messages, whereas it is REQUIRED for
syslog-sign special messages.
ABOUT this change
In general terms, this new field is introduced. With a sort
explanation why it is needed, both for syslog-syslog and for -sign
Section 2.3 is NEW (the current 2.3 becomes 2.4, etc)
2.3 XHDR part
Between the HEADER part and the MSG part, an extended header, the
XHDR part, can be used to store high resolution date, time and
originator information. For all sylog-syslog messages this field is
is OPTIONAL. It is RECOMMENDED for all messages created or handled by
implementations that can make use of syslog-sign.
It is REQUIRED for all syslog-sign special messages.
The XHDR part MUST contain the following 2 subfields:
X-DAYTIME and X-ORIGINATOR, and MAY contain extra header fields
for similar purpose.
There are no special separation characters between the subfields,
or between the XHDR and MSG part. The separation has to be done
by semantic analysis of the syslog message.
The sender (the syslog-device) SHOULD insert a space between them;
this is more for human readability then for recognition.
Whenever the XHDR part can not be identified by a collector, it (the
collector) MUST act as if there is no XHDR, and SHOULD see the
information as start of the free-formatted MSG/CONTENT field.
2.3.1 The X-DAYTIME field
The X-DAYTIME field is REQUIRED within the XHDR part. It
MUST carry the same information as the TIMESTAMP field, with
increased resolution. Both year/century information and sub-second
resolution will be added. Also the timezone MAY be stored.
As the TIMESTAMP is always is denoted in localtime, and the
X-DAYTIME MAY use UTC, numerically the information can differ.
It is RECOMMENDED to format the X-DAYTIME fields according to
internet timestamp standard [1; draft-ietf-impp-datetime-05.txt]
This formatting is REQUIRED for syslog-sign aware devices.
In short, this format is: "ccyy-mm-dd 'T' hh:mm:ss[.<sub>]<off>"
This format does not use any spaces. However the 'T' character
MAY be replaced by 1 space. It is RECOMMENDED to use the
capital T.
All fields (but the separators) are numerical. The subsecond
information (<sub>) is optional. Without this field the period
is NOT ALLOWED. The timezone is expressed as offset to UTC; a "Z"
may be used to express UTC is used.
The above description is informational only, RFCXXXX [1] is
leading.
For backwards compatibility, ISO timestamps are allowed too,
in syslog-syslog messages.
At least the ctime() format, with the C locale, SHOULD be
recognised. Optionally, timezone and/or subsecond resolution
MAY be added to this format. It is REQUIRED that collectors,
which read the XHDR part, support this ISO format. It is RECOMMENDED
to support all other ISO daytime formats that may be usable for the user.
Also, it is REQUIRED that these collectors are able to present
those alternative timestamps, as if they where normal timestamps.
(Only) whenever a collector can not handle the timestamp in the X-DAYTIME
field, it MUST use the timestamp of the TIMESTAMP field in the HEADER
part; and convert them as needed.
In short, the ISO formatting is "<dow> mmm dd hh:mm:ss[.sub]
[<timezone>] ccyy", ehere dow is the day of week in 3 positions
(Sun, Mon, Tue, Wed, Thu, Fri, Sat), sub is a fraction of seconds,
and timezone is either a name of the timezone, or the numerical
difference with UTC.
The above descriptions is informational only. The [ISO8601]
and [ISO8601:2000] revision is leading.
2.3.2 The X-ORIGINATOR field
The X-ORIGINATOR field is REQUIRED within the XHDR field.
Within this field, a unique originator of the message MUST be stored.
It is RECOMMENDED to use the FQDN here. But other originators, like
a hostname and a domain (NIS, MS, ..) are allowed too.
Whenever such a FQDN (or similar) still can be ambiguous, other
information MUST be added, to make it unique. This situation can
arise by (e.g.) multi-daemon, multi-processor or multi-threading
systems.
In this case, two colon's ("::") SHOULD be inserted between the FQDN
(or simulair) and the extra information.
There SHOULD NOT be any space in this field
2.3.3 Other X-fields
The are no other X-fields defined, nor REQUIRED. However it is
RECOMMENDED that whenever an implementation does need other high-
resolution header fields, they are conceptually situated at the end
of the XHDR field. And not at the start of the MSG/CONTENT field.
Those fields SHOULD be OPTIONAL and a relay or collector MUST NOT
depend on them.
2.3.4 Example
Whenever it was logged when this line is typed
"2002-02-028T16:02:27.87+00:20 laptop.ons-huis.net::PC"
would be an excellent XHDR field.
The suffix "::PC" is needed, since this system can both be used
in a Windows/PC mode and in a FreeBSD/Unix mode. Both share the
same FQDN.
===
ABOUT this text
It speaks for itself, I hope.
See http://www.ietf.org/internet-drafts/draft-ietf-impp-datetime-05.txt
for info about [1]
Probably, the 2.3.4 example should move to 2.4 (now 2.5)
Section 3.1. syslog Packets Containing a Signature Block WAS
Signature block messages MUST be completely formed syslog messages.
Signature block messages have PRI, HEADER, and MSG parts as
described in Sections 4.1.1 and 4.1.3 of [RFC3164]. [...]
The CONTENT field of the syslog signature block messages
have the following fields.
NEW proposed text
Signature block messages MUST be completely formed syslog messages.
Signature block messages have PRI, HEADER, XHDR and MSG parts as
described in sections 4.1.1 and 4.1.3 of [RFC3164], and in
section 2.3 of this RFC. There are no optional fields, all are
mandatory.
All fields should be filled in by the device, as described
in sections mentioned above.
Note: the TAG and X-ORIGINATOR SHOULD be equal to those fields
of the normal syslog messages of which the signatures are calculated.
The CONTENT field of the syslog signature block messages
have the following fields.
ABOUT this change
As before, a little change to denote the REQUIREMENT of this
extended header.
I also changed the "syslog" value for the TAG field. There where
discussions before; but now I'm really working with it, I don't see
any reason not to fill in the "normal" TAG (of the device).
Read: when the application itself calls syslog() to send the
signatures, that tag will be used! (Think about it, it is an option!)
There should also be a change in the description of certificate blocks.
But the format of that message isn't described explicitly, yet
Some more little changes will be needed, to. But I assume they will come in
automatically, like the Toc, my name in C10/11, and the references.
Hope this text is clear. But shoot when it isn't! Then those improvements
can be used for the 05 draft.
Is that one planned already ;-)
--ALbert
sent mail to [EMAIL PROTECTED], to address me personal.
sent mail to [EMAIL PROTECTED], to address me for businesses
