On Tue, 17 May 2005 14:19:10 PDT, David MacQuigg said:
What worries me about "going all the way" and including lots of nice
options, is that the history of this project shows that even the most
trivial of agreements among the different factions are impossible to
Yep. You think this is bad, you should have seen some of the flame-fests
that lead up to the RFC1341 MIME specs.. ;)
negotiate. The ID declaration is about as simple and "non-partisan" as I
can make it, and you can see the negative reactions that is
That's it's major failing. It tries to be non-partisan while papering over
the very deep and important reasons there's multiple factions here. One ID
won't work when the players aren't agreeing on what an ID is.
generating. Imagine the arguments over which keywords (SPF1, SPF2,
SENDERID(C), CSV, REQ, RES, AUTO, ... ) will be designated as IANA
approved!!
Actually, what Hector and I are slowly thrashing out will bypass that. We just
define the *frameworks*, and the "owner" of each proposal, SPF1, SPF2, CSV,
RES, HashCash, whatever just create the appropriate paperwork that registers
their pet scheme. That can be done like this:
http://www.iana.org/assignments/media-types/index.htm
Seems to work OK for MIME media types. I don't see any issue with doing it
for ID parameters. (Seems to be not much more than a formalized "Hi, we're
company X, and our Foo product uses 'application/moby-foo' as a type"...)
If there is way to get the benefit of these options without
adding it all to SMTP, and I believe there is, then we should spend our
limited time and energy on just getting a simple, neutral way to declare an
ID.
Hector and I are willing to settle on a simple, neutral way for client and
server to agree on *what* ID they want to declare. :)
pgp5Seca04Qhy.pgp
Description: PGP signature