[openpgp] Re: Fwd: New Version Notification for draft-gall agher-openpgp-media-types-00.txt

Daniel Kahn Gillmor <[email protected]> Tue, 18 Nov 2025 16:16:58 -0500

Newsgroups	gmane.ietf.openpgp
Message-ID	<[email protected]>

On Mon 2025-11-17 22:23:18 +0000, Andrew Gallagher wrote:
> I think the fundamental question here is “how many things do we need to name?”

Why is that a fundamental question?  I mean, we want to name all the
things that people are likely to want to interoperably share.  right?

So let's write down the list.  if it's not too long, just make one entry
in the list for each item, rather than an N dimensional matrix where
each dimension can have K values ;)

>> The fact that some OpenPGP tooling can ingest an armored object the same
>> way as a non-armored object is cute: application code that knows its
>> OpenPGP tooling has that capacity can check the non-parameterized name
>> and ignore the parameters in that case.
>
> Right, but if the same media type represents both armored and
> non-armored formats, then we’re effectively mandating that cuteness
> into the future.

do we want to mandate this future cuteness?  If we can all agree that
armored forms are kind of redundant today, given that b64 encoding is
already well-understood and widely implemented, and the OpenPGP armored
headers are basically an attractive nuisance, maybe having separate media
types helps to segregate the cuteness into its own media type.

> And if we can’t use either content-encoding or parameters to denote
> armor, we leave an important metadata detail untepresentable (within
> an HTTP API context).

But why can't you use content-encoding if you need to b64 it?  it won't
be formal OpenPGP ascii armor, but just let the transport layer handle
the encoding.

    --dkg

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]

signature.asc (application/pgp-signature, 324 B)