RE: revised Proposed Charter

["James Scott" <james.scott@xxxxxxxxxxxx>]

Earl Hood wrote on 26 July 2005 8:19 a.m.
> 
> On July 25, 2005 at 22:06, "James Scott" wrote:
> >
> > I think that the "i=" tag is more correctly described as the signing 
> > agent and that the "d=" tag should be derived from the "i=" value.
> > Perhaps "i=" should be REQUIRED, while "d=" is OPTIONAL (or is REQUIRED 
> > for DNS key retrieval).
> 
> Nope.  The i= tag identifies the sender/author.  Quoting from 
> the draft:
> 
>   Identity of the user or agent (e.g., a mailing list manager) on
>   behalf of which this message is signed.
> 

Sounds like the signer to me, but that is for a later debate.  We are
discussing the charter here :)


> > A more fundamental question is whether the proposed charter is in 
> > conflict with the "q=" tag.  The proposed charter states
> > 
> > 	"Keys will be stored in the responsible identity's DNS hierarchy."
> > 
> > So why have a "q=" tag at all?
> 
> I think it is mistake to artificially constrain things when 
> there is no cost to making things more flexible.  The charter 
> implies that the initial deliverable will be based on a DNS 
> PKI, but that does not prohibit developing specs that support 
> alternatives in the future.
> Right now, the draft is written with alternatives/extensions 
> in mind, but I think it could use some "beefing up" in this area.

I agree that "beefing up" the draft could be useful, and expect that it will
be discussed later.

> 
> > The existence of this tag automatically opens up DKIM to alternative 
> > key storage/retrieval mechanisms.
> 
> Yep, and the draft implies this, but in a restrictive matter; 
> mainly due to the wording chosen.  The wording is limited to 
> "retrieving the public key".

We should probably have the charter, which is what we are currently
discussing, contain language that reflects the intention/expectation that
extensions beyond the initial DNS based key retrieval will be specified.

James