Hi, Glen hit it correctly.
On Thu, 14 Aug 2003, Glen Zorn wrote: > > All of the current RFCs/Ids describe 7 bit US-ASCII only. So I don't > see any > > way to use UTF-8 in the current framework. > > But RFC 3164 just _documents_ BSD syslog, it doesn't _define_ IETF > syslog; I-Ds are made to be changed. Presumably, the purpose of this WG > is not just to document an ancient protocol, but to improve it. > Let me go over "The Way Things Work" in the IETF. :-) There are various kinds of "standards" developed in RFCs. RFC 3164 is Informational - this means that it does not represent a standard of any kind and may be safely ignored by everyone. The reason this Working Group wrote it was to explain the way that it had been seen to have been working and (more importantly) to document the security flaws in it. That paved the way for our subsequent works to fix those flaws. Both syslog-sign and RFC 3195 (reliable delivery) are Standards Track documents. This means that they will be real Internet Standards some day. This doesn't mean that they are immutable - there are multiple ways to change Standards. First, a Standard may be "Obsoleted". Let's take Telnet as an example. Jon Postel wrote RFC 761 in June 1980 to describe it. In May 1983, Jon and Joyce Reynolds wrote RFC 854 which Obsoleted RFC 761. This means that anyone looking for the specifications for Telnet should start with RFC 854. Second, a Standard may be augmented. Still using Telnet, in January 1993, David Borman wrote RFC 1408 explaining a new Telnet Option. Essentially this makes no changes to the Telnet specification but says that "this" may also occur within Telnet. Anyone looking to implement Telnet may stop reading after they finish RFC 854 but they would be wise to implement these Options for robustness and completeness. Third, a Standard may be "Updated". In January of 1994, David Borman published RFC 1571 which updates RFC 1408. This explains that there was a problem with RFC 1408 and RFC 1571 addresses it. The fundamental premise of RFC 1408 is still good but specifics are needed to describe a particular issue. People looking to implement Telnet should be reading RFC 854, 1408 and 1571. They should also be reading many other RFCs which describe various other features and options but that's beside my point. So..., we have the syslog-sign ID. This is going to be the first definitive Standard on syslog. :-) I think that it gives everyone a good basis for consistently providing event messages and a way to authenticate the origin of the messages. We could ask John and Jon to include a section on the Internationalization of messages within that document for completeness. However, I think that we're all ready for that document to be published and I don't know that John and Jon have any inclination or background to work on Internationalization issues. This is going to be fine as a basis from which to work on updates. Rainer is working on a way to Augment syslog-sign. His work will document how non-US-ASCII characters may be sent within syslog (as it is defined in syslog-sign). At some future time, someone may need to Update syslog-sign. For example, the TIMESTAMP-3339 describes time on this planet. Someone may have need to describe the time on Mars or on another planet in syslog messages so a new document may be written which will describe the problem and the resolution. [I am NOT asking for volunteers on that work at this time.] Finally, we have RFC 3195. Marshall and Darren wrote that based upon RFC 3164 which was all we had to go by at that time. When syslog-sign, and when syslog-international are published (or near enough) we can ask them to incorporate the changes needed. [Along with changes needed by the netconf WG.] They may choose to Update 3195, or they may Obsolete it. Thoughts on this (on the mailing list) will be accepted but it seems a bit premature until we see where syslog-international is going. What all of this means is that Rainer needs to look through the relevent RFCs describing Internationalization efforts and see how prior wisdom indicates how non-US-ASCII characters may be placed into syslog-sign - even if that means Augmenting syslog-sign to allow it to include 8-bit characters. As a subject matter expert, he needs to think about how it may be best done for the community at large. Does all of this make sense? Rainer: Apologies for talking about you in the third-person but it seemed like the best way to describe everything. :-) Thanks, Chris
