Hi Rainer, Let me start about by saying that I am often curmudgeonly, so please forgive any negative tone to this message; I am making the comment to be constructively critical. I have had experience dealing with problems similar to those I find in this proposal, so please pay attention to the concerns.
I want to clarify my position, which you aggregated with other positions, and inadvertently misstated. Since it has my name in the greeting, I would like to make sure your misstatement doesn't mislead anybody about my position. I did not say that XML-based syntax is a good idea. It may be; it may not be; whether it is will depend on lots of factors that need to be weighed carefully. Two of the potential benefits of using XML are reuse of existing implemented standards (which benefits both operators and implementors) and interoprability with other application formats (which benefits application developers and consequently application users). I think an XML-"like" syntax may be a BAD idea because it achieves neither of these two benefits, and adds the negative tradeoffs of having to maintain the new XML-like syntax, requiring operators to learn a unique syntax for syslog, and having to support a unique new syntax in implementations. Making it "look like" XML doesn't mean it gets the benefits of using XML. Beyond this point, I make only one other comment about the proposal. Using existing terms for existing standards to refer to non-compliant "look-like" things benefits few. It is misleading and adds confusion to the already difficult process of standardization. I think it is a bad idea to refer to your proposal as "simple XML" - it is either XML or it is not - or to refer to the information as a "cookie", which has a commonly accepted usage which this usage is not. My $.02 (or $.01). Thanks, dbh > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 18, 2003 9:02 AM > To: Harrington, David; [EMAIL PROTECTED] > Subject: RE: syslog-protocol: Cookie Format > > > 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 >
