> Anyhow, I see a valid point in Dado's suggestion: all of > these 3 fields > are highly optional and all of them have no strict definition. Maybe > this is not a good thing for well-defined header fields.
Maybe this is not a good thing for an industry "standard" - Maybe we should make them not-optional and/or strictly define them. >From RFC2026: "A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable." I question whether these field definitions have resolved the known design choices, are well-understood, and enjoy enough community interest to be considered valuable. I think coming to an agreement on the format and semantics, and specifying it clearly and umambiguously in the documentation, would enhance the value of these fields. Let's standardize the semantics of the field, rather than just standardizing a bucket for undefined information. David Harrington [EMAIL PROTECTED] _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec
