On 07/Jul/11 16:13, Dave CROCKER wrote:
> On 7/7/2011 6:57 AM, Murray S. Kucherawy wrote:
>>> I'd s/to be liberal/to be exceedingly liberal/ (we don't want to revise
>>> Postel's statement, do we?)
>>
>> You're either liberal in your application of the RFCs, or you're not. I
>> don't see how adding that word improves things here.
>
> well, it keeps the thread going...
You /have/ to be liberal, but that can be limited in degree and in
time. An app must be liberal in what it accepts, not only because a
specification is subject to some variance in interpretation, but also
because of unavoidable time differences in its adoption. Since no RFC
can be transmitted faster than the speed of light, a host which
adopted an RFC at time t0 (see graph) has to wait at least until time
t2 before a compliant signal from a distant source may reach it.
^
| time
| X________________t2 (RFC-compliant signals
| |\ may reach the host
| | \ from the distant source)
| | \
| | \
| | \ .
| | \ .
| | \ .
| . | \________t1 (RFC reaches signal source)
| . | /
| . | /
| \ | /
| \ | /
| \ | /
| \ | /
| \| /
| \/_______________t0 (RFC reaches the host)
| /\
| /| \
| / | \
|\ / | \
| \ / | \
| \ / | \
| \ / | \
| \ / | \ space
+-----X-------X--------X------------------------------------>
RFC- host signal
Editor source
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
