On 12/22/2017 9:37 AM, John Levine wrote:
Perhaps we should think about how to prepare
for that, e.g., the dread version number field.
To repeat my non-traditionalist view of version numbers: I've seen
claims of effective uses for them, not mere promises of future
usefulness, but I haven't retained the examples.
Rather, my view is:
1. Added features: A revision often adds a feature or extends values,
or the like. My claim is that the presence of that additional
information also signals use of the later version of the specification.
Hence the version field is, at best, redundant.
2. Deprecated features: Consider the above and then reverse it. The
presence of a deprecated feature tells the receiver that the sender is
using the older version of the spec. Again, the version field is redundant.
3. Incompatible features: This is the interesting case, where the
previous and later versions have conflicting behaviors. My view is that
this is not merely a new 'version' but, rather, is a new protocol.
However the protocol itself -- not version -- has been identified by the
lower layer, a new label should be used.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
