On Tue March 8 2005 11:51, David MacQuigg wrote:
The public is getting mad as hell about spam. There *will* be a solution
to this problem. If the IETF doesn't provide it
Spam is a social problem. The IETF is an Engineering group. Engineers
don't solve social problems (as engineers).
some politicians or
bureaucrats will.
Unlikely. They seem to create more problems, such as the aptly
named CAN-SPAM legislation, which confirms that spammers indeed
can spam.
I may not understand all that is going on in the IETF,
but it sure looks like they dropped the ball.
Let's try to objectively and calmly consider which ball you
claim has been dropped.
They have allowed the
standards effort
Which standards effort? IETF standardizes many things. Are
you complaining about IP? TCP? HTTP? SIP? ACAP? DHCP? What,
precisely?
to disintegrate into a bunch of programmers squabbling
over details that are not needed in a universal standard.
"Universal standard" for what?
If we continue
the present path, it may be years before there is a clear "victory" in the
battle between competing and incompatible standards.
It is unclear precisely which standards you are categorizing as
"competing and incompatible". IETF standards become standards
through one of two processes, as detailed in RFC 2026. Either
there is some procedure that is not suitable for phased review
and has no interoperability considerations, in which case it is
subject to scrutiny and possibly approved as BCP, which goes
into immediate effect with full force of a standard. The other
process is the "Standards Track", which begins with a Proposed
Standard, which is itself subject to review (in Internet-Draft
form), is supposed to contain no known technical omissions, to
have resolved design choices, and to be well-understood. If
there is "a bunch of programmers squabbling over details", that
is a good indication that design choices have not been resolved,
and/or that there is something which is not well-understood,
and/or there are some technical omissions. After remaining at
Proposed Standard for at least 6 months, and after there are at
least two independent and interoperable implementations, a
specification can progress to Draft Standard (after formulated
as a new Internet-Draft and subjected to the review process).
After at least another 4 months and when there is demonstrable
wide support, the specification may finally become a Standard.
Proposed Standards and Draft Standards are not Standards.
Sometimes there are competing design choices, and no clear way
to make an objective decision that would be required to enter
the Standards Track at Proposed Standard. In such cases, the
competing design specifications might be published as Experimental
RFCs so that a rational choice can be made based on implementation
experience. Experimental RFCs are not standards, and cannot
become standards except by one of the processes mentioned above
(involving a new Internet-Draft and the review process).
Experimental specifications might well be "competing and
incompatible"; their publication (but let's be clear; they are
in no way standards) provides an opportunity to evaluate the merits
and shortcomings of those specifications in order to gain
understanding, resolve design choices, and ensure that there are
no technical omissions.
I understand the details are important, but how much of what is in the
current proposals is really necessary for these different methods to work
together in the same transfer?
It is a complete mystery exactly which "current proposals" you
are referring to here on the ietf-smtp mailing list, which is
part of no current IETF working group, has no chair, no charter,
and no work items.
Surely the IETF can get together a few neutral experts who can listen to
advocates
Advocates for what?
from all sides, and come up with a standard on just the few items
needed for *interoperability*.
Interoperability of what?
Then we can break the current logjam,
Which "logjam"?
and
all parties can do their own thing within the standard.
What standard?
More importantly,
we can tell ISPs, companies in the spam fighting business, and the public
"We have a standard. Get moving."
It is unclear precisely what standard you think is possible
within the IETF regarding the social problem of spam. The
IETF is no more able to define whether or not a particular
message is "spam" than it is able to determine whether or
not a particular group of people constitute a "country"
(RFC 1591, bottom of page 6).