Pete,
On 10/26/2011 6:16 PM, Pete Resnick wrote:
You have just defined an interoperability criterion that includes all sources
of software misbehavior, daemon sleep times, and anything else that can cause
delays.
I notice you conveniently snipped my example of using a status code that caused
I clipped enough to provide context for my reply. No other intent was present.
If I snipped too much, please add it back and explain its relevant. (Your
observational text about the snipping didn't explain the relevance.)
trouble. But yes, timeouts are commonly put into standards track documents, and
reasonably so. Implementation parameters do cause interoperability problems and
many of those are observable from the net. I have no idea how you can claim
these aren't "interoperability criteria".
The new work does not change the protocol definition, including timeouts. It
works in the grey area of operational choice. Operations, not protocol.
Operations = practice.
Let's go back to my initial claims: If it implementation experience would cause
changes to the instructions we give in a document to implementers, then it
deserves to be on the standards track. If it's a "protocol, service, procedure,
convention, or format" [2026, 3.1], it belongs in a technical specification. If
We have a very consistent tendency in the IETF to argue only one side of an
issue and to quite literally ignore or flatly deny counter-points. To remedy
that, in this case:
RFC 2026, Section 5:
"The BCP subseries of the RFC series is designed to be a way to
standardize practices...community's best current thinking on a statement of
principle or on what is believed to be the best way to perform some
operations or IETF process function."
Anyone who thinks that the IETF's use of the words procedure, convention and
practices are completely precise and completely orthogonal should please let me
know what their repertoire of drugs is, because I really would like to see the
world that way. Absent the drugs, the world we are living in is rather more
messy and ambiguous than your line of argument would suggest.
Equally, I suggest that the draft under consideration is a "way to perform" SMTP
processing. It does not change SMTP at all, but pertains to internal
operational issues in HOW the protocol is used, not in WHAT is does.
it gives implementation instructions (values for parameters, how the protocol
ought be implemented, etc.), then it belongs in an applicability statement. Both
TSs and ASs go on the standards track.
Now is the time for noting that the suggestion to use Applicability Statement is
rubbish. ASs are not used and have no practical meaning in the current IETF.
They were a fine idea. I wish they had succeeded. But they didn't.
You are encouraged to demonstrate that my perception is incorrect, such as by
citing a /pattern/ of AS assignments over the last 5 years and by describing
their real-world utility. To the extent that you wish to change the reality of
their non-use, please do it through a collaborative process that gets people to
sign up for it before risking their work with a process experiment, rather than
by suddenly foisting it on a document not intended for the process experiment.
Greylisting is far more obviously a protocol with testable interoperability
than is, say, RFC 5234 or 5322.
[To clarify: I am not committed to greylisting being a protocol. I'm just saying
it looks more like a protocol than do 5234 or 5322. It is the claim that there
is no way to test interoperability that I reject..]
5234 and 5322 define things that need direct processing by whoever receives the
data. There is no intermediary. The interaction between data generation and
data parsing/processing is exactly that, an interaction. In addition, some of
the data with 5322 specify actual, honest to goodness protocol behaviors.
Reply-to directs the construction of a portion of a new email message, for example.
The effect of the proposed capability, in contrast, is entirely indirect. It
does not define a new format or a new protocol command or a new protocol
response. Rather, it uses /existing/ ones in a particular way. As such, sorry,
but those other specs are "more like a protocol" than this one is.
5322 and other format specs explicitly entail parsing and processing (and in
the case of From: and Reply-to:, replying) by the remote engine. That's
essential interoperability.
How does one "test interoperability" in the case of parsing that is going on in
a local implementation like 5322? How is that different than greylisting? And
for ANBF...?
You think that the inability to produce a successful parse of data does not
demonstrate an interoperability failure?
In other words, formats are inherently bilateral. Greylisting is unilateral.
Formats are bilateral, but only in the sense that both sides have a common
understanding of the semantics of the parsed format.
That 'only' is pretty substantial, since its the essence of interoperation.
Greylisting is bilateral
for those who actually participate: That is, if I receive 4xx status code, I
know to wait a while and resend.
That's a requirement for processing SMTP. The client SMTP is not required to
know or care that greylisting is happening. As such, the client SMTP engine is
not "participating" in greylisting. It is participating in SMTP.
Successful delivery happens if we both do our
parts correctly. It is certainly the case that if I am a poorly implemented SMTP
client, I will not try again and my mail will not be delivered (the point of the
That's an SMTP failure, whether greylisting is being done by the server SMTP or
not.
Note the key point: The success and failure conditions you cite apply to ANY
SMTP interaction, independent of greylisting. As such, they do not test
greylisting "interoperability".
Again: since my view is rubbish, please define an interoperability test for it.
(I don't think I am making any statement about *your* *view*. I apologize for
this coming across as a personal attack. I used "rubbish" only to mean, "I
Well, I was the one who introduced the personal language in that last round but
it wasn't intentional. I am concerned with calling the substance rubbish, not
the speaker. (I am pretty sure that I was vetted as rubbish long enough ago and
publicly enough to make it a waste of everyone's time to repeat it now, so it
didn't occur to me that that might have been what you intended...)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net