Rainer, I've put some comments about your list below. If you repost this, you might want to re-order ... there are a few dependencies within this list.
> #1 testing and code review has shown that there is no point > in trying to preserve more than <PRI>; RFC 3164 provides > a false impression of common behaviour. > > This is controversal, but the facts are suggesting this is the way it > is. > We should try to reach consensus on this. A catch here is that extending the format to be: <PRI>VERSION may produce unexpected results with various syslog daemons. > #2 The max message length issue resurfaces. There seems to be a > fragile consensus that we can life with the compromise in > syslog-protocol and eventualy open a debate if we (ever) go to > a TCP transport. > > Again, controversal, too. This should be defined by each of the syslog/transport documents. It shouldn't be documented in syslog-protocol because it is largely dependent on the implementation. > #3 There is a question if NUL octets are to be supported in > the MSG content. > > No consensus yet. Why not just use '\' as the escape character to quote any value outside of 32-126 ? Isn't this close enough to a defacto-standard to use? > #4 There seems to be a fragile consensus that MSG should > primarily contain textual data, including XMLified content. > On the contrary, pure binary data should not be used. > > This is somewhat controversal. I don't think this should be discussed. It's data that fits #3. End of story, as far as I'm concerned :) > #5 Character encoding in MSG: due to my proof-of-concept > implementation, I have raised the (ugly) question if we need > to allow encodings other than UTF-8. Please note that this > question arises from needs introduced by e.g. POSIX. So we > can't easily argue them away by whishful thinking ;) > > Not even discussed yet. This has implications for #3 & #4 and is possibly dependent on #10. > #6 field order > > This is related to #1 and can, I think, quickly be fixed once #1 is > settled. This needs the header fields (#7, #10) to be accepted, as well, before it can be settled. > #7 Header fields: there seems to be a fragile consensus that > MSGID, PROCID, APP-NAME, and VERSION should be in the header > and TRUNCATE should not be in it. > > This needs to be finalized, but I think we are very close. We should consider how to make them optional, too. > #8 MSG-octet counting and/or trailer is resurfacing. I think > this item is not well understood and well discussed. > > We need to discuss it. By trailer do you mean an End of Message (EOM) or EOR marker ? Or something else ? > #9 I have found some minor items not already discussed during > my proof-of-concept implementation (like "drop requirements" > and such). These are not absolutely vital, but should be > considered before a final text is issued (or even the next > revision). > > This needs to be discussed. As it is new, I have no idea what the > discussion may lead to. Are you referring to implementation details, here, with things like "drop requirements" ? If so, this is part of what would be a different document again, syslog-implementation. > #10 STRUCTURED-DATA: there has been surprisingly few discussion > about STRUCTURED-DATA. I conclude that this is non-controversal. Is this mean to be a header field? Examples posted, so far, suggest that it is. To explain that comment, I'm considering everything prior to MSG as a header. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
