- From: Ross Patterson <Ross_Patterson@ns.reston.vmd.sterling.com>
- Date: Wed, 30 Jul 97 15:26:10 EDT
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Jeffrey Mogul <mogul@pa.dec.com> writes: >Good point. I think interpretation #2 makes more sense, since >the proxy could have sent > > Non-Compliance: MyNameSpace=MyThing@Somebody.Else.Proxy > >if it meant #1. Cool, although I was kinda hoping for a "Whoa! We didn't mean for parameters to be supported on Non-Compliance!" > For example, a response with: > > Compliance: rfc=9999;uncond > Non-Compliance: rfc=9999;uncond@proxy.foo.net > > states that proxy.foo.net is not unconditionally compliant with > RFC9999, but does not imply that proxy.foo.net is not > conditionally compliant with RFC9999. If the proxy is not even > conditionally compliant with RFC9999, it should instead send > > Compliance: rfc=9999;uncond > Non-Compliance: rfc=9999@proxy.foo.net > > when forwarding the response. I guess this means that a client needs to sort out all the Non-Compliance headers it receives from proxies in a response and determine for itself how parameters interact. COND and UNCOND will probably be OK, but I wonder about other parameters, especially the ever-present "token" parameter. I guess I weigh in as thinking that parameters should not be permitted in Non-Compliance headers. Ross Patterson Sterling Software, Inc. VM Software Division
Received on Wednesday, 30 July 1997 12:34:08 UTC