Hi Anton, The term "cookies" was first used by John Kelsey in his first drafts of syslog-sign to denote that the content of the message was somehow special and should be parsed differently. This sounded like a good idea then and Rainer used the same approach when he started thinking about syslog-international. Since the cookies (or "tags" or "identifiers" or whatever you wish to call them) still seem to be a good thing, I asked Rainer to formalize them in syslog-protocol.
I did make the suggestion that it "look" like XML. I'm very glad to get the discussion going and will support the consensus of the WG so please, everyone, comment on this issue. Thanks, Chris On Wed, 17 Dec 2003, Anton Okmianski wrote: > 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 > > > > > > >
