I guess the obvious next question then would be: why only two? That
is, are there other use cases which are sufficiently different that
some level of extensibility is needed?
hadn't been thinking of a restriction in number. the general model seems to be:
Permit multiple signatures that do not (necessarily) conflict.
Personally, I'm extremely worried that this will create mayhem, but there have
been simple, reasonable -- and maybe even compelling -- usage examples that
would be wrong to prevent.
So my own view is simplicity and expediency means that we should not go through
the design of the different scenarios, but flexibility and power mean that we
also should not do anything knowingly to prevent experimenting with them.
This could represent a potential slippery slope,
yup.
but if we added
some kind of signature typing, with each type having associated
rules, we could define two types now, (perhaps originating MTA
and list server) and then someone else could define others later
on.
signature "typing"?
I suggest, instead, that we make sure the signature header remains extensible
and that any future decision that we need to adding parameters, such as a type
field, be pursued then. Later.
d/
--
Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
ietf-dkim mailing list
http://dkim.org