Eliot Lear wrote:
I think perhaps it would help, Dave, if you could step through the
ramifications of your concerns.
I don't understand your question. What is it about the Introduction to the
Errata that is not sufficiently clear or complete?
You appear to be asking about the ramifications of being non-interoperable, and
I know you don't really mean that.
What it doesn't say is how the confusion
manifests itself. Can you please clearly do so with examples?
You need an example of the problems that can ensue from having one side of a
protocol exchange consider one attribute to be the sole output and another side
consider two attributes or a different one attribute to be the output?
Really?
If the UAID is not the same as the address in the From:
header field, the mail system SHOULD take pains to ensure that the
actual UAID is clear to the reader.
If you are going to go to lengths to separate the Identity Assessor from
other parts of the system, it makes it more confusing when you continue
the old phrasing of "mail system" above. Which mail system? Who is
responsible for that? I presume you mean the signer, since the signer
is the one who inserts the UAID.
damn. damn. damn. yes it does make it more confusing. yes I meant to change
it. grrrr. sorry.
I believe the intent of that sentence is something like "receiving MUA", but on
reflection, I'm not sure I fully understand what this requirement really is or
what is considered reasonable for satisfying it. And I mean that as a
specification-clarity issue, not an user interface philosophy issue.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html