Devin Kowatch wrote: > > Hi, > I have a few questions about syslog-relaible, I was hoping that this > group could help clarify some things. > > 1. BUG: the syslog COOKED DTD is missing a hostname attribute to the > <entry> tag.
Yes. I've added that for the next iteration. > 2. What is the difference between the hostname atribute and deviceFQDN > attribute (in the <entry> tag)? The deviceFQDN is the fully qualified domain name for the device that originated the message. The hostname is taken from the message and is not fully qualified. That is, "hostname" is a mirror of the same field as described in RFC3164 part 4.1.2, while deviceFQDN gives the DNS name of the device. I would think that if you're normally using TCP/IP for everything, the hostname would match the start of the deviceFQDN in the usual circumstances. I can imagine they might differ if you're also running NetBEUI that allows spaces and apostrophes and such in the names. > 3. The link properties described in section 4.4.3 lists a 'U' property > that indicates that a valid user has been authenticated. I find this > a little strange because I don't really see users authenticating > to a syslog server, I only see other hosts authenticating. Is 'U' > meant to be used when a vaild host has sucessfully authenticated? Yes. "User" is SASL-speak for a login name, basically. The host is the user of the connection. > Also how is this different than the 'A' link property, which > indicates that an authentication layer is being used? It's possible that a user has logged in on this link, but that messages could be injected by an intruder without said injections being detected. In other words, it's the fourth part of A/I/L/R - In reverse order, no replay, no loss, no modifications, no additions. I.e., every message is authentically coming from where it claims to be coming from. > 5. What is the intended treatment of white space in betewen <entry> and > </entry>. Would > <entry ...> > Some message.</entr> > > be printed as "\nSome message." or as " Some message." or as "Some > Message" or does it matter? Ummmm... Don't do that. :-) See 4.1.3 of RFC3164. > 7. Can the syslog server (BEEP Listener) cut off the client (BEEP > Initiator) by sending a <close ...> before the client has indicated > that it's done? According to the rules on page 20 of RFC3080 (regarding the <close> operation), if the peer has sent the MSG but not received any ANS frames, it may not issue the <close>. Once the peer starts getting ANS frames back, it can issue the close, but must continue processing ANS frames until it gets the OK. The device has to finish sending all ANS frames, then the NUL, and then can close the channel. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://images.fbrtech.com/dnew/ ** Try our EbolaBurgers... So tender they melt in your mouth.
