Hi David and others, > 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.
I am glad to hear that the overall opinion is that the xml based syntax seems to be a good idea. > 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. Actually I am looking at the same subset that is used in BEEP (RFC3080). The goal is that we do not allow constructs that it would be hard to find a good reasoning for (in syslog). Even with RFC 3080, which is used as transport for RFC3195, there was a looot of discussion both inside and outside of this WG from syslog developers who said "this is far too complex, we will not implement it". As far as I can see, this very same argument is still around and one of the reasons why there are few implementations of 3195 (I have to say, though, that I initially had the same opinion and prooved it to be false when I implemented 3195 - so it is maybe just an education issue...). So my effort is to satisfy the "simple enough" and "I will not need to include an XML parser in my app" arguments while still being able to provide a more standardized form of the cookie format. As some pointed out, this XML based approach could - in the long term - also be used to structure syslog payload, which is currently beyond the charter of this WG. I currently can not see any harm by insisting on "simple XML" for cookies. But, yes, you are right, the more one thinks about yet unexplored options (payload structure!) the more it can become a bad idea. The pro side of simple XML is that it is indeed very simple to use and has kind of the "syslog spirit for simplicity". > The use of a special syntax that looks like but is not XML, fails to > achieve either of the demands. To an XML parser, it *is* XML when reading. To an app without an XML-parser, it is textual data that you can parse with a simple, custom-build parser. The issue is when writing. There, an XML parser may generate more elaborate format, which may break the custom-build parser. Do you think that RFC3080 defined BEEP XML *is* a compromise between no-XML and full-XML? > 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. I am listening very closely. My response is to describe what is behind my XML format suggestion. Which goals I (we?) try to tackle. Did the SNMP ASN.1 subset decision have similar reasons? If so, is this a good indication the the very same reasoning will not work for syslog, too? Is it a comparable case? Thanks for taking the time to look into this issue. I appreciate your feedback very much! Rainer
