Kriss Andsten wrote:
> 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)
Point taken, though 20kb is actually not that big, IMO, especially if you're going
to be downloading it to read it anyway.
> 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.
I'll agree to a certain extent. The problem, however, is coming up with a wire
protocol that is more efficient without losing the flexibility and easy processing
of XML (yes, nesting has its problems, but I'd rather deal with them in ASCII than
in something like ASN).
> 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
That's the basic idea behind ULM, but...
* It can't do encapsulation for encryption, authenticity, or timestamping.
* It can't do other nesting to deal with redundant data (my own previous posts
point out that I'm still looking for better ideas on this, but nobody's
suggested any so far).
* It's still an ASCII format and doesn't actually buy you much data compression
(in fact, it requires more bits in some circumstances). I don't know of any
encoding other than something gross like ASN that would give you flexible
tagging and still save space (hmm, now that I think of it, it might not
actually even save space).
> 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.
The problem with saying that the date format should be up to the thing parsing the
logs is that you now have the problem that the log parser and the log generator
have to negotiate this format, etc. A single standard way of representing the date
is much better, IMO. However, I'm not married to the ISO date format and welcome
alternative suggestions. I chose the ISO date format because I figured there
would be existing code that can generate/parse it. I agree that the timezone is
somewhat superfluous.
> 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?
So far, lots of people have mentioned "bloat" and "complexity", but nobody's
actually come up with anything less bloated/complex that still gets the job done.
I would love to see such a thing, but am not convinced I will. Feel free to prove
me wrong.
--
Chris Calabrese
Internet Infrastructure and Security
Merck-Medco Managed Care, L.L.C.
[EMAIL PROTECTED]
.
