Hi Albert, On Tue, 26 Aug 2003, [EMAIL PROTECTED] wrote:
> > > John and Jon have updated syslog-sign: > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-12.txt > > > [[Grrr]]. Every time I continue on implementing draft-N, J&J come > up with draft-<N+1>. I never catch up, that way :-) IDs get revised based upon comments. ..and all of the comments seem to be coming from you. ;-) > > However, I will switch to draft-12 now. And will comment it as soon I > find thing "hard" to implement. > > > The first one's are found: > > sec 2.2 TIMESTAMP(3339) > ======================= > Are the following timestamps allows/wanted? > (1) 2003-08-26T12:01:00-00:00 > (2) 2003-08-26T12:02:00.+02:00 > (3) 2003-08-26T12:03:00.12345678901Z > > Ad 1. This an UTC time, but with an offset of zero instead of a "Z" > to denote UTC. I have implemented this, while it easy to do. > (less code) and it seams to be allowed. > Ad 2. Currently this is not allowed. There should be at least 1 > digit after the (fracseconds) dot. ("1*DIGIT") > I can live with this. But I often see a construction like > this; e.g. to denote "the fraction is unknown/unaccurate". > Possible we should allow it (but I'm NOT asking for it) > Ad 3. When a TZ offset is used, there is only "space" for > 6 secfrac digits ("millisecond"). When UTC is used (with "Z") > the resolution can be increased with 3 digit ("microseconds"). > I think we should not "allow" that. And change the syntax to > allow upto 6 digits, for all timezones. > Then, the limit 'upto 32 positions' for the complete timestamp > is met, always. > > > sec 2.1 PRI > =========== > > As Chris explained, syslog-sign is/will be the "official standard" for > syslog, not rfc3164. It's improved. So we can also remove "historical > limits". The upper value of "191" for PRI (local7.debug) is such a limit. > Without changing the protocol (which has space for 3 digits ("999"), we > can extent this. It's not simple to add severities, but we can add > facilities with out braking anything. > > 999 happens to be 124*8+7. So I propose to extent the allowed facilities > to 124. > > This gives a lot of possibilities for new numbers. Here, we have the > four options: > First, simply add "local8" to "local108". > Second, assign some `new numbers' to 'new, modern items' (e.g. Web, ssh, > virus, database,..) > Third, we make it "assigned numbers" (like ports etc), and define the > "outside this rfc". Then, it is possible to extent syslog-numbers, as > needed. Possible, this can/must be done by IANA. > Last, we can assign some numbers, and define the rest as "reserved" (but > allowed). > Personally, I would vote for option 3. > > To extent the facilities, we only have to add 1 of 2 paragraphs to > section 2.1. When requested, I'm willing to propose one. > > NOTE: I Agree, this remark is late. I was always on the track "keep in > inline with rfc3164", but the mail of Chris has shown me we are allowed > to improve syslog. I think this simple change is a big improvement! (Let > face it, the current "name/numers" are old) What you are suggesting with your Option 3 is to have a new part in the "IANA Considerations" of syslog-sign stating the Facilities not defined are open to future use by the consensus process (RFC 2434 page 6). That sounds good to me. The current set of Facilities and Severities are listed by IANA here: http://www.iana.org/assignments/syslog-parameters If we do define new Facilities in syslog-sign, then they will have to adhere to all of the requirements and specifications of syslog-sign when it becomes an RFC. Right now I'm trying to think of how to "Internationalize" the entire syslog packet rather than just the MSG part. It __may__ be that we will want PRI values of <193> to <383> to have the same Fac/Sev values as <0> through <192> but a device receiving any of those PRI's would know that the entire packet (following the PRI) is in UTF8. That's really just an example of why we may want to put off that decision at this time as I'm really waiting for someone from the IAB to get back to me on the thought of real Internationalization. Of course you know that these suggestions will require J&J to produce syslog-sign-13. ;-) Seriously, these are good items to bring up. Thanks, Chris
