Rainer: Sorry if I did not follow earlier discussion and misunderstand something obvious. But here is my feedback.
I like the key=value approach. A lot! This would be hugely welcome in syslog and this is a great undertaking! To begin with, we could plug things like severity and facility because, otherwise, they don't even get stored for standard UDP syslog messages! I have dozens of practical examples of other things that could be put into these tags. I am not clear why it has to be enclosed specifically in XML-like tags though. See what we did below for an alternative. If "/>" is a special sequence, are there any rules for escaping it if one needs to put it in tag values? I am also not clear on the use of word "cookie" in general. Can you explain where does this name concept come from? The only association that comes to my mind is with web browser cookies, and I don't see the connection. Can we call these key-value pairs "tags" or something else? At Cisco, we are evangelizing a new logging specification for logging to file or through syslog. It is called CiscoLog. It specifies optional use of tags. We are looking at delimiting individual tags with [] and the tag section with ": ". Here is an example of a message with tags as seen on the wire, but without the syslog PRI field: 12: host.cisco.com: *Jun 13 2003 23:11:52.454 UTC: %BACC-4-BAD_REQUEST: RDU: [comp=parser][mac=1,6,aa:bb:cc:11:22:33][txn=mytxn123]: Bad request received from device [1,6,aa:bb:cc:11:22:33]. Header missing. Things in square brackets after "RDU: " are tags. We don't follow some of the optional syslog RFC3164 time and other header formats partly for legacy reasons and also largely due to the fact that syslog server implementations vary in what they store (or how they forward) messages while we need a minimum set of data to always be present in the log file and in a consistent format. I can give more details about our format if needed. I am allowed to disclose it. It is also useful to differentiate tag syntax from tag meaning. We addressed this with the use of "semantic extensions". For example, tag with key "ip" just means that the value is a properly formatted IP related to message. Tag "ip.orig" means it is IP of host originating message. Tag "ip.client" means it is a tag from a client talking to server which originated the message. You can also see things like "ip.from", "ip.to". Would it be useful to make the syntax/semantic distinction in the standard? BTW, we also use tags to mark parts of a multi-part messages. So, there is a lot of uses for them. > <cookie MSGNO=234 VENDOR=example vendorparam=name%nnn > /> msg.msg.msg Are spaces allowed for values? They should be, I think. Why a different syntax for experimental tags? Getting back to syslog-international, I think tag values should also be allowed to be in foreign languages eventually. Preferably UTF-8. Tags could be used to provide any easily parseable parameters. If I use "username" tag, for example, then in Japan the value could be in Japanese. We had some specific requirements from some Cisco apps to support this. We support foreign languages in tag values and specifying UTF-8 encoding for entire message (US-ASCII is preserved as is). Thanks, Anton. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Rainer Gerhards > Sent: Wednesday, December 17, 2003 12:55 PM > To: [EMAIL PROTECTED] > Subject: syslog-protocol: Cookie Format > > > Hi WG, > > Chris has proposed a XLM-like cookie format in private > mail. I received > permission to quote him on this. I would appreciate any > feedback from > the WG. > > Chris said (Chris, please correct me if you feel I am quoting out of > context): > > #### > The thought just struck me about the use of cookies, languages, etc. > The > use of the special characters is what John Kelsey proposed. > We're not > limited to that if you can come up with something better. I was > thinking > of something like the following at the start of the MSG: > > <cookie MSGNO=123 ENCODING=USASCII /> msg.msg.msg > or > <cookie MSGNO=234 VENDOR=example vendorparam=name%nnn > /> msg.msg.msg > or even > <cookie block=certblock /> certificate.block.msg > > syslog-protocol would then define the IANA held cookie > parameters and > vendors would be able to add their own. Experimental > parameters could > be > done like "vendorparam" (above) where the "%" replaces the > "=" of a real > parameter. > #### > > Please note: In this quote, "msg.msg.msg" is a syslog > message. It is NOT > (necessarily) multiple messages (it may for fragmented messages, but > that is a separate issue). > > A key point in Chris suggestion is that this is NOT actual > XML. It just > looks so. But we could specify the exact sequence of parameters and > such, so that no XML parser is needed to process it. After > some initial > scepticism, I have to say that I like this approach. It > looks very clean > and extensible. > > In this mail, I am trying to gather some feedback from the WG if we > should move into the proposed direction. If so, I will > focus on some of > the details. > > Questions so: Do you like this? Do you think it is useful? Should we > proceed into this direction? > > Rainer > >
