Hi, Rainer: Thanks for accepting my request to fix the TRUNCATE field to 2 digits.
With the 2 digits fixed, the issue is indeed pretty much under control. As to the whether to swap the meaning for value 4 and 16, it's really debatable as to which one is a more likely case. I think it depends on sender's syslog application and their legacy code base. In most business cases, for a new messaging protocol to be adopted, the existing product's legacy code base is to be modified to make it new protocol compliant. This adoption of IETF syslog protocol is no exception. With the legacy code base to deal with in mind, you can imagine that there must be lots of existing rich features already in place maximizing the message payload usage to the fullest. In this situation, the new IETF format's overhead, such as Structure Data section, can very likely demand message truncation handling to a message. That's the view I, a developer, have in mind. As to whether the interim and/or receiver devices will be the more likely place for the truncation is really arguable and it's case by base at most. Finally, in essence, with the "fixed 2 digits" granted to me, I will leave this value meaning assignment to you for final decision, given that you will think about my reasoning above. Thanks, Steve > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:syslog-sec- > [EMAIL PROTECTED] On Behalf Of Rainer Gerhards > Sent: Thursday, September 22, 2005 5:19 AM > To: syslog-sec@employees.org > Subject: RE: [Syslog-sec] Change request on "Syslog protocol - version > 14,sec 6.2.4 TRUNCATE value" > > Steve, > > many thanks for the input. I understand the reasoning for the two digits > and find it well thought-out and useful. I will change that in the next > release of the draft if there is no objection against it (Chris: I guess a > change is OK in the current status of the ID?). > > However, I do not fully agree on the change of the values. The initial > idea was that truncation at the sender is expected to be a very rare > occurence. Truncation at the receiver seems much more likely. Based on > that assumption, I have assigned to lower number to the expected-most- > common case. In the current scheme, this leads to one-digit numbers for > the common case. That was the major driving force. > > Of course, if we use fixed two digits, this is no longer an issue. I am > still not convinced why a change in the values would be benefitial > (granted, there is also no hard reason to why they should be retained as > they are). However, I think a change should have a good reason. Probably I > am overlooking something. So I would appreciate if you could elaborate a > little on the advantage in changing these values. > > Rainer > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > [EMAIL PROTECTED] > > Sent: Thursday, September 22, 2005 3:07 AM > > To: syslog-sec@employees.org > > Cc: [EMAIL PROTECTED] > > Subject: RE: [Syslog-sec] Change request on "Syslog protocol > > - version 14,sec 6.2.4 TRUNCATE value" > > > > Hi, > > > > Someone just advised me that my previous email was encoded in > > UTF-8 by MS Outlook and it looked having some strange > > characters to some email readers. > > > > This email should be in ANSI encoding. > > > > Just in case I have also attached an enclosure of the same > > content saved in ANSI encoding. > > > > Thanks, > > > > Steve > > > > > -----Original Message----- > > > From: Steve Chang [EMAIL PROTECTED] > > > Sent: Monday, September 19, 2005 4:11 PM > > > To: 'syslog-sec@employees.org' > > > Subject: [Syslog-sec] Change request on "Syslog protocol - > > version 14, sec > > > 6.2.4 TRUNCATE value" > > > > > > (It seems the syslog-sec email server only takes plain text. > > > So, I am resending this email from last Friday night.) > > > > > > > > > Hi, > > > > > > > > > I would like to propose 2 changes to this latest draft > > version 14, section > > > 6 and section 6.2.4. > > > > > > 1.) Please reserve a fixed 2 digits for the TRUNCATE field. > > Do not make it > > > a 1*2 DIGITS as it's current specified. > > > > > > 2.) Please swap value 4 and value 16 designations for the truncation > > > semantics. > > > From: > > > VALUE Meaning > > > 1 all or some SD-ELEMENTs were truncated > > > 2 all or part of MSG was truncated > > > 4 truncation occurred at the receiver > > > 8 truncation occurred at an interim system > > > 16 truncation occurred at the initial sender > > > Table 3. TRUNCATE values. > > > > > > To: my change request: > > > VALUE Meaning > > > 00 no truncation > > > 01 all or some SD-ELEMENTs were truncated > > > 02 all or part of MSG was truncated > > > 04 truncation occurred at the initial sender > > > 08 truncation occurred at an interim system > > > 16 truncation occurred at the receiver > > > Table 3. TRUNCATE values. > > > > > > > > > Reasonings for the above changes: > > > At the initial sender, except for very rare > > occasions, normally > > > there should not be any truncation situations. Hence, > > > most syslog messages sent out should have no truncation. > > > So, it should be "0". > > > > > > Let's consider truncation scenarios my proposed scheme: > > > At the initial sender, for those exceptions when truncations > > > do happen, the truncation value can be set to combination of > > > "value 1" and/or "value 2" with "value 4" (initial > > sender) set. > > > > > > As a result, the truncation value from the > > truncation happened > > > at the initial sender can be of a value of ( 1 + 4 ) > > or ( 2 + 4 ) > > > or ( 1 + 2 + 4 ). Anyway, it's one digit number. > > > This single digit will be good for either truncation or > > > no truncation cases. > > > > > > However, truncation could happen at either interim > > system or at > > > the receiver end, then the trouble comes! The > > truncation field > > > will be added with value 8 or 16. It becomes 2 digits. > > > The message handler of the message to be truncated, > > already short > > > of space, needs to do message manipulations just to > > be able to > > > update the TRUNCATE value which was 1 digit into 2 digits. > > > This will be very cumbersome and illogical in practice. > > > > > > Therefore, I am proposing the new changes to fix the > > TRUNCATE field > > > to "2 DIGITS" as proposed above. This change will help the > > > involved > > > parties, in doing the message preparation or > > delivery, to update > > > the > > > TRUNCATE field with the least overhead and trouble. > > > > > > > > > Thanks, > > > > > > > > > Steve Chang > > > > > > > > > > > > > > > > > > ====== Some of the original text below from the draft > > version 14 ========= > > > > > > Internet-Draft The syslog Protocol > > July 2005 > > > 6. Required syslog Format > > > > > > The syslog message has the following ABNF [7] definition: > > > > > > SYSLOG-MSG = HEADER SP STRUCTURED-DATA [SP MSG] > > > > > > HEADER = VERSION SP FACILITY SP SEVERITY SP > > > TRUNCATE SP TIMESTAMP SP HOSTNAME > > > SP APP-NAME SP PROCID SP MSGID > > > VERSION = NONZERO-DIGIT 0*2DIGIT > > > FACILITY = "0" / (NONZERO-DIGIT 0*9DIGIT) > > > ; range 0..2147483647 > > > SEVERITY = "0" / "1" / "2" / "3" / "4" / "5" / > > > "6" / "7" > > > TRUNCATE = 1*2DIGIT <<***** Suggest to fix > > to 2 digits. > > > See reasoning later! > > > HOSTNAME = 1*255PRINTUSASCII > > > > > > APP-NAME = 1*48PRINTUSASCII > > > PROCID = "-" / 1*128PRINTUSASCII > > > MSGID = "-" / 1*32PRINTUSASCII > > > . > > > . (snip) > > > . > > > > > > > > > 6.2.4 TRUNCATE > > > > > > The TRUNCATE field is used to indicate if the message has been > > > truncated since it was sent or generated by an > > application. Such a > > > truncation might happen on the initial sender and any receiver, > > > including receivers on interim systems (relays). Values in the > > > TRUNCATE field are made up of bits. Each of this bits has been > > > assigned a specific value so that there is no doubt about bit > > > ordering. The values described in table 3 below MUST be used. > > > > > > VALUE Meaning > > > 1 all or some SD-ELEMENTs were truncated > > > 2 all or part of MSG was truncated > > > 4 truncation occurred at the receiver > > > 8 truncation occurred at an interim system > > > 16 truncation occurred at the initial sender > > > Table 3. TRUNCATE values. > > > . > > > . (snip) > > > . > > > > > > > > > > > > > > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec
