> Below some thoughts... > > > Use strict XML such as: > > <cookie msgno="123" encoding="USASCII" /> > > > > Use loose rules so the information can be easily converted to > > XML (if one wishes) such as: > > <cookie msgno=123 encoding=USASCII> > > > > Define the format and delimiters with little regard to any > > conversion to XML, such as: > > [cookie msgno=123 encoding=USASCII] > > My preference is for this last format. I think [] brackets make it > clearer it is not XML and visually look more like field separators and > not part of a value (at least to me). > > I think Rainer needs to provide more details about the appropriate > character-set/encoding for tag names (probably printable > USASCII 32-126 > range), and character-set/encoding (probably UTF8) and escaping rules > for tag values. I think rather than having to escape a space > character > in the values, I'd prefer quotes around the value like in > example #1 and > define an escape sequence "\" for quote characters. This way we also > don't have to specify escape sequence for the "]" character. > Here is an > example: > > [meta msgno="123" username="abra\"kadabra"]
I have the feeling that Anton's approach is better than using XML. I still fear that even the word "XML" will make some implementors stay away from it. So, if nobody objects today, I will edit -protocol-00 to -01 tomorrow in this spirit. I will then post -01 - if we don't like it, it is easy to change it in -02 ;) There is one thing, though. Even though I like the [...] syntax, I think we can't just use plain '[' because this is already in widespread use. I think that would totally confuse things. As such, I will use "[EMAIL PROTECTED]". So it starts with "[EMAIL PROTECTED]" to make sure it is a -protocol meta-data item. > > Also, are we going to use "meta-data" or "meta" instead of > the "cookie" > like in above examples? based on Anton's comment of th meta-data not actually being meta-data. I evenutally have a better term. What if we simply call this "structured data"? > Personally, I'd perefer if we could come up > with a away to use neither such that the placement of the > tags and their > general format implied that this is the meta-data portion. Similar to > how we don't say what the other syslog fields are -- we just > provide the > value. I agree placement-ignorant positioning should be doable with the "[EMAIL PROTECTED]" approach. I guess I will see minor issues when I actually edit the draft ;) > > Another alternative for encoding tags would then be something like > [msgno=123][msgpart=2]... In this example, no quotes are > needed, but "]" > character would need an escape sequence if it appears in the > tag value. I think the other one is better. > > We also need to specify rules or outline lack of preference for: > > A) Order of tags. Alphanumeric or any? I am leaning towards > allowing any > order in case vendors want to order them a certain way for > better visual > display or in order to communicate some precendece. My vote is any order > > B) Does order of tags have to preserved on relay? I assume so. YES > > C) Are duplicate tags allowed? I think they should be for handling > multi-values tags like IP? That should be described on a tag-by-tag basis. > > > 1) What attributes are going to be defined in syslog-protocol. Few, actually I think just fragmentation bits. We could also add some optional bits to reflect RFC3195 cooked information. But this may be beyond scope (I will not do that in the -01 edit). > > I think only tags that are strictly necessary for the syslog-protocol > itself should be defined there. If there will be no tag > definitions at > all in syslog-protocol, it is fine with me. > > > 2) How can others define additional attributes in the future. > > I see the point about potential vendor conflicts, but vendor > extensions > are cumbersome IMO. Maybe we leave it upto the "marketplace" > or future > standards to sort out. One potential scheme could be a > "vendor" tag we > could standardize. This way, a parser familiar with the specific tags > of a given vendor can interperet them according to the > specific rules of > that vendor. But each vendor can still come up with a tag > "ip" and use a > different syntax for it if they so choose. At least for now. Not sure > if "vendor" tag should be required though. Need to think about this. Eventually I make I proposal right in -01 ... as I wrote, it is easy to change it in -02. It seems harder to discuss this without having any text to look at. > > There is a lot more work that can be done in standardizing tags, but > maybe it is not necesssary in the initial standard. I think > it would be > nice to outline rules for representing different things, but yet allow > vendors to add semantic extensions. For example, we define the syntax > for "ip", but vendors can then define tags like "ip.from", "ip.to", > etc... I think this is too much of a scope for now though. Agree ... sounds like payload to me ;) Rainer
