On Sun, Dec 22, 2002 at 08:07:55AM -0800, Christopher Lonvick wrote: > > On Fri, Dec 20, 2002 at 12:45:47PM -0800, Christopher Lonvick wrote: > > the question of rfc3339 timestamps. > > I'd like to discuss that separately from this discussion of a tcp-based > transport. The last I saw, you had raised a question about sending the > time referenced to GMT rather than local timezone. Was that resolved? If > it is the consensus of the WG to use that format (along with accepting > the traditional 3164 timestamp format), then it may be placed into > syslog-sign.
I was advocating the localtime format. IIRC it was Darren Reed who suggested the timestamp to be sent in GMT. I think at the end we agreed that the timestamp should be transmitted in localtime, and converted to GMT on the receiver if needed. > > > I'm still not seeing what features/functions are missing from 3195, or > > > what features/functions a simple tcp-based syslog would fill. I don't see > > > that documenting any/all of the old methods would serve a purpose either. > > > > > > I'll keep this discussion open to see if we can get a clear reason for a > > > simple reliable tcp protocol. > > > > the reason is similar to why RFC3164 was released: document current > > practices. The protocol described in RFC3164 has been extended in nearly all > > syslog implementations developed recently. > > Would that be to document all of the ways that the fields were > extended/expanded/morphed, or to describe the various tcp-based > implementations, or both? I would not necessarily go for expanded field description, though I can be convinced here. Syslog-ng for instance defines a new hostname format which includes hop information (hop means that each relay appends its hostname to the chain of hostnames). As this extended hop format is more or less compatible with plain hostnames, this does not cause incompatibility. The description should focus on the means of encapsulating one single message into the TCP stream, where the message has the same format as the UDP packet in RFC3164. One example might be (please forgive me my non-native English): TCP based transport Syslog/tcp uses the Transport Control Protocol (TCP) as its underlying transport layer mechanism. The TCP port that has been assigned to syslog/tcp is 11111 (FIXME an IANA assignment is needed). Either the syslog sender (push mode) or the receiver (pull mode) may initiate a TCP connection to the other side. In push mode the sender and the initiating side of the TCP connection is the same. In pull mode the receiving side connects to the sender first, thus the side initiating the connection and the one sending messages are not the same. The role of the sender/receiver and connection related parameters (source IP/port, destination IP/port) are specified externally, possibly in the configuration of the implementation. After the connection is established in either modes, the sender starts sending messages in a format defined by RFC3164 section 4. An exception is that unlike UDP, TCP is stream based, thus a way to separate messages is needed. For this purpose we reserve the NL (ASCII 10) character which MUST NOT occur in message bodies. Each message is terminated by a NL (ASCII 10) character or a CRLF sequence (ASCII 13, 10). As the communication takes place in one way only either the sender or the receiver MAY shut the connection down in the unneeded direction. ------ Of course a length prefixed protocol would also be possible, where embedded NLs are not a problem, this is the protocol which is used by syslog-ng, and - as I know - by Cisco PIXes. I strongly oppose anything more complex, if one needs negotiation, optional fields or anything like that the BEEP based syslog protocol is the route to follow. As for the extensions of different fields, they are usually simply lifting some of the restrictions in RFC3164 (for example syslog-ng is able to send FQDN instead of a simple hostname, as I have users who have over 30 hosts named ns where the fqdn is unique). -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
