Chris, There is one other issue which I would like to bring up, which may be within the scope of this WG, and that is extensibility.
For example, RFC3195 by virtue of its use of BEEP, potentially allows for additional (optional) profiles which may relate to the events themselves. Some uses of this that I can think of are: - event routing (an upstream node telling a downstream one where to send various events) - event filtering (an upstream node telling a downstream one that nothing upstream is interested in event 'foo', so don't bother sending it) - event prioritisation (assigning events to channels, for example separating out stuff that needs to be delivered real-time from stuff that doesn't) - negotiating a payload format and/or a superset of the COOKED DTD What I am after here is not a standardisation of the details of all that (though that would be nice), but at least a standard way to hook it in, and a means of publishing new profiles and enhanced COOKED DTDs without having to revisit the base standards. Maybe this is as simple as stating that the greeting message MAY contain additional profiles that allow nodes to install filters, routes, priorities, request a payload format, switch the DTD, etc. Obviously if both ends do not support a given profile, format or DTD it would simply be ignored. Cheers, Frank > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher Lonvick > Sent: 17 December 2002 22:41 > To: [EMAIL PROTECTED] > Subject: What Can Be Changed in syslog > > > Hi, > > I appreciate the thoughts of everyone on the topics brought up so far. > Let's make sure that we all understand what we can do within the current > scope of the WG. > > TIMESTAMP This field may be changed in syslog-sign. We'll have to rev > 3195 to accept this after syslog-sign is accepted as an RFC. > > non-US-ASCII characters in the payload. This may be addressed in > syslog-sign, or specified in another Internet Draft (which will > be accepted as a WG document if there are enough people > supporting the idea). Just for reference: > ftp://ftp.rfc-editor.org/in-notes/rfc2825.txt > A Tangled Web: Issues of I18N, Domain Names, and the > Other Internet protocols > > payload length. It's up to the WG to change this. It may be changed in > syslog-sign if that's the concensus of the WG. In that case, > syslog-sign will have to have dire warnings of trying to push > the new format through old-style (3164) relays or collectors. > We'll have to do that anyway if we change the TIMESTAMP. > > payload format. Out of scope. I'll allow discussion on the WG mailing > list (here) but anything coming from that cannot be a document > of this WG. After we accomplish our Charter Goals, we may ask > the ADs to allow the WG to reCharter the WG to address that. > ..but not at this time. > > I'll ask anyone interested in making changes to any of these to post notes > to the WG list preferably with a suggestion of modifications to the > current IDs, or a suggestion to write a new ID (with the commitment of > being the author. :) > > Let's separate these components apart from the discussion topic of a > "light" reliable transport. > > Thanks, > Chris > > >
