> Please review this and send in your comments to the mailing list.
Here are my comments on the syslog draft v00.
The first thing I noticed was the lack of form feed characters between
the pages. This made it hard to get a good looking printout. Is it
no longer required in RFCs? I suggest putting them in there anyway.
In section 3, 'Packet Format and Contents', the text reads:
The code set is seven-bit ASCII in an eight-bit field. These are
the ASCII codes as defined in "USA Standard Code for Information
Interchange" [2] only using codes 32 through 126.
I strongly suggest not doing the same mistake as where done in RFC 822
when email was standardized. I see no reason to limit the syslog
messages to a seven bit code set, but I do see a number of problems.
Why should norwegian, french, swedish and almost everyone but the
english speaking peoples in the world not confirm to the syslog
standard when we send syslog messages containing our languages
characters.
I suggest allowing eight-bit transmittion of codes 32-126 and 160-254.
The lower 32-126 should be required to be ASCII, but the upper part
should be left to the user. I suggest recommending ISO 8859/1 as the
common charset, but I do not believe it can be part of the standard.
In section 3.1, it is not very clear what is the difference between
code 32 "security/authoriszation messages" and 80
"security/authoriszation messages". I suggest writing something about
the difference.
In section 3.2, I do not quite understand how the last sentence is to
be interpreted. What is the originating device? If it is what I
believe it is, the requirement is impossible to follow when the
hostname is missing from the message. Assuming the following setup:
<originator> -> <relay> -> <collector>
If the message do not contain the hostname of the originator, there is
no way for the relay to make the message appear to have been sent from
the originator when it is received by the collector. In this case, as
far as I know, the only way for the collector to find out where the
message came from is to look at the IP header, and it will give the
address of the relay, not the originator.
In the conventions, I suggest recommending a date format including
four digits year and timezone in numbers (ie. like +0000, not GMT).
To make it easier to process the date format, I suggest recommending
the ISO 8601 date format. This is 'YYYY-MM-DDTHH:MM +TZTZ', now would
then be '2000-10-12T14:05+0800'. A quick search on the web suggested
<URL:http://www.cl.cam.ac.uk/~mgk25/iso-time.html> as a nice page to
read about this format.
Parhaps it is a good idea to change the examples to contain better
dates? Unless there are some more examples, I expect implementors
will look at the examples in section 3 and believe dates should have
the given format.
I also sugggest listing the common way to include program name and
process id, namely 'program[pid]: ' after the date and hostname.
I believe the conventions part of the draft should be extented to
include some examples on recomented use. I suggest recommending
<pri> date devicename/ip-address progname[pid]: info
as the prefered way to include the common parts in a syslog message.
--
##> Petter Reinholdtsen <## | [EMAIL PROTECTED]
