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 PROTECTED]> > To: "Anton Okmianski (aokmians)" <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > 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 PROTECTED] > > Sent: Friday, October 14, 2005 5:56 PM > > To: Rainer Gerhards; [EMAIL PROTECTED] > > 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 > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
