Subject: Syslog-sign and BCP 18/ RFC2277
From: Rainer Gerhards <[email-masked]>
Date: Fri, 1 Aug 2003 11:55:02 +0200

Hi all,

RFC2277 says:

"  Protocols MUST be able to use the UTF-8 charset, which consists of
   the ISO 10646 coded character set combined with the UTF-8 character
   encoding scheme, as defined in [10646] Annex R (published in
   Amendment 2), for all text.

   Protocols MAY specify, in addition, how to use other charsets or
   other character encoding schemes for ISO 10646, such as UTF-16, but
   lack of an ability to use UTF-8 is a violation of this policy; such a
   violation would need a variance procedure ([BCP9] section 9) with
   clear and solid justification in the protocol specification document
   before being entered into or advanced upon the standards track.
"

Syslog-sign does not support UTF-8 as it requires 7 bit clean data.

Do we have an issue here?

Rainer

------------------------------

Date: Fri, 01 Aug 2003 15:28:53 -0400
From: [email-masked]
Subject: I-D ACTION:draft-ietf-syslog-international-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF.

	Title		: Syslog-international Protocol
	Author(s)	: R. Gerhards
	Filename	: draft-ietf-syslog-international-00.txt
	Pages		: 13
	Date		: 2003-8-1

This document describes syslog-international, a mechanism adding
support for international character sets to syslog.
Syslog-international provides these features in a way that has no
requirements and no impact on existing syslog implementations. It is
possible to support syslog-international and gain some of its
functionality by only changing the behavior of the devices generating
syslog messages. Some additional processing of the received syslog
messages may realize additional benefits. There is no need to change
syslog relays in order to support syslog-international. Existing
syslog implementations will benefit from the fact that
syslog-international supporting devices emit proper syslog messages
in all cases. It is common practice for many non-syslog-international
clients to accidently emit 8 bit characters if used in e.g. European
language environments. Syslog-international just adds a protocol
layer to the MSG part of the syslog message. As such, it is
compatible with all existing and future implementations of syslog.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-international-00.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-syslog-international-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-syslog-international-00.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------------------------------

Date: Tue, 5 Aug 2003 18:59:22 +0200
From: Rainer Gerhards <[email-masked]>
Subject: New RFC 3195 Library

Hi WG,

I am happy to announce that we have an intial version of our logging
library available. It is open source, comes with a BSD license and
compiles both under Win32 and Linux (verified with Red Hat 8.0).

So far, it implements RFC 3195 RAW only. The main difference to the
existing BEEP libraries supporting the same profile is ease of use. We
have a very simple API (just 6 methods) and require no specifc threading
model (at least for the initiator).

See http://www.monitorware.com/liblogging/doc/srAPI_8c.html for a quick
overview.

Interoperability testing has been done with SDSC syslogd and went well.

The lib is far from being completed, but it may even be useful in its
current form, so I thought I release the news. We will continue to work
on this library and I hope to have major updates available the coming
weeks. It is our goal to provide a production-strength 1.0.0 version
within the next few weeks (anyhow, I don't like to specify a date ;)).

The project home page is available at

http://www.monitorware.com/liblogging/

Special thanks go the Marshall T. Rose who insisted on the fact that
"BEEP can be done simple" (the "just say no" approach) and Devin Kowatch
who provided code for the Linux port as well as motivated me to do it
quickly.

I would especially be interested in feedback from those working with
embedded devices. The library has grown - currently around 4000 lines of
code - and I expect it to grow to maybe 10,000 lines of code. This is
far more than the initial project goal was. If you have an opinion, I
would appreciate your thoughts. Please contact me off-list, as this is
not really a protocol issue.

Rainer Gerhards

------------------------------
End of syslog-sec-digest V1 #229
********************************

From: [email-masked] (syslog-sec-digest)
To: [email-masked]
Subject: syslog-sec-digest V1 #230
Reply-To: 
Sender: [email-masked]
Errors-To: [email-masked]
Precedence: bulk

syslog-sec-digest      Wednesday, August 13 2003      Volume 01 : Number 230

In this issue:

    Re: Typo in RFC3195
    Typo in RFC3195
    Re: Typo in RFC3195
    Re: Typo in RFC3195
    RE: syslog-int
    RE: syslog-int
    RE: syslog-int

----------------------------------------------------------------------

Date: Mon, 11 Aug 2003 21:14:49 +0200
From: Rainer Gerhards <[email-masked]>
Subject: Re: Typo in RFC3195

> i don't think so... the only things that you must escape in XML are "<" and "&".
   >">" isn't special when it occurs in #pcdata.

Ahh... Ok, got it. Will make sure I do it right in COOKED.

Thanks,
Rainer

------------------------------

Date: Mon, 11 Aug 2003 18:54:27 +0200
From: Rainer Gerhards <[email-masked]>
Subject: Typo in RFC3195

Hi WG,

In RFC 3195, page 15, the samples reads

- ---
 This would be relayed as follows:

         C: MSG 1 0 . 2235 242
         C: Content-Type: application/beep+xml
         C:
         C: <entry facility='160' severity='6'
         C:   hostname='bomb'
         C:   deviceFQDN='bomb.terrorist.net' deviceIP='10.0.0.83'
         C:   timestamp='Oct 22 01:00:04'
         C:  >&lt;166> 1990 Oct 22 01:00:00 bomb tick[0]: BOOM!</entry>
         C: END
         S: RPY 1 0 . 978 45
         S: Content-Type: application/beep+xml
         S:
         S: <ok/>
         S: END
- ---

Shouldn't that be

- ---
 This would be relayed as follows:

         C: MSG 1 0 . 2235 242
         C: Content-Type: application/beep+xml
         C:
         C: <entry facility='160' severity='6'
         C:   hostname='bomb'
         C:   deviceFQDN='bomb.terrorist.net' deviceIP='10.0.0.83'
         C:   timestamp='Oct 22 01:00:04'
         C:  >&lt;166&gt; 1990 Oct 22 01:00:00 bomb tick[0]:
BOOM!</entry>
         C: END
         S: RPY 1 0 . 978 45
         S: Content-Type: application/beep+xml
         S:
         S: <ok/>
         S: END
- ---

The difference is in this line:

         C:  >&lt;166&gt; 1990 Oct 22 01:00:00 bomb tick[0]:
BOOM!</entry>

I think the ">" needs to be escaped to &gt; - am I right?

Rainer

------------------------------

Date: Mon, 11 Aug 2003 11:29:04 -0700
From: Marshall Rose <[email-masked]>
Subject: Re: Typo in RFC3195

> The difference is in this line:
>
>          C:  >&lt;166&gt; 1990 Oct 22 01:00:00 bomb tick[0]:
> BOOM!</entry>
>
> I think the ">" needs to be escaped to &gt; - am I right?

i don't think so... the only things that you must escape in XML are "<" and "&".
">" isn't special when it occurs in #pcdata.

/mtr

------------------------------

Date: Mon, 11 Aug 2003 19:53:45 -0700
From: Darren New <[email-masked]>
Subject: Re: Typo in RFC3195

Marshall Rose wrote:
> i don't think so... the only things that you must escape in XML are "<" and "&".
> ">" isn't special when it occurs in #pcdata.

Right. You only have to escape where there's ambiguity, so you only have
to escape ">" when it's inside a tag. You *can* escape >, of course.

- -- 
Darren New, San Diego CA USA (PST)
Don't take home left-over tripe.
   It'll just digest itself before
     you get around to eating it.

------------------------------

Date: Tue, 12 Aug 2003 11:30:11 -0400
From: Anton Okmianski <[email-masked]>
Subject: RE: syslog-int

Hi!

I assume this is the forum to provide the feedback on this draft.

> 	Title		: Syslog-international Protocol
> 	Author(s)	: R. Gerhards
> 	Filename	: draft-ietf-syslog-international-00.txt
> 	Pages		: 13
> 	Date		: 2003-8-1
http://www.ietf.org/internet-drafts/draft-ietf-syslog-international-00
.txt

First of all, thanks for putting the draft together!

1. I think it was a good idea to put language headers into the MSG
part as opposed to other syslog fields. This would allow me, for
example, storing the message on disk in the same format and/or re-use
the language header even when bypassing syslog.

2. The LANGUAGE field.  Is it necessary?  Can it be omitted?  I can
easily see a situation where an application supporting foreign
languages does not know the source language.  For example, my
applications takes usernames in any language (in Unicode).  Now, I
need to produce a syslog message which has the username in it. What am
I going to put in the LANGUAGE field?

Also, there can be situations (bizarre as they are) when a message
contains multiple languages in it. With Unicode-based encodings, it is
not a problem.  What happens in this case?

I'd propose removing the LANGUAGE field.

3. RFC1766 referenced in the LANGUAGE field spec is officially
obsolete.  Need to address it one way or another if the LANGUAGE field
stays?

4. I am concerned about attempting to support ALL encodings and ALL
charsets. Is it necessary?  If this is a new standard, why do we need
to provide for support of all legacy encodings?  Why can't we just
standardize on Unicode encoded as straight binary UTF-8 or UTF-7?
Maybe also provide for support of UTF-16 for more compact
representation of Asian languages.  Either one will cover all
languages and would not require getting into the business of
interpreting locale/language specific charsets and many encodings.

So, can we do away with the CHARSET field and only use Unicode-based
and US-ASCII encodings in the ENCODING field?

5. Even if we support multiple encodings, it would probably help to
specify a few that  MUST be supported.  Otherwise, how do we ensure
interoperability if each implementation can choose its own set of
supported encodings/charsets?

6. Can we specify that the absence of the header should be interpreted
as UTF-8 encoded message?  A UTF-8 compliant syslog daemon will be
backwards compatible as it would be able to receive message sent in
plain US-ASCII as this range of characters is encoded identically.

7. Just a minor thing.  The spec and examples show the special prefix
as "@#i18n", but there is a note in the spec that the "i" should be
capital "I".  Why not change it in the examples then?

8. With internationalization of messages, the length of messages will
inevitably grow.  Should we provide for multi-part messages to
overcome the 1024 byte limit?  Multi-part messages could have the same
standard syslog header along with some additional part-seq-number.  I
guess this also required msg-seq-number.  If we don't deal with
multi-part messages as part of syslog RFC, applications will invent
their own mechanisms to identify messages that belong together.  A
standard mechanism would be nice.

Thanks!

Anton.

------------------------------

Date: Tue, 12 Aug 2003 17:33:54 -0400
From: Anton Okmianski <[email-masked]>
Subject: RE: syslog-int

RFC2277 "IETF Policy on Character Sets and Languages" could be of use
for syslog-international draft:
ftp://ftp.isi.edu/in-notes/rfc2277.txt

Of note:

 - It clearly favors UTF-8.  Does not mention UTF-7.
 - It seems to argue that language must be identified.

Anton.

> -----Original Message-----
> From: Anton Okmianski [mailto:[email-masked]]
> Sent: Tuesday, August 12, 2003 11:30 AM
> To: [email-masked]
> Cc: Nathan Sowatskey; David Bainbridge
> Subject: RE: syslog-int
>
>
> Hi!
>
> I assume this is the forum to provide the feedback on this draft.
>
> > 	Title		: Syslog-international Protocol
> > 	Author(s)	: R. Gerhards
> > 	Filename	: draft-ietf-syslog-international-00.txt
> > 	Pages		: 13
> > 	Date		: 2003-8-1
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-intern
> ational-00.txt
>
>
> First of all, thanks for putting the draft together!
>
> 1. I think it was a good idea to put language headers into
> the MSG part as opposed to other syslog fields. This would
> allow me, for example, storing the message on disk in the
> same format and/or re-use the language header even when
> bypassing syslog.
>
> 2. The LANGUAGE field.  Is it necessary?  Can it be
> omitted?  I can easily see a situation where an application
> supporting foreign languages does not know the source
> language.  For example, my applications takes usernames in
> any language (in Unicode).  Now, I need to produce a syslog
> message which has the username in it. What am I going to
> put in the LANGUAGE field?
>
> Also, there can be situations (bizarre as they are) when a
> message contains multiple languages in it. With
> Unicode-based encodings, it is not a problem.  What happens
> in this case?
>
> I'd propose removing the LANGUAGE field.
>
> 3. RFC1766 referenced in the LANGUAGE field spec is
> officially obsolete.  Need to address it one way or another
> if the LANGUAGE field stays?
>
> 4. I am concerned about attempting to support ALL encodings
> and ALL charsets. Is it necessary?  If this is a new
> standard, why do we need to provide for support of all
> legacy encodings?  Why can't we just standardize on Unicode
> encoded as straight binary UTF-8 or UTF-7?  Maybe also
> provide for support of UTF-16 for more compact
> representation of Asian languages.  Either one will cover
> all languages and would not require getting into the
> business of interpreting locale/language specific charsets
> and many encodings.
>
> So, can we do away with the CHARSET field and only use
> Unicode-based and US-ASCII encodings in the ENCODING field?
>
> 5. Even if we support multiple encodings, it would probably
> help to specify a few that  MUST be supported.  Otherwise,
> how do we ensure interoperability if each implementation
> can choose its own set of supported encodings/charsets?
>
> 6. Can we specify that the absence of the header should be
> interpreted as UTF-8 encoded message?  A UTF-8 compliant
> syslog daemon will be backwards compatible as it would be
> able to receive message sent in plain US-ASCII as this
> range of characters is encoded identically.
>
> 7. Just a minor thing.  The spec and examples show the
> special prefix as "@#i18n", but there is a note in the spec
> that the "i" should be capital "I".  Why not change it in
> the examples then?
>
> 8. With internationalization of messages, the length of
> messages will inevitably grow.  Should we provide for
> multi-part messages to overcome the 1024 byte limit?
> Multi-part messages could have the same standard syslog
> header along with some additional part-seq-number.  I guess
> this also required msg-seq-number.  If we don't deal with
> multi-part messages as part of syslog RFC, applications
> will invent their own mechanisms to identify messages that
> belong together.  A standard mechanism would be nice.
>
> Thanks!
>
> Anton.
>
>
>
>
>

------------------------------

Date: Wed, 13 Aug 2003 09:22:48 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: syslog-int

Hi Anton,

Thanks for your comments! I am answering a bit out sequence...

> RFC2277 "IETF Policy on Character Sets and Languages" could be of use
> for syslog-international draft:
> ftp://ftp.isi.edu/in-notes/rfc2277.txt
>

I went through it while drafting...

> Of note:
>
>  - It clearly favors UTF-8.  Does not mention UTF-7.

The issue here is that UTF-8 is 8 bit. Unfortunately, all other syslog
RFCs/Ids specify the message to be 7 bit and US-ASCII only. I already
sent a note to the WG list if that should be changed in the other RFCs -
responses are still outstanding (I guess vacation season is hitting...).

The issue here is even when it is changed in the other RFCs, existing
syslogds may be broken by 8 bit characters. So this may not be something
that could be done easily. On the other hand, at least my experience
shows that most of them handle 8 bit, so it may be worth re-thinking.

In this position, I selected UTF-7 because it can encode within the
US-ASCII constraint.

I would really appreciate any comments on the other RFCs, too -
especially 3195 and syslog-sign. If they had 8 bit chars,
syslog-international could indeed plainly specify UTF-8, which would
resolve many issues... But again, we must ensure we do not break
existing things! One goal behind syslog-international is to make it
compatible with existing syslogds. As we all know, changes move in
gradually and I expect that "older" syslogds will be around for *quite*
a while...

>  - It seems to argue that language must be identified.

This is why it is in...

Rainer

------------------------------

Date: Wed, 13 Aug 2003 10:24:31 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: syslog-int

Hi Anton,

Now the second response ;)

First of all, I will revise the ID in respect to
ftp://ftp.rfc-editor.org/in-notes/rfc3536.txt, which I initially did not
pay proper attention to. This may bring a number of changes. I can not
do it this week, but most probably have done so by the end of next week.

> 1. I think it was a good idea to put language headers into the MSG
> part as opposed to other syslog fields. This would allow me, for
> example, storing the message on disk in the same format and/or re-use
> the language header even when bypassing syslog.

This is one of the intentions.

It leaves one problem, though - the hostname may include international
fields. But I think we can solve this with DNS internationalization. I
didn't manage to get this into the -00 ID but it may be worth talking a
little bit about the header. As of now, it is left out, which could
cause some issues. On the other hand, the current format makes
syslog-international highly compatible and integratable within an
existing syslog infrastructure.
>
> 2. The LANGUAGE field.  Is it necessary?  Can it be omitted?  I can
> easily see a situation where an application supporting foreign
> languages does not know the source language.  For example, my
> applications takes usernames in any language (in Unicode).  Now, I
> need to produce a syslog message which has the username in it. What am
> I going to put in the LANGUAGE field?

Good point. As you mentioned, it is in because of RFC2277. I think it
must be a user-configurable option. Maybe it should be "-" if the
emiting syslog client does not know...

Any more comments anyone?

>
> Also, there can be situations (bizarre as they are) when a message
> contains multiple languages in it. With Unicode-based encodings, it is
> not a problem.  What happens in this case?
>
> I'd propose removing the LANGUAGE field.

If I think about it, it is actually not bizarre - think of e.g. Japanese
or French names inside an English message (or substrings).

What does the rest of the WG think?

>
> 3. RFC1766 referenced in the LANGUAGE field spec is officially
> obsolete.  Need to address it one way or another if the LANGUAGE field
> stays?

4.3 of RFC2277 says that it should be used - this is why it is in.

>
> 4. I am concerned about attempting to support ALL encodings and ALL
> charsets. Is it necessary?  If this is a new standard, why do we need
> to provide for support of all legacy encodings?  Why can't we just
> standardize on Unicode encoded as straight binary UTF-8 or UTF-7?

I know there are some issues with Unicode acceptance and there may also
be some missing Unicode libs... As such, I would like to see (for Japan)
at least EUC and probably (S)JIS supported. In European languages, it is
the same thing.

> Maybe also provide for support of UTF-16 for more compact
> representation of Asian languages.  Either one will cover all
> languages and would not require getting into the business of
> interpreting locale/language specific charsets and many encodings.

Of course, we can also specify that all should be Unicode based and the
syslog client/collector needs to do the conversion. I just have the
feeling that this puts a lot of burden on the syslog side which again
will hinder implementation. But of course I am more than willing to
change this if there is enough support in this WG for plain Unicode...

If we go Unicode, we can only specify the UTF-7 encoding for the reasons
stated above. As of now, we would have a single encoding allowed.

>
> So, can we do away with the CHARSET field and only use Unicode-based
> and US-ASCII encodings in the ENCODING field?
>
> 5. Even if we support multiple encodings, it would probably help to
> specify a few that  MUST be supported.  Otherwise, how do we ensure
> interoperability if each implementation can choose its own set of
> supported encodings/charsets?
>
> 6. Can we specify that the absence of the header should be interpreted
> as UTF-8 encoded message?  A UTF-8 compliant syslog daemon will be
> backwards compatible as it would be able to receive message sent in
> plain US-ASCII as this range of characters is encoded identically.

See above for UTF-8. I really think a lot of the discussion has been and
will focus on the 8 bit char transport.

I would like to not re-specify the syslog frame format, as this removes
a lot of the ease of implementation. I also think that it really does
not belong in here - but I may be wrong. I also see a lot of issues if a
syslog-international enabled syslog client needs to talk to a e.g.
RFC3195 syslogd not supporting syslog-international. There is no defined
way of downgrading... Mmmhhh... Well, we could specify that it must send
in UTF-7 in this case (should be readable in the old syslogd) but if it
knows it will be talking to a syslog-international enabled server, it
will use UTF-8.

Does this sound like a solution? I still have the difficulty that I am
somehow mixing up the layers to solve this issue, but this may be not a
real concern...

Comments, anyone?
>
> 7. Just a minor thing.  The spec and examples show the special prefix
> as "@#i18n", but there is a note in the spec that the "i" should be
> capital "I".  Why not change it in the examples then?

;) changed it in the -01 ID.

>
> 8. With internationalization of messages, the length of messages will
> inevitably grow.  Should we provide for multi-part messages to
> overcome the 1024 byte limit?  Multi-part messages could have the same
> standard syslog header along with some additional part-seq-number.  I
> guess this also required msg-seq-number.  If we don't deal with
> multi-part messages as part of syslog RFC, applications will invent
> their own mechanisms to identify messages that belong together.  A
> standard mechanism would be nice.

This is where MORE and SEQNO are meant for. I apologize, it is very
briefly described in the current ID, it went in immediately before
publishing. I preferred to have it in right from the begining. I just
called it "fragmentation" and not "multi-part-messages". Maybe the later
term is more appropriate, I appreciate feedback from the native speakers
(to me, it looks like the same thing looked at from two different
sides...).

"  MORE and SEQNO provide support for syslog messages larger than the
   allowed syslog packet size. This is introduced to allow transmittal
   of "oversized" message, which may be the result of some character
   sets and encodings. These messages will be fragmented by the syslog
   client and reconstructed by the collector. Relays will pass them
   through unmodifed.

   Message fragmentation MAY be used if the underlying transport
   provides reliable and in-order delivery (for example RFC 3195 [8]).
   It the underlying transport is unreliable or its reliability is not
   known, fragmentation MUST NOT be used.

   More specifies wether this is the final fragment of the message or
   not. An asterisk ("*") means that at least one more fragement will
   follow. A period (".") means that this is the final (or only)
   fragment.

   SEQNO specifies the sequence number of fragments. It MUST start by 0
   for the first fragment and MUST be incremented by 1 for each
   following fragment. SEQNO MUST restart at 0 for each new full
   message. A new full message begins after the last message that had
   "." in MORE.
"

I have intentionally limited fragmentation to reliable transports - with
UDP, we would need to include reliability to ensure ordered delivery
which I think is far beyond the scope of syslog-international. I also
don't like the idea of sending frames multiple times as is done in
syslog-sign. In -sign, this is just done for some key frames. If we
would use a similar approach in -international, we would introduce
dramatic overhead.

Comments?

Looking forward to all replies. Just be warned that I am out of office
from the 14th until the 19th and will probably not be able to reply to
any postings in this period. Will follow-up when I am back.

Rainer

------------------------------

Date: Wed, 13 Aug 2003 08:29:31 -0700
From: "Richard E. Perlotto II" <[email-masked]>
Subject: Other syslog IETF

Are we also looking at things like this?

http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-11.txt

Richard

------------------------------

Date: Wed, 13 Aug 2003 09:53:31 -0700 (PDT)
From: Chris Lonvick <[email-masked]>
Subject: Re: Other syslog IETF

Hi Richard,

On Wed, 13 Aug 2003, Richard E. Perlotto II wrote:

> Are we also looking at things like this?
>
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-11.txt

That's another document of our Working Group.
  http://www.ietf.org/html.charters/syslog-charter.html

syslog-int should be an update to syslog-sign.  Naturally comments on
these documents will be welcome.

Thanks,
Chris

------------------------------

Date: Wed, 13 Aug 2003 11:57:47 -0700
From: "Richard E. Perlotto II" <[email-masked]>
Subject: RE: Other syslog IETF

So you are saying that the payload requirements of the international standard
will supercede those of the sign standard?

Richard

- -----Original Message-----
From: Chris Lonvick [mailto:[email-masked]]
Sent: Wednesday, August 13, 2003 9:54 AM
To: Richard E. Perlotto II
Cc: [email-masked]
Subject: Re: Other syslog IETF

Hi Richard,

On Wed, 13 Aug 2003, Richard E. Perlotto II wrote:

> Are we also looking at things like this?
>
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-11.txt

That's another document of our Working Group.
  http://www.ietf.org/html.charters/syslog-charter.html

syslog-int should be an update to syslog-sign.  Naturally comments on these documents will be welcome.

Thanks,
Chris

------------------------------

Date: Thu, 14 Aug 2003 06:48:14 -0700 (PDT)
From: Chris Lonvick <[email-masked]>
Subject: Protocol Action: 'UTF-8, a transformation format of ISO 10646' to Standard (fwd)

Since we're on the subject.

Thanks,
Chris

- ---------- Forwarded message ----------
Date: Mon, 11 Aug 2003 16:17:04 -0400
From: The IESG <[email-masked]>
To: IETF-Announce:  ;
Cc: Internet Architecture Board <[email-masked]>,
     RFC Editor <[email-masked]>
Subject: Protocol Action: 'UTF-8,
     a transformation format of ISO          10646' to Standard

The IESG has approved the Internet-Draft 'UTF-8, a transformation format of
ISO 10646' <draft-yergeau-rfc2279bis-05.txt> as a Standard. This document
has been reviewed in the IETF but is not the product of an IETF Working
Group. The IESG contact person is Ted Hardie.

Technical Summary

This document updates the specification of UTF-8,
an encoding of the UCS which is designed to be
compatible with many current applications and protocols. UTF-8
has the characteristic of preserving the full US-ASCII range,
providing compatibility with file systems, parsers and other software
that rely on US-ASCII values but are transparent to other values.
This memo obsoletes and replaces RFC 2279.

Working Group Summary

This draft and the interoperability reports associated with it were
discussed
on the [email-masked] mailing list. Archives may be
found at http://lists.w3.org/Archives/Public/ietf-charsets/ among
other places.

Protocol Quality

This specification was reviewed for the IESG by Patrik Falstrom.

------------------------------

Date: Thu, 14 Aug 2003 22:41:18 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: Protocol Action: 'UTF-8, a transformation format of ISO 10646' to Standard (fwd)

Chris and all,

I am still strugling with UTF-8 & ALL syslog RFCs.

http://www.ietf.org/internet-drafts/draft-yergeau-rfc2279bis-05.txt, in
4. says:

"   For the convenience of implementors using ABNF, a definition of
UTF-8
   in ABNF syntax is given here.

   A UTF-8 string is a sequence of octets representing a sequence of UCS
   characters. An octet sequence is valid UTF-8 only if it matches the
   following syntax, which is derived from the rules for encoding UTF-8
   and is expressed in the ABNF of [RFC2234].

   UTF8-octets = *( UTF8-char )
   UTF8-char   = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
   UTF8-1      = %x00-7F
   UTF8-2      = %xC2-DF UTF8-tail
   UTF8-3      = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
                 %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
   UTF8-4      = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) /
                 %xF4 %x80-8F 2( UTF8-tail )
   UTF8-tail   = %x80-BF
"

If you look at this definition, 8 bit characters are required. All of
the current RFCs/Ids describe 7 bit US-ASCII only. So I don't see any
way to use UTF-8 in the current framework.

Am I missing something?

Rainer

> -----Original Message-----
> From: Chris Lonvick [mailto:[email-masked]]
> Sent: Thursday, August 14, 2003 3:48 PM
> To: [email-masked]
> Subject: Protocol Action: 'UTF-8, a transformation format of
> ISO 10646' to Standard (fwd)
>
>
> Since we're on the subject.
>
> Thanks,
> Chris
>
> ---------- Forwarded message ----------
> Date: Mon, 11 Aug 2003 16:17:04 -0400
> From: The IESG <[email-masked]>
> To: IETF-Announce:  ;
> Cc: Internet Architecture Board <[email-masked]>,
>      RFC Editor <[email-masked]>
> Subject: Protocol Action: 'UTF-8,
>      a transformation format of ISO          10646' to Standard
>
> The IESG has approved the Internet-Draft 'UTF-8, a
> transformation format of ISO 10646'
> <draft-yergeau-rfc2279bis-05.txt> as a Standard. This
> document has been reviewed in the IETF but is not the product
> of an IETF Working Group. The IESG contact person is Ted Hardie.
>
> Technical Summary
>
> This document updates the specification of UTF-8,
> an encoding of the UCS which is designed to be
> compatible with many current applications and protocols.
> UTF-8 has the characteristic of preserving the full US-ASCII
> range, providing compatibility with file systems, parsers and
> other software that rely on US-ASCII values but are
> transparent to other values. This memo obsoletes and replaces
> RFC 2279.
>
>
> Working Group Summary
>
> This draft and the interoperability reports associated with
> it were discussed on the [email-masked] mailing list.
> Archives may be found at
> http://lists.w3.org/Archives/Public/ietf-> charsets/ among other
places.
>
>
> Protocol Quality
>
> This specification was reviewed for the IESG by Patrik Falstrom.
>
>
>
>
>

------------------------------

Date: Thu, 14 Aug 2003 18:19:47 -0400
From: Anton Okmianski <[email-masked]>
Subject: RE: Protocol Action: 'UTF-8, a transformation format of ISO 10646' to Standard (fwd)

Rainer et al:

I don't claim to have definitive answers here -- just some thoughts.

Can we define a new syslog standard that is UTF-8 based?  It will be
backwards compatible for US-ASCII.

If somebody fires US-ASCII only message encoded in UTF-8, it will be
the same 7-bit stuff, right?  So, this will be compliant with older
syslog implementations.

If somebody wants to fire a message with non US-ASCII characters in
the syslog message, then they should only be fired to a syslog daemon
implementation that supports the new standard and UTF-8.   Is not this
ok?

Or do we want to state it is our goal that the legacy syslog
implementation should be able to receive and store internationalized
messages?  Is it strictly necessary?  Yes, it would reduce the need to
upgrade infrastructure, but it would tie us to a less compact UTF-7.

One other bad thing about UTF-7 is that it represents all US-ASCII
unchanged *except* for "+" character because it is used as an escape
character. I also think it has some restrictions on "\", "~" and a
trailing "-".  So, UTF-7 is not actually fully US-ASCII compatible,
while UTF-8 is. Right?  Other nastiness/annoyance is that I think
UTF-7 allows multiple ways to encode the same thing.

Because of the history of syslog where implementations appeared before
the standard, I think it may be acceptable to eventually try to
standardize things instead of supporting legacy application which are
not even known to follow the standard anyway.

The UTF-7 IETF standard itself suggests that UTF-8 should be followed
anywhere where possible: "UTF-7 should normally be used only in the
context of 7 bit transports, such as mail. In other contexts, straight
Unicode or UTF-8 is preferred."  I think we can afford to say that
legacy syslog implementations do not have to deal with
internationalized messages since they were not intended to. Then, it
follows that we can afford to support UTF-8. Right?

Supporting multiple encoding could be an answer, but not an elegant
one.  It would actually mean that new implementations need to support
both UTF-7 and UTF-8.  If we supported just UTF-8, then we may not
even need any new headers in the message (except for maybe a language
which is debatable).

Just as anecdotal evidence... There is definitely momentum behind
supporting just UTF-8 in new protocols.  I was giving a related
presentation today and people were somewhat skeptical when I mentioned
potentially using UTF-7.  Adopting UTF-7 does seems to people as a
forward-looking move.

I understand your concerns though.  Just my 2.5 cents.

Thanks for investigating all this!

Anton.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Rainer Gerhards
> Sent: Thursday, August 14, 2003 4:41 PM
> To: Chris Lonvick; [email-masked]
> Subject: RE: Protocol Action: 'UTF-8, a transformation format of ISO
> 10646' to Standard (fwd)
>
>
> Chris and all,
>
> I am still strugling with UTF-8 & ALL syslog RFCs.
>
> http://www.ietf.org/internet-drafts/draft-yergeau-rfc2279bis
> -05.txt, in
> 4. says:
>
> "   For the convenience of implementors using ABNF, a definition of
> UTF-8
>    in ABNF syntax is given here.
>
>    A UTF-8 string is a sequence of octets representing a
> sequence of UCS
>    characters. An octet sequence is valid UTF-8 only if it
> matches the
>    following syntax, which is derived from the rules for
> encoding UTF-8
>    and is expressed in the ABNF of [RFC2234].
>
>    UTF8-octets = *( UTF8-char )
>    UTF8-char   = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
>    UTF8-1      = %x00-7F
>    UTF8-2      = %xC2-DF UTF8-tail
>    UTF8-3      = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
>                  %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
>    UTF8-4      = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3(
> UTF8-tail ) /
>                  %xF4 %x80-8F 2( UTF8-tail )
>    UTF8-tail   = %x80-BF
> "
>
> If you look at this definition, 8 bit characters are
> required. All of
> the current RFCs/Ids describe 7 bit US-ASCII only. So I
> don't see any
> way to use UTF-8 in the current framework.
>
> Am I missing something?
>
> Rainer
>
>
> > -----Original Message-----
> > From: Chris Lonvick [mailto:[email-masked]]
> > Sent: Thursday, August 14, 2003 3:48 PM
> > To: [email-masked]
> > Subject: Protocol Action: 'UTF-8, a transformation format of
> > ISO 10646' to Standard (fwd)
> >
> >
> > Since we're on the subject.
> >
> > Thanks,
> > Chris
> >
> > ---------- Forwarded message ----------
> > Date: Mon, 11 Aug 2003 16:17:04 -0400
> > From: The IESG <[email-masked]>
> > To: IETF-Announce:  ;
> > Cc: Internet Architecture Board <[email-masked]>,
> >      RFC Editor <[email-masked]>
> > Subject: Protocol Action: 'UTF-8,
> >      a transformation format of ISO          10646' to Standard
> >
> > The IESG has approved the Internet-Draft 'UTF-8, a
> > transformation format of ISO 10646'
> > <draft-yergeau-rfc2279bis-05.txt> as a Standard. This
> > document has been reviewed in the IETF but is not the product
> > of an IETF Working Group. The IESG contact person is Ted Hardie.
> >
> > Technical Summary
> >
> > This document updates the specification of UTF-8,
> > an encoding of the UCS which is designed to be
> > compatible with many current applications and protocols.
> > UTF-8 has the characteristic of preserving the full US-ASCII
> > range, providing compatibility with file systems, parsers and
> > other software that rely on US-ASCII values but are
> > transparent to other values. This memo obsoletes and replaces
> > RFC 2279.
> >
> >
> > Working Group Summary
> >
> > This draft and the interoperability reports associated with
> > it were discussed on the [email-masked] mailing list.
> > Archives may be found at
> > http://lists.w3.org/Archives/Public/ietf-> charsets/ among other
> places.
> >
> >
> > Protocol Quality
> >
> > This specification was reviewed for the IESG by Patrik Falstrom.
> >
> >
> >
> >
> >
>
>

------------------------------

Date: Thu, 14 Aug 2003 23:22:01 -0700
From: Glen Zorn <[email-masked]>
Subject: RE: Protocol Action: 'UTF-8, a transformation format of ISO 10646' to Standard (fwd)

[email-masked] <mailto:[email-masked]>
writes:

> Chris and all,
>
> I am still strugling with UTF-8 & ALL syslog RFCs.
>
> http://www.ietf.org/internet-drafts/draft-yergeau-rfc2279bis-05.txt,
> in 4. says:
>
> "   For the convenience of implementors using ABNF, a definition of
> UTF-8
>    in ABNF syntax is given here.
>
>    A UTF-8 string is a sequence of octets representing a sequence of
>    UCS characters. An octet sequence is valid UTF-8 only if it
>    matches the following syntax, which is derived from the rules for
>    encoding UTF-8 and is expressed in the ABNF of [RFC2234].
>
>    UTF8-octets = *( UTF8-char )
>    UTF8-char   = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
>    UTF8-1      = %x00-7F
>    UTF8-2      = %xC2-DF UTF8-tail
>    UTF8-3      = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
>                  %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
>    UTF8-4      = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail )
>                  / %xF4 %x80-8F 2( UTF8-tail )
>    UTF8-tail   = %x80-BF
> "
>
> If you look at this definition, 8 bit characters are required.

Maybe I'm reading it wrong, but UTF8-1 appears to be 7 bits.

> All of the current RFCs/Ids describe 7 bit US-ASCII only. So I don't
see any
> way to use UTF-8 in the current framework.

But RFC 3164 just _documents_ BSD syslog, it doesn't _define_ IETF
syslog; I-Ds are made to be changed.  Presumably, the purpose of this WG
is not just to document an ancient protocol, but to improve it.

>
> Am I missing something?
>
> Rainer
>
>
>> -----Original Message-----
>> From: Chris Lonvick [mailto:[email-masked]]
>> Sent: Thursday, August 14, 2003 3:48 PM
>> To: [email-masked]
>> Subject: Protocol Action: 'UTF-8, a transformation format of ISO
>> 10646' to Standard (fwd)
>>
>>
>> Since we're on the subject.
>>
>> Thanks,
>> Chris
>>
>> ---------- Forwarded message ----------
>> Date: Mon, 11 Aug 2003 16:17:04 -0400
>> From: The IESG <[email-masked]>
>> To: IETF-Announce:  ;
>> Cc: Internet Architecture Board <[email-masked]>,
>>      RFC Editor <[email-masked]>
>> Subject: Protocol Action: 'UTF-8,
>>      a transformation format of ISO          10646' to Standard
>>
>> The IESG has approved the Internet-Draft 'UTF-8, a transformation
>> format of ISO 10646' <draft-yergeau-rfc2279bis-05.txt> as a Standard.
>> This document has been reviewed in the IETF but is not the product
>> of an IETF Working Group. The IESG contact person is Ted Hardie.
>>
>> Technical Summary
>>
>> This document updates the specification of UTF-8,
>> an encoding of the UCS which is designed to be
>> compatible with many current applications and protocols. UTF-8 has
>> the characteristic of preserving the full US-ASCII range, providing
>> compatibility with file systems, parsers and other software that rely
>> on US-ASCII values but are transparent to other values. This memo
>> obsoletes and replaces RFC 2279.
>>
>>
>> Working Group Summary
>>
>> This draft and the interoperability reports associated with it were
>> discussed on the [email-masked] mailing list. Archives may be
>> found at http://lists.w3.org/Archives/Public/ietf-> charsets/ among
>> other
> places.
>>
>>
>> Protocol Quality
>>
>> This specification was reviewed for the IESG by Patrik Falstrom.

Hope this helps,

~gwz

"They that can give up essential liberty to obtain a little temporary
safety deserve neither..."
- -- Benjamin Franklin, 1759

"It is forbidden to kill; therefore all murderers are punished unless
they kill in large numbers and to the sound of trumpets."
- -- Voltaire

------------------------------

Date: Fri, 15 Aug 2003 08:02:19 -0700 (PDT)
From: Chris Lonvick <[email-masked]>
Subject: RE: Protocol Action: 'UTF-8, a transformation format of ISO 10646' to Standard (fwd)

Hi,

Glen hit it correctly.

On Thu, 14 Aug 2003, Glen Zorn wrote:

> > All of the current RFCs/Ids describe 7 bit US-ASCII only. So I don't
> see any
> > way to use UTF-8 in the current framework.
>
> But RFC 3164 just _documents_ BSD syslog, it doesn't _define_ IETF
> syslog; I-Ds are made to be changed.  Presumably, the purpose of this WG
> is not just to document an ancient protocol, but to improve it.
>

Let me go over "The Way Things Work" in the IETF.  :-)  There are various
kinds of "standards" developed in RFCs.  RFC 3164 is Informational - this
means that it does not represent a standard of any kind and may be safely
ignored by everyone.  The reason this Working Group wrote it was to
explain the way that it had been seen to have been working and (more
importantly) to document the security flaws in it.  That paved the way for
our subsequent works to fix those flaws.  Both syslog-sign and RFC 3195
(reliable delivery) are Standards Track documents.  This means that they
will be real Internet Standards some day.  This doesn't mean that they are
immutable - there are multiple ways to change Standards.

First, a Standard may be "Obsoleted".  Let's take Telnet as an example.
Jon Postel wrote RFC 761 in June 1980 to describe it.  In May 1983, Jon
and Joyce Reynolds wrote RFC 854 which Obsoleted RFC 761.  This means that
anyone looking for the specifications for Telnet should start with RFC
854.

Second, a Standard may be augmented.  Still using Telnet, in January 1993,
David Borman wrote RFC 1408 explaining a new Telnet Option.  Essentially
this makes no changes to the Telnet specification but says that "this" may
also occur within Telnet.  Anyone looking to implement Telnet may stop
reading after they finish RFC 854 but they would be wise to implement
these Options for robustness and completeness.

Third, a Standard may be "Updated".  In January of 1994, David Borman
published RFC 1571 which updates RFC 1408.  This explains that there was a
problem with RFC 1408 and RFC 1571 addresses it.  The fundamental premise
of RFC 1408 is still good but specifics are needed to describe a
particular issue.  People looking to implement Telnet should be reading
RFC 854, 1408 and 1571.  They should also be reading many other RFCs which
describe various other features and options but that's beside my point.

So..., we have the syslog-sign ID.  This is going to be the first
definitive Standard on syslog.  :-)  I think that it gives everyone a good
basis for consistently providing event messages and a way to authenticate
the origin of the messages.  We could ask John and Jon to include a
section on the Internationalization of messages within that document for
completeness.  However, I think that we're all ready for that document to
be published and I don't know that John and Jon have any inclination or
background to work on Internationalization issues.  This is going to be
fine as a basis from which to work on updates.

Rainer is working on a way to Augment syslog-sign.  His work will document
how non-US-ASCII characters may be sent within syslog (as it is defined in
syslog-sign).

At some future time, someone may need to Update syslog-sign.  For example,
the TIMESTAMP-3339 describes time on this planet.  Someone may have need
to describe the time on Mars or on another planet in syslog messages so a
new document may be written which will describe the problem and the
resolution.  [I am NOT asking for volunteers on that work at this time.]

Finally, we have RFC 3195.  Marshall and Darren wrote that based upon RFC
3164 which was all we had to go by at that time.  When syslog-sign, and
when syslog-international are published (or near enough) we can ask them
to incorporate the changes needed.  [Along with changes needed by the
netconf WG.] They may choose to Update 3195, or they may Obsolete it.
Thoughts on this (on the mailing list) will be accepted but it seems a bit
premature until we see where syslog-international is going.

What all of this means is that Rainer needs to look through the relevent
RFCs describing Internationalization efforts and see how prior wisdom
indicates how non-US-ASCII characters may be placed into syslog-sign -
even if that means Augmenting syslog-sign to allow it to include 8-bit
characters.  As a subject matter expert, he needs to think about how it
may be best done for the community at large.

Does all of this make sense?

Rainer:  Apologies for talking about you in the third-person but it seemed
like the best way to describe everything.  :-)

Thanks,
Chris

------------------------------

Date: Fri, 15 Aug 2003 21:57:37 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: Protocol Action: 'UTF-8, a transformation format of ISO 10646' to Standard (fwd)

Hi all,

I am replying to this message as one of the many great feedbacks I
received. If I sum it up, I think I am convinced now that I need to move
things toward UTF-8 support which means that the syslog packt format
needs to be re-specified. I am prepared to do so.

However, just let us step back a little and look why I was so hesistant
not to touch the current frame format. I strongly believe in the fact
that protocols should be done in layers. As such, I saw RFC 3195 &
syslog-sign which define the syslog message. I intended to add *a layer*
on top of them which supports international characters. However, I also
intended not to re-specify the complete syslog protocol with a new ID. I
have the impression that by doing so, we are mixing things that do not
necessariy belong together.

Keep in mind, flexible protocols - and expandable ones - are almost
every time implemented in layers. I do not like the idea that whenever I
specify a new feature on top of the existing protocol, I need to
respecify ist lower layer workings. In the current example, support for
UTF-8 means (and again, I am willing to take that route) that we can't
just add it on top of the current protocol but need to re-write/specify
the syslog format itself.

As I have said, I am perfectly willing to take that route and will
change the ID in this regard.

However, I would like to propose a change in the way we look at the
syslog protocol series. How about (trying to define) a basic syslog
protocol format that does not need to be changed with each new feature
and THEN map this format both to the lower lever transports as well as
upper-level issues like signing and internationalization. I think we
are now ready to take this route, thanks to the great work acomplished
so far. We have a good understanding of the reliability, security,
backward compatibility and internationalization features. If the WG
follows that route, we probably had to darft some more Ids... Let me
provide a sample:

Syslog-format - the "core" standard describing the packet format of a
syslog message. Maybe a large part from rfc 3195 could be the basis
together with syslog-sign and -international.

Syslog-sign, -international - added as upper layers on top of
syslog-format. They extend the format by new feature but do not change
it. Other, payload oriented, standards could follow here once the time
is ready for them.

Transport mappings - like rfc3164 and rfc 3195. They describe how the
syslog-format is mapped onto a specific transport. So this is the
lower-layer series. Again, these could be extended without changing the
upper layers. For example, I could imagine a mapping to use SNMP
trap/inform message to transport syslog-format messages.

As we are right now all concerned with BEEP, let me compare this
approach with what BEEP does. Syslog-format would be much like RFC 3080,
specifying the basic workings. Syslog-sign, -international and so on
would be much like BEEP profiles. And 3164 & 3195 would be transport
mappings like RFC 3081 is for BEEP.

Please note that not only BEEP follows this approach - many successful
protocol families do.

I know I am proposing quite a change in the current RFC series. I also
have probably overlooked something. I for sure know there are better and
more informed opinions then mine in the WG. Anyhow, I thought I drop
this concern, which was the basis of my sticking to UTF-7 in
- -international. I sincerely hope it is helpful and will serve a good
need. And as I said, I am ready to re-specify the complete syslog format
in -international.

Looking forward to your comments,
Rainer

> -----Original Message-----
> From: Anton Okmianski [mailto:[email-masked]]
> Sent: Friday, August 15, 2003 12:20 AM
> To: Rainer Gerhards; Chris Lonvick; [email-masked]
> Subject: RE: Protocol Action: 'UTF-8, a transformation format
> of ISO 10646' to Standard (fwd)
>
>
> Rainer et al:
>
> I don't claim to have definitive answers here -- just some thoughts.
>
> Can we define a new syslog standard that is UTF-8 based?  It
> will be backwards compatible for US-ASCII.
>
> If somebody fires US-ASCII only message encoded in UTF-8, it
> will be the same 7-bit stuff, right?  So, this will be
> compliant with older syslog implementations.
>
> If somebody wants to fire a message with non US-ASCII
> characters in the syslog message, then they should only be
> fired to a syslog daemon
> implementation that supports the new standard and UTF-8.   Is not this
> ok?
>
> Or do we want to state it is our goal that the legacy syslog
> implementation should be able to receive and store
> internationalized messages?  Is it strictly necessary?  Yes,
> it would reduce the need to upgrade infrastructure, but it
> would tie us to a less compact UTF-7.
>
> One other bad thing about UTF-7 is that it represents all
> US-ASCII unchanged *except* for "+" character because it is
> used as an escape character. I also think it has some
> restrictions on "\", "~" and a trailing "-".  So, UTF-7 is
> not actually fully US-ASCII compatible, while UTF-8 is.
> Right?  Other nastiness/annoyance is that I think UTF-7
> allows multiple ways to encode the same thing.
>
> Because of the history of syslog where implementations
> appeared before the standard, I think it may be acceptable to
> eventually try to standardize things instead of supporting
> legacy application which are not even known to follow the
> standard anyway.
>
> The UTF-7 IETF standard itself suggests that UTF-8 should be
> followed anywhere where possible: "UTF-7 should normally be
> used only in the context of 7 bit transports, such as mail.
> In other contexts, straight Unicode or UTF-8 is preferred."
> I think we can afford to say that legacy syslog
> implementations do not have to deal with internationalized
> messages since they were not intended to. Then, it follows
> that we can afford to support UTF-8. Right?
>
> Supporting multiple encoding could be an answer, but not an
> elegant one.  It would actually mean that new implementations
> need to support both UTF-7 and UTF-8.  If we supported just
> UTF-8, then we may not even need any new headers in the
> message (except for maybe a language which is debatable).
>
> Just as anecdotal evidence... There is definitely momentum
> behind supporting just UTF-8 in new protocols.  I was giving
> a related presentation today and people were somewhat
> skeptical when I mentioned potentially using UTF-7.  Adopting
> UTF-7 does seems to people as a forward-looking move.
>
> I understand your concerns though.  Just my 2.5 cents.
>
> Thanks for investigating all this!
>
> Anton.
>
>
>
>
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Rainer Gerhards
> > Sent: Thursday, August 14, 2003 4:41 PM
> > To: Chris Lonvick; [email-masked]
> > Subject: RE: Protocol Action: 'UTF-8, a transformation
> format of ISO
> > 10646' to Standard (fwd)
> >
> >
> > Chris and all,
> >
> > I am still strugling with UTF-8 & ALL syslog RFCs.
> >
> > http://www.ietf.org/internet-drafts/draft-yergeau-rfc2279bis
> > -05.txt, in
> > 4. says:
> >
> > "   For the convenience of implementors using ABNF, a definition of
> > UTF-8
> >    in ABNF syntax is given here.
> >
> >    A UTF-8 string is a sequence of octets representing a
> sequence of
> > UCS
> >    characters. An octet sequence is valid UTF-8 only if it
> matches the
> >    following syntax, which is derived from the rules for
> > encoding UTF-8
> >    and is expressed in the ABNF of [RFC2234].
> >
> >    UTF8-octets = *( UTF8-char )
> >    UTF8-char   = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
> >    UTF8-1      = %x00-7F
> >    UTF8-2      = %xC2-DF UTF8-tail
> >    UTF8-3      = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
> >                  %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
> >    UTF8-4      = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3(
> > UTF8-tail ) /
> >                  %xF4 %x80-8F 2( UTF8-tail )
> >    UTF8-tail   = %x80-BF
> > "
> >
> > If you look at this definition, 8 bit characters are
> required. All of
> > the current RFCs/Ids describe 7 bit US-ASCII only. So I
> > don't see any
> > way to use UTF-8 in the current framework.
> >
> > Am I missing something?
> >
> > Rainer
> >
> >
> > > -----Original Message-----
> > > From: Chris Lonvick [mailto:[email-masked]]
> > > Sent: Thursday, August 14, 2003 3:48 PM
> > > To: [email-masked]
> > > Subject: Protocol Action: 'UTF-8, a transformation format of ISO
> > > 10646' to Standard (fwd)
> > >
> > >
> > > Since we're on the subject.
> > >
> > > Thanks,
> > > Chris
> > >
> > > ---------- Forwarded message ----------
> > > Date: Mon, 11 Aug 2003 16:17:04 -0400
> > > From: The IESG <[email-masked]>
> > > To: IETF-Announce:  ;
> > > Cc: Internet Architecture Board <[email-masked]>,
> > >      RFC Editor <[email-masked]>
> > > Subject: Protocol Action: 'UTF-8,
> > >      a transformation format of ISO          10646' to Standard
> > >
> > > The IESG has approved the Internet-Draft 'UTF-8, a transformation
> > > format of ISO 10646' <draft-yergeau-rfc2279bis-05.txt> as a
> > > Standard. This document has been reviewed in the IETF but
> is not the
> > > product of an IETF Working Group. The IESG contact person is Ted
> > > Hardie.
> > >
> > > Technical Summary
> > >
> > > This document updates the specification of UTF-8,
> > > an encoding of the UCS which is designed to be
> > > compatible with many current applications and protocols.
> UTF-8 has
> > > the characteristic of preserving the full US-ASCII range,
> providing
> > > compatibility with file systems, parsers and other software that
> > > rely on US-ASCII values but are transparent to other values. This
> > > memo obsoletes and replaces RFC 2279.
> > >
> > >
> > > Working Group Summary
> > >
> > > This draft and the interoperability reports associated
> with it were
> > > discussed on the [email-masked] mailing list.
> Archives may
> > > be found at http://lists.w3.org/Archives/Public/ietf-> charsets/
> > > among other
> > places.
> > >
> > >
> > > Protocol Quality
> > >
> > > This specification was reviewed for the IESG by Patrik Falstrom.
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>
>

------------------------------

Date: Fri, 15 Aug 2003 22:16:14 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: Protocol Action: 'UTF-8, a transformation format of ISO 10646' to Standard (fwd)

Chris and all,

I am right now out of office and on a dial-up. Thus, I did not have your
posting with me before I wrote my last post.

I thank you for the explanation which greatly clarifies the overall
picture. I just still wonder if it would make sense to specify a general
syslog format, that then can be mapped to the upper and lower layers.
Maybe I can try to craft syslog-international in that way - using both
the previous great work in this WG as well as the other
internationalization work.

Does this make sense? Should I carry on in this way? Any more comments?

Rainer

> -----Original Message-----
> From: Chris Lonvick [mailto:[email-masked]]
> Sent: Friday, August 15, 2003 5:02 PM
> To: [email-masked]
> Subject: RE: Protocol Action: 'UTF-8, a transformation format
> of ISO 10646' to Standard (fwd)
>
>
> Hi,
>
> Glen hit it correctly.
>
> On Thu, 14 Aug 2003, Glen Zorn wrote:
>
> > > All of the current RFCs/Ids describe 7 bit US-ASCII only.
> So I don't
> > see any
> > > way to use UTF-8 in the current framework.
> >
> > But RFC 3164 just _documents_ BSD syslog, it doesn't _define_ IETF
> > syslog; I-Ds are made to be changed.  Presumably, the
> purpose of this
> > WG is not just to document an ancient protocol, but to improve it.
> >
>
>
> Let me go over "The Way Things Work" in the IETF.  :-)  There
> are various kinds of "standards" developed in RFCs.  RFC 3164
> is Informational - this means that it does not represent a
> standard of any kind and may be safely ignored by everyone.
> The reason this Working Group wrote it was to explain the way
> that it had been seen to have been working and (more
> importantly) to document the security flaws in it.  That
> paved the way for our subsequent works to fix those flaws.
> Both syslog-sign and RFC 3195 (reliable delivery) are
> Standards Track documents.  This means that they will be real
> Internet Standards some day.  This doesn't mean that they are
> immutable - there are multiple ways to change Standards.
>
> First, a Standard may be "Obsoleted".  Let's take Telnet as
> an example. Jon Postel wrote RFC 761 in June 1980 to describe
> it.  In May 1983, Jon and Joyce Reynolds wrote RFC 854 which
> Obsoleted RFC 761.  This means that anyone looking for the
> specifications for Telnet should start with RFC 854.
>
> Second, a Standard may be augmented.  Still using Telnet, in
> January 1993, David Borman wrote RFC 1408 explaining a new
> Telnet Option.  Essentially this makes no changes to the
> Telnet specification but says that "this" may also occur
> within Telnet.  Anyone looking to implement Telnet may stop
> reading after they finish RFC 854 but they would be wise to
> implement these Options for robustness and completeness.
>
> Third, a Standard may be "Updated".  In January of 1994,
> David Borman published RFC 1571 which updates RFC 1408.  This
> explains that there was a problem with RFC 1408 and RFC 1571
> addresses it.  The fundamental premise of RFC 1408 is still
> good but specifics are needed to describe a particular issue.
>  People looking to implement Telnet should be reading RFC
> 854, 1408 and 1571.  They should also be reading many other
> RFCs which describe various other features and options but
> that's beside my point.
>
> So..., we have the syslog-sign ID.  This is going to be the
> first definitive Standard on syslog.  :-)  I think that it
> gives everyone a good basis for consistently providing event
> messages and a way to authenticate the origin of the
> messages.  We could ask John and Jon to include a section on
> the Internationalization of messages within that document for
> completeness.  However, I think that we're all ready for that
> document to be published and I don't know that John and Jon
> have any inclination or background to work on
> Internationalization issues.  This is going to be fine as a
> basis from which to work on updates.
>
> Rainer is working on a way to Augment syslog-sign.  His work
> will document how non-US-ASCII characters may be sent within
> syslog (as it is defined in syslog-sign).
>
> At some future time, someone may need to Update syslog-sign.
> For example, the TIMESTAMP-3339 describes time on this
> planet.  Someone may have need to describe the time on Mars
> or on another planet in syslog messages so a new document may
> be written which will describe the problem and the
> resolution.  [I am NOT asking for volunteers on that work at
> this time.]
>
> Finally, we have RFC 3195.  Marshall and Darren wrote that
> based upon RFC 3164 which was all we had to go by at that
> time.  When syslog-sign, and when syslog-international are
> published (or near enough) we can ask them to incorporate the
> changes needed.  [Along with changes needed by the netconf
> WG.] They may choose to Update 3195, or they may Obsolete it.
> Thoughts on this (on the mailing list) will be accepted but
> it seems a bit premature until we see where
> syslog-international is going.
>
> What all of this means is that Rainer needs to look through
> the relevent RFCs describing Internationalization efforts and
> see how prior wisdom indicates how non-US-ASCII characters
> may be placed into syslog-sign - even if that means
> Augmenting syslog-sign to allow it to include 8-bit
> characters.  As a subject matter expert, he needs to think
> about how it may be best done for the community at large.
>
> Does all of this make sense?
>
> Rainer:  Apologies for talking about you in the third-person
> but it seemed like the best way to describe everything.  :-)
>
> Thanks,
> Chris
>
>
>

------------------------------

Date: Fri, 15 Aug 2003 18:57:49 -0400
From: Anton Okmianski <[email-masked]>
Subject: RE: Protocol Action: 'UTF-8, a transformation format of ISO 10646' to Standard (fwd)

Rainer:

You are digging deep :), but I agree with your sentiment. Buckle up
for a long message. :)

It is not intuitive to me that syslog-sign takes on the job of
specifying the format for key syslog parameters such as timestamp,
host and tag.  I understand this was done out of necessarily, but
would not we prefer to have a separate document which provides the
basic syslog standard? Security seems like value-added stuff. I'd
prefer to have a syslog standard that actually standardizes the basics
first. Maybe just split syslog-sign into two RFCs?

I also think that layered approach could be taken even further than
what you suggested.  We could separate the logical schema from
"syslog-core". Having an abstract schema would help in the future.
For example, to map syslog messages to SNMP nicely, we would need time
in msec, not as ASCII string.  So, it is a different mapping for the
same logical schema field and a different transport. Some compromises
would be necessary to keep it simple though.

Further, we need a storage mapping. I may have missed it, but I don't
remember seeing anything about it.  Indeed, syslogd implementations
provide different options for storage.  Solaris, for example, provides
an option to add message ID, severity and facility. Linux provides an
option to strip domain name part.  Don't we want to specify some
storage standard(s)?  In absence of them, integration with syslog via
off-line processing of stored messages (as suggested in syslog-sign)
will be inhibited.  I also don't think that storage mapping must be
the same as on the wire protocol.  Some people insist that
transferring time in US-ASCII instead of a number for msec presents a
great burden on the message generator. A syslog viewer application
could present it as necessary in whatever time zone.

One other thing related to syslog-sing.  Since syslog-sign is probably
most interesting in distributed environments... I think in such
context syslog facility is largely useless.  So, all Cisco devices
fire all their messages to a single (albeit configurable for each
device) facility. How useful is that? First, there is a limited number
of facilities, so there is no choice.  Second, by firing all messages
to one facility, the collectors can't make any decisions based on
different facilities (logging into separate file, forwarding,
emailing, etc).  Yet, there are separate facilities for things like
FTP, NTP, clock, mail, kernel, etc.  Seems like this is a huge bias
towards the local logging which was the syslog origin.  I wonder if
new protocols need to go beyond that to make them more useful in
distributed environments. For example, allowing facility to be an
arbitrary alphanumeric string would be very useful.

Also, I think the reboot and sequence numbers should be part of the
core syslog standard.  It would be nice if the TAG field was specified
as two parts: Application Name/ID and Process Name/ID. Nowadays, there
are lots of applications which consist of multiple processes and it
would be nice to identify both.  Arguably, multi-part message support
should be part of the core spec as well even though some transports or
storage options may not use it.

Finally, I'd suggest a separate field for data used by syslog
extensions such as syslog-sign or syslog-international headers.  It is
not ideal that we are using MSG field for that.  As an application
developer I may have my own field format within the MSG part and the
extra headers are encroaching on it.

Have a great weekend!

Anton.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Rainer Gerhards
> Sent: Friday, August 15, 2003 4:16 PM
> To: Chris Lonvick; [email-masked]
> Subject: RE: Protocol Action: 'UTF-8, a transformation format of ISO
> 10646' to Standard (fwd)
>
>
> Chris and all,
>
> I am right now out of office and on a dial-up. Thus, I did
> not have your
> posting with me before I wrote my last post.
>
> I thank you for the explanation which greatly clarifies the overall
> picture. I just still wonder if it would make sense to
> specify a general
> syslog format, that then can be mapped to the upper and
> lower layers.
> Maybe I can try to craft syslog-international in that way -
> using both
> the previous great work in this WG as well as the other
> internationalization work.
>
> Does this make sense? Should I carry on in this way? Any
> more comments?
>
> Rainer
>
> > -----Original Message-----
> > From: Chris Lonvick [mailto:[email-masked]]
> > Sent: Friday, August 15, 2003 5:02 PM
> > To: [email-masked]
> > Subject: RE: Protocol Action: 'UTF-8, a transformation format
> > of ISO 10646' to Standard (fwd)
> >
> >
> > Hi,
> >
> > Glen hit it correctly.
> >
> > On Thu, 14 Aug 2003, Glen Zorn wrote:
> >
> > > > All of the current RFCs/Ids describe 7 bit US-ASCII only.
> > So I don't
> > > see any
> > > > way to use UTF-8 in the current framework.
> > >
> > > But RFC 3164 just _documents_ BSD syslog, it doesn't
> _define_ IETF
> > > syslog; I-Ds are made to be changed.  Presumably, the
> > purpose of this
> > > WG is not just to document an ancient protocol, but to
> improve it.
> > >
> >
> >
> > Let me go over "The Way Things Work" in the IETF.  :-)  There
> > are various kinds of "standards" developed in RFCs.  RFC 3164
> > is Informational - this means that it does not represent a
> > standard of any kind and may be safely ignored by everyone.
> > The reason this Working Group wrote it was to explain the way
> > that it had been seen to have been working and (more
> > importantly) to document the security flaws in it.  That
> > paved the way for our subsequent works to fix those flaws.
> > Both syslog-sign and RFC 3195 (reliable delivery) are
> > Standards Track documents.  This means that they will be real
> > Internet Standards some day.  This doesn't mean that they are
> > immutable - there are multiple ways to change Standards.
> >
> > First, a Standard may be "Obsoleted".  Let's take Telnet as
> > an example. Jon Postel wrote RFC 761 in June 1980 to describe
> > it.  In May 1983, Jon and Joyce Reynolds wrote RFC 854 which
> > Obsoleted RFC 761.  This means that anyone looking for the
> > specifications for Telnet should start with RFC 854.
> >
> > Second, a Standard may be augmented.  Still using Telnet, in
> > January 1993, David Borman wrote RFC 1408 explaining a new
> > Telnet Option.  Essentially this makes no changes to the
> > Telnet specification but says that "this" may also occur
> > within Telnet.  Anyone looking to implement Telnet may stop
> > reading after they finish RFC 854 but they would be wise to
> > implement these Options for robustness and completeness.
> >
> > Third, a Standard may be "Updated".  In January of 1994,
> > David Borman published RFC 1571 which updates RFC 1408.  This
> > explains that there was a problem with RFC 1408 and RFC 1571
> > addresses it.  The fundamental premise of RFC 1408 is still
> > good but specifics are needed to describe a particular issue.
> >  People looking to implement Telnet should be reading RFC
> > 854, 1408 and 1571.  They should also be reading many other
> > RFCs which describe various other features and options but
> > that's beside my point.
> >
> > So..., we have the syslog-sign ID.  This is going to be the
> > first definitive Standard on syslog.  :-)  I think that it
> > gives everyone a good basis for consistently providing event
> > messages and a way to authenticate the origin of the
> > messages.  We could ask John and Jon to include a section on
> > the Internationalization of messages within that document for
> > completeness.  However, I think that we're all ready for that
> > document to be published and I don't know that John and Jon
> > have any inclination or background to work on
> > Internationalization issues.  This is going to be fine as a
> > basis from which to work on updates.
> >
> > Rainer is working on a way to Augment syslog-sign.  His work
> > will document how non-US-ASCII characters may be sent within
> > syslog (as it is defined in syslog-sign).
> >
> > At some future time, someone may need to Update syslog-sign.
> > For example, the TIMESTAMP-3339 describes time on this
> > planet.  Someone may have need to describe the time on Mars
> > or on another planet in syslog messages so a new document may
> > be written which will describe the problem and the
> > resolution.  [I am NOT asking for volunteers on that work at
> > this time.]
> >
> > Finally, we have RFC 3195.  Marshall and Darren wrote that
> > based upon RFC 3164 which was all we had to go by at that
> > time.  When syslog-sign, and when syslog-international are
> > published (or near enough) we can ask them to incorporate the
> > changes needed.  [Along with changes needed by the netconf
> > WG.] They may choose to Update 3195, or they may Obsolete it.
> > Thoughts on this (on the mailing list) will be accepted but
> > it seems a bit premature until we see where
> > syslog-international is going.
> >
> > What all of this means is that Rainer needs to look through
> > the relevent RFCs describing Internationalization efforts and
> > see how prior wisdom indicates how non-US-ASCII characters
> > may be placed into syslog-sign - even if that means
> > Augmenting syslog-sign to allow it to include 8-bit
> > characters.  As a subject matter expert, he needs to think
> > about how it may be best done for the community at large.
> >
> > Does all of this make sense?
> >
> > Rainer:  Apologies for talking about you in the third-person
> > but it seemed like the best way to describe everything.  :-)
> >
> > Thanks,
> > Chris
> >
> >
> >
>
>

------------------------------

Date: Fri, 22 Aug 2003 17:25:21 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RFC 3195 RAW

Hi all,

I am right now implementing the raw listener. Question: once the raw
channel is up (let's assume channel 1), is it valid to send an error
response ("ERR" message) if my syslogd experiences a problem. For
example, it may happen that a false calling sequence leaves the library
without a necessary event callback, so the syslog data arrived can
acutally not be processed. This is a type of app error that I would sent
a 451 BEEP response code. Can this be send to channel 1 or must I simply
close the session?

I am not totally sure after reading the RFC, so advise is appreciated.

Thanks,
Rainer

------------------------------

Date: Fri, 22 Aug 2003 10:01:33 -0400
From: [email-masked]
Subject: I-D ACTION:draft-ietf-syslog-sign-12.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF.

	Title		: Syslog-Sign Protocol
	Author(s)	: J. Kelsey, J. Callas
	Filename	: draft-ietf-syslog-sign-12.txt
	Pages		: 38
	Date		: 2003-8-22

This document describes syslog-sign, a mechanism adding origin
authentication, message integrity, replay-resistance, message
sequencing, and detection of missing messages to syslog. Syslog-sign
provides these security features in a way that has minimal
requirements and minimal impact on existing syslog implementations.
It is possible to support syslog-sign and gain some of its security
attributes by only changing the behavior of the devices generating
syslog messages. Some additional processing of the received syslog
messages and the syslog-sign messages on the relays and collectors
may realize additional security benefits.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-12.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-syslog-sign-12.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-syslog-sign-12.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------------------------------

Date: Mon, 25 Aug 2003 06:50:23 -0700 (PDT)
From: Chris Lonvick <[email-masked]>
Subject: Where we're at - 25 Aug 2003

Hi Folks,

I've updated our WG page:
  http://www.employees.org/~lonvick/index.shtml

==

John and Jon have updated syslog-sign:
  http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-12.txt

I believe that Albert suggested that more characters be added to the TAG
field.  He said that "@" would be good.  Are there any others that should
be added in Section 2.2?  I'd like to get that resolved and then move this
work along to WG Last Call and then submission to the IESG as it is
looking very complete now.

==

Glenn has syslog-MIB here:
  http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-04.txt

There havn't been too many comments about this on the WG mailing list so I
expect that people have been reading it and thinking about it.  Please
don't wait; send in your comments now.

==

We also have an ID on Internationalization of syslog messages by Rainer
Gerhards here:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-international-00.txt

This is a -00 draft which has generated several comments.  A suggestion
has been made to "internationalize" the entire packet rather than just the
MSG part.  I'm making some inquiries now but I think that we should
proceed with this ID as it is - essentially a cookie at the start of the
MSG signifies that the contents of the MSG part is not in US-ASCII.  I'll
bring up the issue about internationalizing the entire packet when I get
some guidance.

==

Anything else that anyone wants to discuss?

Thanks,
Chris

------------------------------

Date: Tue, 26 Aug 2003 09:35:28 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: Where we're at - 25 Aug 2003

> John and Jon have updated syslog-sign:
>   http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-12.txt
>
> I believe that Albert suggested that more characters be added
> to the TAG
> field.  He said that "@" would be good.  Are there any others
> that should
> be added in Section 2.2?  I'd like to get that resolved and
> then move this
> work along to WG Last Call and then submission to the IESG as it is
> looking very complete now.

I am sorry to eventually come into your way, but a quick question to
3.4, the reboot session ID. My apologies if this already was discussed,
but the WG mailing lists archive search did not work and I did not find
a related post by browsing.

- -sign says, the reboot session ID mus not be automatically reset to 0 if
it latches at 9999999999. I agree that this is a fairly big number. But
think about a tool like logger. As of my understanding, each
command-line invocation would create a new "reboot session". Now think
of it being used for years.... I am not sure if we would eventually hit
the high mark. On the other hand, it would take years to wrap back to 0.
So is it really that bad to allow for automatic rollover? I am asking
because I assume implementors would do it anyhow. Take my logger
example: when coding this, would I really stop processing when I hit the
highest number? I have to admit I would implement an automatic rollover,
simply because I would eventually loose vital log data if I would not do
it - which is in my point of view worse.

Rainer

------------------------------

Date: Tue, 26 Aug 2003 09:37:03 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RFC 3195 RAW

Hi all,

I am resending this is at seems to have been lost. Sorry if it is a
duplicate, but I also can't find it in the archives.

I am right now implementing the raw listener. Question: once the raw
channel is up (let's assume channel 1), is it valid to send an error
response ("ERR" message) if my syslogd experiences a problem. For
example, it may happen that a false calling sequence leaves the library
without a necessary event callback, so the syslog data arrived can
acutally not be processed. This is a type of app error that I would sent
a 451 BEEP response code. Can this be send to channel 1 or must I simply
close the session?

I am not totally sure after reading the RFC, so advise is appreciated.

Thanks,
Rainer

------------------------------

Date: Tue, 26 Aug 2003 13:31:38 +0100
From: "[email-masked]" <[email-masked]>
Subject: Re: Where we're at - 25 Aug 2003

> 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-masked]
Send business  mail to: [email-masked]

------------------------------

Date: Tue, 26 Aug 2003 08:04:50 -0700 (PDT)
From: Chris Lonvick <[email-masked]>
Subject: RE: Where we're at - 25 Aug 2003

Hi Rainer,

On Tue, 26 Aug 2003, Rainer Gerhards wrote:

> > John and Jon have updated syslog-sign:
> >   http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-12.txt
> >
> > I believe that Albert suggested that more characters be added
> > to the TAG
> > field.  He said that "@" would be good.  Are there any others
> > that should
> > be added in Section 2.2?  I'd like to get that resolved and
> > then move this
> > work along to WG Last Call and then submission to the IESG as it is
> > looking very complete now.
>
> I am sorry to eventually come into your way, but a quick question to
> 3.4, the reboot session ID. My apologies if this already was discussed,
> but the WG mailing lists archive search did not work and I did not find
> a related post by browsing.

It seems to be having toubles.  :-(

>
> -sign says, the reboot session ID mus not be automatically reset to 0 if
> it latches at 9999999999. I agree that this is a fairly big number. But
> think about a tool like logger. As of my understanding, each
> command-line invocation would create a new "reboot session". Now think
> of it being used for years.... I am not sure if we would eventually hit
> the high mark. On the other hand, it would take years to wrap back to 0.
> So is it really that bad to allow for automatic rollover? I am asking
> because I assume implementors would do it anyhow. Take my logger
> example: when coding this, would I really stop processing when I hit the
> highest number? I have to admit I would implement an automatic rollover,
> simply because I would eventually loose vital log data if I would not do
> it - which is in my point of view worse.

That was mostly pulled from the SNMPv3 User-based Security Model:

- ---snip---
Whenever the local value of snmpEngineBoots has the value 2147483647
   it latches at that value and an authenticated message always causes
   an notInTimeWindow authentication failure.

   In order to reset an SNMP engine whose snmpEngineBoots value has
   reached the value 2147483647, manual intervention is required.
   The engine must be physically visited and re-configured, either

Blumenthal & Wijnen         Standards Track                    [Page 14]

RFC 2574                     USM for SNMPv3                   April 1999

   with a new snmpEngineID value, or with new secret values for the
   authentication and privacy protocols of all users known to that
   SNMP engine. Note that even if an SNMP engine re-boots once a second
   that it would still take approximately 68 years before the max value
   of 2147483647 would be reached.
- ---/snip---

They chose 2147483647 because that fits nicely into a hex value.  Since we
are dealing with decimal, we could expand that.  Since our number is about
3x larger, I figure that it should last over 200 years even at a reboot
per second.

I don't think that anyone has yet built a computing device with a life
expectancy of 68 years - let alone 200.  :-)

Seriously, based on that would you recommend a change?

Thanks,
Chris

------------------------------

Date: Tue, 26 Aug 2003 09:27:39 -0700
From: Darren New <[email-masked]>
Subject: Re: RFC 3195 RAW

Rainer Gerhards wrote:
> Hi all,
>
> I am resending this is at seems to have been lost. Sorry if it is a
> duplicate, but I also can't find it in the archives.
>
> I am right now implementing the raw listener. Question: once the raw
> channel is up (let's assume channel 1), is it valid to send an error
> response ("ERR" message) if my syslogd experiences a problem.

In RAW mode, the syslog server (aka collector) sends a MSG, and the
syslog client (the generator of syslog messages) sends a series of ANS
packets. There's nothing in BEEP that would allow the collector to
cleanly abort that stream of ANS messages coming back. Hence, the most
reliable way of making sure this works would be to first attempt to
cleanly close the channel (e.g., send a message on channel 0 to close
channel 1, hoping the client will get the clue) or, if that doesn't
work, simply drop the TCP connection.

My guess is that if your collector has a problem such that it cannot
accept more ANS records coming from the generator, there's really no
good reason to keep the socket open anyway, unless you're running
something else over the same connection.

I suppose another way of dealing with it is to stop sending SEQ for that
channel, letting the window close up, discarding data until you can
accept more.

> I am not totally sure after reading the RFC, so advise is appreciated.

The place you want to look to figure this out is the BEEP RFC, not the
syslog RFC. Syslog-reliable didn't address mid-processing failures.

- -- 
Darren New, San Diego CA USA (PST)
Don't take home left-over tripe.
   It'll just digest itself before
     you get around to eating it.

------------------------------

Date: Tue, 26 Aug 2003 13:17:21 -0400
From: "Harrington, David" <[email-masked]>
Subject: RE: Where we're at - 25 Aug 2003

Hi,

If I recall correctly, there was a possibility of replay attacks if the
counter could wrap. That's why SNMP latches it. Given the 68 year
timeframe, wrap shouldn't be required.

(I remember questioning whether we shouldn't wrap when this was being
developed, and Marshall Rose assured me he would personally come reset
my devices every 68 years if I found it problematic ;-)

Dbh
David Harrington
[email-masked]
co-chair, IETF SNMPv3 WG

> -----Original Message-----
> From: Chris Lonvick [mailto:[email-masked]]
> Sent: Tuesday, August 26, 2003 11:05 AM
> To: Rainer Gerhards
> Cc: [email-masked]
> Subject: RE: Where we're at - 25 Aug 2003
>
>
> Hi Rainer,
>
> On Tue, 26 Aug 2003, Rainer Gerhards wrote:
>
> > > John and Jon have updated syslog-sign:
> > >
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-12.txt
> > >
> > > I believe that Albert suggested that more characters be added
> > > to the TAG
> > > field.  He said that "@" would be good.  Are there any others
> > > that should
> > > be added in Section 2.2?  I'd like to get that resolved and
> > > then move this
> > > work along to WG Last Call and then submission to the
> IESG as it is
> > > looking very complete now.
> >
> > I am sorry to eventually come into your way, but a quick question to
> > 3.4, the reboot session ID. My apologies if this already
> was discussed,
> > but the WG mailing lists archive search did not work and I
> did not find
> > a related post by browsing.
>
> It seems to be having toubles.  :-(
>
> >
> > -sign says, the reboot session ID mus not be automatically
> reset to 0 if
> > it latches at 9999999999. I agree that this is a fairly big
> number. But
> > think about a tool like logger. As of my understanding, each
> > command-line invocation would create a new "reboot
> session". Now think
> > of it being used for years.... I am not sure if we would
> eventually hit
> > the high mark. On the other hand, it would take years to
> wrap back to 0.
> > So is it really that bad to allow for automatic rollover? I
> am asking
> > because I assume implementors would do it anyhow. Take my logger
> > example: when coding this, would I really stop processing
> when I hit the
> > highest number? I have to admit I would implement an
> automatic rollover,
> > simply because I would eventually loose vital log data if I
> would not do
> > it - which is in my point of view worse.
>
> That was mostly pulled from the SNMPv3 User-based Security Model:
>
> ---snip---
> Whenever the local value of snmpEngineBoots has the value 2147483647
>    it latches at that value and an authenticated message always causes
>    an notInTimeWindow authentication failure.
>
>    In order to reset an SNMP engine whose snmpEngineBoots value has
>    reached the value 2147483647, manual intervention is required.
>    The engine must be physically visited and re-configured, either
>
>
>
> Blumenthal & Wijnen         Standards Track
>  [Page 14]
>
> RFC 2574                     USM for SNMPv3
> April 1999
>
>
>    with a new snmpEngineID value, or with new secret values for the
>    authentication and privacy protocols of all users known to that
>    SNMP engine. Note that even if an SNMP engine re-boots
> once a second
>    that it would still take approximately 68 years before the
> max value
>    of 2147483647 would be reached.
> ---/snip---
>
> They chose 2147483647 because that fits nicely into a hex
> value.  Since we
> are dealing with decimal, we could expand that.  Since our
> number is about
> 3x larger, I figure that it should last over 200 years even
> at a reboot
> per second.
>
> I don't think that anyone has yet built a computing device with a life
> expectancy of 68 years - let alone 200.  :-)
>
> Seriously, based on that would you recommend a change?
>
> Thanks,
> Chris
>
>
>

------------------------------

Date: Tue, 26 Aug 2003 18:14:20 +0200
From: Albert Mietus <[email-masked]>
Subject: Reboot counter

Rainer Gerhards writes:
 >
 > -sign says, the reboot session ID mus not be automatically reset to 0 if

 > think about a tool like logger. As of my understanding, each
 > command-line invocation would create a new "reboot session".

Rainer, I think your example isn't typical.

On most system, there is one "global" sender (syslogd on unix), which
run's very long. Usually as long the system is up. It has the counter.
This sender get's it data from several sourcer (Applications using
"syslog() call in libC; again a unix example). So "booting" an
application, --read: you command line tool-- has no effect on the
reboot counter.

See below, for details of your example...
But first, on "the central syslogd"; the RFC doesn't demand it, but
assumes the is only 1 sender on each system. E.g. the "private key" is
shared by all signatures, so by all "sources". Hard to do when all
applications are senders itself.

Back to your example.
Even when quickly "rebooting" (read: increasing the reboot session
counter fast), this should not be a problem. nine 9's is very big!
My code uses the current-time, during initialisation, in seconds after
2002 (syslog-sign didn't existed before) and divide by 2.

This will result in a reboot-session, that will wrap in the year
2600 (or about). And which can be started each 2 seconds.

You can find my code on SF.net, or see below for a C-code fragment:

- --------
GLOBAL int rebootSessionID = 0;

int reboot_session_id(void)
{
  if (rebootSessionID != 0) {
    if (gettimeofday(&now) != 0)
      rebootSessionID = 1      // it has to have a value
    else
      rebootSessionID= (now.tv_sec- ( (2002-1700) * 365 * 3600) ) /  2
  }
  return rebootSessionID;
}
- ------
For a standalone commandline tool, you probably need more a bit more
resolution. E.g. skip the "divide by 2".  Most important is that value
is unique for that session, for that invocation of that commandline
tool. If that means it will wrap in "only a few years", let it
be. It's not typical to have short rebootsessions. It means verifying
the log, is hard to do anyhow !! Then is easy for delete all log of a
reboot session (for a hacker). That can't be verified.

Good Luck.

PS. The code in SF has a bug: it multiplies by 2, instead of
    dividing. Dividing is correct. I will change it on SF, soon.

- --
ALbert Mietus
	Send prive mail to:      [email-masked]
	Send business mail to:  [email-masked]
	Don't send spam mail!

------------------------------

Date: Tue, 26 Aug 2003 13:03:27 -0700 (PDT)
From: Chris Lonvick <[email-masked]>
Subject: Re: Where we're at - 25 Aug 2003

Hi Albert,

On Tue, 26 Aug 2003, [email-masked] wrote:

>
> > 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 :-)

IDs get revised based upon comments.  ..and all of the comments seem to be
coming from you.  ;-)

>
> 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)

What you are suggesting with your Option 3 is to have a new part in the
"IANA Considerations"  of syslog-sign stating the Facilities not defined
are open to future use by the consensus process (RFC 2434 page 6).  That
sounds good to me.  The current set of Facilities and Severities are
listed by IANA here:
  http://www.iana.org/assignments/syslog-parameters

If we do define new Facilities in syslog-sign, then they will have to
adhere to all of the requirements and specifications of syslog-sign when
it becomes an RFC.  Right now I'm trying to think of how to
"Internationalize" the entire syslog packet rather than just the MSG part.
It __may__ be that we will want PRI values of <193> to <383> to have the
same Fac/Sev values as <0> through <192> but a device receiving any of
those PRI's would know that the entire packet (following the PRI) is in
UTF8.  That's really just an example of why we may want to put off that
decision at this time as I'm really waiting for someone from the IAB to
get back to me on the thought of real Internationalization.

Of course you know that these suggestions will require J&J to produce
syslog-sign-13.  ;-)  Seriously, these are good items to bring up.

Thanks,
Chris

------------------------------

Date: Wed, 27 Aug 2003 12:39:52 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: Reboot counter

First things first: I am convinced now that there is no problem with the
reboot session id. I probably should have sone some quick math in the
first place.

But still some comments...

>  > think about a tool like logger. As of my understanding, each
>  > command-line invocation would create a new "reboot session".
>
>
> Rainer, I think your example isn't typical.

I agree. But it is a real one ;)

>
> On most system, there is one "global" sender (syslogd on unix), which
> run's very long. Usually as long the system is up. It has the counter.
> This sender get's it data from several sourcer (Applications using
> "syslog() call in libC; again a unix example). So "booting" an
> application, --read: you command line tool-- has no effect on the
> reboot counter.

Agreed - but we do not life in an *nix only world. I am not sure if
homogenious systems would be better accepted if the only OS would be
*nix, but as of now we do have some others out. Look, we (mainly, I can
say nowadays;)) implement on Windows. There is no such central sender.
We need to "boot" each application...

>
> See below, for details of your example...
> But first, on "the central syslogd"; the RFC doesn't demand it, but
> assumes the is only 1 sender on each system. E.g. the "private key" is
> shared by all signatures, so by all "sources". Hard to do when all
> applications are senders itself.

If that is the case, we indeed have an issue here. Not a big issue if a
single vendor's products run on the non-*nix box. But what if e.g.
Adiscon's EventReporter runs on the same system Kiwi's syslogd runs... I
think there are ways to work this out, but I also think -sign can be
implemented to work around this. I think we do not absolutely have only
one private key for the system.

I am NOT arguing to change anything in -sign (at least yet). I am just
picking up the thought...

>
> Back to your example.
> Even when quickly "rebooting" (read: increasing the reboot session
> counter fast), this should not be a problem. nine 9's is very big!
> My code uses the current-time, during initialisation, in seconds after
> 2002 (syslog-sign didn't existed before) and divide by 2.
>
> This will result in a reboot-session, that will wrap in the year
> 2600 (or about). And which can be started each 2 seconds.
>
> You can find my code on SF.net, or see below for a C-code fragment:
>
> --------
> GLOBAL int rebootSessionID = 0;
>
> int reboot_session_id(void)
> {
>   if (rebootSessionID != 0) {
>     if (gettimeofday(&now) != 0)
>       rebootSessionID = 1      // it has to have a value
>     else
>       rebootSessionID= (now.tv_sec- ( (2002-1700) * 365 * 3600) ) /  2
>   }
>   return rebootSessionID;
> }
> ------

... this is where I should have done some "advanced math" ;) OK, I am
guilty...

> For a standalone commandline tool, you probably need more a bit more
> resolution. E.g. skip the "divide by 2".  Most important is that value
> is unique for that session, for that invocation of that commandline
> tool. If that means it will wrap in "only a few years", let it
> be. It's not typical to have short rebootsessions. It means verifying
> the log, is hard to do anyhow !! Then is easy for delete all log of a
> reboot session (for a hacker). That can't be verified.

That is in fact an excellent point. So for my (unusual) command line
tool, I may be better of to use the day as reboot session id and keep it
the same during all of the day. Of course, I could miss an actual system
reboot, but I think that mapping would work fine for this bizzare
example. So I finally got my issue better solved than I asked for :)

Thanks,
Rainer

------------------------------

Date: Wed, 27 Aug 2003 12:21:41 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: Where we're at - 25 Aug 2003

> What you are suggesting with your Option 3 is to have a new
> part in the
> "IANA Considerations"  of syslog-sign stating the Facilities
> not defined
> are open to future use by the consensus process (RFC 2434
> page 6).  That
> sounds good to me.  The current set of Facilities and Severities are
> listed by IANA here:
>   http://www.iana.org/assignments/syslog-parameters

Sounds good to me, too. I have had many discussions off-list (with
actual customers ;)) that show this is a good idea. local0...7 is a bit
limited nowadays ;)

> If we do define new Facilities in syslog-sign, then they will have to
> adhere to all of the requirements and specifications of
> syslog-sign when
> it becomes an RFC.  Right now I'm trying to think of how to
> "Internationalize" the entire syslog packet rather than just
> the MSG part.
> It __may__ be that we will want PRI values of <193> to <383>
> to have the
> same Fac/Sev values as <0> through <192> but a device receiving any of
> those PRI's would know that the entire packet (following the
> PRI) is in
> UTF8.

Actually, this is a good idea to maintain some backwards compatibility.
But it also has some drawbacks. It does not sound very appealing to me
the first place, because... (see below)

> That's really just an example of why we may want to
> put off that
> decision at this time as I'm really waiting for someone from
> the IAB to
> get back to me on the thought of real Internationalization.
>
>
> Of course you know that these suggestions will require J&J to produce
> syslog-sign-13.  ;-)  Seriously, these are good items to bring up.

... Actually, let me bring back the topic of a separate RFC for the
syslog packet format. I would like to see -sign to be moved to the
standards track as it is. As you (Chris) said, things can always be
revised later ;)

Let me provide some points pro a layered architecture:

#1 It mustn't be complex, so we can keep it consistent with the spirit
of syslog ;)
#2 I see some issues right now while acutally implementing the syslog
RFC series:

I am now implementing RFC 3195. I hope to be able to add -sign soon,
eventually with the help of some of Albert's code. When I do so, I run
into a small dilemma. OK, I can detect the format used when receiving
messages. But when sending, what should I do? I don't know if the
receiver (or the relay chain) speaks -sign. This is especially an issue
with the relay chain... In theory, I should be able to emit
sign-messages and older syslogd's should be able to forward it. I think
that was part of -sign's spirit. But I can't do. Well, actually it will
become a configuration issue where the admin needs to configure my
syslogd and tell it what format it should forward. And, yes, I see this
issue at least initially with a layered approach. Now let's say
- -international once again redefines the packet format. Things become
even more complex now. I even see the issue that I won't be able to use
- -sign on -international messages at all, because -sign demands a
specific packet format but -international needs to change this. Now
imagine the next modifications, for example when 3195 gets updated or
some new cool thing is invented for syslog.

Here is the picture that I personally would prefer:

Let's finish -sign as it is. It is well done and useful work as it is
and I think it should move ahead.

Let's put -international on a temporary hold. It is very early in the
process and not hurt by some weeks delay.

Let's begin to think on a new ID to specify the frame format. That ID
should be
a) simple
b) generic enough to cover the past, present and future (hey, nice
marketingish... ;))

Let me post a brief outline of what I think should go into it:

- - independent of the transport, just the frame format itself. It must,
however, be specified to work over a simplex connection as this is the
type we have with UDP syslog and probably some other implementations
- - the enhanced facility,priority Albert suggests - maybe we could change
it to something like <facil,prio> allowing for even more choice. This
(the comma) would also be a clue that this is actually a new format
syslog packet
- - make everything 8bit, so UTF-8 can be used (-international will become
*very* easy)
- - keep the timestamp, hostname and probably tag as it is in -sign (there
is a slight chance that some will opt for a change in the tag)
- - have some (optional) fields to support fragementation - I am thinking
along the line of moving e.g. the reboot session id and the msg sequence
number into the format itself - of course, as optional fields
- - IMPORTANT: have a mandatory field that contains the format of the
syslog message. It could be a 1, 2, 3 or a string specifying the RFC or
ID... So if there is any change in the format, we'll at least have a
clear indication. Obviously, it doesn't solve the issue of not knowing
which format the sender is to accept, but at least it provides a clue to
the sender that it *indeed is a valid message* but it can't parse that
format. Knowing this would for sure do some help in processing dealing
with it (right now, the collector needs to guess).

In short, the message format would be very much as it is today. In fact,
some of these changes would probably be done by -international (at least
the 8bit part). But putting this in a separate RFC would allow to let
all other protocols refer to it. So even if that format is changed to
v2, that doesn't necessarily mean a v1 -sign syslogd could not use it -
it would not have all options, but it could perform some work. Again,
the important fact is it knows it is dealing with a valid syslog
message.

I know APIs are not discussed in the IETF, but we should take care of
how implemtors can actually implement things. Instead of writing a new
message parser/formatter for each new RFC in the series, one could now
implement a basic parser that hopefully would stay for quite a while and
could be used with all upcoming standards. I am sure this would make
implementation much easier (especially if I look at the current config
settings /guesswork I need to do in my current parsers...).

Of course, that format would still allow us to introduce new features by
coockies, which I see as the preferred way of doing things. I am also
very positive that we have done enough work to now specify a message
format that we can life with for a long time without change (if we
follow the cookie approach).

So let's assume we had this syslog-message RFC. Then we could do the
following. I am repeating myself a little to make it clearer:

1. move on with -sign as it is - no changes, make it become a RFC
2. put -international on hold
3. draft -message
once -message has become reasonable mature, at least from its design
philosophy
4. eventually in parallel:
   - go on with -international
   - change RFC 3195 to adopt -message
   - change -sign to adopt -message
   - provide a "transport mapping" to use message over UDP (a new ID)

We would end with the following layers

Transport Mappings:
* revised RFC 3195
* new ID on UDP mapping
* eventually a mapping onto 3164, so that exisiting
  infrastructure can be used to carry new packets (I
  think this is important)
* some others?

Basic Format
* -message

Specific Applications
* -sign
* -international

This is much of what many successful protocols do. It is also the same
approach used by BEEP.

I also think this will not make syslog complex. It sticks easy. In my
point of view, it gets even simpler. From the implementors point of
view, it would save me a lot of code that otherwise needs to be written
(which also makes it more secure ;)). From the perspective of RFC
writers, I think it eases their job because they don't need to re-invent
the wheel (packet) every time.

So in short, I can't see any bad in this. I would appreciate comments on
this and would also appreciate if you, Chris, could include this thought
in your talks with that person from the IAB.

Of course, I can be horribly wrong, but I have made very well experience
with layered approachs and I know it sometimes can even be a life safer.

Comments? ;-)

Rainer

------------------------------

Date: Wed, 27 Aug 2003 13:42:00 +0200
From: Albert Mietus <[email-masked]>
Subject: Examples in draft- syslog-sing

I raised this isuee some time ago, but let's mention it agian:

In Section 2.4, two examples are given. They are there for some
time now. And in that time, the "recommended" format of loglines
is changed.

This results in examples,which show how rfc3164 messages are
formated. That is still acceptable, but not according to "new
knowledge"

I propose, to update (at least one) example and show a fully formated
line, with long hostname, long timestamp etc.

A few examples (of my current inplementation) are shown below.

<165>2003-08-27T13:38:05+02:00 labtop.ons-huis.net DemoProg[5]: TEST

<165>2003-08-27T13:35:00.761352+02:00 syslog @#sigSIG 0111 509965902 0\
  27 27 3  egTbwI3CsO8EpVzSc1XQ0spV7Yo= IKbm18WmmYD90DsrkL4EjMoYNw8=\
  quveEk1ZqhkTRv4oL8U928bUZ9Y=  JYoz+hkDXhNWGDYU7XhQ/2FLHmQ=

[The second example is broken in 3]

- -- 
ALbert Mietus
	Send prive mail to:      [email-masked]
	Send business mail to: [email-masked]
	Don't send spam mail!

------------------------------

Date: Wed, 27 Aug 2003 16:49:25 +0200
From: Albert Mietus <[email-masked]>
Subject: syslog-sign: TAG in Cert/Sign Blocks

In Sec 2.2 says
  - "a colon terminates the TAG"

Does this imply the TAG __needs__ to end with a colon?
Or does any other 'not valid' char also terminates the TAG?

  -"a space MUST follow a colon, for Signatures/Payload messages.

Does this mean, the TAG end in ": " (which means the TAG is not
terminated by the first colon)? Or, does it mean the MSG part will
start with a " ".

In the later case, sections 3.1 and 4.2 should be updated.
They say "syslog " should be used as TAG (terminating with a space),
and do no mention de colon (or ": ") insite the MSG part.

Better, remove this remark on 2.2.

Let the TAG be "syslog" (no space, as ``all fields are separated by a
space'' in already defined.). And keep the MSG part as is.

Then, the 2 lines below (only the start) are correct.

<175>2003-08-27T16:07:44+02:00 labtop.ons-huis.net syslog @#sigSIG[...]
<175>2003-08-27T16:07:45+02:00 labtop.ons-huis.net syslog @#sigCER[...]
#PRI #---TIMESTAMP------------ #----HOSTNAME-----  #-TAG- #-MSG:COOKIE,etc--

Hope it helps.

Implementing, seams a to help reviewing:-)

- --ALbert Mietus
	Send prive mail to:      [email-masked]
	Send business mail to: [email-masked]
	Don't send spam mail!

------------------------------

Date: Wed, 27 Aug 2003 18:45:51 +0200
From: Albert Mietus <[email-masked]>
Subject: RE: Reboot counter

Hai Rainer,

 > >  > command-line invocation would create a new "reboot session".
 > > Rainer, I think your example isn't typical.
 > > On most system, there is one "global" sender (syslogd on unix), which

 > I agree. But it is a real one ;)
 > Agreed - but we do not life in an *nix only world.

I just named Unix as an example. I'm sorry I a suggested Unix only:-)

The same aplies to other systems, like embedded systems.
 > *nix, but as of now we do have some others out. Look, we (mainly, I can
 > say nowadays;)) implement on Windows. There is no such central sender.

It can even be done on Windows! It's a design/architectural isuee!
Why not implement such a "sender" (a service, in Win32), and let applications
send "messages" to that service.  This is possible!

About A year ago, I have seen such a tool. It was simple and easy.
It even "greped" the MS-eventque and converted them so syslog.

Then it is easy to upgrade to -sign!

 > If that is the case, we indeed have an issue here. Not a big issue if a
 > single vendor's products run on the non-*nix box. But what if e.g.
 > Adiscon's EventReporter runs on the same system Kiwi's syslogd runs... I
 > think there are ways to work this out, but I also think -sign can be
 > implemented to work around this. I think we do not absolutely have only
 > one private key for the system.

This, although even more off-topic, is not a Win only issue. Also on
Unix systems, there is a problem when you try to run several "syslogd
services".
Either you have 1, with a "open interface" that all applications
use. Or you have several --more-or-less central ones, each doing a
part of the job. The RFC doesn't forbit it. It just becomes more
complicated to operate (manage) those systems.

Seams to be time that Adiscon, KIWI and You  should decide. Develop on
you own, and let the customers decide (read: get the trouble:-). Or
define an kind of Win-RFC on that internal interface. All
"application", than can use taht interface. And the customer can
select "the best central service".  Or doesn't the Windows word work
that way:-)

 > > be. It's not typical to have short rebootsessions. It means verifying
 > > the log, is hard to do anyhow !! Then is easy for delete all log of a
 > > reboot session (for a hacker). That can't be verified.
 >
 > That is in fact an excellent point. So for my (unusual) command line
 > tool, I may be better of to use the day as reboot session id and keep it
 > the same during all of the day. Of course, I could miss an actual system
 > reboot, but I think that mapping would work fine for this bizzare
 > example. So I finally got my issue better solved than I asked for :)

Hope it helps

BTW, running a commandline tool is a Unix'm. It's not typical on
Windows! So find it hard to believe "it is real" :-)

- -- 
ALbert Mietus
	Send prive mail to:      [email-masked]
	Send business mail to:  [email-masked]
	Don't send spam mail!

------------------------------

Date: Wed, 27 Aug 2003 12:34:30 +0200
From: Albert Mietus <[email-masked]>
Subject: TAG in syslog-sign draft

I think, we need to add "/" as valid char in the TAG.

At least in the FreeBSD version of syslog (which I'm extending to use
- -sign), the TAG is frequently set to the progname, including its path.
E.g. "/usr/sbin/cron".

I think this logging the path is smart, as it makes clear which
program is logging. (I think most systems nowdays have multiple
executables with the same name. I have a least 3 programs named
"sendmail" :-)

We can allow this, by simply adding this to section 2.2, page 10.

Hope this will be accepted.

- -- 
ALbert Mietus
	Send prive mail to:      [email-masked]
	Send business mail to: [email-masked]
	Don't send spam mail!

------------------------------

Date: Wed, 27 Aug 2003 13:50:03 -0400
From: "Harrington, David" <[email-masked]>
Subject: RE: Reboot counter

Hi,

Topic#1:

On Windows, long-lived services, ala daemons on unix, are typically
implemented as OS services. Not everybody does it this way, but I think
a syslog exporter is likely to be handled this way.

Topic#2:

Since SNMPv3 has already been brought into the discussion, let me say
that SNMPv3 applications can work with a daemon/os-service approach
where multiple applications utilize a shared daemon so there is only one
"engine" on a host, or it can work with each application being uniquely
identified (see SNMPv3 engineID). It could also work with multiple
uniquely identified daemons if that is desired. Those are
implementation/deployment decisions.

SNMPv3 uses shared key authentication, so if multiple applications run
as unique entities, their key databases need to be updated independently
of other applications; if a daemon is used, it is possible to have one
key database that works for all the applications, making key
distribution a bit easier. Of course, if multiple apps need to share a
daemon, then there is the increased complexity of app synchronization of
data, developing an API to the daemon, and API versioning must be
handled, and so on.

Topic#3:

I think that to ensure replay protection, an SNMPv3 command line
application should consider each restart as a reboot, and for those with
daemon-style implementations, each restart of the daemon should probably
be considered a reboot.

I would recommend discussing this further with implementors of command
line applications, such as those who work on the Net-SNMP distribution,
or those who work on the SNMP Research products.

Dbh
David Harrington
[email-masked]
co-chair, IETF SNMPv3 WG

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Wednesday, August 27, 2003 6:40 AM
> To: Albert Mietus
> Cc: [email-masked]; Andrew Ross
> Subject: RE: Reboot counter
>
>
> First things first: I am convinced now that there is no
> problem with the
> reboot session id. I probably should have sone some quick math in the
> first place.
>
> But still some comments...
>
> >  > think about a tool like logger. As of my understanding, each
> >  > command-line invocation would create a new "reboot session".
> >
> >
> > Rainer, I think your example isn't typical.
>
> I agree. But it is a real one ;)
>
> >
> > On most system, there is one "global" sender (syslogd on
> unix), which
> > run's very long. Usually as long the system is up. It has
> the counter.
> > This sender get's it data from several sourcer (Applications using
> > "syslog() call in libC; again a unix example). So "booting" an
> > application, --read: you command line tool-- has no effect on the
> > reboot counter.
>
> Agreed - but we do not life in an *nix only world. I am not sure if
> homogenious systems would be better accepted if the only OS would be
> *nix, but as of now we do have some others out. Look, we
> (mainly, I can
> say nowadays;)) implement on Windows. There is no such central sender.
> We need to "boot" each application...
>
> >
> > See below, for details of your example...
> > But first, on "the central syslogd"; the RFC doesn't demand it, but
> > assumes the is only 1 sender on each system. E.g. the
> "private key" is
> > shared by all signatures, so by all "sources". Hard to do when all
> > applications are senders itself.
>
> If that is the case, we indeed have an issue here. Not a big
> issue if a
> single vendor's products run on the non-*nix box. But what if e.g.
> Adiscon's EventReporter runs on the same system Kiwi's
> syslogd runs... I
> think there are ways to work this out, but I also think -sign can be
> implemented to work around this. I think we do not absolutely
> have only
> one private key for the system.
>
> I am NOT arguing to change anything in -sign (at least yet). I am just
> picking up the thought...
>
> >
> > Back to your example.
> > Even when quickly "rebooting" (read: increasing the reboot session
> > counter fast), this should not be a problem. nine 9's is very big!
> > My code uses the current-time, during initialisation, in
> seconds after
> > 2002 (syslog-sign didn't existed before) and divide by 2.
> >
> > This will result in a reboot-session, that will wrap in the year
> > 2600 (or about). And which can be started each 2 seconds.
> >
> > You can find my code on SF.net, or see below for a C-code fragment:
> >
> > --------
> > GLOBAL int rebootSessionID = 0;
> >
> > int reboot_session_id(void)
> > {
> >   if (rebootSessionID != 0) {
> >     if (gettimeofday(&now) != 0)
> >       rebootSessionID = 1      // it has to have a value
> >     else
> >       rebootSessionID= (now.tv_sec- ( (2002-1700) * 365 *
> 3600) ) /  2
> >   }
> >   return rebootSessionID;
> > }
> > ------
>
> ... this is where I should have done some "advanced math" ;) OK, I am
> guilty...
>
> > For a standalone commandline tool, you probably need more a bit more
> > resolution. E.g. skip the "divide by 2".  Most important is
> that value
> > is unique for that session, for that invocation of that commandline
> > tool. If that means it will wrap in "only a few years", let it
> > be. It's not typical to have short rebootsessions. It means
> verifying
> > the log, is hard to do anyhow !! Then is easy for delete
> all log of a
> > reboot session (for a hacker). That can't be verified.
>
> That is in fact an excellent point. So for my (unusual) command line
> tool, I may be better of to use the day as reboot session id
> and keep it
> the same during all of the day. Of course, I could miss an
> actual system
> reboot, but I think that mapping would work fine for this bizzare
> example. So I finally got my issue better solved than I asked for :)
>
> Thanks,
> Rainer
>
>
>

------------------------------

Date: Fri, 29 Aug 2003 09:31:56 +0100
From: "[email-masked]" <[email-masked]>
Subject: Re: Where we're at - 25 Aug 2003

Hi Chris,
>>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.

> What you are suggesting with your Option 3 is to have a new part in the
> "IANA Considerations"

That is exactly true!

>  That sounds good to me.
Well great, Hope it will be in draft-13 (keeps me busy:-)

- -- 
- --ALbert Mietus
Send prive mail to:      [email-masked]
Send business  mail to: [email-masked]

------------------------------

Date: Fri, 29 Aug 2003 15:18:36 +0200
From: Albert Mietus <[email-masked]>
Subject: Index into fragment

Again ...

The CertBlock contains a index into the payload (size: 1-8)

The RFC doesn't mention the possible value's. In short, does in start
counting at 0, or at 1?

Otherwise said, should the smallest value (as an int) be 1 or
zero. This startvalue is used literaily in the first send certblock.

I think it should be "0"; as that is used for most counters in
syslog. But we have to specify it.

The same applies to "3.7 First Message Number" It also start counting
at 0, I think.

(But this one is less important, even counting at 1 will
not break things)

- -- 
ALbert Mietus
	Send prive mail to:      [email-masked]
	Send business mail to: [email-masked]
	Don't send spam mail!

------------------------------

Date: Fri, 29 Aug 2003 17:21:13 +0200
From: Rainer Gerhards <[email-masked]>
Subject: New real-world product using rfc3195/raw

Hi WG,

just so that you can count the number of implementations: today we
released MonitorWare Agent 1.3 which, among others, contains a RFC
3195/RAW server and client. This product is closed source and targeted
towards the Windows platform. I guess it still counts towards the
implementation count ;)

We already have another solution - Adiscon logger - out which is a small
client only tool. We will release at least 3 more products (final &
beta) within the next few days which support 3195 RAW. COOKED will be
our next target (well, eventually -sign...).

We also have an open source library doing these parts - liblogging - I
am right now preparing a new version with listenere code and hope the
lib will be online shortly. If you would like to be notified when the
lib is ready, please either visit

http://www.monitorware.com/liblogging/

or drop me a mail off-list.

Rainer

------------------------------

Date: Fri, 29 Aug 2003 15:17:34 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RFC 3195 metadata

Hi WG,

probably this mail is (at least slightly) off-topic... Actually I am
looking for some advise from other implementors when it comes to
implementing...

In 3195 COOKED, we have what I would call "metadata" (iam, path,
deviceip, ...). This is very valuable. I am just thinking what to do
with that data

- - when I am a realy relaying to "traditional" syslog
- - when I am a collector persisting it

I am NOT asking in regard what the protocol should look like - I think
this is detailled in the RFC. What I am looking for is what people
actually use this data for. Do they always write it to the log file?
Never? Is it a config option? Or does it go into a separate file?

Please answer off-list, I will compile a summary and post it - if there
is no violent opposition against me doing so.

Thanks,
Rainer

------------------------------

Date: Fri, 29 Aug 2003 14:49:39 +0200
From: Albert Mietus <[email-masked]>
Subject: [minor] FragLen can ony have length upto 3

Page 20 mentions:
"  Fragment Length                FragLen              1-4"

Actually, this can be ``1-3'', as the fragment can never reach a
length of 999. A syslog-header, with fulltimestamp etc will take at
least the other 25 available positions of the 1024 that fitt.

But, is only a detail.

- --
ALbert Mietus
	Send prive mail to:      [email-masked]
	Send business mail to: [email-masked]
	Don't send spam mail!

------------------------------

Date: Fri, 29 Aug 2003 14:34:56 +0200
From: Albert Mietus <[email-masked]>
Subject: syslog-sign, draft-12 length of TPBL

Hello (again)

Draft-12 says the length (size in bytes) of TPBL (Total Payload Block
Length) shoud be 8. (page 20).

I assume, this is a typo, and should be 1-8, like the simulair fields.

Note: It is a integer, like the index, which has length 1-8.

- -- 
ALbert Mietus
	Send prive mail to:      [email-masked]
	Send business mail to: [email-masked]
	Don't send spam mail!

------------------------------

Date: Fri, 29 Aug 2003 15:07:41 +0200
From: Albert Mietus <[email-masked]>
Subject: Question

This time a question, a bit off-topic.

As you know, I'm implementing syslog-sign. And I wondering "when" to
send a SignatureBlock.

The RFC doesn't mentions it (it shouldn't). But maybe somebody a an
opinion about it. A SignatureBlock is always send between 2 normal
messages, using UDP.
In normal cases, it really doesn't matter when it is send, typical,
all messages are received, mostly "in-order". That is typical,
although UDP doesn't guaranty it.

Messages get lost when the network is "to busy".  Or when a cable is
temporally unplugged (for a short time).

So, if two messages are send directly after each other
 a) the make the network more busy. (So it losses the 2nd),
 b) both fall of the lose plug (usually)

The code can try to send messages to increase the probability that all
are received or that "most important one" is received.

My questions is, how to to so.

To simplify the matter, in the examples below each hash is sent only
once. S<n> is the SignatureBlock containing the hash of M<n>.
Each dot represents some (real) time, but not the same about every time.

Option 1: M1 S1 ... M2 S2 ...
Option 2: M1 ... S1 M2 ...S2 M3 ...
Option 3: M1 ... M2 S1 ...M3 S2 ...
Option 4: M1 .. S1 .. M2 .. S2  ..

Option 4 seams nice, to balance the load. But is complex (iff
possible) to implement.

Options 1-3, and variants are more real. I have selected 1 for now, as
it is easy to debug:-) Before I used opt 2, but I'm not sure whether
is actually "better".

Please share you idea's THANKS

- -- 
ALbert Mietus
	Send prive mail to:      [email-masked]
	Send business mail to: [email-masked]
	Don't send spam mail!

------------------------------

Date: Mon, 1 Sep 2003 13:54:13 +0200
From: Rainer Gerhards <[email-masked]>
Subject: TIMESTAMP-3339 (Correction)

WG,

I posted too quickly. Maybe Chris can hold the post. I once again
reviewed RFC 3339 and it says:

- --------------

4.4. Unqualified Local Time

   A number of devices currently connected to the Internet run their
   internal clocks in local time and are unaware of UTC.  While the
   Internet does have a tradition of accepting reality when creating
   specifications, this should not be done at the expense of
   interoperability.  Since interpretation of an unqualified local time
   zone will fail in approximately 23/24 of the globe, the
   interoperability problems of unqualified local time are deemed
   unacceptable for the Internet.  Systems that are configured with a
   local time, are unaware of the corresponding UTC offset, and depend
   on time synchronization with other Internet systems, MUST use a
   mechanism that ensures correct synchronization with UTC.  Some
   suitable mechanisms are:

   o  Use Network Time Protocol [NTP] to obtain the time in UTC.

Klyne, et. al.              Standards Track                     [Page 5]

RFC 3339       Date and Time on the Internet: Timestamps       July 2002

   o  Use another host in the same local time zone as a gateway to the
      Internet.  This host MUST correct unqualified local times that are
      transmitted to other hosts.

   o  Prompt the user for the local time zone and daylight saving rule
      settings.

- ----------------

So I think this means we should stick with that for syslog, too and make
sure the device knows its timezone...

Rainer

------------------------------

Date: Mon, 1 Sep 2003 15:04:47 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: TAG in syslog-sign draft

> I think, we need to add "/" as valid char in the TAG.

Would it hurt if we just said:

- ----
   The TAG is a string of visible (printing) characters excluding SP,
   that MUST NOT exceed 32 characters in length.

   The first occurrence of a colon (":") or SP " " character terminates
the TAG
   field. Generally, the TAG contains the name of the process that
   generated the message. It may OPTIONALLY contain additional
   information such as the numerical process ID of that process bound
   within square brackets ("[" and "]"). A colon MUST be the last
   character in this field.

   To be consistent with the format described in RFC 3164, a space
   character need not follow the colon in normal syslog packets.
- ----

In essence, that would allow any character but SP and colon to be used.
IMHO, this would not break existing applications and provide more
flexibility in what coud be in the tag. Think of e.g.

    Myproc[PID,Threadid]:

>
> At least in the FreeBSD version of syslog (which I'm extending to use
> -sign), the TAG is frequently set to the progname, including its path.
> E.g. "/usr/sbin/cron".

Under Windows, this may be "\usr\sbin\cron". In fact it may even be
"c:\usr\sbin\cron" which includes a colon. So I would prefer to see it
terminated by a SP, but I think this is very dangerous given the current
syslog formats out.

>
> I think this logging the path is smart, as it makes clear which
> program is logging. (I think most systems nowdays have multiple

Me too!

> executables with the same name. I have a least 3 programs named
> "sendmail" :-)

Rainer

------------------------------

Date: Mon, 1 Sep 2003 13:29:56 +0200
From: Rainer Gerhards <[email-masked]>
Subject: TIMESTAMP-3339

WG,

I am, too, currently implementing an -sign message parser (but not yet
signing). I am parsing the timestamp.

In ABNF, we say:

      full-time       = partial-time time-offset

That means I must have a time-offset in any case. What should I do (when
generating messages) if I simply do not (reliably) know the TZ the
device is in? This could happen, e.g. if the device TZ is not
configured. Wouldn't it be better to NOT include any timestamp
information so that the receiver knows of the fact I do  not know the
TZ. This would change the above to

      full-time       = partial-time [time-offset]

I know this is not a very common case, but it may happen.

Any thoghts?
Rainer

------------------------------

Date: Wed, 27 Aug 2003 13:42:00 +0200
From: Albert Mietus <[email-masked]>
Subject: Examples in draft- syslog-sing

I raised this isuee some time ago, but let's mention it agian:

In Section 2.4, two examples are given. They are there for some
time now. And in that time, the "recommended" format of loglines
is changed.

This results in examples,which show how rfc3164 messages are
formated. That is still acceptable, but not according to "new
knowledge"

I propose, to update (at least one) example and show a fully formated
line, with long hostname, long timestamp etc.

A few examples (of my current inplementation) are shown below.

<165>2003-08-27T13:38:05+02:00 labtop.ons-huis.net DemoProg[5]: TEST

<165>2003-08-27T13:35:00.761352+02:00 syslog @#sigSIG 0111 509965902 0\
  27 27 3  egTbwI3CsO8EpVzSc1XQ0spV7Yo= IKbm18WmmYD90DsrkL4EjMoYNw8=\
  quveEk1ZqhkTRv4oL8U928bUZ9Y=  JYoz+hkDXhNWGDYU7XhQ/2FLHmQ=

[The second example is broken in 3]

- -- 
ALbert Mietus
	Send prive mail to:      [email-masked]
	Send business mail to: [email-masked]
	Don't send spam mail!

------------------------------