Subject: [Syslog-sec] Change request on "Syslog protocol - version 14, sec 6.2.4 TRUNCATE value"

From: [email-masked]
Date: Mon, 19 Sep 2005 16:11:12 -0700

(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
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: <[email-masked]>
Date: Wed, 21 Sep 2005 17:07:15 -0800

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-masked]]
> Sent: Monday, September 19, 2005 4:11 PM
> To: [email-masked]'
> Subject: [Syslog-sec] Change request on "Syslog protocol - version 14, sec
> 6.2.4 TRUNCATE value"
> 
>        So, it should be "0".
>        "value 1" and/or "value 2" with "value 4" (initial sender) set.
> 
>        or ( 1 + 2 + 4 ).   Anyway, it's one digit number.
>        to "2 DIGITS" as proposed above.   This change will help the
> involved

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 22 Sep 2005 14:18:41 +0200

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Thursday, September 22, 2005 3:07 AM
> To: [email-masked]
> Cc: [email-masked]
> 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.
> 
> > I would like to propose 2 changes to this latest draft 
> version 14, section
> > 6 and section 6.2.4.
> > 
> >        parties, in doing the message preparation or 
> delivery, to update
> > the
> >       TRUNCATE        = 1*2DIGIT    <<*****  Suggest to fix 
> to 2 digits.
> > See reasoning later!

---

From: [email-masked]
Date: Thu, 22 Sep 2005 14:50:18 -0700

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

> From: [email-masked] [mailto:syslog-sec-
> [email-masked]] On Behalf Of Rainer Gerhards
> Sent: Thursday, September 22, 2005 5:19 AM
> 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
>