David, > -----Original Message----- > From: David Harrington [mailto:[EMAIL PROTECTED] > Sent: Friday, January 26, 2007 4:15 PM > To: [EMAIL PROTECTED] > Subject: [Syslog] RFC3195bis
[.. big snip ..] > Chris and I did not agree that RAW mode should be obsoleted and > replaced with a new mode. That is new work that is NOT in the current > charter, and is not in the proposal to Sam for a minor change to the > charter. That is simply out of scope for the current WG. > > To my knowledge, there has been no discussion of such a change, and > there is no current WG consensus to do this, even if it were in scope. > As co-chair, I would not take such a proposal to Sam because we have > work that is not yet completed, and that needs to be completed before > we start working on new proposals. > > If there is WG consensus to obsolete both RAW and COOKED modes, then > we can simply obsolete RFC3195 and move forward with sylog-sign. A new > proposal for a TARTARE mode can be proposed as a new transport mapping > in the future, under a different charter or as an individual draft. I agree that COOKED should be obsoleted. Reasons are in my other mail from earlier today. Even though I did not consider it before, obsoleting RAW also seems right to me. The reason is that this greatly simplifies interoperability between new (to be written) and existing applications. If we define a TARTARE mode, the BEEP greeting precisely tells sender and receiver what to expect. Keep in mind that RAW and TARTARE (or RAWbis) are incompatible to each other. This stems back to the fact that 3195 demands printable characters only as well as LF as a record delimiter. This does not work with a -protocol formatted message. The appropriate BEEP solution to that problem is to define a new profile. So creating "TARTARE" is the right thing to do. Everything else would be a bad compromise. I see your concerns in regard to the charter. I also understand John's concern. I like you proposal to simply obsolete 3195, then complete -sign and then work on a new version of 3195. There is no need to hurry in getting that done. Very few implementations are using it today and they continue to work (at least if somebody finally deploys them ;)). There is also no need to have a BEEP transport mapping ready in order to get -sign published. The whole point of the discussion was that -sign should be transport-independent. If it is independent, anything we specify now can also work with a later TARTARE BEEP transport. So there is no actual relationship. One might now argue that so -sign messages can not be used with 3195. This is right. But this is right in any case. Existing 3195 transports will never work with -sign. My conclusion: simply obsolete 3195, remove references to it from -sign and let's finish -sign quickly. Then recharter. Rainer [.. big snip ..] _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
