At 01:16 PM 10/20/1999 +0200, Andreas Siegert wrote:
 >Quoting Robert Webber ([EMAIL PROTECTED]) on Tue, Oct 19, 1999 at 06:26:23PM
-0400:
...
 >> I think that "messages should be regular in format and easy to parse" is a
 >> reasonable requirement, though.  This might reflect into fixed-length
 >> fields, or labelled fields, in the protocol specification.
...
 >How about specifiying a standard set of tags that should be there. When
 >receiving from an oldstyle source, the new syslog would log or forward it
with 
 >a tags saying oldstyle so that we can still use the old stuff and have an
easy 
 >way to specify new things. Those tags come to my mind immediately:
 >
 >
 >ot:   Old text record / free form text record (this is always the last tag)
 >st:   Original senders time stamp
 >si:   Original senders ip
 >sk:   Original senders key (whatever this turns out to be)
 >sh:   Original senders hash of the message it sends 
 >fi:   Forwarders ip (there mitght be multiple)
 >ft:     Forwarders time stamp
 >fk:   Forwarders key (whatever this turns out to be)
 >
 >Each tag is preceded by a space and there should be no space after the
colon. 
 >Apart from the free form record no field can have text that looks like a tag.
 >
 >maybe a bit simplistic...

Tagging the fields seems like a good way to go, but possibly my mind has
been contaminated by working with AVT and other WGs where there are long
lists of features and ASCII tags are used to identify the fields actually
used.  draft-abela-ulm-05.txt uses tagging as an approach to improving
logger messages, and there's some overlap between that paper's list and yours.

Requirement: "The fields present in a syslog-sec message must be easily
parsed and unambiguously identified."  Tagging seems like a good approach.

I'd like to see an "escape" (or "opaque") tag to make experimental
extension fields easy to implement.  An implementation receiving a record
with an opaque field would either have the code available to parse into
that field or could ignore it, so new fields could be introduced without
breaking existing implementations.

Bob

Reply via email to