[Top] [All Lists]

Re: Straw consensus call on auth-header draft

2008-10-15 06:38:52

Lisa Dusseault wrote:
I'd like to do a more explicit consensus call now to nail this down. I've tried to identify the major points of attraction rather than every variant, to see where people are leaning. Please reply with one of these options, a variant, and explanation if you like:

A)  auth-header to not require any feature advertising or auto-configuration
B) auth-header to normatively RECOMMEND some kind of feature advertising
C) auth-header to normatively REQUIRE some kind of feature advertising

"C" for having a reason for living (implementing it). Otherwise, whats the point? "A" will further create fuzzy unknowns about trust. While B is the middle ground, it is just as bad as A.

Separately, the unspecified feature advertising or auto-conf should be (choose one or more):
1) IMAP Capabilities advertising
2) E/SMTP capabilities
3) IMAP annotations
4) Something else
5) Nothing

Thats just it.  Whats it for?

The only use I see for it is to pass intra-process (internal) state information, i.e. so that a 2nd trusted process doesn't have to "re-do" whatever the first trusted process did. For an Internal MUA (a trusted process), it can be used for state information.

Why and When would a offline MUA, for example, trust and make use of this information? In terms of DKIM, does it replace the need for an MUA to do DKIM verification?


Hector Santos, CTO

<Prev in Thread] Current Thread [Next in Thread>