Hi, There is a real demand in the industry for leveraging existing standards rather than creating new languages or special syntaxes. The demand is to reduce the number of special languages an operator needs to learn, and to make it possible to integrate the data from one application type with others.
If you're going to use XML at all, then I recommend using real XML so the data specified can be read by other applications that already use XML, and integrated with their other data. I'm not sure how many applications will want to integrate with syslog cookies, but if there is useful information in the cookie, then another application might be able to use that info in combination with other info to create additional features. The use of a special syntax that looks like but is not XML, fails to achieve either of the demands. I also suggest you learn from the mistakes of others. SNMP uses a special "adapted subset" of ASN.1 and that has caused lots of problems over the years. dbh David Harrington [EMAIL PROTECTED] co-chair, IETF SNMPv3 WG, concluded > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > 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 > > >
