Before we dive too deep into which fields to support and how to name them, we should first discuss the structure and organization of the names.
I propose we roughly follow the proposal from Balazs:
1. Core Fields -- flat names that are defined by lumberjack/CEE. These should encompass the minimal set of fields that are commonly used.
2. Extended Fields -- additional fields are either tied to a specific product/application or a functional product group (anti-virus, firewalls, etc.)
We should focus on scoping and defining #1, probably combining the libumberlog, patterndb, liblognorm, RFC5424/IANA fields. Maybe the best place to start is with the `auditd` list http://people.redhat.com/sgrubb/audit/audit-parse.txt and abstract linux-specific names to be more generally applicable.
For #2, we need to figure out how these work. I vote that the structure should infer the namespace and the namespace should either be unique to the vendor/product or developed by the community. {"red_hat":{"auditd":{"time":"..."}}} would work, or collapsed to {"red_hat|auditd|time":"..."} (feel free to substitute divisive char: !/.:|)
The functional product categories should be related to an organizational entity -- lumberjack, cee, IANA, etc.
We need some way to distinguish vendor/product namespaces from organization/functional ones.