Re: [yam] Referencing 1652bis and update to RFC 5321/5322

[Alessandro Vesely <[e-mail]>]

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