At 3:58 PM 1/5/95, Ned Freed wrote:
Rhys is the one who said this, not me!
how last minute it is. I suggest that the current draft be modified
slightly to permit a comma-separated list of Content-Types in the protocol
parameter ("for future use"), and also relax the restrictions on "there
must only be two parts" a bit, and then move the draft forward as is.
The basic idea sounds interesting and reasonable.
The intent to leave it strictly as 'for future use' does not.
Things which are strictly 'for future use' almost never get used. The SNMP
security field is one of the classic examples.
On the other hand, the cost of reserving a field for future use isn't
especially high, so I'm not sure I see the downside. A more important factor is
not allowing ad-hoc extensions that do not interoperate. In other words, its
one thing to have a reserved field that is never used, but it is quite another
for there to be a field that different implementations use in incompatible
ways.
As such, in some cases I prefer reserved fields to open fields that anyone can
use for any purpose.
The spec needs to have enough flesh to it to make this generality
real. If we have a clear, concrete, and reasonable sense of the way this
will be used, then fine. The spec needs to say it, so there isn't any
doubt. No, we don't have to have absolutely all of the details worked out,
but there needs to be enough substance to leave no doubt how this will turn
out.
The current specification says that security multiparts must have two parts and
protocol paramter lists the type of one of the parts. As such, any security
multipart that has more parts, has a protocol parameter that lists more than
one type, or both, is not legal. I regard this as effectively the same as
"reserved for future use".
Given the amount of discussion with no real consensus on how additional parts
could or should be used, as well as the semantic issues associated with having
two signatures or encryption interchange key sets at the same level, I've come
around to the position that we'd be better off leaving this alone.
It is also not beyond possibility that another security service besides PEM
or PGP will lay better claim to additional parts within these structures.
Ned