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

On 9/6/2013 8:41 AM, Paul Hoffman wrote:
> On Sep 6, 2013, at 7:19 AM, Barry Leiba <[email protected]> wrote:
>
>> 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.

Sean