Well written requirements completely describe the final solution space.
We won't have consensus on requirements until we're done making
technical decisions.
However, for those that feel strongly about requirements we should be
collecting criteria by which to compare various mechanisms and
proposals.
On Jim's comments:
All I'm trying to avoid is this group
creating the sixth email signature protocol.
Maybe we will :-) ... or perhaps one of the old proposals will get
recycled and we simply need to specify our usage... or there will be
other focused mechanisms developed. All of these are viable outcomes of
the current charter.
Paul
PS - can we declare the charter to be done soon?
-----Original Message-----
From: owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of James
M Galvin
Sent: Friday, October 01, 2004 11:31 AM
To: John Levine
Cc: ietf-mailsig(_at_)imc(_dot_)org
Subject: Re: Why we don't require requirements
I am trying to keep this discussion at the level of the
charter, so starting at the bottom of your message:
Are these requirements? I suppose so, but they all seem pretty
obvious in context.
I agree on both points: they are requirements and they are
obvious in context. Your points were:
what does the signature protect
granularity of the signature
key distribution
My point is that both the S/MIME and PGP technologies (there
is a third, RFC1848-MOSS, which I only mention I believe is
applicable because we're not talking about solutions) are
agnostic on all three points. This means that the
specifications as written describe a profile that may not
work directly but the core technology is just fine.
All are designed to work with email. More precisely, all
work with MIME objects, which is really all that is needed.
So, the charter could say we're looking to meet the
requirements you mention (which it does) and include as a
non-goal creating a new protocol for generating a signature
in email (which it does not).
By way of example, consider the use of security multiparts (RFC1847).
All it needs to be part of a solution to this problem is a
secure email protocol and a bit of a profile for the use of
the protocol, where the profile covers the three points you
mention. MTA Signatures is most of what I'm talking about.
All I'm trying to avoid is this group creating the sixth
email signature protocol. I agree that everything else
mentioned is work to be done.
Jim