Anton,
very reasonable ;)
I think multi-part is a good term. OK, it triggers MIME in my head,
but I think every term used to split up a message into multipe
parts/fragments/segemnts/whatever is already used in some other context.
As we don't do MIME in syslog, multi-part should cause the least
Hi WG,
we talked quite a bit about different MTUs for different transport
mapping. We may run into a situation where a message is larger than is
actually supported by the transport (e.g a hypothetical SNMP trap
transport supporting only ~500 octets). As we have multi-part message in
-protocol, a
I have gone through all of the good posts on this issue. I have the
feeling that we currently have the following status:
- some people argue that a synced/I know my TZ indicator for the
timestmap has advantages in the real world
- some people argue that a synced/I know my TZ indicator for the
Rainer:
In the light of this sum-up, I propose the following compromise:
- we will continue to use the rfc 3339 timestamp in its
unmodified way
- we will ignore that RFC 3339 calls for timesync (because
we can't ensure it)
- there will be NO header field indicating the reliability
