[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of
It is time to decide if MASS is going to have a BoF at IETF 62. As
you know, one was not held at IETF 61. Is the group ready to nail
down a charter and milestones?
I'm afraid I see no consensus here at all on what problem
we're trying to solve, let alone on the right way to solve
it. Instead, we're engaged in the time-honored IETF practice
of letting the unattainable best be the mortal enemy of the
As such, I think a BOF would be a complete waste of time.
Another question to think about is whether the IETF really wants to make a
fifth attempt in the email signature area, so far it has done PEM, MOSS, PGP
I think that what we have here is an application protocol rather than a core
infrastructure platform. The IETF has never been that comfortable at the
application layer, particularly the consumer facing part of it. How is an
organization going to work out best security practices for HTML email when
the majority of the members cannot see the value of the idea?
I have a very clear idea of what I want to achieve and I believe that my
view of the problem to be solved and the approach to solving it is shared by
the majority of the application oriented people. I also believe that there
is simply no point in trying to explain the value of that concept to network
focused people who use elm or pine as their mailer.
The crypto packaging and some of the keying infrastructure is the only part
of this problem that is within the scope of what the IETF is comfortable
addressing. Most of the design decisions and most of the specification work
that needs to take place is in the user interface and human factors space.
Having just gone through the MARID experience I have no desire to start
another standards effort on the same topic and with the same cast of
characters in the same forum.