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

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 27 Oct 2005 18:35:56 +0200

Tom, 

> I am not quite clear about this.
> 
> In the I-D, it isn't really English (or American) that we are 

I talked about English to say that US-ASCII is sufficient. I am somewhat hesitant to put a requirement into the draft to actually use English. Maybe in the appendix, but I don't think it is wise to do it in the standards text.

> restricting
> SD-NAME to
> but, as the I-D says, to
>  PRINTUSASCII except = SP ] "
> There are lots of other English characters -  which this 
> keyboard won't
> generate - we do not want to see in there:-)  

Which ones do you think should be excluded, too?

> So far so good.
> 
> But you seem to be saying more, that SD-NAME SHOULD be an 
> English word, as
> opposed to German or French or .. as well as being limited to 
> the character set
> above.

see note above. Do you recommend we should actually make English an requirement?

Rainer
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "Rainer Gerhards" <[email-masked]>
> To: "Anton Okmianski (aokmians)" <[email-masked]>; 
> <[email-masked]>
> Sent: Monday, October 17, 2005 12:19 PM
> Subject: RE: [Syslog] Unicode - was: AD Review 
> fordraft-ietf-syslog-protocol-14
> 
> 
> Anton:
> 
> thanks for your reply. I agree that structured data can 
> contain (and probably
> does in a real use case) data that is also present in the MSG 
> part. As of this,
> there is need to support Unicode there, too. As you outline, 
> STRUCTURED-DATA is
> mostly machine-processed. I do not fully agree that it won't 
> be interpreted by a
> human, so there eventually is some hit by visual spoofing. 
> This is acceptable as
> the security concerns are outweighted by the required functionality.
> 
> However, there might still be one thing that we could consider to do:
> STRUCTURED-DATA consists of SD-IDs, PARAM-NAMEs and 
> PARAM-VALUEs. Your argument
> definitely shows that PARAM-VALUEs must support Unicode. But 
> is it true for the
> other two entities, too? Will we loose required functionality for the
> international community if we restrict either SD-ID, 
> PARAM-NAME or both to
> US-ASCII? If the answer is "no", then we can probably 
> restrict some entities. I
> know that local characters in these identifiers might be 
> helpful. But is it
> really something we MUST have?
> 
> Let me use an example. In Germany, "Müller" (containing u 
> with Umlaut - ü) is a
> common name. As such, a user name "Müller" is something we 
> can have. Now, if I
> encode this in (hypothetical) STRUCTRED-DATA, I may end up 
> with something like
> 
> USER="Müller"  [PARAM-NAME = PARAM-VALUE]
> 
> The "USER=" part should be locale- and language-ignorant - at 
> least in my point
> of view. So it is probably not a good idea that a German 
> implementation would
> encode it as
> 
> BENUTZER="Müller" ["Benutzer" is German for "User"]
> 
> While the extension-mechanism for vendor- and experimental 
> extensions does not
> specify any details, it probably is a good idea to use 
> English language tags in
> order to facilitate interpretation of the tags (and 
> universal) adoption. The
> extension mechanism should not be used as a translation tool. 
> (Maybe this is
> also something we should point out in syslog-protocol). But 
> if we intend to
> facilitate universal adoption of tags, we can probably 
> require them to be
> English names. And in such a case, US-ASCII would be sufficient.
> 
> Please do not misunderstand me. I am not suggesting that 
> using local language is
> a bad thing per se. I also do not think of the use of English 
> in this context as
> the use of the local language of e.g. the US and the British. 
> I am thinking
> about the use of English as the language of IT, the language 
> that - at least
> currently - lays the foundation for international 
> collaboration (and as such
> conceptually should not be tied to some nations). The fact 
> that I am from a
> non-native English speaking country might proove my point a little.
> 
> My concern is that if we encourage implementors to create 
> language-specific tag
> names, interoperability might become a much bigger problem 
> than when we stick
> with a single, universal (in this context!) language. I 
> currently do not see any
> samples where local-language tag names will actually be 
> required. Maybe I am
> overlooking the obvious. Maybe English is not sufficiently 
> enough considered to
> be the "univesal language of IT", so that local policies 
> might require tag names
> to be in local language. But at the same time, would this not 
> also mean that we
> would need to support not a single, universal, timestamp but 
> rather a wealth of
> different local formats?
> 
> Any feedback is deeply appreciated.
> Rainer
> 
> > -----Original Message-----
> > From: Anton Okmianski (aokmians) [mailto:[email-masked]]
> > Sent: Friday, October 14, 2005 5:56 PM
> > To: Rainer Gerhards; [email-masked]
> > Subject: RE: [Syslog] Unicode - was: AD Review for
> > draft-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: "Tom Petch" <[email-masked]>
Date: Thu, 27 Oct 2005 19:20:10 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Rainer Gerhards" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, October 27, 2005 6:35 PM
Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14

> In the I-D, it isn't really English (or American) that we are

I talked about English to say that US-ASCII is sufficient. I am somewhat
hesitant to put a requirement into the draft to actually use English. Maybe in
the appendix, but I don't think it is wise to do it in the standards text.

Tom Yes, a comment about using English words in an appendix sounds like a good
approach.

Tom - I am happy with the list we've got.  (I was thinking that English does
have characters - somewhat obscure - with diacritic marks and these do not
appear in USASCII; but they are not as significant as those in French or German
so USASCII is perfectly adequate to express what is wanted; but adding any
unqualified reference to English characters could be construed as including
them).

Rainer
<snip>

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 27 Oct 2005 15:28:21 -0400

> see note above. Do you recommend we should actually make 

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]