constant feature sets -- Where do we go from here?

Here's a summary of my perception of what's happened with my proposal
to associate constant feature sets with URLs, followed by some general
ideas about what I might do with that proposal now.

Note that for the purposes of this message, "associating constant
feature sets with URLs" is basically synonymous with "indirection" 
"delegating the transmission of a feature set to such-and-such server."

On 12 Jan 1999, I posted a scheme to extend the syntax document.
Essentially, I proposed to allow <URL> as a syntax element. An
optional secure hash value could be attached to eliminate the
possibility of spoofing.

There were objections and counterproposals, many of which I consider
unresolved, not because so much because I don't have a solution with
which I would be satisfied, but because there may be no consensus on a
solution. I'll try to list those unsettled issues here. If I overlook
something, it's an error on my part, and I'd appreciate a reminder. Or
if I'm still thinking about an objection or counterproposal which has
in fact been dropped, I'd appreciate hearing about that, too.

  1. Why not just use the secure hash function value as key into 
     a cache stored on the server? (Larry Masinter, 12 Jan 1999)

  2. It might be good to have a registry of standard feature sets.
     (various people, including Ted Hardie and Graham Klyne)

  3. How much should the proposal be specifying about mechanism as
     opposed to expression? (Graham Klyne, 13 Jan 1999, and others later)

  4. It would be better to allow URLs to refer to sets of definitions of
     of named auxiliary predicates, and then have feature sets refer
     to those named predicates by name, rather than to allowing URLs 
     to represent feature sets directly. "This moves the protocol
     references awa from the core capability expression." (Graham Klyne, 
     13 Jan 1999)

  5. Do we even need delegation? (Koen Holtman, 15 Jan 1999)
     Do you have a specific negotiation protocol in mind where
     we need delegation? (Koen Holtman, 19 Jan 1999)
     The interoperability benefits are small, and we run a
     real risk of developing the wrong mechanism, or an 
     over-bloated set of mechanisms.

  6. We're still trying to define the problem to be solved. Lets back off
     and think about more scenarios, e.g. using indirection to express
     corporate policy on capabilities. (Graham Klyne 15 Jan 1999)
     We need a clear, application-independent statement of the 
     goals of a "constant feature set." (Graham Klyne 20 Jan 1999)
     Here are some scenarios. (Graham Klyne 21 Jan 1999)

  7. Maybe the proposed error recovery stuff is wrong. (This was part 
     of the general discussion of mechanism versus expression, and Koen
     Holtman also had some specific criticisms on 15 Jan 1999.)

  8. We need to define the problem. We need to have some sort of feature
     grouping to avoid the wastefulness which stopped the use of 
     Accept-* headers in HTTP. We need the indirection system to 
     scale well.
     
  9. The creation of a capability negotiation *protocol* is out of 
     scope for this group. We are charged with creating a feature
     registry.. (Ted Hardie, 20 Jan 1999) [It's not clear to me
     whether this might mean that using URLs in capability expressions
     might be out of scope.]

 10. Indirect references without the ability to override defaults
     are useful in a common case [platforms/resources that don't 
     change] but still, failing to take into account resources or
     platforms that can change [by extending algebra to allow overriding]
     seems like a mistake. (Franklin Reynolds, 21 Jan 1999)

 11. It would be desirable to be able to [automatically?] factor out common
     subexpressions and abbreviate them [as in the feeble, greeble example].
     (Ted Hardie, 21 Jan 1999)

So, where to from here?

  1. I could drop the proposal. Maybe we don't need this anyway, or
     maybe it would be counterproductive to do it without redoing the 
     algebra to support overriding, or maybe it would be counterproductive
     to do it without knowing more details about what protocols will be
     available when it's deployed. Then either
     1a. Indirection is dead.
     1b. The indirection proposal is dead, long live indirection!
         Someone can expand the algebra to support overriding as well 
         as indirection, possibly along the lines of the W3C proposal.

  2. I could try to get consensus on a detailed set of requirements, 
     planning to rework the proposal afterwards. (The requirement 
     that I'm particularly concerned with is conservation of bandwidth 
     for mobile net devices. The requirements for the other scenarios that 
     Graham has brought up seem to come along for free.)

  3. I could just rewrite my proposal, incorporating technical corrections, 
     perhaps as an Internet Draft, and try to get consensus on that. There 
     seems to be no interest in the group (myself emphatically 
     included!) in dealing with transport issues. Perhaps those issues
     could be ignored if the title and the proposal itself clearly
     indicated that it's an extension particularly intended for 
     devices which already support HTTP?

Any suggestions or comments would be appreciated.

  Bill Newman
  [email protected]