Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14

From: "Steve Chang \(schang99\)" <[email-masked]>
Date: Fri, 14 Oct 2005 09:18:43 -0700

Hi,

Just a thought.

For this argument, to keep most people happy, it seems logical to expand
the HEADER section with 2 more fields which are still US-ASCII.

One is SD-encoding-type (1 byte) followed by anther one 
MSG-encoding-type (1 byte).

With these 2 1-DIGIT fields, everyone can have their own way.
The receiving end should have not problem decoding it.
It saves arguments and it allows code reuse in practice.

Steve

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Anton Okmianski (aokmians)
> Sent: Friday, October 14, 2005 8:56 AM
> To: Rainer Gerhards; [email-masked]
> Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-
> protocol-14
> 
> Rainer:
> 
> > So it might be useful to think about where we have an issue
> > at all. The MSG field, I think, does not count as identifying
> > information. It is meant as a human-readable message. Even
> > though it obviously carries information, I think it is not
> > subject to an easy visual spoofing attack. Ok, one can think
> > about scenarios where visual spoofing might cause confusion,
> > but the severity level of this should be fairly low. I think
> > it has the same implications as hoax mails, where
> > misinformation in the textual part is a simple fact of life
> > and not avoidable without stopping to use that service. So I
> > conclude that supporting the full set of Unicode characters
> > inside MSG is fine.
> 
> Agree.
> 
> > The STRUCTURED-DATA is another story. Here, it includes
> > information that might primarily be used as identifying
> > information.
> 
> Identifying, but mostly used by software that can filter messages,
which
> is not susceptible to visual character confusion.
> 
> > Reviewing the current defined SD-IDs, I hardly
> > see any need for using Unicode encoding. As far as I recall,
> > we have selected Unicode instead of US-ASCII because we
> > thought it might be benefitial for further extensions.
> > However, given the fact of visual confusability and the need
> > to deal with it, I am questioning if it acually is a good
> > idea to encode STRUCTURED-DATA in Unicode. Wouldn't it be
> > better to use US-ASCII, which relievs us of all of these
> > issues? So far, I do not see a compelling reason for full
> > Unicode support in SD-IDs.
> 
> With all due respect, I strongly disagree. Structured data may include
> anything. It is just structured. It can contain same pieces of
information
> that may be found in the message.
> 
> We have a very specific use-case where a structured element is a
username.
> And that username can be in Japanese.  I can see many other use-cases
like
> this.  Being from Germany, I am sure you can easily come with some
too. :)
> How about any company name in a foreign language?  Address?  English
is
> not an exclusive language of system administration anymore.
> 
> > Of course, we could just go ahead and document these issues
> > in security considerations. I think, however, that we should
> > try to solve them before resorting to that. I think we have a
> > good chance of finding a workable solution.
> >
> > My suggestion to the WG is that we drop Unicode encoding for
> > STRUCTURED-DATA and use printable US-ASCII instead.
> >
> > I would appreciate feedback on the following:
> >
> > #1 Is it OK the support Unicode - without restriction - in MSG?
> 
> Well, the restriction is that we require use of the most compact
encoding
> as you mentioned.
> 
> > #2 Is there support in the WG for changing STRUCTURED-DATA encoding
> >    from Unicode to US-ASCII?
> 
> Not from me. :) In fact, I think it is very critical to support
non-ASCII
> in structured data.
> 
> Thanks,
> Anton.
> 
> >
> > If the answer to #2 is "no", please provide reasoning as that
> > will help speed up the process.
> >
> > --
> > Rainer
> >
> > _______________________________________________
> > Syslog mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/syslog
> >
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/syslog

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Fri, 14 Oct 2005 12:24:07 -0400

And the receiver has to support both? A MUST?

Generally, the more options, the harder is the interop. 

Anton.  

> From: Steve Chang (schang99) 
> Sent: Friday, October 14, 2005 12:19 PM
> To: Anton Okmianski (aokmians); Rainer Gerhards; [email-masked]
> Subject: RE: [Syslog] Unicode - was: AD Review 
> fordraft-ietf-syslog-protocol-14
> 
> Hi,
> 
> Just a thought.
> 
> For this argument, to keep most people happy, it seems 
> logical to expand the HEADER section with 2 more fields which 
> are still US-ASCII.
> 
> > > So it might be useful to think about where we have an 
> issue at all. 
> > > The MSG field, I think, does not count as identifying 
> information. 
> > > It is meant as a human-readable message. Even though it obviously 
> > > carries information, I think it is not subject to an easy visual 
> > > spoofing attack. Ok, one can think about scenarios where visual 
> > > spoofing might cause confusion, but the severity level of this 
> > > should be fairly low. I think it has the same 
> implications as hoax 
> > > mails, where misinformation in the textual part is a 
> simple fact of 
> > > life and not avoidable without stopping to use that service. So I 
> > > conclude that supporting the full set of Unicode 
> characters inside 
> > > MSG is fine.
> > 
> > Agree.
> > 
> > > that might primarily be used as identifying information.
> > 
> > which is not susceptible to visual character confusion.
> > 
> > > Reviewing the current defined SD-IDs, I hardly see any need for 
> > > using Unicode encoding. As far as I recall, we have 
> selected Unicode 
> > > instead of US-ASCII because we thought it might be benefitial for 
> > > further extensions.
> > > However, given the fact of visual confusability and the 
> need to deal 
> > > with it, I am questioning if it acually is a good idea to encode 
> > > STRUCTURED-DATA in Unicode. Wouldn't it be better to use 
> US-ASCII, 
> > > which relievs us of all of these issues? So far, I do not see a 
> > > compelling reason for full Unicode support in SD-IDs.
> > 
> > information that may be found in the message.
> > 
> > We have a very specific use-case where a structured element 
> is a username.
> > like this.  Being from Germany, I am sure you can easily come with 
> > some too. :) How about any company name in a foreign language?  
> > Address?  English is not an exclusive language of system 
> administration anymore.
> > 
> > > Of course, we could just go ahead and document these issues in 
> > > security considerations. I think, however, that we should try to 
> > > solve them before resorting to that. I think we have a 
> good chance 
> > encoding as you mentioned.
> > 
> > non-ASCII in structured data.
> > 
> > Thanks,
> > Anton.
> > 
> > >
> > > If the answer to #2 is "no", please provide reasoning as 
> that will 
> > > help speed up the process.
> > >
> > > --
> > > Rainer
> > >

---

From: "Steve Chang \(schang99\)" <[email-masked]>
Date: Fri, 14 Oct 2005 09:37:01 -0700

Yes. I would think these 2 new fields have to be MUST fields.

In reality, the receiver is already required by this new protocol 
to be bilingual to handle both US-ASCII and UNICODE.  
As a developer, I do not see difficulty in decoding the 2 encoding 
types up front and then apply the indicated decoding scheme to 
SD and MSG part of message.

It's a small price to pay as compared to hardcode this new protocol
with only one encoding type (you lose flexibility this way.)
Facing no win-win situation, I naturally choose the least cost option.

Steve

> From: Anton Okmianski (aokmians)
> Sent: Friday, October 14, 2005 9:24 AM
> To: Steve Chang (schang99); 'Rainer Gerhards'; [email-masked]'
fordraft-ietf-syslog-

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 14 Oct 2005 18:50:46 +0200

Steve,

here, I agree with Anton. The reason is that this calls for both
encodings, but that will not save us the hassles with Unicode.

Please keep in mind

> to be bilingual to handle both US-ASCII and UNICODE.  

That is not fully true. US-ASCII is a subset of UNICODE, so there is no
need to detect US-ASCII at all - it inherently is there with UNICODE.

> SD and MSG part of message.

That does not solve the issues with Unicode visual spoofing.

Rainer
PS: I need to leave now, will reply to Anton's initial comment later...

> > > > > life and not avoidable without stopping to use that 
> service. So
> I

---

From: "Steve Chang \(schang99\)" <[email-masked]>
Date: Fri, 14 Oct 2005 09:58:57 -0700

Thanks for the clarifications.

I agree with your view now.

Steve

> On Behalf Of Rainer Gerhards
> Sent: Friday, October 14, 2005 9:51 AM
> To: [email-masked]
fordraft-ietf-syslog-
> > > > > > instead of US-ASCII because we thought it might be
benefitial
> > for
in

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 28 Oct 2005 08:03:52 +0200

David,

I think this thread got a little out-of-sync. I think there is no doubt
about the fact that syslog must support all international languages, so
that any local information can be conveyed. This was one of the major
driving factors behind syslog-protocol. What I have been discussing with
Tom here is wheter or not the *tag* (SD-IDs) need to have full
international support. The SD-Ids are identifying information, you might
think of them like extended header-fields or - maybe a better example -
like XML tags. They identify the information that is provided in a given
element.  

The full reasoning is given in 

    http://www.mail-archive.com/syslog%40lists.ietf.org/msg00013.html

Rainer

> From: David B Harrington [mailto:[email-masked]] 
> Sent: Thursday, October 27, 2005 9:28 PM
> To: 'Tom Petch'; Rainer Gerhards; [email-masked]
> > see note above. Do you recommend we should actually make 
> > English an requirement?
> 
> I think that would be a mistake. 
> 
> For a vendor, e.g. a Chinese vendor, who produces switches that are
> sold only to the Chinese market, whose customers speak primarily
> Chinese and have limited English skills, forcing implementers to hire
> translators to translate their syslog messages into English and
> USASCII, and forcing their customers to hire translators to translate
> the syslog messages back into Chinese so they can understand them is
> simply stupid.
> 
> We should make the character set UTF-8, not USASCII, so the whole
> world can send messages in the language that best suits their
> customers' environments. For many of those environments, English will
> be the language of choice because it is widely used in the IT world.
> But we should not force vendors to implement in languages that are
> inapprorpriate for their audiences.
> 
> If we want to force standardization, let's focus on the message
> content rather than standardizing the language the proprietary content
> is expressed in.
> 
> David Harrington
> [email-masked]
> 
> 
> 
> 
>