On Wed 2017-05-31 08:45:34 -0300, David Bremner wrote: > Not all keys will necessarily be generated with a given version of gmime. > --- > devel/schemata | 33 ++++++++++++++++++++++++++------- > 1 file changed, 26 insertions(+), 7 deletions(-) > > diff --git a/devel/schemata b/devel/schemata > index 00ebb7a6..30f6ac53 100644 > --- a/devel/schemata > +++ b/devel/schemata > @@ -14,7 +14,7 @@ are interleaved. Keys are printed as keywords (symbols preceded by a > colon), e.g. (:id "123" :time 54321 :from "foobar"). Null is printed as > nil, true as t and false as nil. > > -This is version 2 of the structured output format. > +This is version 4 of the structured output format. > > Version history > --------------- > @@ -30,6 +30,9 @@ v3 > - Replaced message.filename string with a list of filenames. > - Added part.content-disposition field. > > +v4 > +- replace signature error with a set of flags mirroring gmime 3.0 / gpgme signature status > + > Common non-terminals > -------------------- > > @@ -120,17 +123,33 @@ encstatus = [{status: "good"|"bad"}] > sigstatus = [signature*] > > signature = { > - # (signature_status_to_string) > - status: "none"|"good"|"bad"|"error"|"unknown", > - # if status is "good": > + flags: sig_flags > + # if flags["good"]: > fingerprint?: string, > created?: unix_time, > expires?: unix_time, > userid?: string > - # if status is not "good": > + # if flags["bad"] || flags["error"]: > keyid?: string > - # if the signature has errors: > - errors?: int > + > +} > + > +sig_flags = { > + # exactly one of the next three will be set > + good?: bool, > + bad?: bool, > + error?: bool, > + valid?: bool, > + key-revoked?: bool, > + key-expired?: bool, > + sig-expired?: bool, > + key-missing?: bool, > + alg-unsupported?: bool, > + crl-missing?: bool, > + crl-too-old?: bool, > + bad-policy?: bool, > + sys-error?: bool, > + tofu-conflict?: bool > } I understand that this is mapping to underlying gpgme/gmime status, but the "exactly one of the next three will be set" business makes me uncomfortable as an API. what if it's not true? If we've got a bitfield, we should expose it as a bitfield. but if we know that there is additionally a status component that has one of exactly three values, we should expose it as its own element. So i'd prefer: status: "good"|"bad"|"error", flags: sig_flags, # if status is "good": … and then excise good? error? bad? from sig_flags. what do y'all think? --dkg