Hi Petter and Everyone,
At 02:25 PM 10/12/00 +0800, Petter Reinholdtsen wrote:
>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.
That's a good point. We are, however, writing the "observed"
behaviour of the syslog protocol. Can you or anyone else provide
examples of messages that have been observed in the wild that do
contain characters as you describe? I'll be glad to re-qualify
the character set if we can document that messages have been
observed that do contain them.
Let's also be sensitive to the fact that there are syslog message
interpreters out there. If we do find additional characters in the
wild, can we confirm that they are acceptable to the better known
packages? I'm thinking of swatch; are there others that we should
consider? Could anyone on the list take a look through swatch and
see if it has any constraints about the character set that it will
accept? I really don't want to make any changes to the acceptable
behaviour of syslog that will have bad affects on good programs
like swatch.
>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.
hmm... I pulled those values from an old note.
====================================================================
#define LOG_CRON (9<<3) /* clock daemon */
#define LOG_AUTHPRIV (10<<3) /* security/authorization messages (private) */
#define LOG_FTP (11<<3) /* ftp daemon */
====================================================================
I've just found another reference that LOG_AUTHPRIV was deprecated
so I don't mind removing it and placing (10<<3) into the "reserved"
group. I can't find any recent references to LOG_FTP so that one
could also go into "reserved". If anyone objects, please post to
the list and we'll discuss.
I did find something else strange. On different Sparcs, I'm finding
that the file /usr/include/sys/syslog.h contains the following:
====================================================================
#define LOG_UUCP (8<<3) /* uucp subsystem */
#define LOG_CRON (15<<3) /* cron/at subsystem */
/* other codes through 15 reserved for system use */
#define LOG_LOCAL0 (16<<3) /* reserved for local use */
====================================================================
Is this file used in Solaris?
>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.
I see what you're saying. When I wrote that, I was trying to say that
the relay MUST NOT tamper with any of the contents of the message. It
will, of course act like any other node on the Internet and use its
own address when re-transmitting the message. I'll clean up the
language to make that clear.
>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.
I think that there is an ITU standard on dates/times as well. I'll
track that down and make a point of it in the draft. This may also
work in the subsequent IDs.
>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.
OK.
>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.
Good idea. I'll place a good example of the best practices for including
FQDN, address, proper date/time, name/pid and clear information.
>--
>##> Petter Reinholdtsen <## | [EMAIL PROTECTED]
Thanks for the review and your comments. I'll get together a new draft
with several of these items worked in. Please let me know about the
character set.
Thanks,
Chris
