[rfc-i] Fwd: Pre-IETF RFCs to Historic (not really proposing)

Frank Ellermann hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail.com
Sat Sep 17 13:34:31 PDT 2011


On 16 September 2011 21:48, Fred Baker wrote:

> If I now have yet another email address that is more likely to
> actually reach me than some other might, I can think of an entire
> industry that would like to know that. And by the way, would
> happily send mail *from* it.

Wrt MAIL FROM nslookup -q=txt ietf.org is satisfactory (SPF FAIL).
The opposition also cannot produce a DKIM signature for ietf.org,
the best they can achieve is an SPF PASS and DKIM signature for
some spammer domain with a 5322 From: you at ietf

Any @ietf.org address is *better* protected than softfail at paypal
or softfail at cisco, let alone neutral at gmail.

> Hence the model of an introduction service that leaves me as the
> author in the position of choosing to engage or to not engage, and
> from what address I might be willing to engage.

Okay, that is a different issue, authors should be free to "forget"
a published IETF RFC when they don't care about it any more:  After
all "the IETF" accepted it at some point in time, and is responsible
for it "forever".  Unless it is "obsoleted by XXXX" or "historic".

After I figured out that "son-of-1036" isn't an Internet Standard,
but only an expired draft (plus similar misconceptions wrt SMTP and
news URIs on my side) it was rather hard to sift through dozens of
RFCs and expired drafts in an attempt to reconstruct "the truth".

Anything clearly stamped as expired or obsolete or historic helps,
even if "expired" turns out to be what everybody actually does.

Likewise published errata can help, it is just bad if examples for
convoluted calculations of say UUID v3 in published RFCs are wrong.
That most editorial errata are irrelevant for implementors is no
problem.  Unverified technical errata are not optimal, but they are
at least a hint that something might be not as it should be.

-Frank


More information about the rfc-interest mailing list