I definitely agree with Dan here.
The original purpose of the mailing list was to build an RFC,
which pretty much implies just net stuff. On the other hand, the
net spec by itself isn't really that interesting without a
reference implementation that does the other stuff that's needed
too.
Furthermore, the list seems to have bogged down with silly issues
like how to transmit timestamps (I'm guilty of this too), when it
hasn't even answered questions like what information needs to be
on the wire, etc.
I suggest the following roadmap:
1. Decide on fundamental services/information
o Possibilities I can think of include facility, level,
message-text, originating host, originating timestamp
2. Decide on standard optional information
o Possibilities I can think of include program name,
process id, timezones, etc.
3. Decide on standard optional services
o Possibilities I can think of include signing of
messages, encryption, hop-by-hop authentication, and
quality-of-service stuff (like putting high-severity
messages in the queue first so they don't get dropped
or wait when there's congestion)
4. Come up with a net protocol that can express the fundamental
and optional information, provide the optional services, and
possibly be extensible to additional informational fields
while balancing all this against bandwidth ease of parsing,
etc.
5. Decide on features needed in the reference implementation.
6. Design the reference implementation, including config files,
etc.
7. Build the reference implementation.
--
Chris Calabrese
Internet Infrastructure and Security
Merck-Medco Managed Care, L.L.C.
[EMAIL PROTECTED]
.
