I've put some comments about your list below.  If you repost this,
you might want to re-order ... there are a few dependencies within
this list.

> #1 testing and code review has shown that there is no point
>    in trying to preserve more than <PRI>; RFC 3164 provides
>    a false impression of common behaviour.
> This is controversal, but the facts are suggesting this is the way it
> is.
> We should try to reach consensus on this.

A catch here is that extending the format to be:


may produce unexpected results with various syslog daemons.

> #2 The max message length issue resurfaces. There seems to be a
>    fragile consensus that we can life with the compromise in
>    syslog-protocol and eventualy open a debate if we (ever) go to
>    a TCP transport.
> Again, controversal, too.

This should be defined by each of the syslog/transport documents.
It shouldn't be documented in syslog-protocol because it is largely
dependent on the implementation.

> #3 There is a question if NUL octets are to be supported in
>    the MSG content.
> No consensus yet.

Why not just use '\' as the escape character to quote any value outside
of 32-126 ?  Isn't this close enough to a defacto-standard to use?

> #4 There seems to be a fragile consensus that MSG should 
>    primarily contain textual data, including XMLified content.
>    On the contrary, pure binary data should not be used.
> This is somewhat controversal.

I don't think this should be discussed.  It's data that fits #3.
End of story, as far as I'm concerned :)

> #5 Character encoding in MSG: due to my proof-of-concept
>    implementation, I have raised the (ugly) question if we need
>    to allow encodings other than UTF-8. Please note that this
>    question arises from needs introduced by e.g. POSIX. So we
>    can't easily argue them away by whishful thinking ;)
> Not even discussed yet.

This has implications for #3 & #4 and is possibly dependent on #10.

> #6 field order
> This is related to #1 and can, I think, quickly be fixed once #1 is
> settled.

This needs the header fields (#7, #10) to be accepted, as well, before
it can be settled.

> #7 Header fields: there seems to be a fragile consensus that
>    MSGID, PROCID, APP-NAME, and VERSION should be in the header
>    and TRUNCATE should not be in it.
> This needs to be finalized, but I think we are very close.

We should consider how to make them optional, too.

> #8 MSG-octet counting and/or trailer is resurfacing. I think
>    this item is not well understood and well discussed.
> We need to discuss it.

By trailer do you mean an End of Message (EOM) or EOR marker ?
Or something else ?

> #9 I have found some minor items not already discussed during
>    my proof-of-concept implementation (like "drop requirements"
>    and such). These are not absolutely vital, but should be
>    considered before a final text is issued (or even the next
>    revision).
> This needs to be discussed. As it is new, I have no idea what the
> discussion may lead to.

Are you referring to implementation details, here, with things like
"drop requirements" ?

If so, this is part of what would be a different document again,

> #10 STRUCTURED-DATA: there has been surprisingly few discussion
>     about STRUCTURED-DATA. I conclude that this is non-controversal.

Is this mean to be a header field?  Examples posted, so far, suggest
that it is.  To explain that comment, I'm considering everything prior
to MSG as a header.


Syslog mailing list

Reply via email to