-----Original Message-----
From: David Harrington [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 15, 2006 1:25 PM
To: 'Rainer Gerhards'
Cc: [EMAIL PROTECTED]
Subject: [Syslog] byte-counting vs special character
Hi Rainer,
[speaking as co-chair]
Can we change the subject line to "byte-counting vs special character"
for this topic so it is easier to find comments on this topic
as compared to other things in the timeline? That will make
it nuch easier for the chairs.
This WG has already gotten stuck, and had WG progress stall,
trying to provide backwards compatibility to a bunch of
incompatible implementations. I argued on this list before
becoming co-chair that backwarsd compatibility may not be
achieveable for some features and we need to stop getting
hung up on it. Sometimes to build a good standard, you need
to choose something that will break some existing implementations.
I raised this concern with Chris when I started as co-chair.
I do not want to see backwards compatibility arguments stall
progress again. I made sure this was reflected in the
timeline, which says that by Friday (if you decide to use a
special character) you must reach consensus on which special
character to use.
[/speaking as co-chair]
[speaking as contributor]
I like the argument that the LF solution will not break
existing implementations, but I would like to know this is
actually true. Have you actually tested this against multiple
implementations, or is it a theoretical argument?
I know you have tested a number of other proposed ways of
doing things against multiple implementations to try to
verify backwards compatibility. Have you actually tested
multiple existing implementations with the LF and found that
they do continue to work without significant problems? Can
you tell the WG which ones you have tested? Are there
implementations that break when using this solution?
In a different message you argue that syslog-sign only needs
to support -protocol because the implementations will need to
have new code added anyway, and the added complexity of
backwards compatibility to rfc3164 implementations is not needed.
You only mention one implementation explicitly that provides
syslog/tls, syslog-ng over stunnel. Would all the other
implementations need to be modified to support a TLS
substrate anyway, so it would not make a difference to them
which special character was chosen or if byte-counting was
chosen? Which syslog/tls implementations will be impacted by
our choice here?
Ideally, only the implementations that support a feature need
to pay the price for the feature.
A syslog message delineator will only be needed in
implemntations that add support for syslog/tls (or other
streams). Whether one supports byte-counting or a special
character, only implementations that support multiple
messages in a stream, e.g. syslog/tls, should need to be
modified to support the choice.
Personally I find the octet-counting cleaner because previous
discussions on terminators showed that available
implementations are highly inconsistent with their special
characters.
Since byte-counting happens outside the syslog message, and
only for syslog in a delimited stream coming in over the
syslog/tls port, it would not impact existing code, only code
that supports syslog/tls.
New syslog/tls code would be needed to extract each "normal"
syslog message from the stream and then send it on for
processing through the existing parser.
If message originators start escaping special characters in
the message content, existing receivers may need to be
modified to un-escape the characters. Think about
applications, such as intrusion detection systems, that
search for special patterns in syslog content
- those could be broken by having the content changed by
escaping characters in the middle of the content.
What happens at a store-then-forward relay? Does the relay
store the escaped characters or does it un-escape them first?
Does it escape them again when it forwards the message? Does
it escape them if it un-escaped them on input? Does it escape
them if it did not un-escape them on input? What if the
sender included some escaped characaters (like '\') for other
purposes? Should the relay unescape them as well?
Will it know to re-escape them on output? What should the
ultimate reciever expect to receive?
Byte-counting looks way less complex to me than choosing a
special character and escaping/unescaping special characters
in the content during the sending/forwarding/recieving
process. (And my opinion has nothing to do with the H**** in
my email address.)
dbh
> -----Original Message-----
> From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 15, 2006 12:41 AM
> To: Miao Fuyou
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Syslog] timeline
>
> Miao,
>
> I am actually concerned about backward compatibility with existing
> code
> *without* the need to upgrade any of that code. As you know,
deployed
> software tends to stick.
>
> If we use just LF, existing, deployed technology (e.g. syslog-ng
with
> stunnel) would be able to understand a message sent from a "new
style"
> syslogd. Having the octet count in front of the message
removes that
> ability, as the old syslogd will no longer see the <pri> at
the start
> of the message.
>
> I agree that it is trivial to modify code to take care for
the octet
> counter. But this is not my concern. My concern is that I
would like
> to achive as good as possible compatibility with existing deployed
> (aka
> "unmodified") technology. I should have been more specific on that.
> Sorry for the omission...
>
> I am also unaware of any implementation that mandates CR LF over
just
> LF. Could you let me know which ones are these?
>
> Rainer
>
> > -----Original Message-----
> > From: Miao Fuyou [mailto:[EMAIL PROTECTED]
> > Sent: Monday, August 14, 2006 7:07 PM
> > To: Rainer Gerhards
> > Cc: [EMAIL PROTECTED]
> > Subject: RE: [Syslog] timeline
> >
> >
> > Hi, Rainer,
> >
> > A new implementation could rely on byte-counting only and then
> > delete LF from the frame(appplication knows exactly where the LF
> > is), it may not force us to use escapes. For LF, I think it is
> > difficult to get 100% compatibility for a legacy
implementation to
> > comply TLS-transport without any change to the code. At
least, some
> > imlementation may need to change
> CR LF to LF
> > because some implementations use CR LF rather than LF.
So, it may be
> > ok to add several LOC to delete FRAME-LEN SP from the frame.
> >
> > I still prefer byte-counting only to byte-counting+LF even
> if it is a
> > feasible tradeoff.
> >
> > Miao
> >
> > > -----Original Message-----
> > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, August 14, 2006 10:18 PM
> > > To: Miao Fuyou
> > > Subject: RE: [Syslog] timeline
> > >
> > > We should not go byte-counting + LF. This is the worst choice:
it
> > >
> > > A) breaks compatibility
> > > B) Forces us to use escapes
> > >
> > > So we get the bad of both worlds, without any benefits.
> > >
> > > Rainer
> > >
> > > > -----Original Message-----
> > > > From: Miao Fuyou [mailto:[EMAIL PROTECTED]
> > > > Sent: Monday, August 14, 2006 12:58 AM
> > > > To: 'Anton Okmianski (aokmians)'; 'David Harrington';
> > > [EMAIL PROTECTED]
> > > > Subject: RE: [Syslog] timeline
> > > >
> > > >
> > > > My vote: byte-counting only > byte-counting + LF > LF
> > >
> > >
> >
> >
> >
>
> _______________________________________________
> Syslog mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/syslog
>
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
