another message after a too-long vacation season ;) Because I had lots
of time to think, this is a LONG message. It's the reply PLUS a
suggestion for an -international-00 change in regard to the metadata
(formerly cookie) format. I am outling a specific problem and potential
solution, so please bear with me and actually read it until the end ;)
> > I see the argument. Do you think that relying on something already
> > accepted - like BEEP XML in RFC3080 is a solution? As far
> as I can see,
> > RFC3080 is increasingly becoming implemented. So while not
> full XML, it
> > may be a standard that works "as expected"?
>
> I believe that RFC3080 specifies the use of actual XML, not any
> simplified version. It does insist on XML 1.0, and allows dropping of
> the <? ...> headers at the start (since you're not passing an
> independent document but rather an XML fragment inside
> another protocol,
> and that protocol tells you that you're getting XML there).
> But in 2 of
> the 3 implementations I've seen the innards of, it's using
> off-the-shelf
> XML parsers. (And the reason the third one didn't is we didn't want to
> make it dependent on outside libraries, allowing porting to (say)
> routers or hand-held PDAs or whatever).
>
> However, the examples I've seen such as
> <cookie MSGNO=123 ENCODING=USASCII />
> are not valid XML tags, missing the quote marks around
> attribute values.
I agree. The samples were not meant to serve as a formal spec, just to
get the rough idea. They were good in the informal mail exchange I had
with Chris. I should have edited them before posting here. So the sample
should actually have read:
<cookie msgno="123" encoding="USASCII" />
>
> Rather than "simplified XML", consider "restricted XML",
> which is what I
> think you're talking about wrt RFC3080. But this is a restriction on
> allowable DTDs, not a simplification on the syntax.
Yes, this is more to what I really meant. I think that if we move
towards XML for the metadata (formerly known as cookie), then we should
supply a DTD. This DTD probably should build on the DTD for BEEP XML as
found in RFC3080, section 7.
If we take this route, this probably means that we also need to include
the ability to create actual containers, things like (line breaks for
readability, only)
<cookie type="whatever">
<subtag param="value" />
<subtag param="value> </subtag>
</cookie>
I think we can't call it XML without this. But I have to admit I am not
deep enough in XML to know if it is possible to define a DTD that
strictly requires no-containers, only.
Also, I think we have an issue with properly XMLizing a full message.
Fortunately, we can skip the header as this is not part of the content
(and XML metadata/cookies) should only be used inside the MSG part.
Let's look at a plain example message:
"I am a message"
according to -international-00, it would be as follows (with an example
cookie):
"@#V-example.com-MyTag I am a message"
as far as -international-00 PLUS current discussion goes, this would end
up being (I stripped out some non-important parts:
"<cookie ....>I am a message"
the important things is what is NOT shown: "</cookie>". To be proper
XML, it would need to be
"<cookie ....>I am a message</cookie>"
Simply adding a "closing slash" to the initial tag wouldn't help. I
think this is still not correct XML ("I am a message" is outside any
container):
"<cookie .... />I am a message"
So if we try to use XML based cookies/metadata, we need
a) make sure that the full MSG is XML compliant
b) create a specific portion inside MSG where XML is expected to live
(and only there)
I think the first approach is not desirable here, as it would introduce
a lot of compatiblity issues. In fact, I think it is close to undoable
in a "clean" way. So option b) seem to be the choice ... and I think it
is even a good choice, one that is matching the (simple) spirit syslog.
A quick look at the ABNF as it currently is:
SYSLOG-MSG = PRI HEADER MSG [TRAILER]
MSG = (COOKIE SP [COOKIE-PARAMS SP] MSG) / PAYLOAD
PAYLOAD = *((%d32-126) / (%d128-254))
We could modify it to this:
SYSLOG-MSG = PRI HEADER MSG [TRAILER]
MSG = [METADATA SP] / PAYLOAD
PAYLOAD = *((%d32-126) / (%d128-254))
METADATA = "<metadata" 1*PRINTASCII "/>"
; "BEEP XML" stream according
; to DTD (to be defined)
; MUST start with "<metadata"
In this ABNF, I have removed the recursive cookie structure. This in
itself is good news, because recursion tends to be misunderstood.
Instead, I have specified a specific (SP terminated) field holding the
metadata (cookies) in BEEP XML format. That structure, of course, can be
a tree, so there is some recursion again. The METADATA part must start
with "<metadata" simply to detect that it is present. I think this poses
no problem to existing technology (else we may simply think of inserting
another sequence just in front of it).
I have gone through many scenarios and think this approach works well
for most if not all. I am still a bit concerned about fragmented
messages with a lot of metadata - which means that the metadata needs to
be fragmented, too. Aynhow, I thought I post this before finally
thinking it out so that I can gather the WG's feedback (I may be totally
on the wrong path...).
As a side note, structured payload (as Anton has briefly described a
Cisco sample in
http://www.mail-archive.com/syslog-sec%40employees.org/msg01347.html)
could also be transported inside either the metadata XML stream <payload
/> container OR in the traditional PAYLOAD region. I would opt for the
metadata stream, but it is too early to discuss this.
All in all, I think the metadata field, and using restricted XML inside
it, is probably a good idea to meat a number of goals. It has, however,
one big drawback. And that is simplicity and acceptance. David has
provided very good thoughts on market acceptence in his post
http://www.mail-archive.com/syslog-sec%40employees.org/msg01357.html.
While the topic of this post was BEEP, the ideas behind it are general
enough to apply to this discussion. Just to make sure: we are NOT
talking about even mentioning RFC 3080 in -protocol. So our issue is not
the acceptance of BEEP but the acceptance of XML (but in a restricted
but well-formed form [DTD]).
Fortunately, XML is very well accepted. However, this may be a little
different when it comes to syslog vendors/implementors. I am not sure if
this actually is an issue. Most importantly, nobody is forced to use
XML, but you are kind of forced to use it when you would like to use new
features... which in turn could lead to these features not being
(poperly) implemented. If I got the spirit of David's message correct,
he righly said that "It doesn't help if (just) the WG is happy with the
standards. Implementors (and thus vendors) must be happy and see benefit
in them - otherwise the standard won't be implemented.".
On the pro side for XML inside -protocol is that a syslog client who
wants to emit a message - even an XML enhanced one - does not
necessarily need to have an XML parser. I assume that most, if not all,
of our XML usage only requires very basic formatting, so this can be
written with a simple snprintf() - to say it programatically.
Non-technically said, it is more or less the same effort as it was for
the syslog-sign-13 cookies.
I would appreciate if we could try to solve those both issue before I
edit the -protocol draft, simply because it will greatly influence the
actual edit. For a short summary, this mail opens two questions:
#1 Are we ready for moving XML into a core piece of the syslog spec (the
later part of my message)?
#2 If so, is the format described in the first part of my message
acceptable?
I appreciate all comments. I would especially encourage Albert to
comment, as he already implemented -sign and thus may have some good
insight to share (especially on #1).
Sorry for the long mail...
Rainer
