IPP> Fwd: associating constant feature sets with URLs

IPP> Fwd: associating constant feature sets with URLs

IPP> Fwd: associating constant feature sets with URLs

Richard Shockey rshockey at ix.netcom.com
Tue Jan 12 17:26:02 EST 1999


This was posted on the CONNEG list.... I thought it might be of interest.

##################


>From: Bill Newman <wnewman at netcom.com>
>Subject: associating constant feature sets with URLs
>To: ietf-medfree at imc.org
>Date: Tue, 12 Jan 1999 13:56:48 -0800 (PST)
>X-Mailer: ELM [version 2.4 PL25]
>Sender: owner-ietf-medfree at imc.org
>List-Archive: <http://www.imc.org/ietf-medfree/mail-archive/>
>List-Unsubscribe: <mailto:ietf-medfree-request at 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 at 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 at ix.netcom.com  
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<



More information about the Ipp mailing list