> Interesting thought. Does anyone else support this? Would this be "just > anyone" or should the profiles be registered with IANA?
Anyone could put together an experimental or private profile with an associated URI, and perhaps publish it as internet draft in the first instance. Since nobody would be required to implement it in order to interop with the basics, it shouldn't impact anyone else. If a particular profile caught on and proved its usefulness, then that could be put forward for standardisation and registration. I believe the particular ones I mention below all fall into the category of possible tuning profiles, so it's just a matter of using that existing mechanism within BEEP, and it would still interop with existing implementations. Cheers, Frank > 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 > > > > > > > > > > > > > > >
