On 7/5/07, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
I posted draft-carpenter-rfc2026-changes-00.txt at Russ Housley's request. Obviously, discussion is very much wanted. http://www.ietf.org/internet-drafts/draft-carpenter-rfc2026-changes-00.txt
From the draft:
"Is it acceptable if features A and B are shown to be interoperable between implementations X and Y, and features C and D are shown to be interoperable between implentations P and Q?" Yes. The point of the requirement is to identify features that are unimplementable, for technical or non-technical reasons. The requirement does not exist to compel implementors to make identical engineering trade-offs in order to arrive at the shangri-la of "universal interoperability", where all features are present in all implementations. 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. There are no interoperable HTTP authentication schemes, and the TLS requirements in drafts I've seen consist of either obfuscation (recent DAV documents), or a choice between TLS versions (recent Atompub documents). At least the Atompub TLS requirements don't mislead implementors too badly. The text reads "to guarantee". It should read "with the goal of" or "to guarantee universal interoperability, in theory, by requiring security mechanisms that won't be used in practice." -- Robert Sayre "I would have written a shorter letter, but I did not have the time." _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf