On Tue 14/Oct/2014 00:55:40 +0200 Tim Bray wrote: > Ned, I think that what you’re arguing is that naked ASCII-armored > messages shouldn’t be used; instead use RFC3156 multipart. Except > for, if we can have a media-type for the naked kind, we can integrate > this stuff between multiple textually-oriented messaging apps > immediately, right now, no waiting. Waiting for the implementors of > all these apps to learn the virtues of multipart and then implement is > unattractive, when there’s an alternative we could use right now. Among the "virtues of multipart", one is to be content-agnostic, so that it is not necessarily text what gets delivered upon decription/ verification. Another one is to be wrappable in turn, allowing possible misinterpretations as unsigned footers are appended to signed stuff. Would it be worth having a generic template for generating media types for simplified containers which have a single leaf of a given type? For example, both article.txt.gz and signed_picture.png.asc look like monopart something. Would it be enough to say "text+gzip" and "image+pgp-signature" for monopart subtypes? Just wondering Ale