ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] Proposal for v= tag

2006-04-23 08:53:06
I agree, the whole point of getting core out quickly is to avoid the need
for excessive numbers of v= tags.

Core contains the bulk of the potential interoperability issues, well the
ones that can be solved at any rate. With SSP the issue is not going to be
interoperability, its going to be competing heremeneutic interpretations of
the semantics.



-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Stephen 
Farrell
Sent: Saturday, April 22, 2006 11:20 AM
To: Mircea Purdea
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Proposal for v= tag


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


Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html
<Prev in Thread] Current Thread [Next in Thread>