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

[Ned Freed <[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...

Absent evidence showing this has been a real source of problems - which AFAIK
has not been provided - yes, it's a cosmetic change. A good change to make,
sure, but fixing such a minor matter doesn't even come close to making it worth
the trouble of republishing a core specification.

> May I ask whether RFC 5321 contains text that prevents policy
> specifications?

Not that I know of. The effective block on detailed policy specifications
arises from other sources.

> 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?

Because there's no consensus on what that mandatory policy should be. Heck, we
cannot even manage to publish a specification that says when it's appropriate
to place blocks on port 25. Such a specification would do more to combat psam
than SPF or DKIM ever will.

Like it or not, the lack of "clarity" in the specifications regarding policy
choices for the players in pretty much every possible role is 100& intentional.
And changing it is certainly not a cosmetic matter. But even if it were - even
if it were in scope for us to mess with - I see no indication that we're any
closer to achieving the necessary consensus to make such a change.

And you certainly cannot fix this through specification clarification. You seem
to believe that the problem is due to misinterpretation of confusing
specifications. It just isn't. Yes, there are those who play
specification-mining games to justify their positions on such matters, but
attempting to address this quickly turns into a game of whack-a-mole. And even
if it were possible to write specifications that made this sort of thing
impossible, it would at most remove one tool from the objector's toolset. It
would not change their minds.

> 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].

Because the minute you try and travel down that path, you run into those who
still believe that "every email is sacred" or something along those lines.
Basically, we're dancing around the fact that 90% or more of the email that's
sent today ends up being silently discarded. This is reality, and while it
seems exceptionally foolish to me not to acknowledge it, a nonnegligable number
of people don't approve of specifications that even condone such actions, let
alone actively encourage them.

> >>  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.

What would be revoluationary would be the formation of a real consensus on such
issues.

				Ned