And the receiver has to support both? A MUST? Generally, the more options, the harder is the interop.
Anton. > -----Original Message----- > From: Steve Chang (schang99) > Sent: Friday, October 14, 2005 12:19 PM > To: Anton Okmianski (aokmians); Rainer Gerhards; [EMAIL PROTECTED] > 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. > > 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 PROTECTED] > > [mailto:[EMAIL PROTECTED] > > On Behalf Of Anton Okmianski (aokmians) > > Sent: Friday, October 14, 2005 8:56 AM > > To: Rainer Gerhards; [EMAIL PROTECTED] > > 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 > > > 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
