[calsify] JSContact and Versioning

[Robert Stepanek <[e-mail]>]

We would like to revisit versioning in JSContact and would appreciate your feedback before end of WGLC. Specifically, we plan to change the currently proposed version scheme such that:
 * Rather than using the RFC number as a version, we propose to use version strings that are independent from the RFC numbering scheme. We define the initial JSContact version to be "1", but we also explicitly state that for now the only thing implementations can rely on is that future version values lexicographically sort after former ones. In a future JSContact RFC we might introduce a more sophisticated version scheme.
 * We replace the current "Version" field in the IANA registration templates with "Minimum Version" and "Maximum Version", such that the IANA registry is enough to identify which properties or values are supported in which versions. They can then follow the according RFC references in the same registry.

Also, we'll slightly rephrase the RFC document section about versioning. The following bullets paraphrase what we intend to define. Most of this already is in the current document, but it might be simpler to review here as a whole:
 * Version changes may add new property and value definitions that are so significant that implementations should be made aware of their presence by only inspecting the version value. This can be useful for protocols to allow clients or servers to advertise which JSContact version they are able to process, or to select one of multiple MIME body parts with JSContact data by version.
 * Version changes may obsolete or update existing property and value definitions such that they are incompatible with their definitions of earlier versions. This should always be the last tool in the box, but introducing versions now hopefully allows us to handle these situations in the future.
 * Version changes always require a RFC that defines the impact on future JSContact version.
 * Not every new property or value definition that gets registered at IANA requires to change the version. The majority of changes should not, because we want to encourage people to register their JSContact additions. Since our IANA-registration policy is Expert Review, it's always up to the discretion of the designated experts if the proposed additions require a RFC document or JSContact version bump.

Cheers,
Robert