Re: Another try at OPTIONS

  I like the revised proposal better, and I think that it does as well
  as can be done to preserve compatibility with 2068 implementations,
  and I very much like the idea of using RFC numbers as feature

  On the question of proxies modifying the responses, perhaps it would
  be better for a proxy that does not implement a particular feature
  to add a non-compliance indication without removing the original
  assertion; this might enable a client to detect the true situation.

  	Non-Compliance =
        "Non-Compliance" ":" proxy-host 1#non-compliance-option

    proxy-host = host [ ":" port ]

	non-compliance-option =
        compliance-namespace "=" option-item [ ";" option-disposition ]

	option-disposition = "passed" | "dropped"

  If the proxy recognizes the option-item as one that it will pass
  through but not react to, it will send the 'passed'
  option-disposition.  If it recognizes the option-item as one that
  will not operate correctly through itself (either due to an
  implementation restriction or as a matter of policy), then it will
  send the 'dropped' option-disposition.  If the proxy does not
  recognize the option-item, it will send no option-disposition, in
  which case the client must rely on its own knowlege of that item to
  make any guess as to whether or not it might work through that

  A Non-Compliance header field MUST NOT be sent by any origin

  What do the client and proxy authors out there think?  Would this
  enable you to do something useful?  Is there a way we could or
  should modify the rules for the Public header like this?

Scott Lawrence           EmWeb Embedded Server       <>
Agranat Systems, Inc.        Engineering  

Received on Wednesday, 23 July 1997 07:09:17 UTC