ALbert: > I'm in the process of reviewing the current dradt, after I > have been very busy for some time. > > I hope to send a full review in about 1 or 2 weeks (I will > not be there in Soul and will delay my comment untul your are > back) But due to private communication with Rainer, I will > post my comment on the TAG issue now. > > > 417 TAG > ======= > > I think the TAG need to be stuctured! All current syslog > receivers (collectors, > relays) use __PARTS of__ the RFC3164 TAG to route messages.
I am not clear about the basic premise in this discussion. How do all current syslog implementations use TAG (typically process identifier) to route message? What do you mean? I obviously don't know all syslog implementations, but I have not seen standard Linux or Solaris syslog implementations, which I assume are in widest use, allow a configuration where message destination is determined based on the TAG value. I am also not clear about your distinction about structured or non-structured TAG. Was what Rainer specified for TAG structured? I thought it was. I don't know if anyone argued for unstructured content in the TAG. To me, the specification for TAG provided the structure, but it was just missing the specific details about what must go into the structure - semantics. I think we must be clear on that. If we want that to be a process name or/and PID of the originating application, then we have to state that. Then, we can have a discussion about how to best identify processes and relays could indeed reliably use the TAG for routing messages. Thanks, Anton. > In RFC3164, the TAG is simple and short, so it is quite > simple to use it for routing. Note: not the complete TAG is > used, only the 'program name', never the PID part. > > With the new TAG, with an static ID an a dynamic part, > similar routing should be possible. At least, the RFC should > be clear on it. So, by demanding the static part is "fixed", > and make sure that static part can be found. > > Given the current practice, routing is based (mainly) on the > program-name, it would be wise to (at least suggest) how > (where) that part can be found. > > The other option, a new TAG which is long, but unformated > (unstructured) is not an option. The the purpose of a TAG > becomes useless. When a (e.g.) security officer has to verify > "all" is done by the book, we can not send him "all" the > log. We need to make a selection. the TAG is vital to that, > as no other parts of it can be used for it! This is valid for > other users of the log to. And both of off-line and real-time > processing. > > > Proposal: Forget native support for VMS/Windows/DOS and even > Unix pathnames. And introduce an URI (URL)-alike schema. > Where only '/' (not the one form Unix, but from URL's) is > used to "path separation" and ':' and '//' are major separators. > > In this case, the ABNF is simple; only the semantics become a > little more complex. Also, it become simple for > web-applications to log. The have an URL already. All "old > fashioned:-)" application have an URL: > ''file://path/to/appl'' already. This is valid > on any system. > > > Note: the dynamic part has to be added > Note2: for web-applictions, which include a 'hostpart' in the > URL: that hostname is NOT the same as the HOSTPART in the > header. Frequently (a web-farm) several systems share the > same URL, but not the hostname. Then the sysadmin can decide > which one to use for routing. > > > Hope I have argued we need a structured TAG. And I hope the > URI/URL-based idea will solve the "my-system-native-notation" > problem. But feel free to improve it. > > Greetings, I would like to see some discussion before Seul. > > --ALbert Mietus, PTS Software BV > ALbert dot Mietus at PTS dot nl, for busnines mail > ALbert at ons-huis dot net, fot private mail > No SPAM please! > > > > >
