Subject: RE: [ietf-dkim] SSP requirements

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 7 Aug 2006 07:39:17 -0700

> [mailto:[email-masked]] On Behalf Of Michael Thomas

> Douglas Otis wrote:
> 
> > An another policy that might be considered would be one for 
> the DKIM 
> > client
> 
> 
> I'm sorry, I have no idea what a dkim client is. Can you in as few of 
> words as
> possible tell me what that is?

In a client-server architecture a client is any party that initiates a protocol exchange rather than responding to one.

So a DKIM client would be a mailer that has the ability to generate a DKIM compliant signature. I described a client of this type if you want a design. 

http://middleware.internet2.edu/pki06/proceedings/hallam_baker-usable_email.pdf

My current plan is to build this capability into Thunderbird.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 8 Aug 2006 10:17:11 -0700

> [mailto:[email-masked]] On Behalf Of Dave Crocker
> Stephen Farrell wrote:
> > 
> > Hallam-Baker, Phillip wrote:
> >> OK a new point, the SSP requirements need to be addressed to 
> >> different
> >> audiences:
> >>
> >> 1) Authors of software
> >> 2) Operators of software.
> > 
> > I don't recall seeing this mentioned before!
> 

> As soon as we allow items like the above onto the list, we 
> automatically need to list large numbers of others, 
> concerning deployment, administration, operations and use.  
> None of these will have any meaningful benefit to the list, 
> other than to make the list longer and to make the salient 
> issues more obscure.

It's a question of viewpoint.

Operational requirements are not the same as architectural requirements. One drives the other but there are two different levels of abstraction.

Some people are talking at one level of abstraction, others are talking past them at another level of abstraction.

Operational requirements are probably best documented in the form of use cases and the architectural requirements deduced from them.

Most of the people generating posts on the list are talking about their personal operational issues and making the mistake of thinking everyone has the same situation. Leading to interminable disputes.