Andrew Newton writes:
The former is the necessary bits on the wire to make email
signatures survive through existing infrastructure, and the
likely compromises that will entail -- very SMTP
specific. The latter is a much more general proposition as
this authorization function may well be used by other
services: there's already questioning on the SIP list, fwiw,
about whether a similar anti-forgery scheme would be
relevant for them.
Not that I have anything against SIP, but we shouldn't turn this
working group into solving the problems of the world. How about aiming
to make it generally useful for other applications but with a primary
focus on email?
Absolutely. The last thing I want to get bogged down in is
requirements for other uses. A simple 'domain of
interpretation' (or service as we called it) on the return
value of the authz query was all I was thinking about, with
exactly one allocated value from IANA permited by the
charter.
Mike