However, I do not believe the current
Charter reflects this problem space very well. Or rather, to
put it the other way, the Charter does not constrain the work
to this problem space.
Indeed.
I am hoping to get a revised version out today or tomorrow. The
list discussion has been quite fruitful in identifying
deficiencies in the current draft charter.
Your paragraph above is an excellent starting point for the
Charter, in my opinion.
I liked it too...
Separately, I do want to comment briefly on the issue of
interoperability. Multipart/signed was designed expressly to
be backwards compatible with non-MIME-aware email components.
Consider that the content that was signed appears first and
the security information second, so as not to distract
"backwards" components.
"backwards compatible" is certainly the term that was used -- and
intended -- when multi/sig was developed. However in the current
context, it needs clarification. The two interoperability goals
that multi/sig achieved were a) not breaking non-supporting
recipients, and b) permitting non-supporting recipients to
extract the original text in a manner that was no (too)
distracting.
My wording is stylized in order to set the stage for the current
round of effort, as I understand it:
The new mechanism must be essentially invisible to
non-supporting recipients.
In addition, MTAs may not be MIME-aware but insofar as they
"handle" virus scanning, they are more than capable of
dealing with the solution to this problem space. The only
reasonable way to do virus scanning is to break a message
into its parts and scan each part. An MTA either does this
or knows how to "call a tool" that does it. Same for this
problem space.
I am not understanding how this relates to the current thread.
Please clarify.
point out that doing it without MIME does not mean doing it
without PGP or S/MIME. That's a separate point worthy of
debate in the working group.
Since both of their specifications are MIME based, you are
describing creation of a new specification.
Further, there are additional requirements/constraints that have
been listed, that neither pgp nor s/mime currently satisfy.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker at ...
brandenburg.com