associating constant feature sets with URLs

I'm working on a proposal to allow feature sets to be stored at web
addresses. The intent is that a program can say, for example, "I have
the capabilities described at [some URL], and in addition I have
sound". The primary motivation for this feature is to allow devices
with limited-bandwidth links to the net backbone, such as mobile
devices, to provide only the address of constant information over
their low-bandwidth links, allowing the information at the address to
be retrieved separately (generally over high-bandwidth, non-mobile
links).

I have the outline of a straw man proposal (below), and I'd like to
solicit comments on the general idea before trying to embed it in a
formal document. As I understand it from Ted Hardie, it would probably
be best to put this as a separate document (instead of amending the
"draft-ietf-conneg-feature-syntax" document), because the ITU needs a
stable syntax document to refer to as soon as possible, and the ITU
doesn't need the functionality that I propose to add.

The requirements that I see for any mechanism for a device to delegate
transmission of its feature sets to another server are:
  1. The proposal should be as simple as possible, and as consistent 
     with the pre-existing CONNEG framework as possible.
  2. Although overridable defaults (as in [W3C-CCPP]) are undesirable 
     because of the first point, we should try to get as many of their 
     benefits as possible. In particular, if all model 137 phones 
     have grey-scale displays with 100x200 resolution,
     and all of them have the capability for sound input/output, it 
     should at least be possible to store that information at a web 
     location and then say "I have the capabilities described at [some URL], 
     *and* I have 32 Mb of RAM." (This is in distinction to the 
     overridable default statement that "*except* *instead* I have
     32 Mb of RAM.")
  3. It should be possible for users to prevent spoofing attacks.
     However, since foreseeable spoofing attacks would be rather
     difficult to do and would have no consequence worse than denial
     of service, features intended to prevent spoofing attacks can
     be optional and must not be a hassle for users who don't want
     to worry about them.
  4. Devices which delegate transmission of feature sets or feature
     requirements should be able to detect failure due to network
     problems (e.g. failure of the server which they delegated the
     transmission to). They should be able to retry by any method
     they choose, e.g. trying again harder, trying again with
     content negotiation disabled, or trying again with explicit
     transmission of all feature sets (not using delegation).
  5. It is desirable to integrate this proposal with a proposal for
     registering feature sets analogous to the current proposal
     ([CONNEG-FEATURE-REG]) for registering features.
  6. Nothing in the proposal should interfere with the ability of 
     web caches to cache delegated feature set resources as they would
     cache any other resources.
  7. [open for discussion] What should be the detailed behavior 
     of the protocol when the connection to the delegated feature 
     set server times out?
As far as I know, these requirements are open for discussion -- I'm
not aware of any previous consensus on any of them.

It should also be possible to support registered feature sets, by
analogy with the existing facilities to support registered features.
I'd be prepared to add this to the proposal if there is a consensus
on the requirements for this.

Before I discuss my entire proposal, let me compare my proposal to the
functionality provided by the CC/PP proposal from the W3C [W3C-CCPP].
My proposal is simpler because I omit any direct support for
overridable values. In particular, under the CC/PP proposal, the
negotiation language is powerful enough to express such things as "I
have the capabilities described at [some URL], *except* *instead* I have 32
Mb of RAM [instead of the default 16 Mb of RAM]." Under my proposal,
this functionality is replaced by
  a. a negotiation language which is only powerful enough to express
     "I have the capabilities described at [some URL] *and* I have 32 Mb
     of RAM" (which will work only if the feature set stored at the URL
     doesn't have contradictory information about RAM); and
  b. support for URLs decorated with "?" optional suffixes, so that 
     organizations which really need to provide many options with defaults
     can implement this functionality using CGI scripts and URLs
     of the form "http://conneg-server.some-company.com/model-137?ram=32".

Finally, here's my proposal.

The syntax specification in section 4.1 of [CONNEG-SYNTAX] is
amended so that the definition of "filter" becomes
  filter = "(" filtercomp ")" *( ";" parameter )
         / "<" URL ">" *1( ";shf=" securehashfunctionvalue )

The URL must have a "http:" prefix. Fancy URLs with trailing "?"
properties are explicitly allowed; this leaves an hook to allow sites
maintaining feature set servers for devices with many configurable
options to allow default properties to be overridden at the delegation
server. (E.g. the model 137 could have 16 Mb RAM as an overridable
default after all if the feature set server is sophisticated enough to
handle URLs of the form
"http://conneg-server.some-company.com/model-137?ram=32".)

The resource returned by the server should have a text type. The
resource is processed by first verifying that the secure hash of the
text resource matches the securehashfunctionvalue (if any), then
recursively calling the "filter" parser on the text in the resource.
It is an error if the result of the recursive parse is not a single
complete "filter" object.

A conforming implementation must provide error return codes which
allow the caller to detect failure to read from the delegated feature
set server (and to distinguish this error from other possible error
conditions, such as failure to connect to the server which the user is
trying to negotiate with), so that the caller can retry or back off
appropriately, as it chooses. A conforming implementation should
provide distinguished error returns which allow the caller to
distinguish between (1) failure to connect to the delegated feature
set server, (2) failure of the secure hash function checksum, and (3)
failure to parse the feature set returned by the delegated feature set
server.

The choice of secure hash function is undecided -- I haven't looked
into it yet. A good choice would be secure, widely used, easy to
implement, and unencumbered by licensing and export control issues.

I'm not sure what's the best definition of failure to read from the
delegated feature set server -- in particular, I don't know 
what default timeouts are appropriate, or how important it is
to be able to override the default timeouts. 

It should also be possible to support registered feature sets
in a similar way, by further amending the syntax specification in 
section 4.1 of [CONNEG-SYNTAX] to read
  filter = "(" filtercomp ")" *( ";" parameter )
         / "<" URL ">" *1( ";shf=" securehashfunctionvalue )
         / "." registered_filter_name
where any registered filter name will be expanded into the 
corresponding filter.

References:
  [CONNEG-FEATURE-REG] "draft-ietf-conneg-feature-reg-03.txt"
  [CONNEG-SYNTAX] "draft-ietf-conneg-feature-syntax-04.txt"
  [CONNEG-CCPP] "draft-ietf-conneg-W3C-ccpp-01.txt"
  [W3C-CCPP] <http://www.w3.org/TR/NOTE-CCPP/>

I'd appreciate any comments. If we can reach some sort of consensus
on this, I can write it up in a more Internet-Draft-ish format and 
put it on a web site somewhere instead of just on the list.

  Bill Newman
  wnewman <at> netcom.com
  (working at Nortel in Richardson, Texas despite my unofficial-looking 
  address)