Re: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope.

Yeah, but don't you see Phillip, this was already done, in SSP for each 
of its drafts, and in DSAP in its expired draft.
Why are we wasting time trying to remove this NO MAIL concept? So that 
you can just create a slot later on in your spec?
I don't get it.

--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


allam-Baker, Phillip wrote:
> Now add the three pages of boilerplate.
>
> That is why I said four. 
>
> > -----Original Message-----
> > From: Hector Santos [mailto:hsantos(_at_)santronics(_dot_)com] 
> > Sent: Tuesday, June 05, 2007 5:10 PM
> > To: Bill(_dot_)Oxley(_at_)cox(_dot_)com
> > Cc: Hallam-Baker, Phillip; ietf-dkim(_at_)kitterman(_dot_)com; 
> > ietf-dkim(_at_)mipassoc(_dot_)org
> > Subject: Re: [ietf-dkim] RE: I think we can punt the hard 
> > stuff as out ofscope.
> > Its not 4 pages!!! <grin>
> >
> > Good show Bill!
> >
> >
> > --
> > Sincerely
> >
> > Hector Santos, CTO
> > http://www.santronics.com
> > http://santronics.blogspot.com
> >
> > Bill(_dot_)Oxley(_at_)cox(_dot_)com wrote:
> > > Edit/draft follows
> > > The result of a Sender Signing Policy Check is one of five possible
> > >    policies:
> > >
> > >       (1) Some messages from this entity are not signed; the message
> > >       SHOULD be presumed to be legitimate in the absence of a valid
> > >       signature.  This is the default policy.
> > >
> > >       (2) All messages from this entity are signed; all 
> > messages from
> > >       this entity SHOULD have a valid signature, either directly on
> > >       behalf of the originator or on behalf of a third 
> > party (e.g., a
> > >       mailing list or an outsourcing house) handling the message.
> > >
> > >       (3) All valid messages from this entity are signed, and SHOULD
> > >       have a valid signature from this entity.  Third-party 
> > signatures
> > >       SHOULD not be accepted.
> > >
> > >       (4) Signing policy for this domain is expressed at 
> > the individual
> > >       address level.  A second Sender Signing Policy Check should be
> > >       performed specifying the individual address
> > >       
> > >       (5) This Domain does not send messages/This domain only signs 
> > > third party messages
> > >
> > > Done, now the rest of the WG should be happy thanks, Bill
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org on behalf of Hallam-Baker, 
> > > Phillip
> > > Sent: Tue 6/5/2007 3:54 PM
> > > To: Hector Santos
> > > Cc: Scott Kitterman; ietf-dkim(_at_)mipassoc(_dot_)org
> > > Subject: RE: [ietf-dkim] RE: I think we can punt the hard 
> > stuff as out ofscope.
> > >  
> > > OK how about this as a plan
> > > 1) We do policy according to the view of scope currently 
> > being expressed by the chairs and myself.
> > > 2) You and I submit a four page ID that registers a NOMAIL 
> > policy for DKIM.
> > > 3) The group decides whether to accept the paragraph of 
> > text into the text of the main draft or not during the Draft phase.
> > > > -----Original Message-----
> > > > From: Hector Santos [mailto:hsantos(_at_)santronics(_dot_)com]
> > > > Sent: Tuesday, June 05, 2007 3:48 PM
> > > > To: Hallam-Baker, Phillip
> > > > Cc: Michael Thomas; Scott Kitterman; ietf-dkim(_at_)mipassoc(_dot_)org
> > > > Subject: Re: [ietf-dkim] RE: I think we can punt the hard stuff as 
> > > > out of scope.
> > > > Hallam-Baker, Phillip wrote:
> > > >
> > > > > NOMAIL is out of scope, wildcards for signature policy are not.
> > > > Deja-vu.  NOMAIL is not out of scope in SSP and you need to STOP 
> > > > saying
> > > > it.   The CONFUSING VOTE that was taking - I still don't now 
> > > > show what
> > > > it meant but it was not what it would to be removed from SSP!
> > > >
> > > > > There are two deployment stories we need to be able to give,
> > > >  > one that meets 95% of needs with legacy infrastructure 
> > support,  > 
> > > > the second that meets 100% of needs with a minor incremental  > 
> > > > change to the legacy infrastructure.
> > > > I don't see how SSP violates this principle.
> > > >
> > > > > The second of these provides a slot ready made
> > > >  > for NOMAIL, (and for STARTTLE, PGP and SMIME if you like).
> > > >
> > > > Oy vey! So then it is not out of scope as you said.
> > > >
> > > > > I am meeting your set of requirements in full. I am just
> > > >  > not doing so in such a way that my proposal is out of scope,  > 
> > > > that is all.
> > > > Well, I would like to know who proposed this lame rule 
> > that it should 
> > > > be out of scope when it wasn't and was clearly part of all 
> > the sepcs 
> > > > - SSP and DSAP specs.
> > > >
> > > > If people voted under the disquise of a general "NO MAIL" 
> > > > concept across
> > > > the board, well, it is clear now this is not what they voted for 
> > > > because you are making provisions for it.
> > > > I don't understand why is so secret. I don't want a NO-MAIL DKIM 
> > > > policy to be dependent on a KLUDGED MX concept or  LMAP support.
> > > >
> > > > --
> > > > Sincerely
> > > >
> > > > Hector Santos, CTO
> > > > http://www.santronics.com
> > > > http://santronics.blogspot.com
> > > _______________________________________________
> > > NOTE WELL: This list operates according to 
> > > http://mipassoc.org/dkim/ietf-list-rules.html



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