Or we could simply reiterate Postel's law: "In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior. That is, it must be careful to send well-formed datagrams, but must accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear)." [STD5]
dbh > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Friday, January 05, 2007 8:47 AM > To: Glenn M. Keeni; [EMAIL PROTECTED] > Subject: RE: [Syslog] Syslog Protocol doubts > > Hi Glen, > > thanks for the message. Let me start on an overview level: if you look > at the evolution of the draft, you will see that earlier versions were > quite specific on what to do if the message was malformed. However, > based on dicussion, one after another of these rules were deleted. The > reason was always that MUSTs here are not actually needed to ensure > interoperability. > > You can get a glimpse of this discussion by looking at > > http://www.syslog.cc/ietf/why-indepth.html > > This is a very old page. For more recent samples, you should > consult the > mailing list archives. There are (too) plenty samples of this being > discussed to point to anything specific. > > The bottom line behind the current draft is that we do not necessarily > specify what happens if the message is malformed. This is not > vital for > interoperability. Also, implementors will provide different solutions > (most probably operator-configurable) to address real-world needs. For > example, we could specify that a message with leap seconds in > it MUST be > discarded - but if the operator insists that he needs such a > message, an > implementor will always create a way to process it. > > We are specific on invalid UTF-8 sequences. This must not be > interpreted, because this is a big security issue. However, > even than it > might be OK for an implementation to store the invalid UTF-8 sequence. > > If that is consensus, we can add the statement "the handling of > non-compliant messages will be implementation dependent" which very > precisely describes the list consensus. > > Rainer > > > -----Original Message----- > > From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] > > Sent: Friday, January 05, 2007 12:32 PM > > To: [EMAIL PROTECTED] > > Subject: [Syslog] Syslog Protocol doubts > > > > Hi, > > I have been trying to figure out the error conditions > > that a syslog receiver will need to anticipate and the > > corresponding actions that it is expected to take. I do > > not see this clearly spelt out in the protocol document. > > There are several MUST clauses, I understand that a > > compliant syslog sender WILL always send messages that > > meet the MUST clauses. But the document does not spell > > out clearly what a compliant syslog receiver will do > > when it gets a non-compliant message. Possible actions > > could be: > > a. discard whole message > > b. discard non-compliant part ( assuming the non- > > compliant part can be isolated) > > c. rectify the non-compliance e.g. > > - truncate message: [this is mentioned in 6.1] > > - truncate the long-fields (software, > > swVersion etc.) > > d. implementation dependent > > > > Is this a problem ? I have listed the MUST conditions > > in the attached document. My take is that we may have to > > address each one of these. Or we can include a sweeping > > statement like " non-compliant messages will be discarded" > > or "the handling of non-compliant messages will be > > implementation dependent". > > > > Glenn > > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
