Re: Choice of SMTP headers

I believe there are a couple of assumptions that are hidden here and in 
similar conversations that have taken place on this and many other 
similar lists over the past n years.
1) The fundamental principle behind mail is that it's a communication 
between (at least) two entities.  Solutions may have costs, barriers, 
and benefits that affect senders, receivers, or both.  And the costs and 
benefits may accrue to different people.
2) Most end-users rely on their ISPs (or ASPs), Enterprise IT managers, 
or educational institutions to manage their mail servers, DNS, and other 
infrastructure pieces (I'll refer to these folks collectively as 
infrastructure providers).  Their choice of mail client may be driven 
from above or may be a personal choice.  Users and infrastructure 
providers have different motivations for implementing these solutions, 
and, as above, differences in cost, conveninence, and desire.
I don't bring these up in support of or against any specific proposal, 
but to remind us of some core principles behind what we're building.  
Like the International Email Address (IEA) and International Domain Name 
(IDN) efforts, there's a lot of work involved in moving us from here to 
there, and the various groups have very different reasons for wanting or 
not wanting to get there.
I think this has been proposed before, but for each proposal (including 
these kind of discussions), I think it would be very helpful for folks 
to articulate which constituent does the work and which problem it is 
supposed to solve.
Thanks,
-Edwin


Alan DeKok wrote:

> "Mark C. Langston" <mark(_at_)bitshift(_dot_)org> wrote:
>  
>
> > >  They upgrade laptops regularly.  So there's already an existing
> > > model for deploying software upgrades.  Wait 2-3 years, and deployment
> > > will have reached the majority of users.
> > >      
> > ...and for those people that must wait a year, or two, or three, before
> > email is functional again?
> >    
>  They will have incentive to upgrade sooner.
>
>  
>
> > When a service that many view as fundamental, such as email, stops
> > functioningi as deployed, trickling out a fix isn't seen as an
> > appropriate response.
> >    
>  It's already stopped functioning properly.  And you're confusing the
> design of a fix with it's deployment (or "trickling out").  We
> shouldn't throw away designs simply because some people will deploy it
> slowly.  That's their problem.
>
>  My original comment on the 2-3 year deployment was that it was an
> UPPER bound on deployment time.  After 2-3 years, a large number of
> people will have upgraded software, through the simple expedient of
> upgrading their systems.  People who want it deployed sooner have
> incentive to do so, and can choose to do so.
>
>  
>
> > For that reason, it'd be better to come up with a recommendation whose
> > impact is largely, or completely, server-side, and transparent to the
> > client and end-users.
> >    
>  Such as...?
>
>  This is the problem I've seen on ASRG for over a year now.
> "Solution X doesn't satisfy criteria A, so we should wait for a
> solution which does satisfy it".  But no one proposes such a system.
>
>  After a year of this, that argument starts to look like a polite way
> of refusing to deploy anything, ever.
>
>  Alan DeKok.
>
>