Before I get into the summary of the jabber meeting, I want to say this:
We finished getting through the open issues, and there are just a few
that need more discussion on the list. I've asked Eric to work on
getting an -03 version out, after mailing list discussion of those few
issues, within two weeks. That means that (1) everyone MUST read -02
and make sure that it's ready (modulo these few open items), and (2) we
must get these last few items discussed and sorted through, and we must
all focus on resolving our differences on them and finding a consensus
that we think works. Please hold to hard lines at this point only when
compromising on that item will truly be harmful. I know we can get this
wrapped up and ready for Working Group Last Call on the -03 version of
the document!
-------------------------------------------------------------------
We called today's jabber session to order today at 15:00 UTC, and went
through the remainder of Eric's issues list, starting where we left off
last week. Eric's list does mostly match with Eliot's, and we referred
to Eliot's for the details of the issues. For reference, some pointers:
Last week's log:
http://www.ietf.org/meetings/ietf-logs/dkim/2006-05-18.html
This week's log:
http://www.ietf.org/meetings/ietf-logs/dkim/2006-05-25.html
Eric's issues list:
http://mipassoc.org/pipermail/ietf-dkim/2006q2/003640.html
In attendance:
Barry Leiba, Stephen Farrell, Paul Hoffman, Doug Otis, Peter Koch, Eric
Allman, Mike Thomas, Jim Fenton, Dave Crocker, Tony Hansen, Bill Oxley.
The bits in quotes at each issue title are quoted from Eric's list.
Issue 1263: "(get rid of x=): I /think/ this has been resolved."
Participants did, indeed think it has been resolved; issue should be closed.
Issue 1264: "(proposed fingerprint tag description)."
This was proposed by Murray, who wasn't on the jabber chat, and the
participants didn't know enough about it to discuss it in Murray's
absence. Issue remains open; push it back to the mailing list.
Issue 1265: "(signing by parent domains)."
Some see potential issues with the ability to say something like
"d=example.com" and "i=sub.example.com". In particular, there's the
danger of something like "d=com; i=example.com". Some think there's
little benefit to allowing it, and closing the hole would be better.
Others see a great benefit, allowing example.com to have one place to go
for keys, while signing for many subdomains. Eric suggests this:
"thought: a domain could use a CNAME for _domainkey.<dept>.example.com
that would point up the tree." Jim Fenton will start a thread about this
on the mailing list. No resolution for now; leave open, discuss on
mailing list.
Issue 1266: "(sec 5.2 move recommendations for key retention to a BCP)."
Lots of discussion about whether to specify a length of time or be vague
about it, whether being vague is of any value to implementors, and
whether it even makes sense to try to tell verifiers what they MAY or
SHOULD do, since they can (and will) do whatever they want anyway. In
the end it seems that a modification of Doug's proposed rewording can be
acceptable to all, so Eric is going to do another pass on the wording
and post it to the mailing list. Issue remains open until then.
Issue 1267: "(expiry based on received time rather than current time)."
Doug is happy with what's in the -02 draft on this, and no one else
voiced any concern. Close.
Issue 1268: "(format of t=)."
The issue is whether to leave this as an integer representing seconds
since 1970, or whether to change it to some more readable version, which
might be easier to compare with other fields in the message. Brief
discussion, which included a "not broke, don't fix it" comment. Chairs
agree and suggest no change unless there's a "really good reason to
change it." Much agreement, and no "really good reason," so issue is
closed with no change to the spec.
Issue 1269: "(body length mechanism rejections)."
Looks like we're happy with what's in -02, but just as we start to move
on there's more discussion along the "can't tell verifiers what to do"
line. The original issue was an objection to advising verifiers to
"reject", and the consensus on that, as advice, stays. In particular,
we want to advise verifiers on determining whether a signature is
*valid*, but leave the "what to do with it" part for another document
(or local policy). Tony doesn't like the advice to ignore the
signature. Others clarified that what we're really saying is to look at
the other sigs in that case. Most accept current wording, but there's
some unhappiness all 'round, so it's not optimal. Dave and Eric will
collaborate on another iteration of this text, to try to resolve that
and to make it clear what's normative and what's a recommendation.
Issue remains open.
Issue 1270 is an error -- title duplicates 1269, content duplicates 1271.
Should be deleted.
Issue 1271: "(Binary algorithms and algorithm spoofing during a
transition.)"
Little discussion, no support for Doug's position ("No one else thinks
this is a problem."). Close.
Issue 1272: "(when i= domain != d= domain)."
Everyone is happy with Doug's proposed change, but Jim points out that
issue 1265 affects this. Consensus to accept this now, with the
realization that the whole text may change again depending upon what we
decide about 1265. Eric notes that this change is already in -02.
Issue 1274: "(r= for instilling good domain-name practices)."
Consensus that (1) there's no support on the list (nor on the jabber
chat) for this, and (2) it can be added later if we decide it's needed,
so it needn't be done for -base. Mostly, there was some sympathy for
wanting a distinction between "I vouch for it," and "It came from my
domain, but I don't vouch for it." It's just that there's skepticism
about whether it belongs here, as opposed to in a reputation service.
Close this one.
The jabber meeting was adjourned at 16:02 UTC, with thanks to all for
participating.
We're planning another for next Thursday, same Bat time, same Bat
channel. We'll review, at that time, progress on the issues that have
been sent back to the mailing list, and see where we are on preparing
-03 for WGLC.
-------------------------------------------------------------------
Barry Leiba, DKIM Working Group Chair (leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html