Andrew:
The \u is a valid Unicode and UTF-8 character.
See section 1 (first bullet point) in UTF-8 RFC:
http://www.ietf.org/rfc/rfc3629.txt
Also defined as valid in Unicode standard:
http://www.unicode.org/Public/UNIDATA/Blocks.txt
I can't tell what it could possibly be used to indicate no
>The only tricky issue that remains is the NUL octet. The more I think
>about it, the more I think the CLR to disallow it is less evil than to
>make it stay...
I agree that having the CLR for NUL octet exclusion is OK.
Quick question, if someone is sending international data in UTF-8 format,
can
Hi Rainer,
I concur on the message size issue. Let's leave it as it stands until we get
to a TCP mapping. Can you mention in your document that the real life max
UDP size was found to be 4K bytes? I think this is a valuable finding and
would save a lot of hair pulling on the part of implementers.
There should be no issue with allowing different types of payload format
in the message text. If someone wants to define syslog messages with a
message text that happens to be formatted as XML, that should not be an
issue but constitutes a valid scenario. Syslog is a mechanism, a tool;
what parti
Sounds more like one for the netconf WG, where XML is king, backwards
compatability is not an issue, messages can be orders of magnitudes larger,
security is inherent etc etc. The only downside is that work on
notifications/events has only just started but one school of thought is that it
should b
I think the charter looks good. It describes what the working group has
to do and its deliverables. I agree that there is a next level of
details that spells out the specifics of how to do it. We had a lot of
discussion on this and seem to have come to a consensus, which is
something that we sho
> Also, sorry if I missed some earlier discussions on signing
> messages. Proposed charter mentions source authentication.
> For TCP mappings (such as BEEP), TLS already provides
> authentication and encryption. SSH transport would provide
> similar facilities. Is there an overlap here? Is mes
Chris:
This is fine, but does not include all the other specific details we agreed on
and as such is not different from what we had before. I think we can focus our
efforts better by creating narrower scope. How about limiting backwards
compatibility to only. Requiring standardization of bett
For what it is worth...
I have tried to create a send-template for rsyslogd, my *nix syslogd. It
covers:
> VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP
> [SD-ID]s SP MSG
>
> or, somewhat incorrect but shorter:
>
> VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID [SD-ID]s M
I fully agreee.
Rainer
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick
> Sent: Wednesday, November 23, 2005 6:05 PM
> To: [EMAIL PROTECTED]
> Subject: [Syslog] Revised proposed charter
>
> Hi All,
>
> v2 of proposed charter ===
Hi John,
On Wed, 23 Nov 2005, Moehrke, John (GE Healthcare) wrote:
Yes, at this point I am happy putting my serialized XML into the MSG
part. I just want to know if there is going to be a requirement
forbidding us from putting our serialized XML into the MSG part. I was
getting that impression.
Hi All,
v2 of proposed charter ===
Syslog is a de-facto standard for logging system events. However, the
protocol component of this event logging system has not been formally
documented. While the protocol has been very useful and scalable, it has
some known security problems which wer
Darren, Anton:
While I agree with Darren we should NOT specify any specfic format of
MSG, I agree with Anton that we should NOT put the wording "human
readable" into the charter.
Rainer
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Anton
> Okm
Yes, at this point I am happy putting my serialized XML into the MSG
part. I just want to know if there is going to be a requirement
forbidding us from putting our serialized XML into the MSG part. I was
getting that impression. I want to continue to work together, I really
don't want to invent som
Darren:
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Darren Reed
> Sent: Wednesday, November 23, 2005 9:09 AM
> To: Moehrke, John (GE Healthcare)
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [Syslog] RE: Message format
>
> > To all,
Darren,
I fully agree with you. My understanding is that John just needs to
transmit text in the MSG part which co-incidently "looks like" XML It
must, however, a bit longer than 1K, which is backed by the current
state of discussion. I, too, strongly object mandating XML or anything
else formatte
> I think this is a valid use case. Syslog traditionally has not only
> focussed on network management but has always been used for
> application-layer event notifications. I think what John asks for is
> within our charter and doesn't even require any change to what we have
> been discussing so fa
Rainer, Glenn, all:
I second Rainer's findings. Relays don't work as described on Solaris and Linux
syslog daemons either. Each of them does their own things. Linux comes the
closest to the described behavior. Only it inserts its own timestamp and
hostname regardless of what you send. Solaris
This is really disappointing...
I have done further testing with more syslogds to confirm the initial
findings. The more different programs / versions I try, the more a mess
this gets. OK, we knew FreeBSD syslogd does not include the hostname.
Next I tested with some Windows products, which looked
I think this is a valid use case. Syslog traditionally has not only
focussed on network management but has always been used for
application-layer event notifications. I think what John asks for is
within our charter and doesn't even require any change to what we have
been discussing so far.
Rainer
I don't think we are asking for anything specific. The XML payload (RFC
3881) is text, and somewhat human readable. We went with XML payload
because we have well defined object identifiers that have been
standardized and used throughout the hospital by many different systems
provided by many differ
> To all,
>
> The view that syslog must only be used to transport "human readable
> syslog messages" is disturbing. Is this the view of the syslog
> community?
At present what we're concerned with is a logging facility that does
generate and consume human readable messages.
At some point in the
Before we get lost in discussions about the technical merits of
message formats, do we have consensus on what the new charter
should be ? Chris, can you post what the latest charter is so
we can all take a look and provide any last comments ?
Darren
_
Glenn,
very interesting approach with the timestamp. I think your ideas can be
the key to maintaining a lot of backwards compatibility by still
retaining new functionality.
First some bad news: I am not sure if by "BSD syslog" you are refering
to RFC 3164 or a specific distribution of BSD. I have
To all,
The view that syslog must only be used to transport "human readable
syslog messages" is disturbing. Is this the view of the syslog
community? If it is then I know that healthcare will take it's security
audit message (RFC3881) and build our own transport likely using web
services. We will
Chris/Rainer,
> we continue to use ... at the start of syslog messages. This will
> allow current receivers to continue to receive messages and put them in
> the right bins. Does anyone disagree with this?
Complete agreement.
>
>
> The WG has agreed to use the timestamp Rainer has in the curr
WG,
we have been discussing which of these fields to include as required in
the header. This discussion so far has not looked at existing technology
and standards. I am not talking about backwards-compatibility at the
protocol level, but rather about the "real" log emitors, the
applications.
A ve
Hi everyone,
Just in case someone doesn't know me (would not be too suprising as I
have not posted to the list recently) I'm the author for syslog-ng a
popular syslog implementation for various UNIXes. To be honest apart
from being subscribed to this list I have not followed the discussions
recent
Andrew,
on the size: Though I have some concerns, I can agree with your point of
view. In fact, one of the syslog-protocol revisions had a mechanism
called multi-part messages. This could be utilized. Maybe we should do a
separate spec on "large size messages". That wouldn't be too much effort
and
>> Mapping over UDP should be limited to a single message per packet.
>I agree on that. If we need an ultra-compact UDP delivery, we could
>later add it in a separate transport mapping.
Yes, good idea. I doubt anyone will ever want to do this, or at least go to
the effort of trying to get it draf
Andrew & WG,
a follow-up to my own posting, just some extra information.
> > When mapping over plain TCP I believe we should limit the
> > total message size
> > to 65507 bytes (to keep it compatible with UDP) and delimit
^^
Anton and other alre
Hi Andrew,
(snipped for brevity)
> Mapping over UDP should be limited to a single message per packet.
I agree on that. If we need an ultra-compact UDP delivery, we could
later add it in a separate transport mapping.
> When mapping over plain TCP I believe we should limit the
> total message si
comments inline...
And an important question for the WG close to the end of the message!
Rainer
> -Original Message-
> From: Darren Reed [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 23, 2005 6:06 AM
> To: Rainer Gerhards
> Cc: Darren Reed; [EMAIL PROTECTED]
> Subject: Re: [Sys
33 matches
Mail list logo
