On Fri, 29 Oct 1999, Chris Calabrese wrote: First: Might be an idea to post an URL rather than attach the entire thing as bloody HTML every time? (After all, that's what the things are for) Second: It's definitely a lot of junk to haul over the network, let alone process. Yes, looks quite.. comperhensive/bloated (fine line there), but -sending- the stuff as XML over the net (I get the impression that's the genereal idea of that thing)..? It's not a very bandwidth considerate way to send stuff in. It opens you up for a lot of nastyness issues (nesting tends to do this - granted, sane implementations can avoid problems), if you consider the data source untrusted. Would it not be a better idea to transform it into XML on the log server end (as in 'implementation thing, for those who feel they need XML logs'), keeping the transmission a bit.. dumber/simpler/more robust? Simply tagging the data by something non-bastardly big (and not neccessarily human readable) would work well enough, the rest of the spec looks nice, 'cept for a few things: date format should -really- be up to the thing ultimately parsing the logs. There's No Bloody Use (TM) what-so-ever sending the timezone (and the other date sugar) with the message itself, or putting it down as a basic requirement, imo. If the human reading the stuff wants the junk for some reason, this step can be performed on the server. Lastly, it's -not sane- to send IP (or net in general) related stuff in ascii. Bloody good way to DoS a firewall and log server if every packet you haul to it that causes a log entry makes a ~400 byte impression with a lot of ascii gunk to parse. If you force it to use another way of logging that stuff, well.. it defeats the purpose of a standard logging format, no? Rather than have a net specific part with source, dest, junk, junk, format, it might be an idea to have a 'type' saying what the aux data is, have a couple of defined types, say an ipv4 one that specifies source as a six byte string (host.port), a mail one that specifies source as an ascii string (sender). Maybe also spec'ing the fields that'll be sent for the type of aux data. Yes, XML could do this nicely, but as mentioned above.. treating everything like ascii makes any kind of automatic handling more of a pain than anything else. Not to mention hauling plain ole XML down the pipe. All imo, of course. Anyone who thinks spec'ing the data depending on the facility (type) and keeping it -slim- is a worse approach? > Chris Calabrese Kriss Andsten --- .... --..-- -.-- --- ..- .-. . .- -.. -- --- .-. ... . --..-- . .... ..--.. Kriss Andsten <[EMAIL PROTECTED]> telnet slartibartfast.vogon.se 4243
