On 2007-07-07 08:30, Keith Moore wrote:
Also from the draft:
"At least for the strong security requirement of BCP 61 [RFC3365], the
Security Area, with the support of the IESG, has insisted that all
specifications include at least one mandatory-to-implement strong
security mechanism to guarantee universal interoperability."
I do not think this is a factual statement, at least when it comes to
HTTP, which is where my interest lies.
note that it is not necessary to have at least one
mandatory-to-implement strong security mechanism to guarantee
interoperability. consider, for example, a client-server protocol for
which conforming servers are required to implement
_two_ strong security methods and for which clients are required to
implement _at least one_ of those two methods. this
would ensure interoperability even though there were no single
mandatory-to-implement for clients.
depending on the circumstances, putting a greater burden on the server
than the client, or vice versa, might make sense.
As far as 2026bis goes, my idea would be to have language that defines
the bounding requirements. There are specifics in BCP 61 = RFC 3365
which would be out of place in 2026bis.
In the above quote I would suggest
s/to guarantee universal interoperability/in the interests of universal
interoperability/
Brian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf