ietf-mxcomp
[Top] [All Lists]

Re: Drive Towards Consensus

2004-06-21 20:31:32

In 
<1CD00592-BFE8-11D8-BD27-000A95CA7FAE(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us> 
Marshall Rose <mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us> writes:

the co-chairs think this is a useful thread; in fact, we're going to
place the following plan in front of the working group:

it is clear to the co-chairs that the "tipping point" with respect to
the working group's deliberations revolve around the sufficiency of
the SPF syntax to address near-term concerns. if the syntax is
adequate, it is hard to argue for an alternative or future syntax; if
the syntax is inadequate, then the SPF syntax is of transitory use.


I've read the proposed scenarios and the replies to them.  It is hard
to give an overall response without making bland assertions, but it is
hard to give point-by-point responses without getting lost in the
details.

So, in this post, I'll give my overall view of these situations,
details will follow in other posts.


People advocating XML have given scenarios which are mostly fleshed
out versions of what they have been saying all along.  This is very
good, and it also means that I wasn't surprised by anything.

Overall, I found none of the scenarios to give a compelling reason why
requiring support of XML would outweight its the negative effects.
(These negative effects of XML are caused by both technical and, uh,
"emotional" reasons.  It is tempting to dismiss the "emotional"
reasons, but we have to deal with the real world here.)


Briefly, all of the scenarios fall into one or more of the following
catagories:

* They can easily be handled directly with the current SPF syntax.

* They can easily be handled with an SPF modifier that points to where
  the information can be found.

* They are so far beyond the scope of MARID that they dilute and
  muddle the purpose.

* They are not useful because no one will believe unverifiable claims,
  such as "I send only 100 emails per day".

* They can best be handled other ways.

* They require email receivers to do work for the senders with no
  benefit for the receivers.  As a result, I don't see them being
  implemented by the receivers.


-wayne