John R Levine writes: > > > d) Versions are cumulative. Every signature that is a valid version N > > > signature is still a valid version N+1 signature, give or take the change > > > in the b= hash due to the version bump. > > > > I think this is unnecessarily restrictive. It's unnecessary because a > > verifier that wants to handle multiple versions can always incorporate > > a routine per version. It's restrictive because a later version might > > want to disavow an earlier version. > > If you want to change the semantics that much, like I said, give it a > different name.
Like I said, it's unnecessary. Why do you think it's better to proliferate field names? AIUI, what you're proposing here is a major change from the way the RFCs I've seen are constructed. They say, the protocol must be interpreted exactly as in this document and for any different version all bets are off, but of course an agent may choose to support multiple versions. It's a matter of designer judgment whether the incompatibilites are sufficient to warrant a new name. This has worked well enough for the Internet so far AFAICT. Why do you think DMARC is an appropriate place to experiment with a different interpretation of version numbering? I note your file system example, but it seems to me that is fundamentally different in that not only the protocols but the reference (and typically dominant) implementation are controlled by the same entity, and furthermore, layering is much more accurately enforced in OSes than on the Internet. I noted Ned Freed's comment about "MIME-Version: 1.0" being a mistake, but security protocols are a different use case, and I think it's best to control extensions very carefully. _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
