Hi All,
I am finding that the people contributing to the mailing list are making
progress in defining a useful protocol. I also see that they are
discussing implementation details. Both of these tell me that we're on
the right track.
What we found in Vancouver is that we were on the wrong track. The
protocol being discussed was going to break existing receivers and
information was going to be dropped on the floor. By keeping PRI, the
existing receivers will not drop things on the floor and we can expect a
much better acceptance rate from the community.
We've seen that RFC 3195 is being implemented. I do not want to de-focus
this group by encouraging discussion of that at this time. After we get
syslog-protocol and syslog-transport-udp submitted to the IESG, I will ask
how we want to proceed with a revision of that Proposed Standard. One
person has suggested to me that it can be revised through an individual
submissionn.
Rainer's list (below) will serve as our list of issues. I'd like for
these to be closed out within 2 weeks. I'm going to look for rough
consensus on these issues and I will greatly appreciate everyone accepting
the decisions we make at the end of that time. After that, I'll ask for
Rainer to submit a new ID. If needed, I'll also ask for Anton to submit a
new ID. I'll allow a week of review on those. If we still see
implementors willing to implement this then we will progress these to the
IESG.
Addtional comments below.
On Fri, 25 Nov 2005, Rainer Gerhards wrote:
Tom, WG:
Comments inline...
Rainer
[tp] Strange, I was thiinking quite the opposite, that we had
a fragile
consensus which disappeared in
Vancouver and has not been refound. Looking back at the
messages posted in the
past few days, about what should be in the header in what
order, I was thinking,
what now? because I see no consensus, rather the re-emergence of many
different points of view.
So while the proposed charter looks ok, because it does not
go into that detail,
I do not see how we progress any further, into the next level
of technical
detail, of what and
how should be in the header.
I agree that we have not found consensus again. However, I think we are
in a better shape on the details than it it might look. My personal view
is that many items are shortly before reaching actual consensus. Let me
sum up the items I see. We might use that as a potential basis for
reaching consensus.
#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.
3164 was written based upon what Eric told me of how things originally
worked. Obviously not much has stayed that way since. We can accept that
things are received and placed in the right bins if a message has PRI.
I'm OK with keeping that and defining the rest of the message as long as
we keep the free-form text which has been the basis of syslog for all of
these years.
#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.
#3 There is a question if NUL octets are to be supported in
the MSG content.
No consensus yet.
#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.
If we can agree that a natural language indicator (likely an SD-ID
element) can be defined, then I believe that we are setting the stage so
that future definitions may be made to allow for XML, binary, and perhaps
even Martian. Those are outside of the current scope of the WG. Let's
concentrate on transferring the textual information.
#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.
I haven't reviewed that yet. However, I'll note that allowing different
encoding can be accomplished in the future as long as we establish a
default encoding and a way to identify it in our current work.
#6 field order
This is related to #1 and can, I think, quickly be fixed once #1 is
settled.
Agreed.
#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.
Agreed.
#8 MSG-octet counting and/or trailer is resurfacing. I think
this item is not well understood and well
