d/(sorry. somehow clicked send rather than paste...)
Michael Thomas wrote:
Dave Crocker wrote:
Michael Thomas wrote: There is no statement that they cannot co-exist, so
it's probably better not to assert that such a statement is false.
The statement is that SSP is intended for processing by a filtering
engine and that it has no direct MUA-related intent.
I'm pretty sure this a game of gotcha, but opposing "filtering
I speak for your goals, but all I'm trying to do is a) understand what was
originally meant and b) make sure we use terminology carefully and describes
needs and functions precisely.
engine" and "MUA" in the above construct implies that they are two disjoint
categories. They aren't, and thus your construction
Oh. Well they are in fact entirely disjoint, except to the extent that an MUA
might contain a filtering engine.
I'd be glad to explain the fundamental differences -- they are legion or, at
least, considerable.
falls into the false dilemma fallacy, I'm pretty sure. Also: MUA's and
their considerations are not outside of our charter, and it's
Yeah, they are. They are not explicitly excluded, in the charter next -- nor
are they included -- but they are most certainly outside the competence of
this group.
And I thought this had been demonstrated sufficiently many times in the past.
To the extent that one more time is needed, feel free to move from the
'concept' of MUAs being relevant to the actual work of attempting to make them
relevant, by discussing particulars.
perfectly reasonable to bring up issues that may help MUA developers use
DKIM and SSP. It's also yet another false dilemma to say that
It is always reasonable to bring up issues that may help any developer. I
haven't seen that happening here, but no, it's certainly not excluded.
However I'll ask how this is meaningfully relevant to the original reference,
which I'll re-cite, since I suspect most folks have forgotten:
Bill(_dot_)Oxley(_at_)cox(_dot_)com wrote:
I think I am missing something DKIM base crypto claiming responsibility
of the singing domain
SSP Senders signing policy, usage statement of DKIM by sender
ASP Authors signing policy who is not clearly a sender or a member of the
signing domain but wants to assert a policy anyway
MUA how to reliably display something useful about the above information
Am I correctly framing the thread? thanks, Bill
We have repeatedly demonstrated that this working group is not in a position
to give guidance about 'how to reliably display something useful' about
SSP-related information.
MUA's are the same thing as their UI's or even worse their human interface
considerations (which a MUA may or may not even possess). It would be
helpful to not keep making these errors of composition.
I've no idea what errors you are referring to, but for reference a UI is
merely a component of an MUA.
By human interface considerations I assume you mean the User Centered Design
or Activities Based Design factors or the like that affect a user's cognitive
processes while attempting to get work done with the MUA?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html