Re: [openpgp] User ID conventions (it's not really a RFC2822 name-addr)

[Jon Callas <[e-mail]>]

> I'd like to have a clearer undersatnding about the actual conventions
> for OpenPGP User IDs in the context of e-mail.  The standards currently
> say that the convention is an RFC2822 "name-addr", but (as detailed
> below), that does not appear to be the actual convention in practice.

A simple place to start is that RFC 6531 seems to be the present upgrade/replacement for RFC2822. There have been interim ones and I didn't spend a lot of time sorting out details. Whatever the present successor is, let's just call it R.

> 
> While we're updating RFC 4880, we should fix the standards to reflect
> reality.  There are two proposals at the end that i'd love feedback on.
> I prefer proposal 2.

I think I do, too, with your addenda. 

Rewinding to history and second if not first principles, the User ID field is ideally free-form text. The most common free-form text is an email address, and that's described by R, and I think your proposal 2.

However, there are a lot of places where people have put human-readable text in (e.g. "XYZ Group Release Signing Key") that doesn't have a machine readable context at all. There have also been X.500 Distinguished Names, Common Names, and so on put there. There have been other outré uses as well. As long as we don't end up with it being *precisely* an email address, meaning that we outlaw just plan text, I think it's fine.

At one time, I really wanted User Attribute Packets (created for having images as IDs), to have other types of structured data including email addresses. The reasons for not doing it then (it's a pain, and who's going to support it) apply today. It's still a good idea, though.

If whatever you come up with precludes text with no machine meaning, I think you hit the flip side of having a defined type of ID: there's lots of things that already don't meet it, and people will just ignore what's there because history.

Operationally, I think that supporting Just Text merely means that if the field fails parsing rules (like Proposal 2) then it's Just Text and we're moving on.

	Jon