On May 28, 2018, at 12:06 AM, Vincent Breitmoser <look@my.amazin.horse> wrote:
I believe you've described the very problem with this approach here: A
powerful
and flexible mechanism leads to many inconsistencies between implementations,
that's just unavoidable. For sieve scripts you might be fine with that, at
worst
some messages will go in the wrong folder once in a while. But are you really
okay with same level of inconsistency in a trust model?
I think I’ve described the opposite.
The filtering model in Sieve is well-defined. There are differences in a GUI
overlay because different communities value different shortcuts, and also put
different viewpoints on the shortcuts. The Sieve scripts generated by any one
of those disparate GUIs will execute the same way on another. Now I, the user,
may have to create a collection of filters to do what I want because of what
gets exposed to me in the GUI, but the resulting script will execute the same.
Let’s suppose Neal does what he wants — it’s just a list of domains. That’s a
really easy thing for him to implement (perhaps, as I’ll reply to him next) but
the regex that he generates will execute the same everywhere.
However, that’s not the real point I wanted to make. That point is that there’s
a difference between being an implementer and the protocol. A good implementer
makes decisions about things for their own vision, but a protocol designer has
to make something that satisfies different visions. Moreover, the protocol
inevitably is a compromise between differing visions. A standard is something
that is a compromise, and as such is not any one person’s vision whatever it
ends up with. And as we all know, a compromise is something where everyone is
more or less equally unhappy with it, but not so unhappy that they walked away.
I haven’t told you what I’d do (and did) with any of this so far, but I’d be
happy to later. Advice I give as an implementer is usually different than
advice I give as a protocol designer. The standard as it exists is something
that got the rough consensus of the working group, and that rough consensus is
worthy of a little respect. Perhaps not too much, but certainly a little. The
problem with making the protocol match one’s own opinions is that it’s
effectively saying not only that what one thinks is right in some sense, but
also that other people’s opinions are wrong and that no one else should do
something different.
Jon
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp