Michael Richardson wrote:
"Keith" == Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> 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.
+1
The issue here, in my technical opinion, is the difference in the
functionality.
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
decide.
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
is known.
--
HLS
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf