[Top] [All Lists]

Re: [smime] Fixing the definition of the smime-type parameter by creating a registry

2013-09-07 11:04:59
On 9/6/2013 8:41 AM, Paul Hoffman wrote:
On Sep 6, 2013, at 7:19 AM, Barry Leiba <barryleiba(_at_)computer(_dot_)org> 

In the handling of draft-ietf-pkix-est, it came up that there really
ought to be a registry for values of the "smime-type" content-type
parameter.  Sean and I discussed it, and I put together a quick
document (see below) to create the registry and do the magic.  We
should have a brief discussion of it here before Sean AD-sponsors it
and sends it out for last call.

In particular, we decided to propose "RFC Required" for the
registration policy.  Is that the right policy?  Does anyone have
other comments about the registry or the document?

Please, a few reviews and comments will be needed before we can
proceed.  And it' short.  So have at it.
The idea of having a registry seems fine, and "RFC Required" seems fine.

The idea of having a registry seems fine, and "RFC Required" seems fine. However, as an active developer in this area, I am weary of having more registries to consult for things that rarely if ever change. I am not in favor of a registry without more evidence that there are significantly more diverse CMS payloads that are expected to be carried in MIME-related bodies.

I do have a suggestion:
The current registry in draft-leiba-smime-type-registry only has two columns: smime-type value and Reference.

Actually, it should have six columns, the additional four columns being: CMS Type, CMS Type (OID), Inner Content, and Inner Content (OID). For example, enveloped-data would be CMS Type: EnvelopedData; CMS Type (OID): 1.2.840.113549.1.7.3; Inner Content: id-data; Inner Content (OID): 1.2.840.113549.1.7.1. This additional information would make the registry more useful.

smime mailing list