- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Wed, 30 Jul 97 12:13:56 MDT
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Ross Patterson writes:
>14.QQQ Non-Compliance
>...
> Non-Compliance = "Non-Compliance" ":" 1#non-compliance-option
>
> proxy-host = host [ ":" port ]
>
> non-compliance-option = compliance-option "@" proxy-host
This implies that non-compliance-option allows parameters, e.g.:
Non-Compliance: MyNameSpace=MyThing;MyParam@Somebody.Else.Proxy
Is this an accident of syntax? If not, what is the interpretation of
such a header? Two possibilities come to mind immediately:
1) Somebody.Else.Proxy doesn't support the MyNameSpace=MyThing item.
2) Somebody.Else.Proxy supports the MyNameSpace=MyThing item, but
doesn't support it with the MyParam parameter.
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.
So I'm adding this to the definition of Non-Compliance:
If the compliance-option in a non-compliance-option includes one or
more option-param(s) (see section 14.ZZZ), then the proxy server's
non-compliance is limited to the scope of the option-param(s). If
the compliance-option does not include an option-param, then the
proxy server is asserting non-compliance with the option in
general.
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.
Thanks
-Jeff
Received on Wednesday, 30 July 1997 12:18:57 UTC