I could throw in a couple of comments to this thread ... but I think
Anton has well summed it up. I, too, vote that we get the current work
done. I'd like to begin to fiddle a little on the storage format before
the WG can actually look at it - I'll do so via loganalysis, but only
after
Hi WG,
I am trying to close up the current open issues for protocol before I
create new ones ;)
I would like to turn to issue 8, that is structured data element
placement. I have put together the (few) most important thoughts here:
http://www.syslog.cc/ietf/protocol/issue8.html
Anton proposed
Anton,
this is a tough one ;)
Well, I think demanding that capability is more about host
implementation. I think it is better to focus on the
protocol and what
the client/sender must put into the UTC offset field if one is not set
on the system.
This is right. And I have to admit it is an
Rainer:
I would like to turn to issue 8, that is structured data
element placement. I have put together the (few) most
important thoughts here:
http://www.syslog.cc/ietf/protocol/issue8.html
Anton proposed that we
a) allow elements only in their own, well-defined field
b) merge that
Hi!
I think that the 1024 bytes limit is rather arbitrary (CLR?). It does
not always avoid fragmentation, nor does it provide for efficient
transfer when larger messages need to be transmitted.
I assume we can't completely avoid fragmentation with -protocol, because
that would require a very
Let's not try to create a protocol just to standardzie something not
directly related to the internet. If you want to develop a parser and
have the parser accepted as a standard why don't you just develop it
as open source, say, on sourceforge?
Just for the records: I plan to include support
