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

On Sep 7, 2013, at 10:09 AM, Barry Leiba <[email protected]> wrote:

> Hi, Sean, and thanks for the comments.
> 
>> 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.
> 
> In general, we often think we don't need a registry.  And then we add
> new values.  But we still think we don't need a registry.  And then we
> add new values again.  This is the third time we've added values for
> smime-type.  I think that says that we need a registry.  Better to
> consult a registry, where all the values are listed in one place, than
> to have to find the three different RFCs where values are defined (and
> to know that you have to find those three), and then to look through
> them to see the valid values.
> 
> I bet someone will say that we've defined all the smime-type values
> that we will, and *now* it's stable and we don't need to add any more.
> 
> I bet we said that after the second time, as well.

+1 to what Barry said. Developers don't need to check the registry if they already know all the values they care about; registries are for developers who want to know what they don't already know.

>> 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.
> 
> I thought about that, and started to write the document that way.
> Then I had these thoughts:
> 
> 1. Not all those columns apply to all the values.  How do those
> columns apply to CMC-Request, CMC-Response, and server-generated-key ?
> What about "certs-only?
> 
> 1.5. When there are registry columns that often don't apply, people
> registering new values get confused about how to do their
> registrations, and what to specify (or not) for those columns.
> 
> 2. All that information is documented in the reference document for
> the value, when that information applies.
> 
> 3. One really needs to go to the reference document to understand how
> to use the values anyway.
> 
> Rather than making the registry more complicated, I'd rather have the
> values documented with a good reference pointer, and leave it at that.
> 
> Do others think that additional columns in the registry add enough
> value to put them there, despite those points above?

There is a negative value to duplicating information from RFCs in the registry. Registries should have the absolute minimum amount of duplicated information from the RFCs. Any developer who cares at all a protocol will already be looking in the RFC. A developer who only cares to know what code points are taken doesn't need the rest. This should not make anyone "weary".

--Paul Hoffman
_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime