Re: [openpgp] review of the SOP draft

[Clint Adams <[e-mail]>]

> >> armor: armor: Add ASCII Armor
> >> -----------------------------
> >
> > [...]
> >
> >> If the incoming data is already armored, and the `--allow-nested` flag
> >> is not specified, the data MUST be output with no modifications.
> >> Data is considered ASCII armored iff the first 14 bytes are exactly
> >> `-----BEGIN PGP`. This operation is thus idempotent by default.
> >  
> > Explain why we want idempotent and why we want to do this guessing game.
> 
> I'm at a bit of a loss here, because these seem obvious to me.
> 
> We want a guessing game because users who don't know what they want are
> going to guess anyway, and they're likely to guess wrong.  We might as
> well guess on their behalf if they don't know.
> 
> We want idempotent because "ensure this thing is armored" is a
> reasonable semantic request -- indeed, it's probably the *only*
> reasonable semantic request.  Perhaps we could drop --allow-nested?

As an implementer, I don't want this because this kind of run-time
detection is annoying, though it would be more annoying if the check
weren't explicit.

As a user, I don't want this because it violates the POLA.  Why would
I be directing something to "ensure this thing is armored"?  If I piped
something to base64 and it came out unchanged I would be shocked and
horrified.

Along those lines, having some subcommands default to binary output
and others default to ASCII Armor also seems confusing except in cases
like `armor` and `dearmor` where the intent would seem obvious
(modulo this whole idempotency thing).