Re: Updated proposal for OPTIONS issue

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