Re: [ietf-dkim] Moving on to ADSP - was RE: Handling the errata after the consensus call

2009-03-11 Thread Hector Santos
Stephen Farrell wrote: > > Siegel, Ellen wrote: >>> -Original Message- >>> On Behalf Of John Levine >>> >>> Seems like a reasonable way to avoid the i= fight. If there's interest, >>> I can whip up a new ADSP draft with an r= tag. >>> >> Sounds like a good approach to me. > > Just in cas

Re: [ietf-dkim] Moving on to ADSP - was RE: Handling the errata after the consensus call

2009-03-11 Thread Stephen Farrell
Siegel, Ellen wrote: > >> -Original Message- >> On Behalf Of John Levine >> >> Seems like a reasonable way to avoid the i= fight. If there's interest, >> I can whip up a new ADSP draft with an r= tag. >> > > Sounds like a good approach to me. Just in case: Please don't prepare a new A

Re: [ietf-dkim] Moving on to ADSP - was RE: Handling the errata after the consensus call

2009-03-11 Thread Siegel, Ellen
> -Original Message- > On Behalf Of John Levine > > Seems like a reasonable way to avoid the i= fight. If there's interest, > I can whip up a new ADSP draft with an r= tag. > Sounds like a good approach to me. Ellen ___ NOTE WELL: This li

Re: [ietf-dkim] Moving on to ADSP - was RE: Handling the errata after the consensus call

2009-03-11 Thread Jeff Macdonald
On Wed, Mar 11, 2009 at 10:40:18AM -, John Levine wrote: >>I'm not sure what my opinion is on that last point, but on the first >>point I think it's best to define an identifier that's specifically >>for ADSP's use, if we want that function. Some signers may give that >>tag the same value they

Re: [ietf-dkim] Moving on to ADSP - was RE: Handling the errata after the consensus call

2009-03-11 Thread Michael Adkins
John Levine wrote: >> I'm not sure what my opinion is on that last point, but on the first >> point I think it's best to define an identifier that's specifically >> for ADSP's use, if we want that function. Some signers may give that >> tag the same value they give i=, and there's no harm done. S

Re: [ietf-dkim] Moving on to ADSP - was RE: Handling the errata after the consensus call

2009-03-11 Thread Wietse Venema
John Levine: > >I'm not sure what my opinion is on that last point, but on the first > >point I think it's best to define an identifier that's specifically > >for ADSP's use, if we want that function. Some signers may give that > >tag the same value they give i=, and there's no harm done. Some >

Re: [ietf-dkim] Moving on to ADSP - was RE: Handling the errata after the consensus call

2009-03-11 Thread John Levine
>I'm not sure what my opinion is on that last point, but on the first >point I think it's best to define an identifier that's specifically >for ADSP's use, if we want that function. Some signers may give that >tag the same value they give i=, and there's no harm done. Some >signers may use a diff

Re: [ietf-dkim] Moving on to ADSP - was RE: Handling the errata after the consensus call

2009-03-10 Thread Barry Leiba
Dave says... > 2.  d= is sufficient for ADSP's stated goal. > > 3.  The current ADSP re-defines i= semantics.  While this is theoretically > legal, it is neither necessary nor useful.  So the important question is not > about legality, but about need. ADSP's use of i= makes the meaning of DKIM > co

Re: [ietf-dkim] Moving on to ADSP - was RE: Handling the errata after the consensus call

2009-03-09 Thread Dave CROCKER
MH Michael Hammer (5304) wrote: > With regard to the other discussion, for the implementations I'm engaged > in, d= works fine for ADSP. I recognize that for other implementations > using i= provides additional value. I therefore would support keeping > the reference string (domain part or HRS of i

[ietf-dkim] Moving on to ADSP - was RE: Handling the errata after the consensus call

2009-03-09 Thread MH Michael Hammer (5304)
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Barry Leiba > Sent: Monday, March 09, 2009 3:20 PM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] Handling the errata after the consensus call > > The discussion s