Michael Richardson wrote:
"Keith" == Keith Moore <moore(_at_)network-heretics(_dot_)com> writes:
>> In my view, SHOULD are user protocol options to set.
Keith> In my view, SHOULD should rarely be used for optional
Keith> protocol features, because optional protocol features should
Keith> themselves be rare. And the primary purpose of SHOULD is not
Keith> to permit optional protocol features.
Let me give an example of where I think SHOULD is useful:
a TLS end-point SHOULD verify the received certificate against
a trusted anchor.
Removing this requirement in SMTP-TLS has meant that we now have
opportunistically encrypted email transmission. It makes sense for the
TLS library to have this option.
In a web browser, the same SHOULD is much more controversial.
Some TLS libraries have this as a MUST, and there is all sorts of
trouble for people implementing other protocols or authentication
mechanisms over TLS.
The issue here, in my technical opinion, is the difference in the
With HTTP, you have the design ergonomics options for interactive I/O
with the user to allow the user (giving him the benefit of doubts) to
With SMTP, it is inherently designed for automated decisions. I guess
one can suggest it is technically possible by having user decisions
predefined. But for SMTP-TLS, we have a chicken and egg design
problem - what comes first the SYSTEM or the USER? SMTP-TLS is
decided before the USER is known, but is not inconceivable to have a
belated automated SMTP-TLS state decision made until the target user
Ietf mailing list