Specification development process follows

Specification Status Lifecycle

All specifications will be tagged with a status that defines it’s usability for implementers.

Status Definition Usage
Raw Every new specification or major version starts with raw status experimental use only
Draft When a specifciation is completed and testable (ie it has a working test harness) then it becomes draft suitable for beta testing
Stable When a specification has a successful third party implementation (ie passes conformance test cases) then it becomes stable. safe to implement in production systems
Deprecated When a specification is superseded by a new major version then the previous major version is deprecated may still be used in production but should not be used for new builds
Retired when a specification is obsolete and should no longer be used in any production deployment then it becomes retired remains on this site for historical reference puposes
Deleted Usually applies to unsuccessful specifications that never made it to stable status Will be removed from this site

Specification Version Management

Specifications will follow semver conventions with a major.minor.patch version numbering system (eg version 1.5.3). The following rules apply to versioning

Version level definition usage
major a breaking change that requires a change to consumer systems implementers must indicate version in URL path eg
minor a functional change or enhancement that is non breaking (eg a new optional property in an API) implementers must indicate minor version in body of message but not in URL path
patch a non functional change such as a documentation update no impact on implementers

Implementation Conformance

We aim to support implementers through their development efforts and conformance testing process.

  • join our slack team and subscribe to whichever channels match your implementation needs (we have one channel per specification). You’ll be able to chat directly with the team that wrote the specification and we’ll do our best to help you with any questions that might arise as you build your implementation.
  • Every specification will follow IETF “MUST”, “SHOULD” “MAY” language so that it’s clear what a conforming implementation means. We will also aim to provide free open source conformance testing tools in the same GitHub repository that is used for specification development. Test your implementation using these tools.
  • When you are confident that you have a conformant application then let us know by raising a ticket in the corresponding specification repository to request that your product ro service be listed on our “known implementations” list. Attach the compliance report from the testing tool and, once verified, we’ll add you to the list.

Licensing & IPR Policy

IPR Policy for is

  • All specifications are available under GPL3.0 open source license.
  • does not own any IP. Ownership of all contributions remains with the contributor.
  • From time to time, specifications may be offered as initial contributions to formal projects run by UN/CEFACT. In such cases, contributors are expected to grant ownership of their IP to the UN.

Current Team Membership

Is visible simply by browsing the corresponding GitHub team membership

UN/CEFACT membership

Please modify this page and make a pull request to propose any additions, changes or fixes.