- From: Eric Murray <ericm@lne.com>
- Date: Mon, 29 Apr 1996 20:45:29 -0700 (PDT)
- To: bsy@cs.ucsd.edu
- Cc: dpkemp@missi.ncsc.mil, ietf-tls@w3.org
Bennet Yee writes: > > I agree with most of your points about passwords. However, the scenario > that you draw about extensions would imply that we should think about > mechanisms by which extensions to TLS may be made cleanly -- reserve some > record type numbers that are vendor-specific, and mandate that the rest > be not used except as officially sanctioned blah blah blah when/if TLS > gets revised. If we don't do this, then we risk creating compatibility > problems in the future. While I agree that an extension mechanisim might be useful, I think there's more utility in keeping the standard simple to understand and implement. An extension mechanisim that allowed vendor-specific extensions would probably require yet another negotiation, if you don't want to repeat the HTML problem of conflicting vendor-added features- i.e. "do I write my TLS to talk to Microscape's TLS extentions, or Netsoft's?"). Adding another negotiation would increase the complexity of the TLS standard. Look at the RFCs, it's the simple standards that have been successful and widely deployed, while there are many super-flexible but complicated standards that have few implementations. I think it would be better to create one simple TLS standard, then add on additional standards or IANA registration schemes for things like password-exchamge protocols, additional CipherSuites, support for pre-encrypted data, etc. rather than trying to do everything now. -- Eric Murray ericm@lne.com ericm@motorcycle.com http://www.lne.com/ericm PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03 92 E8 AC E6 7E 27 29 AF
Received on Monday, 29 April 1996 23:46:48 UTC