Hi,
While it may be sensible to start using v= now, or when an RFC
issues, or in some other way, I don't think that having a
different v= for each Internet-draft is a good idea really.
Perhaps you are expecting too much of each version of the I-D
in terms of stability/compatibility. These are working documents,
clearly labeled as such and expecting a clear interoperability
story between -xx and -yy for all xx,yy is not reasonable IMO.
What the WG needs to do is finish the work and then everyone
will have a nice, stable RFC to reference and code from.
Stephen.
Mircea Purdea wrote:
Given that DKIM has reached a stage where new specifications are no
longer backwards compatible, I think it has become imperative that a
clear identification of signature formats be adopted. Not having a
stable specification is one thing, but promoting confusion by not
properly identifying incompatible protocols is a different thing
entirely, and one which I find unacceptable if DKIM is to be deployed in
production environments. It seems absurd, therefore, to have a v= tag,
and yet abstain from using it.
Having said that, I believe that single digit identification (as in
'DKIM1') is out of the question, as it does not lend itself to draft
formats. Instead, I propose the following:
1. Use a string format that directly reflects the specification it is
based on.
ex: v=draft-ietf-01; (would correspond with
'draft-ietf-dkim-base-01.txt')
The idea behind this is to have a simple, yet flexible identification
value, that can easily be adapted to both drafts and final specifications.
In addition, it is much more useful to have a clear indication of the
specification itself; rather than an abstract identifier which might
confuse one who is not familiar with the protocol.
Note that if following this notation, the final version of the
specification should not be identified as 'DKIM1', but 'rfc13913' (the
number being, of course, an example).
or
2. Use an eight digit yyyymmdd format, that specifies the date its
specification was published.
ex: v=20060413; (would correspond with
'draft-ietf-dkim-base-01.txt')
Again, the idea here is to be able to identify the specification used
to define the signature.
The advantage of this format lies in its clear, fixed length value,
but unlike the previous proposal, (human) interpretation of this value
would require some familiarity with DKIM history.
I think that reaching a resolution on this issue before the next draft
release is imperative, and therefore hope that these proposals, at
least, help start a productive, and hopefully conclusive discussion.
Mircea Purdea
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html