Ned,
On 28/Jun/10 18:15, Ned Freed wrote:
On 27/Jun/10 19:41, John C Klensin wrote:
Speaking for myself only, the changes called for by this group
and the preevaluation documents so far would probably be
time-consuming to get right (and get agreement that they are
right) and would undoubtedly improve the quality of the
documents, they are, in the grand scheme of things, largely
cosmetic.
It's actually even worse than that - we are effectively enjoined by our charter
to only make cosmetic changes. IMO such changes only make the cost-benefit cut
if they provide the added benefit of moving things to standard.
Issue #5[1] is even less than "cosmetic", I guess...
May I ask whether RFC 5321 contains text that prevents policy
specifications? If not, why both SPF and ADSP wrestle with the issue
of not mandating recipient's behavior, to the point of avoiding to
mention what would be expected? I've heard generic explanations, but
never really understood why, say, RFC 5617 has to be more obscure than
the corresponding Wikipedia page[2] on the term "discardable"[3].
Specifically, little or no evidence has been offered
that the present text is causing serious implementation or
interpretation problems. Even if such evidence appeared around
a few points, the problems could be solved with short and
focused documents clarifying those particular points rather than
revising and reissuing the base specifications.
Bingo. And this is a bit of a cononudrum: If something in a document is causing
interop problems, it is by definition not a cosmetic issue, and exceeds the
purview of this group to address.
A change spelling how email policies should be worded would be far
better than cosmetic. It would be revolutionary, given the current
state of affairs. Yet, it would not directly cause interop problems.
My reading of the tea leaves says that this time may be different. As long as
the proposal is simple, clear, and crisp - a property most of the past
efforts have not managed to have - I think there's a nonnegligible chance we're
going to be looking at a two step process in the not too distant future.
+1, unless you think the change above alluded to could be feasible.
--
[1] http://trac.tools.ietf.org/wg/yam/trac/ticket/5
[2] http://en.wikipedia.org/wiki/Author_Domain_Signing_Practices
[3] http://mipassoc.org/pipermail/ietf-dkim/2010q2/013746.html
and http://mipassoc.org/pipermail/ietf-dkim/2010q2/013751.html
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
