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

Bill,

I am suppressing the urge to reply to all the points you raise, and trying
to focus on what I see as important to resolve first...


At 13:27 29/01/99 -0800, Bill Newman wrote:
[...]
>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 this point, I beg to differ:  I think that "indirect reference" and
"delegation" are two distinct functions.

Maybe this use of the term "delegation" will always cause problems...


------------
>  6. We're still trying to define the problem to be solved.
[...]
>  8. We need to define the problem.

I think this is key at this stage:  I cannot avoid the feeling that
different people are still thinking primarily about different problems.  (I
think it's time to re-post my updated scenarios message.)


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

I thought our chair's comments indicated we were constrained by charter to
expression.

>  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.]

I think it's fine to say we use URLs, and even to indicate what they may
mean;   what we don't define here is how to resolve them (using HTTP or
whatever).


-----------
>So, where to from here?
[...]
>
>  2. I could try to get consensus on a detailed set of requirements, 
>     planning to rework the proposal afterwards.

I'd favour this approach:  (1) agree requirements/goals/terminology
(through discussion of scenarios, perhaps);  (2) isolate specific
functional goals from them;  (3) consider various technical proposals that
have been made;  (4) rework and develop the proposal document.


#g

------------
Graham Klyne
([email protected])