> > in fact, the "just say no" thing works great for most of > > beep's features. what you're left with is a mandatory framing > > mechanism and some xml parsing for channel 0. > > Well, I thought this was not the spirit of BEEP - but I guess you must > know better ;) I'll re-read the RFC in this regard.
the thing to understand about *any* protocol specification is that it is specifies only what goes on the wire. how you choose to implement it, and what you choose to implement is immaterial, providing that what goes on the wire looks like what the specification says it has to look like. philosophically, this comes from a 30-year old directive to not constrain actual implementations. in the grand scheme of things syslog is a rather specialized function. that's fine, it has a job to do and it does it well. (contrast this with something like ftp which provides a generalized file access service that is presumably O/S and FS independent...) in situations like this, it makes a lot more sense (to me), to start with the expertise for a given syslog implementation and figure out what the correct model and api is for the underlying beep layer. frank o'dwyer is right when he says a good way to start is by looking at the syslog-raw protocol examples in 3195. that probably illustrates 90% of the functionality that your beep stack would need. the other 10% might deal with things like connection caching, determining whether you want sasl/tls, etc. > In fact, we are doing a lot of business with Japanese security folks and > especially the 1024 char limit and the charset hurt *very much* in this > space. We had to take the liberty to violate these sections of 3164 to > make things work... which certainly does argue for putting together an additional set of requirements and getting the wg rechartered for address those. /mtr
