7. namespace and versioning
---------------------------
We've discussed this at some length, and come up with the following:
- propose to remove the version information from the content type
(leaving the content type of "aplication/x-rpki")
- propose to keep any version number out of the namespace
identifier
- propose to restore the "version" attribute of the message element
and define its value as "1" for this specification.
It would be easier to evaluate these recommendations if you shared the
reasoning by which you reached them. :)
- note that there may be a requirement for explicit version
negotiation in future versions of this protocol, but defer the
specification of any such negotiation until the next version
"Once you start down the dark path, forever will it dominate your
destiny, consume you it will...."
- allow implementations to accept any message, irrespective of the
version value as long as the recipient understands the namespace
and the recipient understands all elements and attributes that
are
used in the message.
That's probably ok. Other opinions?
One good (and ancient) example of relatively sane protocol versioning
specification is RFC 1058, the RIPv1 spec, section 3.4 of which says:
Before processing the datagrams in detail, certain general format
checks must be made. These depend upon the version number field in
the datagram, as follows:
0 Datagrams whose version number is zero are to be ignored.
These are from a previous version of the protocol [...].
1 Datagrams whose version number is one are to be processed
as described in the rest of this specification. All fields
that are described above as "must be zero" are to be
checked.
If any such field contains a non-zero value, the entire
message is to be ignored.
1 Datagrams whose version number are greater than one are
to be processed as described in the rest of this
specification. All fields that are described above as
"must be zero" are to be ignored. Future versions of the
protocol may put data into these fields. Version 1
implementations are to ignore this extra data and process
only the fields specified in this document.
In other words: If it's a higher version number than you understand,
you process the fields you recognize and ignore everything else.
Unstated corollary: old fields may not be reused for new purposes. In
the pathological case of needing to do a completely incompatable
change to the protocol without just starting over as a new protocol,
abandon all of the old fields except for the version number.
Your proposed rule here is stricter than that, so I don't think your
proposed rule will cause a problem.
