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

From: Barry Leiba <[email-masked]>
Date: Fri, 6 Sep 2013 10:19:23 -0400

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.

Barry

> From:  <[email-masked]>
> Date: Wed, Aug 28, 2013 at 10:38 AM
> Subject: New Version Notification for draft-leiba-smime-type-registry-00.txt
> To: Barry Leiba <[email-masked]>
>
> A new version of I-D, draft-leiba-smime-type-registry-00.txt
> has been successfully submitted by Barry Leiba and posted to the
> IETF repository.
>
> Filename:        draft-leiba-smime-type-registry
> Revision:        00
> Title:           Creation of a registry for smime-type parameter values
> Creation date:   2013-08-28
> Group:           Individual Submission
> Number of pages: 4
> URL:
> http://www.ietf.org/internet-drafts/draft-leiba-smime-type-registry-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-leiba-smime-type-registry
> Htmlized:        http://tools.ietf.org/html/draft-leiba-smime-type-registry-00
>
>
> Abstract:
>    Secure/Multipurpose Internet Mail Extensions (S/MIME) defined the
>    Content-Type parameter "smime-type".  As the list of defined values
>    for that parameter has increased, it has become clear that a registry
>    is needed to document those values.  This document creates that
>    registry, registers the current values, and specifies the policies
>    for registration of new values.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 Sep 2013 08:41:51 -0700

> proceed.  And it' short.  So have at it.

The idea of having a registry seems fine, and "RFC Required" seems fine.

--Paul Hoffman

---

From: Sean Leonard <[email-masked]>
Date: Sat, 07 Sep 2013 07:45:52 -0700

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

---

From: Barry Leiba <[email-masked]>
Date: Sat, 7 Sep 2013 13:09:54 -0400

Hi, Sean, and thanks for the comments.

> 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.

> 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

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 7 Sep 2013 11:09:33 -0700

> 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.

> 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