Jim,
Jim Fenton wrote:
Having just reviewed yet another document referring to "recent activity
by the Internet Engineering Task Force (IETF) to create protocol
standards around SPF and DKIM", I am reminded how little the community
outside IETF grasps the difference between Informational, Experimental,
and Standards Track, never mind the differences between Proposed, Draft,
and Full Standard. So I agree that, largely, no one cares whether DKIM
is PS or DS.
Taken as stated, your example actually implies that we shouldn't bother with
standards effort at all, since the folk you cite consider anything with 'RFC'
in
the name to be a standard. Are you suggesting that because some people do not
understand (or care about) the IETF standards imprimatur, no one else does?
Ultimately, a standards process is whatever it is and the outside world chooses
how to deal with it. A standards group can only define itself as it sees fit
and try to conform to that. Some people ignore whether a document is standards
track. Some ignore level of maturity. Others pay close attention to these
distinctions.
In the IETF, the purpose of moving to Draft is to formally declare that a
specification has reached an additional level of maturity.
IETF standards differ from ITU standards, for example, by having maturation
levels. ITU standards, from one version to the next, can be dramatically
different and fundamentally incompatible. IETF standards cannot.
I have been seeing significant uptake in DKIM adoption and am concerned
that, if we are seen to be making large changes to the specification,
we're likely to induce another round of waiting until we're "done" on
the part of implementers and adopters. Regardless of how we describe
the compatibility between -bis and 4871, it's all about the perception
if large changes are being made.
Basic concern about perceptions of substantial change is generic, serious and
of
course legitimate, IMO.
But how does it apply to what might be done to move the specification from
Proposed to Draft? What particulars are you worried about?
IETF rules are rather forceful in this regard. The only substantive changes
permitted, for a specification moving from Proposed to Draft, is to remove
unused or problematic features. That is, the only substantive changes
permitted
make a specification simpler.
If, indeed, a feature is unused or problematic, then how will dropping it hurt
adoption? A simpler specification typically aids adoption, rather than hurting
it.
And just to keep things real, can you cite some examples of the effect you are
concerned about?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html