On May 27, 2018, at 1:56 PM, Neal H. Walfield <neal(_at_)walfield(_dot_)org>
wrote:
[...[\]
I would like to make a counter proposal, that Vincent and I came up
with at FOSDEM: I think that we should deprecate Regular Expression
support and replace it with a list of domains (optionally prefixed
with "*." to indicate any subdomain).
I believe you can do this.
A regexp that is "domain_1|domain_2" does this just fine.
First, most users don't
understand regular expressions. And, although it would be possible to
allow users to enter one or more domains and then convert them to a
regular expression, it is not easy to reverse this process, which is
essential for explanatory purposes and editing. Second, not including
an RE engine reduces complexity.
My response is that that was not what the working group consensus was.
The working group consensus was that we didn't want to debate specifics, but
regular expressions are sufficiently powerful to meet any reasonable (and
probably lots of unreasonable) scoping.
I understand what you're saying, but I gotta reply, "So what?" I think I'm
going to end up in a small rant in the following. I apologize in advance for
any offense I might give in this small rant.
Let me shift the discussion to something slightly related. I have email
accounts on a number of servers, and several of them allow me to do server-side
filtering of my email. They provide a handy web page that lets me set up my own
filtering rules. At the bottom of everything, all of these sites do filtering
with Sieve. Sieve, like OpenPGP is an IETF standard, it is RFC 5228 and a lot
more.
Each of the email servers I use has a slightly different web-GUI framework for
specifying a rule. One of them, for example, is structured so that I have to
enter "To" and "CC" on separate lines. Another one lets me specify "To" or "Any
Recipient" (which means either To or CC). On another, I have to actually use
the generic filter on some line and type in the CC if I want to filter on CC.
In the actions phase of this, one of them automatically terminates after
matching one other rule, while another one makes me put in an action line to
stop processing following rules. But at the end of the day, they're all Sieve
scripts.
(Oh, and one of them lets me upload my own Sieve script, but If I do that, I
can no longer use the web GUI. Well, I can, but the GUI will likely overwrite
all or part of the rules in ways that might totally break everything.)
There is *nothing* in OpenPGP that says you have to expose the full details of
regular expressions to the user. Just like with Sieve, there's a full grammar
that has expressive power that doesn't need to be used, and probably shouldn't
be.
I agree completely that most users don't understand regexes. I agree that they
shouldn't be subjected to them, and that the vast majority of what anyone needs
is pretty much what you said — a list of domains. And yes, sensible software
that does something nice for the user is not going to be able to ingest in an
arbitrary regular expression and display it simply. Just like these server
filtering web pages don't expose all the power of Sieve, a sensible program
that lets people construct trust scope doesn't have to be just a text box that
someone types a regexp into.
A protocol standard like OpenPGP specifies a grammar for messages. It's a way
to encode a message so that other people can understand it as well as a way to
interpret a message that someone else hands you.
In English, you can go up a staircase. You can also mount the staircase, ascend
it, climb it, mount it, and even more. Grammar and vocabulary do not require
you to put all the synonyms on the sign by the stairs. Up and Down are
wonderful things to put on the sign. Ascend and Descend are a bit pretentious
and non-native speakers might have trouble with them; thus they're compliant
but have UX issues. The symbol ⬆ (that's the "Up Arrow" emoji in case it
doesn't display properly) is not strictly standards-compliant, but if you're a
fan of the Postel meta-rule, knock yourself out.
Protocol standards are not specifications for software implementations nor are
they requirements documents. GnuPG is a wonderful piece of software that tries
very hard to be a reference implementation that implements every single
feature. It is not a requirement that every implementation implement every
feature. That's why we have the RFC 2119 keywords. You gotta do the MUSTs. It
would be nice to do the SHOULDs. You don't have to do the MAYs.
If you look at Section 5.2.3.1 of RFC 4880, it is perhaps more convoluted than
it could be, but whatever. The gist of it is that since it says that an
implementation SHOULD implement the preference subpackets as well as the Reason
for Revocation, which at least implies that the others are all MAYs. It further
says that you SHOULD ignore anything you don't "recognize" (which I interpret
to be a synonym for "implement") and that if the critical bit it set, you
SHOULD sit in the corner and sulk about anything you don't recognize.
Moreover, there's a regular expression helpfully defined in Section 8 that is a
pretty bog-simple language, but like any regular expression matcher, you can
create patterns that will drive weak people to strong drink. Nowhere are you
*required* to let your user do things legal but silly. The reason it's there is
to *permit* people to do complex things, not to expose the complexity to every
user. It doesn't break the standard to implement a list of domains. It doesn't
break the standard to let someone type in "*.example.com" for their scoping as
opposed to ".*\.example\.com".
I believe that part of the reason so many people rail about the horrors of
OpenPGP is that lots of us have the idea that OpenPGP is a software
specification for GnuPG. That GnuPG is such a good piece of software is
ironically part of the problem. It's as if every web browser revolved around
the "curl" command.
I agree with you completely about scoping up until you want to change the
standard. The scoping is the way it is so that simple things are easy and
complex things are possible. If we make it so that only simple things are
possible it doesn't help anyone. (And as I said before, working group consensus
was such that the bog-simple regular expressions were the way to go.
Okay, thanks for reading this far.
Jon
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp