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.
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?
Barry
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime