Morning all, Rather than try to define everything that could possibly occur (ala CIM) we decided a while back to use "open" registries which allow the specification to evolve over time. Anyone will be able to propose additions via a process TBD (e.g. rough consensus on a public list, dedicated expert, first in first served, etc.) and will either get them (or not) within 7-30 days. Additionally we will require implementations to forward and ignore markup they don't understand - as opposed to stripping it or throwing errors. This works well for Atom which uses this wording<http://tools.ietf.org/html/rfc4287#section-6.3> : 6.3. Processing Foreign Markup Atom Processors that encounter foreign markup in a location that is legal according to this specification MUST NOT stop processing or signal an error. It might be the case that the Atom Processor is able to process the foreign markup correctly and does so. Otherwise, such markup is termed "unknown foreign markup". When unknown foreign markup is encountered as a child of atom:entry, atom:feed, or a Person construct, Atom Processors MAY bypass the markup and any textual content and MUST NOT change their behavior as a result of the markup's presence. When unknown foreign markup is encountered in a Text Construct or atom:content element, software SHOULD ignore the markup and process any text content of foreign elements as though the surrounding markup were not present. We need something similar to go into the spec. Sam