On Sat, Mar 7, 2009 at 12:08 PM, Hector Santos wrote:
> DKIM Chair wrote:
>> Then there's the question of where ADSP stands, and whether it can proceed
>> as is,
>> or needs to be changed in light of the "errata". Pasi may have some
>> comments on
>> this, and I know the working group will. We
I am for #2 personally speaking. The errata discussion has become way
too complex and it would be extremely confusing for operational users
of dkim to have to switch back and forth between rfc and errata.
This, as long as 4871bis is a "short" step before draft standard - and
the draft standard do
DKIM Chair wrote:
> 1. Include the other errata into Dave's draft, leave the whole thing as "old
> text
> / new text" format, and put it out as an RFC that updates 4871. There would
> be
> no rev of 4871, and implementors would need to use both documents. Work on
> 4871-bis from there.
>
>
Barry Leiba wrote:
>> If we were to come out with a 4871bis *without* also attempting to move
>> it forward on the standards track, then I agree that we'd be sending a
>> bad message to the industry. But I don't think doing a bis without
>> concurrent advancement is being seriously considered -- I'
> If we were to come out with a 4871bis *without* also attempting to move
> it forward on the standards track, then I agree that we'd be sending a
> bad message to the industry. But I don't think doing a bis without
> concurrent advancement is being seriously considered -- I'm certainly
> advocatin
On the contrary, moving DKIM **forward in the standards process** sends
exactly the proper message: that DKIM *is* stable enough for us to
advance its standards level.
Remember, advancing along the standards track has serious constraints on
the types of changes permitted to the spec. It is *not* a
I frankly don't see the point of a -bis document, and so long as the errata
shows up reasonably close to the top in a google search, I think that the
dev front should be fine. Invoking another round of IETF process at this
point sends exactly the wrong message: that DKIM is not stable. DKIM
has bee
Pasi,
Did I miss your response about this substantive point?
d/
Dave CROCKER wrote:
> pasi.ero...@nokia.com wrote:
>> - I think introducing clear terminology for the identity/identities (or
>> identifier/identifiers) "output by DKIM" would make DKIM significantly
>> easier to understand, and w
Dave Crocker wrote:
> 2. The RFC Editor publishes rules for Errata. So does the IESG.
> You indicate that Pasi is refusing to process
> draft-ietf-dkim-rfc4871-errata-02 for two reasons: It introduces new
> terminology and it makes too many changes. Neither of these is
> included (or excluded)
pasi.ero...@nokia.com wrote:
> Dave Crocker wrote:
>
>> 2. The RFC Editor publishes rules for Errata. So does the IESG.
>> You indicate that Pasi is refusing to process
>> draft-ietf-dkim-rfc4871-errata-02 for two reasons: It introduces new
>> terminology and it makes too many changes. Neithe
DKIM Chair wrote:
> The first point is that while 2/3 of the working group prefer the stronger
> and
> more extensive clarifications in the "Dave draft" (realizing that he's the
> editor, and that others were involved in drafting this; it's a convenient way
> to
> refer to it) to the more mi
Pasi, Stephen, and I had a conference call to sort out where we can go with the
errata, the idea of a 4871-bis, and so on. This summarizes what we think,
where
we'd like the working group to go, and what the working group needs to decide.
The first point is that while 2/3 of the working group
12 matches
Mail list logo
