##################
>From: Bill Newman <wnewman@netcom.com>
>Subject: associating constant feature sets with URLs
>To: ietf-medfree@imc.org
>Date: Tue, 12 Jan 1999 13:56:48 -0800 (PST)
>X-Mailer: ELM [version 2.4 PL25]
>Sender: owner-ietf-medfree@imc.org
>List-Archive: <http://www.imc.org/ietf-medfree/mail-archive/>
>List-Unsubscribe: <mailto:ietf-medfree-request@imc.org?body=unsubscribe>
>
>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@netcom.com
> (working at Nortel in Richardson, Texas despite my unofficial-looking
> address)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
Fax 314.918.9015
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<