Fyodor wrote:
> 
> On Mon, 12 Jun 2000, Fredrick Paul Eisele wrote:
> 
> > While the machine output from NMAP is handy I would prefer
> > and XML stream.
> 
> I tend to agree.  If I did it all over again, I probably would have
> started with XML.
> 
> > If I submit a patch would it be worthy of incorportation?
> > Thanks
> 
> Yes, I would love incorporate a well thought out XML logging patch (-oX or
> whatever).
Did the -oX thing.
I replaced the HTML artifacts (unfininshed) with XML.
I thought that once you have XML then HTML is redundant/anacronistic?

> But machine output can almost never be changed, so it must be designed
> very well from the start.  In particular, I would like to see a format
> that:
> 
> 1) Is extensible -- Hopefully new features can be easilly added without
> any format change that would break older parsers (eg new host attributes
> like traceroute or new per-port attributes like daemon version number or
> banner)
One of the nice features of XML is XSLT, i.e. worst case wholesale
data conversion is not that bad.
Even better it is seldom necessary to do such wholesale conversion.
Nonetheless, take a look at the tags I created, do they make sense?


> 2) Is documented -- I admit there is no documentation for -oM, but I would
> like future output modes to be documented (at least if they are meant to
> be read by p rograms)
The principle piece of documentation is the XSchema.

> 3) Is not too bloated -- First priority is to make the format clean and
> extensible, and perhaps as self-documenting as possible.  But at the same
> time, it should not take up an ungodly amount of space.  People often scan
> hundreds of thousands of machines.
Yes, I know XML tends to be bloated... 
but it compresses extremely well even with trivial compression (gzip
--fast).
The relative sizes for the samples are 
  junk.xml:6133
  junk.xml.gz:771
  junk.nmap:1109
  junk.nmap.gz:353

 
> 4) In compliance with XML requirements and norms (I'm no XML expert so
> don't ask me what those are :).
The attached is well formed XML etc.
It is not build using a DOM as the output is pretty simple at this
point and I don't feel the extra overhead is worth it.

I am sure there are bugs.
Do you have test cases, hmmm I guess I should look eh.
Whoa, my ride is here, got to go...
The three attached files should be obvious.

-- 
Fredrick Paul Eisele
Netarx, Inc.
Phone (248)647-9800 Fax (248)647-9840
30910 Telegraph Road
Bingham Farms, MI 48025
phreed@netarx.com
www.netarx.com