[03:44:07] --- dcrocker has left: Replaced by new connection
[03:44:07] --- dcrocker has joined
[10:11:15] --- Barry Leiba has joined
[10:11:46] * Barry Leiba has changed the subject to: DKIM meeting at 1500 UTC
[10:12:04] <dcrocker> today?
[10:12:22] <Barry Leiba> I b'lieve, yes.
[10:12:40] <Barry Leiba> We picked that because Eric's unavailable on Thu.
[10:12:49] <dcrocker> oops. missed that.
[10:13:20] <dcrocker> 8am pacific time, right?
[10:14:11] <Barry Leiba> http://mipassoc.org/pipermail/ietf-dkim/2006q2/003775.html
[10:14:18] <Barry Leiba> 45 minutes from now.
[10:14:24] <dcrocker> ack. tnx.
[10:14:53] <Barry Leiba> But I think Stephen didn't post anything yesterday or today, and there's no agenda posted. So I'll post a message now.
[10:18:57] --- paulehoffman@jabber.org has joined
[10:30:11] --- eric has joined
[10:34:51] --- eric has left: Logged out
[10:39:47] --- eric has joined
[10:46:37] --- thomasm has joined
[10:47:48] --- doug_trendmicro@jabber.org has joined
[10:53:07] --- sftcd has joined
[10:53:58] --- sftcd has left: Replaced by new connection
[10:54:03] --- sftcd has joined
[10:54:42] * Barry Leiba has changed the subject to: DKIM meeting at 1500 UTC... 5 minutes
[10:55:00] <sftcd> hi all
[10:57:35] <eric> hey stephen.
[10:57:57] * Barry Leiba has changed the subject to: DKIM meeting at 1500 UTC... 2 minutes
[10:58:57] * Barry Leiba has changed the subject to: DKIM meeting at 1500 UTC... 1 minute
[11:00:12] * Barry Leiba has changed the subject to: DKIM meeting in progress
[11:00:16] <Barry Leiba> Hi all.
[11:00:20] <Barry Leiba> Time to get started.
[11:00:24] <eric> hello teacher.
[11:00:37] <Barry Leiba> Today's agenda is based on Eric's note first: http://mipassoc.org/pipermail/ietf-dkim/2006q2/003795.html
[11:00:53] <Barry Leiba> And then we'll pick up the last three items from last week: http://mipassoc.org/pipermail/ietf-dkim/2006q2/003774.html
[11:01:10] <Barry Leiba> So I'll let Eric kick off the discussion. E?
[11:01:12] --- jrlevine has joined
[11:01:29] <doug_trendmicro@jabber.org> Is there a diff on the changes?
[11:01:30] <eric> that would be me. i hope everyone got a chance to at least glance over -03a.
[11:01:39] <eric> no
[11:01:47] <sftcd> doign it now actually
[11:01:54] <eric> great, thanks stephen
[11:02:35] <eric> ok, while stephen is doing that, let's get started. the first one is pretty easy.
[11:02:54] <eric> section 3.6, i dropped the mention of passing i= to the key lookup module.
[11:03:06] <paulehoffman@jabber.org> You left i_val in the pseudocode.
[11:03:25] <eric> yep, i just saw that. thanks.
[11:03:30] <eric> text now reads: Parameters to the key lookup algorithm are the type of the lookup (the "q=" tag), the domain of the responsible signer (the "d=" tag of the DKIM-Signature header field), and the selector (the "s=" tag).
[11:03:33] <sftcd> can someone relate this back to an issue number/letter so Eliot can trace?
[11:04:24] <eric> this one was issue "J" from last time
[11:04:29] <sftcd> thanks
[11:04:30] <eric> but i don't know if it got assigned a number.
[11:04:46] <eric> any comments on this (other than fixing the pseudo-code)?
[11:05:01] <Barry Leiba> Eliot did assign numbers to them, so we can look at the titles and compare.
[11:05:05] <Barry Leiba> I'll go have a look.
[11:05:17] <doug_trendmicro@jabber.org> It was F on the last Jabber agenda.
[11:05:46] <Barry Leiba> No, I think J is right.
[11:06:02] <eric> I think there may have been some overlap.
[11:06:32] <Barry Leiba> And it looks like the lettered items haven't gotten into the tracker yet. Oh, well.
[11:06:41] <Barry Leiba> Eric, as far as you know, does -03a cover everything that was agreed to so far?
[11:06:49] <eric> and it was "F" after all.
[11:07:04] <eric> i think so, although i did do it in a hurry.
[11:07:05] <Barry Leiba> OK on "F".
[11:07:16] <eric> so that's an accept?
[11:07:26] <thomasm> go for it.
[11:07:29] <doug_trendmicro@jabber.org> Okay by me.
[11:07:31] <sftcd> yes for me
[11:07:59] <eric> Barry, do you do the official close, or do I?
[11:08:44] <eric> Hmm...... i guess that would be then.
[11:09:04] <Barry Leiba> Oh, sure; if I'm gonna moderate, why not: Issue F is closed, text accepted.
[11:09:04] <sftcd> guess he's getting coffee so you may as well - just say "CLOSE foo; comment"
[11:09:24] <sftcd> colliding chairs! Barry wins
[11:09:25] <eric> ACCEPT item "F" --- http://mipassoc.org/pipermail/ietf-dkim/2006q2/003763.html
[11:09:38] <Barry Leiba> I like Eric's format. He's hired.
[11:09:45] <eric> (sorry, was trying to get the reference)
[11:09:57] <eric> ok, next item, section 6, change in return status wording.
[11:10:17] <eric> that's going to be hard to quote, since it's in several places.
[11:10:30] <eric> the intro reads "In the following description, text reading "return status (explanation)" (where "status" is one of "OK", "FAIL", or "TFAIL") means that the verifier MUST immediately cease processing that signature. If the status is "OK", the signature has sucessfully verified; otherwise, the verifier SHOULD proceed to the next signature, if any is present, and completely ignore the bad signature. If the status is "FAIL", the signature failed and should not be reconsidered. If the status is "TFAIL", the signature could not be verified at this time but should be tried again later. A verifier MAY either defer the message for later processing, perhaps by queueing it locally or issuing a 451/4.7.5 SMTP reply, or try another signature; if no good signature is found and any of the signatures resulted in a TFAIL status, the verifier SHOULD save the message for later processing. The "(explanation)" is not normative text; it is provided solely for clarification."
[11:11:11] <paulehoffman@jabber.org> I'm very uncomfortable with bullet 4 of section 6.3: "4. The signature has correctly verified: the verifier MUST return OK (signature verified)."
[11:11:12] <eric> example callout: "If the query for the public key fails to respond, the verifier SHOULD defer acceptance of this email and return TFAIL (key unavailable)."
[11:11:35] <eric> yeah, that one somehow bothered me too, but I decided that it is accurate.
[11:12:10] <paulehoffman@jabber.org> I don't think that returning OK is a MUST. I would be happier if there were just FAIL and TFAIL states, and the end is just "the signature verifies"
[11:12:11] <eric> of course, we can't force anything on the verifier blah blah blah, but that is the point where the signature is demonstrated to be correct.
[11:12:24] <eric> other comments?
[11:12:28] <thomasm> the question i have on bullet 4 is does that mean break or continue? as in stop processing all signatures or go to the next?
[11:12:38] <sftcd> similar point in text above - "MUST cease processing" why?
[11:13:13] <thomasm> I think it needs to be a bit tighter on "processing" as in "this signature" rather than "all signatures"
[11:13:27] <eric> mike, stephen: got it.
[11:13:46] <dcrocker> if the verifier verifies, how can it be permissable to do anything but return an OK?
[11:14:00] <paulehoffman@jabber.org> A thought: the two failur states could be PFAIL (permanent failure) and TFAIL (temporary failure).
[11:14:21] <thomasm> yes, the issue is that it should return OK for *just* that signature and then move on
[11:14:28] <eric> i'm neutral on the wording.
[11:14:40] <dcrocker> oh. the concern is about one sig vs. multiple?
[11:14:46] <eric> the issue is that it should return OK for that signature and then decide what it wants to do next.
[11:14:55] <eric> maybe that's enough, maybe not.
[11:15:06] <eric> could vary on what the i= tag is, for example.
[11:15:17] <eric> i really want to avoid wading into that quagmire.
[11:15:19] <paulehoffman@jabber.org> Dave: "return OK" will mean different things in different code. Right after the "MUST return OK" we say that, well, maybe that's "OK with some modifications".
[11:15:20] <dcrocker> Seems like "what it wants to do next" is the job of whatever entity called the verifier.
[11:15:39] <thomasm> I believe that the early escape logic for signatures is a property of SSP, which we shouldn't reference
[11:16:37] <eric> that seems to me to be an issue about the paragraph i quoted above.
[11:16:49] <paulehoffman@jabber.org> Given that this is the only use of OK, I think we might be better off with defined failure modes but leave this as just "The signature has correctly verified."
[11:17:16] <eric> by the way, i don't see an obvious way to make the "MUST immediately cease processing that signature" any more clear that it applies only to that signature.
[11:17:50] <thomasm> I think the "immediately" is a little too drama laden :)
[11:17:56] <doug_trendmicro@jabber.org> When there are further tests, it should not indicate processing should end.
[11:18:11] <eric> There are no further tests on that signature.
[11:18:20] <doug_trendmicro@jabber.org> g= i= ?
[11:18:20] <eric> so it should indicate that processing should end
[11:18:24] <sftcd> but s/MUST immediately/MAY/ would be ok for me
[11:18:41] <eric> i think we're talking about different things. i see your point re: OK.
[11:19:04] <eric> So let's be clearer about what we are talking about.
[11:19:16] <jrlevine> how about saying that further processing is useles or something like that. We're just being helpful here.
[11:19:23] <eric> start with item 4: "The signature has correctly verified: the verifier MUST return OK (signature verified). The verifier MAY make note of the special case where the "l=" tag was specified and some portion of the message was not signed; in this case the verifier can return OK (unsigned content)."
[11:19:51] <Barry Leiba> John has a point: To what extent is this normative, and to what extent is it informative?
[11:19:54] <eric> is consensus to drop the "MUST return OK" and instead say something like "signature verifies"
[11:20:06] <sftcd> +1
[11:20:10] <thomasm> +1
[11:20:20] <doug_trendmicro@jabber.org> +1
[11:20:24] <dcrocker> "verifier can return OK" -> "verifier MAY return OK"?
[11:20:47] <eric> dave: issue is really dropping OK as a status at all and waving our arms instead.
[11:20:48] <paulehoffman@jabber.org> Dave: I'm not sure we need an OK state for just this one step.
[11:20:57] <dcrocker> hey. wait a minute. i can't tell what wording everyone is voting on.
[11:21:09] <thomasm> dave: is consensus to drop the "MUST return OK" and instead say something like "signature verifies"
[11:21:19] <eric> we're talking about 6.3, #4
[11:21:33] <eric> and we're not voting.
[11:21:55] <dcrocker> i know what section we are talking about. what I don't know is what final wording folks are doing +1 to.
[11:22:04] <Barry Leiba> OK, I saw three +1 on that.
[11:22:09] <Barry Leiba> Mike repeated the wording.
[11:22:09] <thomasm> "signature verifies" dave
[11:22:14] <Barry Leiba> Dave, you get that?
[11:22:21] <eric> Stop after "The signature has correctly verified."
[11:22:26] <thomasm> leaving the normative "MSUT" working out
[11:22:41] <thomasm> yet still being normative
[11:22:42] <eric> Continue with "The verifier MAY make note ..."
[11:23:18] <eric> at the end, say "the verifier may pass that information to thecaller"
[11:23:19] <eric> or some such
[11:23:34] <paulehoffman@jabber.org> Eric: all that works for me.
[11:23:38] <dcrocker> and just to solidify my denseness: what is the benefit of removing any statement about having a verification component return a result?
[11:23:49] <eric> beats me.
[11:23:58] <thomasm> it just reads awkwardly
[11:24:05] <eric> i just go with the flow.... OM.....
[11:24:43] <thomasm> are we done here?
[11:24:47] <sftcd> we got rid of an unnecessary MUST, which is good
[11:24:49] <eric> dave?
[11:25:05] <eric> well, except that if a verifier does anything else, we might as well toss the whole thing.
[11:25:09] <dcrocker> it probably isn't clear why I am pressing on this, so:
[11:25:39] <dcrocker> the spec currently tends to conflate some higher level systems stuff with lower level component stuff. I believe we are in the midst of one of those. Hence
[11:26:09] <dcrocker> If verifying a single signature is viewed as a component of the larger process, then it is pretty darn strange to not have the component return a result. /
[11:26:34] <thomasm> I believe "the signature verifies" does exactly that, at least to my taste
[11:26:55] <eric> Personally, I think it would be clearer if we retained the "return OK" wording.
[11:27:06] <dcrocker> "signature verifies" states what happens inside the verification component. not what is communicated as the result.
[11:27:16] <eric> but people dislike the MUST, even though an implementation MUST do it this way in order to get anything meaningful.
[11:27:31] <thomasm> we're not "communicating" anything in the receiver
[11:27:37] <thomasm> that's an internal thang
[11:27:49] <eric> i would rather have an unambiguous albeit awkward reading sentence than something unclear.
[11:27:57] <Barry Leiba> On "communicating", let me clarify something...
[11:27:57] <sftcd> (an implementation could go through all signatures and return an array of OK/fail - what's wrong there?)
[11:28:03] <dcrocker> Let's be clear that "people dislike" is constrained by how few folk are here and that all of the folk here are painfully familiar with the detail. We need to worry about other readers.
[11:28:15] <dcrocker> eric: +1
[11:28:27] <eric> Stephen: the algorithm discussion is for a single signature at this point.
[11:28:37] <eric> next level up looks at a set of signatures.
[11:28:41] <Barry Leiba> I see this set of steps as "verifying ONE signature is done like this", inside of some sort of "verify the signatures" loop.
[11:28:55] <paulehoffman@jabber.org> We are describing both process and requirements, and mixing the two together.
[11:28:59] <sftcd> and that's fine, but the "level" thing should be left to coders if possible & it is posible here
[11:29:02] <eric> if you will, section 6 (no dots) is the "set" part, and 6.x is per-sig.
[11:29:04] <dcrocker> barry: i see it that way too, but I do not believe it is WRITTEN that way.
[11:29:20] <eric> semantics != implementatin.
[11:30:03] <eric> but in looking at it, I do see that we have an unclear differentiation between the set versus teh single sig.
[11:30:21] <eric> i can fix this, but it probably makes section 6 go three levels deep instead of two. are people ok with that?
[11:30:36] <thomasm> that's the only that concerned me... all the rest of the wordsmithing is fine to be resolved however
[11:31:02] <paulehoffman@jabber.org> Eric: I'm OK with three levels if it makes the need to do processing on each sig clearer.
[11:31:09] <sftcd> for me too
[11:31:11] <thomasm> +1
[11:31:22] <dcrocker> +1
[11:31:28] <eric> ok, let me try to do that today before i hop on a plane this afternoon and get it out to the list.
[11:31:37] <jrlevine> +1, need three levels for multi-signature loop
[11:31:53] <Barry Leiba> OK... Section 6.3, Eric will reword, hopefully today.
[11:31:58] <Barry Leiba> Onward...
[11:32:10] <eric> actually it will be a bunch of section 6.
[11:32:13] <eric> but mostly 6.3
[11:32:26] <eric> OK, sticking with the same topic, but going back to the top of section6
[11:32:40] <eric> fourth paragraph.
[11:32:51] <eric> nix that
[11:32:58] <eric> that will fall out from the rewording I do today.
[11:33:23] <eric> OK, still in section 6, "MUST perform these steps in order"
[11:33:40] <eric> changed to "Verifiers MUST produce a result that is semantically equivalent to applying the following steps in the order listed. In practice, several of these steps can be performed in parallel in order to improve performance."
[11:33:48] <sftcd> nice
[11:33:59] <paulehoffman@jabber.org> Works for me.
[11:34:08] <jrlevine> Now that the failure codes are all the same, it works.
[11:34:09] <thomasm> +1
[11:34:20] <doug_trendmicro@jabber.org> +1
[11:34:24] <Barry Leiba> No objections?
[11:34:36] <Barry Leiba> OK, onward...
[11:34:43] <eric> OK, I guess this is a CLOSE item "D": http://mipassoc.org/pipermail/ietf-dkim/2006q2/003759.html
[11:34:49] <thomasm> eric: on tfail is should that be SHOULD or MAY on reprocessing?
[11:35:14] <eric> that's a different item, right? not about MUST perform in order
[11:35:23] <thomasm> yes
[11:35:40] <eric> current wording is "SHOULD"
[11:35:50] <eric> (sec 6, para 4)
[11:36:00] <thomasm> I'm not sure we know enough?
[11:36:08] <thomasm> should seems a bit strong
[11:36:16] <paulehoffman@jabber.org> What is the interop or security reason for that SHOULD?
[11:36:24] <eric> interop:
[11:36:45] <thomasm> but there could be a security reason to _not_ do that
[11:36:45] <eric> if a sender's name server is inaccessible at the moment, you would still like the message to go through later when it comes back up.
[11:36:52] <thomasm> from a dos standpoint
[11:37:05] <eric> then all temp failes become perm fails.
[11:37:09] <paulehoffman@jabber.org> That's not interop, that's operations.
[11:37:28] <paulehoffman@jabber.org> It should probably be a MAY with an explanation why you should try again later.
[11:37:37] <Barry Leiba> We should move through these more quickly, if we can...
[11:37:39] <thomasm> I"m just saying that a normative SHOULD means that we'll have everybody retrying, and I'm not sure we
[11:37:47] <thomasm> have enough information to know whether that's good or not yet
[11:38:04] <eric> fine, fine. barry's right. i'll change it to a MAY (let the record show that i disagree). let's move on.
[11:38:06] <Barry Leiba> Looks like Paul and Mike both think "may".
[11:38:17] <jrlevine> make it MAY, if an MTA author doesn't know how to retry a soft fail, we're not going to teach him
[11:38:34] <dcrocker> confused again: "reprocessing"? what text is being discussed?
[11:38:47] <eric> section 6, para 4
[11:38:55] <thomasm> on key unavailable due to dns tmo, for example
[11:38:55] <eric> discussion of TFAIL\
[11:39:05] <doug_trendmicro@jabber.org> Tfail on signature verification.
[11:39:11] <Barry Leiba> Are we also talking about 6.2 item 2?
[11:39:25] <eric> looks like it
[11:39:29] <jrlevine> yes, they better match
[11:39:50] <Barry Leiba> It certainly seems to me that MAY works here.
[11:40:02] <Barry Leiba> The verifier can decide whether to retry or to ignore the sig.
[11:40:43] <eric> can we move on?
[11:40:46] <thomasm> yes
[11:40:53] <Barry Leiba> Dave, you OK?
[11:40:56] <sftcd> +1
[11:41:33] <Barry Leiba> All right, we have to move on. Next?
[11:41:35] <dcrocker> barry, i don't know that's i'm fully understanding, but this doesn't seem to excite my concern, so let's move on.
[11:41:35] <eric> ok. next one is easy (I hope): Section 6.6 (MUA Considerations) now Section 7.
[11:41:57] <sftcd> good - better split that way
[11:41:58] <paulehoffman@jabber.org> +1 on splitting it out.
[11:42:03] <thomasm> +1
[11:42:03] <doug_trendmicro@jabber.org> +1
[11:42:11] <jrlevine> +1 on splitting it out
[11:42:23] <eric> OK, done. I don't think we had an item number on that.
[11:42:23] <dcrocker> Having anything normative about the MUA is a mistake.
[11:42:31] <jrlevine> last sentence of pp 1 and last pp sort of say the same thing, edit one out?
[11:43:08] <eric> OK, I'll drop last para.
[11:43:24] <Barry Leiba> Dave: I think it's reasonable to say that if the MUA claims to support this, this is what it has to do.
[11:43:31] <Barry Leiba> No?
[11:43:43] <eric> Alternative is to move it to an appendix
[11:44:11] <dcrocker> By the way, the opening sentence of 7 is wrong. Nothing we are doing affects the semantics of the From field, so it does not make sence to claim that we are doing recommending something to "retain" it.
[11:44:39] <dcrocker> Barry: actually no it doesn't. We know virtually nothing about what is effective for MUA display, so it is a serious mistake for us to try to dictate what should be done.
[11:45:08] <eric> dave: huh? i don't see that it says anything about the semantics of From, just how it really ought to be displayed.
[11:45:18] <jrlevine> does this belong in a companion implementor's guide or BCP?
[11:45:39] <dcrocker> Eric: "In order to retain the current semantics"
[11:45:41] <thomasm> I'm sort of Dave -- this section should all be informative if here at all
[11:45:59] <eric> i'm getting very concerned that we are slowly and for the best possible reasons emasculating -base.
[11:46:24] <eric> i'll move sec 7 to an appendix, but i strongly resist moving it to another document.
[11:46:28] <dcrocker> 1. I've heard (frankly predictable) comments that systems which modify the displayedFrom field, to show the different identities involved, confused the heck out of users.
[11:47:07] <jrlevine> that would be Outlook?
[11:47:07] <doug_trendmicro@jabber.org> Earthlink had a bad experience in that area.
[11:47:08] <dcrocker> 2. What should be displayed to users requires being extremely careful about their expectations, knowledge, and cognitive load. Directives such as we have in the current text ignore pretty much all 3.
[11:47:28] <doug_trendmicro@jabber.org> Support calls asking why the mod.
[11:47:59] <eric> i guess there is no such thing as an "easy" item......
[11:48:02] <dcrocker> Let me be more concrete: The "might be" example that is shown is counter-productive, for average users.
[11:48:45] <sftcd> maybe make it an appendix and raise a new issue about its content and move on for now?
[11:48:51] <dcrocker> +1
[11:48:55] <sftcd> (if so, who'll raise the new issue?)
[11:49:18] <eric> OK, I'll try to blanderize it so that i won't tread on any sensitive toes.
[11:49:29] <eric> and move it to an app, of course.
[11:50:00] <jrlevine> emphasize what info is available, but not what to do with it, since we know the former but not the latter
[11:50:15] <dcrocker> john: +2
[11:50:22] <dcrocker> (+2 is stronger than +1)
[11:50:23] <doug_trendmicro@jabber.org> +1
[11:50:45] <eric> In that case, let's just drop it entirely. don't bother giving any guidance at all.
[11:51:18] <eric> if it can't talk about possible alternatives about how to present it to the user, there's nothing left in the section.
[11:51:38] <dcrocker> yup.
[11:51:48] <doug_trendmicro@jabber.org> It might be good to have a separate draft to better cover the issue.
[11:52:25] <eric> i think this is a remarkably stupid idea, but i'm just the editor; the WG gets to decide. I'll pull it out entirely.
[11:52:43] <paulehoffman@jabber.org> Eric: you don't have to go that far.
[11:53:01] <dcrocker> eric: you would rather give MUA guidance that is likely to be incorrect and possibly even damaging to usability?
[11:53:01] <eric> why not? if it can't talk about how to present things, then there is literally nothing left in the section.
[11:53:20] <paulehoffman@jabber.org> What John said is correct: it is useful to say what information is available so that an MUA developer will think about it.
[11:53:26] <jrlevine> we can talk about what to present
[11:53:38] <jrlevine> not how to present
[11:53:57] <Barry Leiba> Does it make sense to word it non-normatively and put it in an appendix?
[11:54:29] <doug_trendmicro@jabber.org> I think John is right.
[11:54:31] <eric> The new section will read something like "MUA writers might, if they feel like it, want to consider presenting some of the signature information to end users in some way that is beyond the scope of this document."
[11:54:53] <eric> Literally.
[11:55:02] <thomasm> Eric, considerations are just that.
[11:55:17] <thomasm> if it says anything, it needs to say what they should be cognizant about
[11:55:22] <thomasm> not what they should do
[11:55:28] <paulehoffman@jabber.org> Eric: also about l= truncations.
[11:55:46] <eric> I could expand on "For example, perhaps the MUA would like to make the identity of the signing user available, perhaps showing unsigned content. Or maybe not. Or maybe something else. We don't know."
[11:56:23] <eric> To tell MUA users what to present is just as presumptuous as suggesting to them ways they might present it.
[11:56:24] <thomasm> this does tread a lot into bcp land -- for which we don't have b's and c's yet
[11:56:26] <paulehoffman@jabber.org> Eric: would you like someone else to make a stab at the section? You don't sound like you want to. :-)
[11:56:38] <Barry Leiba> Paul's suggestion sounds good.
[11:56:42] <Barry Leiba> Paul, you volunteering?
[11:56:57] <sftcd> sounded like it
[11:57:08] <Barry Leiba> We have to wrap this up at 1600 UTC (< 5 mins).
[11:57:20] <paulehoffman@jabber.org> I am, but only if Eric is OK with it. I am not suggesting I grab this from him.
[11:57:23] <Barry Leiba> SO we're still not going to get to the three remaining items from last time.
[11:57:25] <doug_trendmicro@jabber.org> Heck
[11:57:27] <eric> I'm OK.
[11:57:42] <sftcd> meet again Thursday to cover those?
[11:57:43] <Barry Leiba> OK... Paul will take a stab at this and send text to Eric.
[11:57:54] <paulehoffman@jabber.org> OK, I'll be OK with you and will send it off today you can can get it into -03.
[11:58:02] <Barry Leiba> Eric will be absent on Thursday, but we can still cover the three missing items.
[11:58:03] <eric> I doubt that I'll be able to be available on Thursday.
[11:58:32] <eric> There are still two points on 003795: intro and timeout wording. should go on the list.
[11:59:26] <paulehoffman@jabber.org> I thought your timeout wording matched what people had asked for before. Suggestion: put it into -03 and let us talk about any issues then.
[11:59:27] <Barry Leiba> OK. I think we thrashed a lot on this jabber. Ah, well. We'll meet at 1500 UTC on Thursday and see where we can get then.
[11:59:45] <doug_trendmicro@jabber.org> Ok.
[11:59:56] <Barry Leiba> Stephen says he's OK to extend Thursday for even 2 hours if people want to.
[11:59:57] <sftcd> type to ya then
[12:00:10] <eric> bye all
[12:00:21] <Barry Leiba> We'll post to the list about it on Wed. See you on Thursday.
[12:00:32] * Barry Leiba has changed the subject to: DKIM meeting adjourned
[12:00:57] --- jrlevine has left
[12:01:01] --- sftcd has left
[12:01:04] --- doug_trendmicro@jabber.org has left
[12:01:24] --- paulehoffman@jabber.org has left
[12:02:31] --- Barry Leiba has left
[12:10:22] --- thomasm has left
[12:10:45] --- eric has left
[13:54:47] --- dcrocker has left
[14:15:54] --- dcrocker has joined
[14:35:10] --- dcrocker has left: Replaced by new connection
[14:35:11] --- dcrocker has joined
[14:41:15] --- dcrocker has left
[14:52:25] --- dcrocker has joined
[15:23:47] --- dcrocker has left
[15:27:19] --- dcrocker has joined
[15:53:34] --- dcrocker has left
[17:25:17] --- eric has joined
[17:29:47] --- dcrocker has joined
[17:36:07] --- dcrocker has left: Replaced by new connection
[17:36:07] --- dcrocker has joined
[17:47:59] --- dcrocker has left: Replaced by new connection
[17:52:11] --- eric has left
[18:00:02] --- dcrocker has joined
[18:51:38] --- dcrocker has left
[18:54:40] --- dcrocker has joined
[19:51:15] --- dcrocker has left