On 6/29/2018 8:13 AM, John Levine wrote:
In article <CABuGu1rh7sjVQQPwUdySE9v4xFEa2=drsfiawirk1w8d6fv...@mail.gmail.com>
you write:
Anything that comes close to 'do whatever you want with this
information' demonstrates NON-standardization.
Not at all. The point of a standard is to say here is what you do if
you want to interoperate. Trying to figure out how to recover when
someone else doesn't follow the spec is a fool's errand, since there
are more ways to misimplement a spec than any of us can imagine.
Your first sentences asserts disagreement, but I don't see how the rest
of the paragraph provides it, since it both looks reasonable and doesn't
seem to contradict what I said.
In any event, my language was carelessly broad and probably misdirected,
so it might be worth some clarification and better precision:
1. A protocol specification defines a space to work within. If you work
outside of that space, your activity has nothing to do with that spec.
2. If you are purportedly working within that space but take actions the
deviate from prescribed actions (or include proscribed ones) then you
really are violating the spec. So one of my points is that a
specification has an obligation to specify actions that are clear and
precise and reasonable. For all actors.
3. Not all protocol details are about actions. The ones about formats
do not necessarily couple with directives about actions; that is, a spec
might define syntax and semantics without saying what is to be done with
the data. But specifications of formats, too, have an obligation to be
c-p-r. Although there are situations that justify common packaging for
'private' information -- that is, non-standardized data inside a
standardized container -- the usual case imposes standards on the data
semantics too. That goes to the other point I meant to make: A
specification that basically says that data may be interpreted in
whatever way the receiver wants is not specifying a standard, because
the encoder has no way to predict how the decoder will interpret it.
(This was at the core of the DKIM d=/s= debate.)
I suppose we could put in a sentence or two reminding people that
unlike DKIM, the list of tags in the spec are the only ones allowed in
an ARC header, so don't try to invent new ones.
That's a major decision to make. It impedes innovation, so it should be
justified pretty carefully. In the text.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
