Re: [ietf-dkim] Splitting the DKIM base doc

Should we split the DKIM base doc into independent modules? I believe Dave has a specific idea that he might share with us... Dave? I'm working on a proposal. Couple of items ahead, in my queue. Soon. d/ -- Dave Crocker Brandenburg InternetWorking ___

Re: [ietf-dkim] Splitting the DKIM base doc

Barry Leiba wrote: Dave brought up, at the Monday DKIM IETF session, the idea of splitting out the key-discovery parts from the base document. I've recently come up with a need to have the canonicalization be separately referenced. I'm throwing this out to the mailing list for discussion: Go

Re: [ietf-dkim] Splitting the DKIM base doc

The next milestone should be WG last call on base in May, so if your suggestion is likely to cause that date to slip, I guess it'd be good to include a justification for that. Good point, of course. Dave and I babbled briefly at each other about this recently, and I think a split makes sense -

Re: [ietf-dkim] Splitting the DKIM base doc

Barry Leiba wrote: I think the work of splitting it will be small, and won't affect the schedule, Given what Eric said he planned to do, with respect to the base document's discussion and reference to the key service, I agree. If I understood correctly the change he is planning will a) co

Re: [ietf-dkim] Splitting the DKIM base doc

Stephen Farrell wrote: Barry Leiba wrote: Dave brought up, at the Monday DKIM IETF session, the idea of splitting out the key-discovery parts from the base document. I've recently come up with a need to have the canonicalization be separately referenced. I'm throwing this out to the mailing

Re: [ietf-dkim] Splitting the DKIM base doc

Michael Thomas wrote: > A split is guaranteed to cause that date to slip, fullstop. > > As I've said, from a developer's standpoint, multiple documents > suck. But here's what I don't understand: if we split the documents, > we will have to submit all of the former parts of -base as a bundle > sin

Re: [ietf-dkim] Splitting the DKIM base doc

Folks, The only thing I'd add is to ask folks to also bear in mind our charter [1] deadlines when suggesting new document structures. ... A split is guaranteed to cause that date to slip, fullstop. Although we certainly need to pay attention to impact on the schedule, the amount of impact

Re: [ietf-dkim] Splitting the DKIM base doc

Dave Crocker wrote: Folks, The only thing I'd add is to ask folks to also bear in mind our charter [1] deadlines when suggesting new document structures. ... A split is guaranteed to cause that date to slip, fullstop. Although we certainly need to pay attention to impact on the schedule

Re: [ietf-dkim] Splitting the DKIM base doc

> I'm really having a hard time understanding why we're so intent on > snatching defeat from the jaws of victory. Mike's comment above got me thinking on this. Aren't we very close as a WG to resolving all known issues with -base now without this split? If so, why introduce such a change if t

RE: [ietf-dkim] Splitting the DKIM base doc

@mipassoc.org Subject: Re: [ietf-dkim] Splitting the DKIM base doc > I'm really having a hard time understanding why we're so intent on > snatching defeat from the jaws of victory. Mike's comment above got me thinking on this. Aren't we very close as a WG to resolving all k

Re: [ietf-dkim] Splitting the DKIM base doc

The following point is against splitting the document: (a) Less convenient for implementors and those who need to reference the documents The following points are in favor of splitting the document: (a) It can help speed up the "process" by deferring controversial topics for later (b) It ha

Re: [ietf-dkim] Splitting the DKIM base doc

At 3:53 PM -0600 3/27/06, Arvel Hathcock wrote: The following point is against splitting the document: (a) Less convenient for implementors and those who need to reference the documents The following points are in favor of splitting the document: (a) It can help speed up the "process" by def

Re: [ietf-dkim] Splitting the DKIM base doc

Paul, The WG should *not* want to speed up getting the normative base spec out by deferring controversial topics to the non-normative overview. Who suggested this course of action? As I said at the mic last week, I think we should have a single document that contains the protocol and the di