From: Graham Klyne <GK@NineByNine.org>
Date: fre jan 3, 2003 14:37:37 Europe/Stockholm
To: Patrik Fältström <paf@cisco.com>
Cc: IETF-XML discussion <ietf-xml@ops.ietf.org>
Subject: Re: draft-ietf-idwg-idmef-xml
Patrik,
Sorry I'm so late coming to this ... I've been rather busy of late,
and am still catching up.
At 04:19 PM 12/12/02 +0100, you wrote:
Can you have a quick look at this.
My personal view without careful reading is:
- They have copied too much of the XML standard and description
into the document itself.
Yes, I tend to agree.
- The selection of charset should say:
The charset to use SHOULD be UTF-8.
(I don't like UTF-16)
If they want to define a generic XML format, allowing UTF-16 is the
right choice, as it's part of XML. Otherwise, I think the case for
not allowing UTF-16 needs to made very carefully -- I personally think
it *can* be made in some cases.
- The DTD should be compiled somewhere...does any of you know
about somewhere one can drop a DTD to and get back information
on syntax issues?
Any validating XML parser should be able to tell you about DTD
problems.
....
And so to my own comments:
My first thought, on reading the requirements/goals sections, was that
RDF/XML [1] would be a good choice for this purpose, rather than
inventing yet another XML-based language. RDF has direct support for
the subclassing this spec uses, and also the inherent extensibility
that the application requires. It also has a simpler fundamental data
model than general XML.
[1] http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/
(unfortunately, this spec is confusing, and is being clarified
(http://www.w3.org/2001/sw/RDFCore/). There are also a number of
other introductory documents about RDF available on the web.
RDF should be a good match for the UML-based modelling used in this
draft; there has been some work on direct mapping from UML to RDF
(http://www-db.stanford.edu/~melnik/rdf/uml/,
http://www.w3.org/TR/NOTE-rdf-uml/).
...
Section 3.3.3:
I'm not sure that this is a good thing to say:
[[
If no language is specified for an IDMEF message, English SHALL be
assumed.
]]
(RFC1766 --and 3066?-- has some words about i-default)
...
Section 3.3.4:
[[
As a note of interest, XML Schemas, currently being developed by the
W3C, will provide support for inheritance, as well as stronger data
typing and other useful features. Future versions of the IDMEF will
probably use XML Schemas instead of DTDs; this is not currently
possible because the XML Schema Recommendation has not been
finalized.
]]
How *old* is this document? XML schema was approved as a W3C
Recommendation (approximately their equivalent to IETF full standard)
over 18 months ago -- http://www.w3.org/XML/Schema
...
Section 3.4:
Data typing should make reference to XML schema datatypes [2]. Even
among those who promote alternatives to XML schema, most folks use the
XML schema datatypes as defined.
[2] http://www.w3.org/TR/xmlschema-2/
Also, the number notations are muddling encoding issues with
presentation issues (cf. use of '.' and ',' in numbers).
...
Sections 3.3.3.2, 3.4.4:
Using XML character references to encode binary data seems seriously
broken to me. Character references in XML denote Unicode code points,
*not* byte values. I suggest looking to the XML encryption work for
ways to encode binary data in XML.
...
Section 4.*:
I think the UML-based data modelling could usefully be separated from
XML DTD definitions; I'd go far as to suggest the UML data model
should be a separate document in its own right. This would serve to
separate the essential data design from its representation in XML.
...
Section 4.*:
This part contains a number of enumerated string values. It seems to
me that these could more usefully be assigned URIs (maybe, URNs).
Using XML namespaces, these could then become element names, with all
but the last part of the URI being the namespace URI. I think this
would better support the claimed requirement (section 2.1.1) for easy
extensibility.
...
Section 5:
I'm uneasy about the approach to extensibility, particularly DTD
extensions. For an Internet standard it feels rather fragile,
depending on things like XML parameter-entity references within a
DTD-declaration. This is a gut feel, which I cannot substantiate.
...
Section 7 examples:
Section 2.2.1 claims that IDMEF elements will be in an XML namespace,
but the examples given have no namespace declaration, so the elements
used there are not namespace qualified.
I think the use of a namespace is correct. A simple fix is to use a
default namespace declaration in the examples, e.g.:
<IDMEF-Message version="1.0" xmlns="????">
:
</IDMEF-Message>
Also, despite this in section 2.2.1:
[[
In anticipation of the widespread use of XML namespaces, this memo
includes the definition of the URI to be used to identify the IDMEF
namespace.
]]
I could not find a definition of the namespace URI.
Section 7.8:
The example contains what I think is an incorrect attempt to use XML
namespace prefix 'VendorCo:'. Specifically, there is no
xmlns:VendorCo declaration in the XML data. I don't think the attempt
to define the namespace in the DTD is valid ... or if it is, I don't
think it's advisable, because it means the namespace cannot be
identified without access to the DTD.
(I'm not certain about this, and think it should be run by an XML
expert.)
...
In summary:
- I think that at the very least, the use of XML should be reviewed by
an expert in XML technologies.
- I think the use of DTDs is inappropriate for this application: XML
schemas would be a better fit, since they have a better (though still
limited) concept of modular extensibility.
- I think the UML data model should be separated from its XML
representation; I personally think a more effective XML
representation would be RDF, which should map quite easily to the UML
model, ir more easily extended, is simpler, and could benefit from a
number of RDF inference tools that might be very useful for analysing
intrusion records.
#g
-------------------
Graham Klyne
<GK@NineByNine.org>