On 8/26/23 14:39, John Levine wrote:
It appears that Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> said:
What I currently have in mind for implementation of interactive email is
(a) messages can include "objects" that are rendered as text, images,
buttons, forms, etc. by the recipient's mail reader.
Sounds a lot like HTML forms.
That's not what my prototype looked like. Offhand I don't recall using
HTML forms at all, but it's been a few years since I looked at that
code. At least without JavaScript (which I didn't want to use because
many MUAs didn't support it and still don't) HTML forms are rather
inflexible in the kinds of interactions that they facilitate.
For example, let's say I email a technical proposal to an IETF WG
list. Other list participants could then vote up/down on that proposal
(or specific sections of that proposal) by clicking buttons associated
with a poll object in the email (e.g. "do you prefer approach A or
B?"). The current vote totals would always be visible to anyone viewing
that original email, and readers could change old votes if/when the
proposal text improved. ...
You really should look at the schema.org stuff and the SML WG.
I have looked at the schema.org work before, when developing my
prototypes for interactive email collaboration. At that time they did
not meet my needs and some of it seemed to me to be poor practice. But
I'll look at their work again to get a more current idea. I'm not
trying to re-invent the wheel if a suitable wheel already exists.
Given the rule of thumb that our standards are most successful when they
formalize existing practice, it seems like the right place to start.
This is IMO overstated and shouldn't be treated as a rule (even a rule
of thumb). But I agree that it's good to learn from existing practice
before deciding what to recommend for widespread implementation and
deployment. Whether the existing practice is something that IETF
should use as a basis for standardization should be based on a technical
evaluation of that practice, its security and privacy and scalability
(...) properties, how well it meets the design requirements, and so on.
At the same time I think there's a need for many different kinds of
interactive mail, with a spectrum of requirements, and I'd hope that the
various solutions can be made to dovetail well with one another.
Keith
