Hi Frank, Interesting thought. Does anyone else support this? Would this be "just anyone" or should the profiles be registered with IANA?
Thanks, Chris On Wed, 18 Dec 2002, Frank O'Dwyer wrote: > 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 > > > > > > > >
