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: syslog-sec-bounces@www....
> [mailto:syslog-sec-bounces@www....] On Behalf Of
> schang99@cisc...
> Sent: Thursday, September 22, 2005 3:07 AM
> To: syslog-sec@empl...
> Cc: clonvick@cisc...
> 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 [schang99@cisc...]
> > Sent: Monday, September 19, 2005 4:11 PM
> > To: 'syslog-sec@empl...'
> > 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
> >    �