On Thu, 14 Jul 2005, Hallam-Baker, Phillip wrote:
The draft charter is actually at
Secondly, this appears to be aimed at, basically, rubber
DKIM drafts. Is there any real point in people outside the DKIM
design committee contributing anything?
This sentence in particular makes makes me particular worried:
"The specification will be based on the <draft-*-dkim-*.txt> draft
documents and will make only the minimal changes deemed essential
to the viability of the service"
To me that means that any discussions or suggestion of change
to current draft can be ruled outside the scope of
discussions and in fact I'm uncertain why with sentence like
that WG is even necessary as authors could as easily send it
as individual submission since they appear to not be
interested in discussion any core issues.
That is actually how the IETF was originally intended to function.
I dare say many IETF people will disagree with you.
People bring a specification that has a solid core and a significant
degree of engineering effort. The WG then works on producing a
specification that is based on the central principles and core but is
better documented and the IETF accepts change control of future
While that happened in couple cases, in majority that I know of parties
bring in one or more specification and IETF sits down and selects best
parts on technical level for standardization. That some company or group
or companies have already implemented it in private is almost never enough
for IETF to put a "stamp" on it (most such work goes into informational
RFCs, i.e. see Verisign's RRP), for example when VLANs spec was developed
cisco had ISL and while key parts of it are what went into 802.1Q, it is
not the same and having ISL deployed was not way to push IETF to adapt it.
There is no shortage of work that needs to be done that builds on the
basic core. But the WG is not intended to be an open forum for people to
bring their header based email signature scheme along.
Again I dare say that in most WGs, people bring in various components and
ideas and then those that are good are used for specification as part
of protocol development process (can I say ATOM?). In spite of what you
think majority of IETF work is also such that it is not deployed prior to
standardization and that is why when spec is ready it is labeled "proposed
standard" and requires several implementations for going to "draft".
I also would like to remind you again that IETF standars are all
individual contributions (that means *individual* not *company*),
I know you don't like this system, but that is how it is right now.
Verisign also developed a very similar technology, as did other parties.
And you're more then welcome to release this if you want us to believe
such assertion. For me it would be seen as unusual for Verisign to be
developing that as you're well known for supporting S/MIME as primary
way to sign emails.