[Syslog] byte-counting vs special character

["David Harrington" <[e-mail]>]

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:[e-mail]] 
> Sent: Tuesday, August 15, 2006 12:41 AM
> To: Miao Fuyou
> Cc: [e-mail]
> 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:[e-mail]] 
> > Sent: Monday, August 14, 2006 7:07 PM
> > To: Rainer Gerhards
> > Cc: [e-mail]
> > 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:[e-mail]] 
> > > 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:[e-mail]]
> > > > Sent: Monday, August 14, 2006 12:58 AM
> > > > To: 'Anton Okmianski (aokmians)'; 'David Harrington'; 
> > > [e-mail]
> > > > Subject: RE: [Syslog] timeline
> > > > 
> > > > 
> > > > My vote: byte-counting only > byte-counting + LF > LF
> > >  
> > > 
> > 
> > 
> > 
> 
> _______________________________________________
> Syslog mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/syslog
> 


_______________________________________________
Syslog mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/syslog