Chris and all, I am right now out of office and on a dial-up. Thus, I did not have your posting with me before I wrote my last post.
I thank you for the explanation which greatly clarifies the overall picture. I just still wonder if it would make sense to specify a general syslog format, that then can be mapped to the upper and lower layers. Maybe I can try to craft syslog-international in that way - using both the previous great work in this WG as well as the other internationalization work. Does this make sense? Should I carry on in this way? Any more comments? Rainer > -----Original Message----- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Friday, August 15, 2003 5:02 PM > To: [EMAIL PROTECTED] > Subject: RE: Protocol Action: 'UTF-8, a transformation format > of ISO 10646' to Standard (fwd) > > > 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 > > >
