Resend, as there apparently where some server issues... 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"] Also, are we going to use "meta-data" or "meta" instead of the "cookie" like in above examples? 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. 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. 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. B) Does order of tags have to preserved on relay? I assume so. C) Are duplicate tags allowed? I think they should be for handling multi-values tags like IP? > 1) What attributes are going to be defined in syslog-protocol. 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. 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. Thanks, Anton.
