: Friday, January 20, 2006 8:57 AM
To: Tom Petch
Cc: [EMAIL PROTECTED]
Subject: Re: [Syslog] Sec 6.1: Truncation
Is the truncation of a message on a UTF-8 boundary rather
than within an extended character something that syslog
daemons SHOULD do rather than MUST do ? (To use the RFC words
.
Tom Petch
- Original Message -
From: Anton Okmianski (aokmians) [EMAIL PROTECTED]
To: Darren Reed [EMAIL PROTECTED]; Tom Petch
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, January 20, 2006 4:39 PM
Subject: RE: [Syslog] Sec 6.1: Truncation
I think the suggestion from me and Tom
- Original Message -
From: Rainer Gerhards [EMAIL PROTECTED]
To: Tom Petch [EMAIL PROTECTED]; Darren Reed
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, January 18, 2006 9:32 AM
Subject: RE: [Syslog] Sec 6.1: Truncation
Tom,
I agree there are some issues with truncation
- Original Message -
From: Darren Reed [EMAIL PROTECTED]
To: Tom Petch [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, January 16, 2006 10:51 PM
Subject: Re: [Syslog] Sec 6.1: Truncation
[ Charset ISO-8859-1 unsupported, converting... ]
Truncation of UTF-8 is actually slightly
[ Charset ISO-8859-1 unsupported, converting... ]
Truncation of UTF-8 is actually slightly worse than has been described.
It is possible to determine from the UTF-8 octets where one coded
character ends and another begins. But because Unicode contains
combining characters, with no limit on
-
From: Rainer Gerhards [EMAIL PROTECTED]
To: Anton Okmianski (aokmians) [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, January 11, 2006 11:30 AM
Subject: RE: [Syslog] Sec 6.1: Truncation
Anton and all,
I have now changed section 6.1 to:
###
6.1. Message Length
Syslog message
the original sender anyway. It is not ideal, whichever way you slice it.
Anton.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Balazs Scheidler
Sent: Thursday, January 12, 2006 5:07 AM
To: Rainer Gerhards
Cc: [EMAIL PROTECTED]
Subject: RE: [Syslog] Sec
Anton and all,
I have now changed section 6.1 to:
###
6.1. Message Length
..
Well written and very sensible.
Darren
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
On Wed, 2006-01-11 at 22:38 +1100, Darren Reed wrote:
Anton and all,
I have now changed section 6.1 to:
###
6.1. Message Length
..
Well written and very sensible.
I like it too :)
--
Bazsi
___
Syslog mailing list
-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards
Sent: Monday, January 09, 2006 4:49 PM
To: Anton Okmianski (aokmians)
Cc: [EMAIL PROTECTED]
Subject: RE: [Syslog] Sec 6.1: Truncation
Rainer:
I agree - this is better than a convoluted rule.
I
PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anton
Okmianski
(aokmians)
Sent: Friday, January 06, 2006 9:48 PM
To: [EMAIL PROTECTED]
Subject: [Syslog] Sec 6.1: Truncation
Rainer and all:
I started reading draft #16. Since we are revisiting
everything... I
am
3:21 AM
To: Anton Okmianski (aokmians)
Subject: RE: [Syslog] Sec 6.1: Truncation
Anton, Darren,
I agree that the truncation rule is probably not really
useful, even confusing. I think it is hard to predict for any
potential message if the more interesting content is in
STRUCTURED-DATA
[ Charset ISO-8859-1 unsupported, converting... ]
Rainer and all:
..
Receivers SHOULD follow this order of preference when it comes to truncation:
1) No truncation
2) Truncation by dropping SD-ELEMENTs
3) If 2) not sufficient, truncate MSG
I don't think that this is a good
Rainer and all:
I started reading draft #16. Since we are revisiting everything... I am not
very comfortable with the current truncation rules.
Receivers SHOULD follow this order of preference when it comes to truncation:
1) No truncation
2) Truncation by dropping SD-ELEMENTs
3) If 2) not
14 matches
Mail list logo