I have a few chair notes to make, based on some things that have
recently been said in discussions. I think these are all procedural
things, and I ask that participants not argue the points I'm making
here as technical positions (I'm simply using these as examples). If
I say that we *can* say something or other, I mean it from a
procedural point of view; the working group has to decide, given those
procedures, what it *does* want to say.
-----
Comment 1:
Let me clarify my statements. My point was that re-opening ADSP was not
part of the re-charter so unless the group feels it is important to
change ADSP we should stick to discussing the Lists BCP based on the way
that DKIM and ADSP are currently written.
I don't believe this is true. The proposed charter has this:
3. Collect data on the deployment, interoperability, and
effectiveness of the Author Domain Signing Practices protocol
(RFC 5617), and determine if/when it's ready to advance on the
standards track. Update it at Proposed Standard, advance it to
Draft Standard, deprecate it, or determine another disposition,
as appropriate.
As I understand it (and as I meant it when I wrote it down), it *is*
within the charter, as we develop experience with ADSP and operational
data to support that experience, to change ADSP.
Again: I'm not saying whether we *should* change it or not. But it is
within the new charter to do so.
-----
Comment 2:
Entirely agreed. As this point the only concrete datum I'm aware of
is that ADSP has been observed to break IETF mailing lists. I would
want to see a lot more practical as opposed to hypothetical experience
before offering further advice.
It is on the charter to get experience and to have concrete data
behind it. We are supposed to be doing that, and we should, and I
absolutely agree that data beats speculation.
That said, it is reasonable to establish rough consensus that certain
advice is good, and to put that advice into an informational document
or a BCP (and see comment 3). Advice backed by hard experience, with
data to support it, is best. Advice based on informed expectation,
which nevertheless might turn out to be wrong, is still valid advice,
though it should be clear what the difference is.
-----
Comment 3:
I guess we can't claim that it's common practice, never might best common
practice. But it is, surely, a good idea.
Not everything in RFC 4871 is normative; there are non-normative
explanations and suggestions there. Similarly, a BCP can certainly
contain non-"normative" stuff, stuff that isn't known yet to be
"best", "current", or even "practice". It needs to be clearly
labelled as "best current speculation", or whatever, but it can be put
into the document.
We do need to be careful about this, though.
-----
Comment 4:
Most lists will break signatures, for a variety of reasons that aren't
going to change, starting with subject line tags.
That something has been done a certain way for years, for decades, or
forever, is not a reason for us not to recommend against it. Things
have changed a great deal over time, and common, even ubiquitous
practices of older days have disappeared when better mechanisms have
appeared, or when those practices have caused difficulties based on
new features.
It is absolutely within scope to say that mailing lists and mail
clients should change in order to allow us to take full advantage of a
great new feature we're enabling... if it is the consensus of the
working group to say that. It is, of course, also within scope to
express the opinion that it's a bad idea to say that. Rough consensus
will decide which way we actually go.
For example, suppose we decided to recommend the following:
1. MUAs SHOULD use the List-ID header, if it is present, to display
"[listname]" at the beginning of the subject line, if there is not
already a bracketed string there.
2. MLMs SHOULD incorporate the List-ID header, and SHOULD NOT prepend
"[listname]" to the subject line, nor change the subject line in any
other way.
3. Mail filters SHOULD allow filtering on the List-ID header.
That would be a valid thing for us to put in the BCP (*if*, again, we
had consensus that that's what we wanted to say). Some participants
might think it's stupid, because compliance will just never happen,
and they are welcome to express that opinion. It'd be nice, though,
if discussion avoided words like "stupid", hm?
-----
Please just take this in and don't waste time discussing it, unless
you really think I have made a procedural blunder here. Even in that
case, maybe take it up with Stephen and me off-list first, at
<dkim-chairs(_at_)tools(_dot_)ietf(_dot_)org>. Thanks.
Barry, as chair
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html