> There's no point in crudding up the protocol to add workarounds > for broken implementations, and certainly it seems like a bad > idea to test dynamically for something that will happen (usually) > only once in the lifetime of the software version (namely, > the upgrade of a 1.0 proxy to 1.1). > I certainly agree that we shouldnt impose a handshake in every transaction, but I do beleive that there is a valid need for an OPTIONS method. I see it in a similar light as TCN, except for communications options or parameters instead of object attributes or languages. It would be useful to ask an entity ( a proxy or server ), the first time you talk to it or discover it: <do you comply with> <rfc2109> or <do you support the optional feature called> <set-proxy> > Larry > -- > http://www.parc.xerox.com/masinter > ----------------------------------------------------------------------------- Josh Cohen Netscape Communications Corp. Netscape Fire Department #include<disclaimer.h> Server Engineering josh@netscape.com http://home.netscape.com/people/josh/ -----------------------------------------------------------------------------Received on Tuesday, 1 July 1997 23:51:27 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:02 UTC