Re: Summary of Issues Raised to date

On 16 Mar 2004 at 16:18, David Nicol wrote:

> I see a dissonance due to combining of multiple goals.  The
> implementors on this list want to pare out weightless specifications
> that appear obvious to us, the architects want to provide hints about
> purpose. 
> 
> I see mm's point but I also respect ys's wish to make clear that a
> wide set of impractical (yet common, naieve) wishes are out of bounds. 
> It is easy to imagine a unworkable standard that mandates things like
> downstream compliance with labels if we aren't careful. 
> 
> Maybe an "unworkable approaches" section would make sense and satisfy
> everyone. 

At last! A posting I can relate to.

I've been silent on this discussion prior to now mostly because it 
seemed to me that a lot of suggestions were being made that, while 
having merit in themselves, would founder when it came to real-world 
implementation. Past experience suggests to me that there are some 
key issues we need to keep clearly in view when discussing this sort of 
thing:

1: The likelihood of getting all the developers on this list to agree to any 
individual proposal is inversely proportional to the complexity of that 
proposal.

2: The likelihood of getting developers *not* on this list to agree to any 
proposal at all is a value approaching nil - you cannot alter the 
infrastructure of the world's e-mail by fiat (I see this as the primary 
problem facing proposals like SPF as well). As a result, if any proposal 
we make is to have any chance of flying, it must be worthwhile even if it 
is only partially adopted, and it must not depend on upstream adoption 
to work.

3: Developers who have been around for a while will have little interest 
in making major changes to their software to encompass a new 
proposal, even if the changes offered by that proposal are worthwhile.

Perhaps it would be appropriate to reiterate the primary goal of this 
group, as defined on the ASRG web site:

    1: Investigate the requirements for a common header to be 
    produced by filters (something like "Filtered-By"), so MUAs do 
    not have to look for different types of headers

This seems like a very simple, achievable goal to me, but the recent 
threads on this list seem to me to have lost sight of it. A lot of the 
discussion going on at present seems to be in the form of ideas that 
grow legs and rush off into the undergrowth to battle demons.

I hate to be the one who suggests a lowest-common-denominator 
approach to a problem, but I really think that's what we need to be doing 
here. Instead of trying to solve *all* the header-related problems we can 
think of, why not start off with the simplest thing we think we might 
actually be able to achieve and build on that?

Just a thought.

Cheers!

-- David --

------------------ David Harris -+- Pegasus Mail ----------------------
  Box 5451, Dunedin, New Zealand | e-mail: [email protected]
           Phone: +64 3 453-6880 | Fax: +64 3 453-6612

Seen in an Irish Hotel:
   "Please do not lock the door, as we have lost the key."