The fact that the check does not contain a machine readable
representation of the endorsement requirements is, I suspect, a
reflection of limitations on the paper-based check system, and
historical inertia. We disagree about whether this endorsement
restriction is part of the content, or part of the check definition.
I like to think of content as the part that is filled in with variable
quantities that are likely to vary on per-check basis, e.g., payee,
amount, date, signer, etc. Anything printed on the check in a
permanent fashion, like a multi-signer requirement for checks above a
certain value, strikes me as not content. However, I agree that, from
a bank's perspective, this info may be considered content because it
is not a standard part of all checks. The bottom line is that in an
automated system, it is not generally feasible for the system to
analyze the content, but it is expected that the system "do the right
thing."
This is not the case for MIME messages. The content is labelled precisely so it
can be analyzed in this way and systems can "do the right thing".
If one wants the system to meet this latter criteria, then
the system should be able to parse the check to determine whether
there are and special requirements that must be met prior to
authorizing transfer of funds.
The nice thing about MIME is that you can have it both ways. If you want to
sign and send plain undifferentiated and unparseable text material (or pictures
or whatever) you can. And if you want to define some sort of content (or
wrapper or whatever you want to call it) that contains specifications details
what the signatures mean, well, you can do that too if you want.
Note also that just because you could do this in the future doesn't mean it can
be done with the present specification. There is no type definition to suport
this service at present. You'd have to define this type in an interoperable
fashion first, and in the process you'd have to deal with a large number of
design and security issues.
Ned