Re: associating constant feature sets with URLs

Bill,

You present some interesting thoughts.  Here are some counter-proposals,
which are not so different from your ideas as may at first appear...

At 13:56 12/01/99 -0800, Bill Newman wrote:
[...]
>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.

OK.

>  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.")

My draft <draft-ietf-conneg-W3C-ccpp-01.txt> suggests another reason why a
mechanism that also allows for overridable defaults may be useful (e.g. the
"font problem").

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

I'm concerned that there may be some mixing of capability expression and
communication mechanism here.  The 'conneg' framework as currently defined
says nothing about any mechanisms that may be used to communicate the
information.  Anti-spoofing measures sound to me like mechanism.  For use
with the capability expression, maybe some kind of authentication might be
desirable?

This may just be a terminology thing -- I just want to be clear about the
issues being addressed here.

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

This really sounds like an operational mechanism issue:  is it really
appropriate for 'conneg' to consider this (the work to date is intended to
be protocol-independent).

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

I think maybe so.  This may be subject to different interpretations?

I would say that integration with a registration mechanism implies a basis
for having  formally registered features/feature sets accessible in
"machine readable" form as well as the registration documents.

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

Hmmm... careful here, I think.  It may be *necessary* to "interfere" with
caching mechanisms.  I think the requirement is probably reasonable but may
need framing more carefully (e.g. "Nothing in the proposal should interfere
with the ability to integrate with web caches so that feature sets may be
cached as appropriate ...").  I am thinking that it may sometimes be
necessary to disallow caching.

This is not (I think) disagreement with your main point, just suggesting
that the requirement must be stated carefully.  Some capabilities may have
different or special "staleness" criteria to other resources.

I would anticipate that well-specified cache control mechanisms would be
capable of dealing with the requirements of capabilities in this area, but
their design would IMO be outside the scope of this work.

>  7. [open for discussion] What should be the detailed behavior 
>     of the protocol when the connection to the delegated feature 
>     set server times out?

Again, is *this* group egtting into desigtn of *mechanism*?  If so, I do
think we should keep a clear separation between mechanism and expression.

It may be, for example, that this group designs the capability expression
framework required, and others (e.g. the W3C mobile group) design
mechanisms that use that framework.  Other groups (e.g. fax, printing) may
use different mechanisms.  But a common expression framework helps to unify
the capability semantics and ease gateways between the different systems.

>As far as I know, these requirements are open for discussion -- I'm
>not aware of any previous consensus on any of them.

Ditto.

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

I had the impression that this idea was kind-of central to this work.  But
I could be wrong.

>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

I would aim for this to be an orthogonal issue.  (I.e. with scope for it to
be addressed later if required.)

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

I'd rather see such functionality, if required, provided within the
capability expression rather than solely through some external mechanism.

>
>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 )

OK:  I see two key functional additions here:
(a) the ability to make a reference within a capability expression to some
externally defined capability expression, and
(b) a mechanism that protects against undesired modification of the
external reference.

I would like the exernal reference access protocol to be decoupled from the
capability expression.  This is a delicate balancing act, because I can
also see a desire for a capability expression to be completely
self-contained, including external reference access protcols.

Two broad approaches occur to me:

(1) use the auxiliary predicate framework, and extend the auxiliary
predicate definition syntax to allow URLs (or URIs).  This moves the
protocol references away from the core capability expression.  I think this
would make it simpler to devise mechanisms that combine external references
with capability expressions in a fexible fashion.

(2) Require that external references contain a number of auxiliary
predicate definitions, and provide a syntax extension that replaces or
augments the "where" clause described in the -syntax- memo.

These approaches involves minimum disruption to the existing syntax
framework, as the core capability expression syntax is not affected in any
way.  Any additional syntax is used to establish en environment within
which the capability expression is evaluated.

>The URL must have a "http:" prefix.

I would not wish to restruct URL forms at this level.  I think that is
appropriate for an application profile of the capability expression
framework.   http: URLs may be inappropriate in a mail environment:  LDAP
or MAILCAP(?) might be more appropriate there.  For Web based applications,
http: probably is appropriate.

> 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".)

My suggestion (2) above allows this kind of selection without imposing
requirements on the URL form.  Specifcally, the URL reference access an
environment of feature expressions -- only those that are required would
referenced by the capability expression.  E.g.

  (& (screen)
     (sound)
     (ram=32) )
  where
     <http://conneg-server.some-company.com/model-137>;shf="123456789"
  end

where <http://conneg-server.some-company.com/model-137> might contain:

  (screen) :- (& (pix-x<=200) (pix-y<=100) (dpi=100) (color=binary) )
  (sound)  :- (& (sound-type=mono) (sound-coding=GSM) )
  (ram)    :- (ram=16)
   :
  etc
   :

I note that this is not such a big change from what you are suggesting,
just a slightly different way of constructing and framing the information.

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

I think this is getting back into mechanism territory again.

I do agree that some kind of behaviour should be defined for the case when
an external reference cannot be evaluated.  But I see details of error
handling and recovery being more application specific.

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

Sure.

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

I think this is application specific.  E-mail time-outs would be
drastically different to Web 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.

Again, I'd look to introduce registered feature sets through the auxiliary
predicate mechanism.  In any case, use the same underlying mechanism that
is used for device characteristics, etc -- after all, it's just another
kind of external reference, isn't it?

This suggests that maybe the syntax for an external reference identifier
should be exactly the same as the syntax for a feature tag:

   tag
   g.tag
   u.URI [ ;shf=hash ]
   
where any of these might be used as an external reference to auxiliary
predicate definition(s).  Would we need integrity checks for registered
feature sets?

#g


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