Although your logic is sound it doesn't seem IETF-compliant. Is there some way we can handle this? For example, if there were a TLS document, and a second document containing ("the SSL profile of TLS")? At 10:45 AM 12/17/96 -0800, you wrote: >David P. Kemp wrote: > >> But the standard, mandatory-to-implement, universally-interoperable >> algorithm cannot be proprietary. > >Unfortunately, operations in the real world mean that there will never >be a universally-interoperable algorithm, even within the domain of >supporting a single protocol, say HTTP. For instance, some >implementations will only contain support for FORTEZZA and others will >contain no support for FORTEZZA. > >There are some CipherSpecs that are only useful where MITM attacks are >unlikely, say anonymous Diffie-Hellman supporting telnet on a single >subnet. We shouldn't say "That's not TLS." since it doesn't support the >'mandatory aglorithm'. > >I'm not arguing against the goal, but the spec needs to deal (carefully) >with how TLS will be actually used. > >PK >-- >Philip L. Karlton karlton@netscape.com >Principal Curmudgeon http://www.netscape.com/people/karlton >Netscape Communications Corporation > > Everything should be made as simple as possible, but not simpler. > -- Albert Einstein > > > Rodney Thayer <rodney@sabletech.com> +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable "Developers of communications software"Received on Tuesday, 17 December 1996 15:06:28 EST
This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:34:55 EDT