Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]

Dave,

One last comment to illustrate my point.

In a similar vain, you have DSN there for the bounce stuff.  Again, this 
is a specific way of doing a bounce, yet not everyone uses this specific 
RFC to do a bounce.  It is relatively recent and not required for 
operations. So technically, in a similar argument for generality, it 
should not be there.
However, the difference with DSN vs SIEVE, is that DSN is a pretty much 
a generic term and can be substituted for a bounce concept.
Not so with SIEVE.  When you specifically say "SIEVE," you are talking 
about a specific, cryptic computer language, that just so happens to be 
a RFC, hence a "formal standard" document, but nevertheless it is not 
the "common standard" used for mail filtering across the board.
With DSN, again, a specific formal RFC standard and method for 
generating a bounce, although it is not used across the board, the DSN 
acronym is generic enough for every system to understand that it is a 
bounce processor.
You can't say that about the way you have SIEVE embedded in that diagram.

If the problem is that we don't have a "pseudo" industry understanding 
for the acronym MFA, like we do for MUA, MTA, MSA, MDA, etc,  then I can 
see why you want SIEVE.  But changing it to MFA and defining MFA would 
be more technically appropriate in my book.
Thats it. Thanks

--
HLS

Hector Santos wrote:
> Dave Crocker wrote:
>
> > > > What about SpamAssassin filters, and Sendmail Milters that do 
> > > > filtering?
> > > They are not doing the same job as Sieve.
> >
> > Folks,
> >
> > Even if they were, I need to repeat that this diagram and this section 
> > of the document are explicitly constrained to formal standards.
> > It's not that discussing the broader range of pragmatic and equivalent 
> > mechanisms isn't also valuable. It is that it makes the task too large 
> > for this document.
> > In fact, I think it opens the door to a book, not an IETF architecture 
> > document...
> Dave,
>
> I think overall you are right, but out of everything in there, SIEVE is 
> the ODD BALL and the way you have outlined, not only does it not apply 
> to many systems, it just isn't used as a formal standard like everything 
> else that is on that diagram.
> In other words, there is no getting away from RFC-x822 and RFC-x821 and 
> the pretty much standard macrocosms, MSA, MUA, MTA, etc are just that, 
> acronym's that can fit most, if not, all email implementation models. 
> The flow is pretty generic.
> But then all out of sudden, you throw in a concept like SIEVE that just 
> doesn't fit with everything else there in a general, generic way.  Not 
> everyone uses SIEVE and more importantly similar MFA engines would not 
> necessarily be where you have SIEVE embedded in the diagram.
> It is only there because the author(s) and their peers are familiar with 
> with this, which is fine, but many systems are not familiar with the 
> same thing.
> You ask for technical opinion, you got it.
>
> Thanks for allowing me to express my opinion.
>
> --
> HLS