Re: mandatory / extensions / options

Josh writes:

    I do think we need to have a set of requirements or goals for
    what we expect for extensions mechs for HTTP.
    
I agree with Josh: I think it makes more sense to agree on what
we want the mechanism(s) to do before we charge off into header
design.

Josh listed a few issues, which inspired me to make a list of
more or less orthogonal issues that we might want to consider:

	support vs. want
	    o	"I support this feature"
	    o	"I want you to support this feature"

	direction
	    o	what the server supports/wants
	    o	what the client supports/wants

	end-to-end vs. hop-by-hop
	    o	e2e: origin servers and user-agents
	    o	hbh: proxies

	granularity of support
	    o	per-resource
	    o	per-origin-server
	    o	per-proxy
	    o	per-client

	duration of support
	    o	per-request
	    o	per-session
	    o	explicit expiration (as in HTTP caching)
	    o	forever
	
	feature naming
		i.e., how do we reliably identify features

	feature grouping
		can we group features into named sets without
		getting too confused?  (E.g., "RFC2068" is
		problematic especially if we don't specify
		whether we mean MUST-level or SHOULD-level).

... and probably some others that I'm forgetting.

I don't think the length of the list above necessarily means
a complex solution.  I.e., if we can figure out the right few basic
mechanisms, they should be able to solve most or all of the issues
above.

E.g., Josh brings up the issue of "level", where he suggests this
kind of distinction:

     Maybe we need to separate per-resource, (higher level) options
     from server (lower level options )
     
     high level: 
     (which could be answered by the resource)
       Methods allowed ( GET,POST, etc)
    
     low level:
      (answered by 'core' server )
      chunking
      "do you support proxying?"
      "do you understand full URIs"
	 (currently, apache is 1.1, but does not accept full URLS)
    
I think this is actually something that might be resolved by
carefully defining how we name and group features.

I would be very much against a design that required the recipient
of a feature request or response to make all sorts of fragile
assumptions in order to decide whether to believe it or not.
I.e., the recipient shouldn't have to guess about the details
listed above; they should be explict.

-Jeff

Received on Monday, 23 March 1998 14:55:01 UTC