Eddy,
> What I was referring to is that you said:
>
> If for some reason the other party doesn't
have the
> same default (bugs
happen), negotiation should drive
> both parties to an agreed value
...
>
> Reading on I assumed you meant that we should
add code to cope with that.
> If you take that to an extreme, we would be
adding “lots of code” just to cover all possible bugs.
That was definitely not my intention. If either
party chooses to negotiate a value, the negotiation
code that has to be implemented anyway
will drive both parties to agreement, but notice the
*if*.
I definitely do not want this taken to an
extreme that would require all keys to be negotiated in
all cases. As a consequence,
there will be situations in which mistakes occur that cause
the
two parties to have different ideas of what
the default value is for a key that wasn't negotiated
(to err is human, most code is written by humans
... ). I am recommending an "if in doubt,
negotiate" approach to implementation that will
tend to limit such problems to relatively
unimportant keys. Coverage
of "all possible bugs" was not my
intention.
> An implementation should only have to cover
the other ends bugs that could cause a crash
> or data corruption at our end. In this
case, I don’t think that means we should change the
> standard to do extra negotiations just to
cover possible bugs.
I think we have
a serious difference in philosophy. The usual
IETF
dictum of being
conservative in what is sent and liberal in what
is
accepted implies
coverage of more than just bugs that could cause
a
crash or data
corruption - see the recent example I sent to the
list
of how a notion
of "implicit offers" could cause a silly
breakdown
in
negotiation. OTOH, being liberal in what is accepted does
not
equate to covering all possible bugs - it means
doing one's best to
do something reasonable in the face of the unexpected
as opposed
to regarding the least little thing going wrong as a
fatal error and
reason to immediately give up.
As to the
standard, I'm not proposing any change. I'm
recommending that implementers
exercise good
judgment by choosing to negotiate
any parameters that are important to the
behavior
and
performance
of their implementation (which
sounds like common sense - are you objecting
to
this?). The negotiation
algorithm has been (and should be) specified in a way that
is robust
to
minor things going wrong, and hence
just using it provides some robustness against
minor
things going
wrong.
The overall principle is
somewhat akin to the exhortation not to complain
about
the behavior
of
the government if you didn't bother
to vote. I think we're close to violent
agreement.
Thanks,
--David
---------------------------------------------------
David L.
Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA
01748
+1 (508) 249-6449 *NEW* FAX: +1 (508)
497-8500
black_david@emc.com
Cell: +1 (978)
394-7754
---------------------------------------------------
