Subject: Re: associating constant feature sets with URLs

From: Graham Klyne <[email-masked]>
Date: Wed, 13 Jan 1999 15:01:37 +0000

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

---

From: Bill Newman <[email-masked]>
Date: Thu, 14 Jan 1999 11:48:24 -0800 (PST)

Graham wrote (in two messages, which I'll respond to together)
 
> (1) Have you seen <draft-ietf-conneg-W3C-ccpp-01.txt>?  It is a discussion
> document I put out in response to the W3C CC/PP working draft.  I am not
> wedded to the specific ideas suggested there, but I do think it gives one
> view of how the W3C work and the conneg work may be related.

I like the ideas there. In particular, I do think it would be good to
solve the font problem, and I like the idea of being able to represent
our data in XML. However, I thought (perhaps incorrectly -- I'm a IETF
newbie) that since the syntax document is in last call, and since
nobody is upset about it, there was consensus that we shouldn't be
changing things very much.  And the "indirect references" approach in
the W3C CC/PP draft seems fairly strongly tied up with the solution to
the font problem (using defaults) and with the use of XML. My proposal
is a way of doing indirection without those things.

I thought of my proposal as a little tweak to solve the one problem
(indirection) that Ted Hardie volunteered me to solve.  The CC/PP
draft is a set of major changes that solves the indirection problem
along with several other problems. I don't have a position on whether
we should make major changes at this point, and I gather from your
response that I may be confused about the group consensus on whether
major changes are still appropriate. If we should make major changes,
then I'd probably drop my proposal.

> (2) For storing feature sets at a URL, the 'auxiliary predicate' construct
> proposed in the '-syntax-' draft may have a part to play.  One advantage of
> this that I see is that it allows the retrieval mechanism (HTTP, or
> whatever) and retrieval addressing (URL) to be separated from the feature
> set description.  (See also Larry's comment.)

My first inclination would be to add this functionality to my
proposal, rather than removing support for indirect feature sets as
filters and replacing it with support for indirect definitions of
named predicates. I would guess that the low-bandwidth people would
probably be happier saying their feature set is
  <http://www.foo.com/conneg/137.html>
than saying
  (model137) where <http://www.foo.com/conneg/137.html> end
or
  (x) where <http://www.foo.com/conneg/137.html> end
But I don't feel strongly about it. 

-------------------------------------------------------------------------------

> mechanism that also allows for overridable defaults may be useful (e.g. the

Yes, solving the font problem would be good. I don't have any strong
opinion one way or the other about whether the solution in
draft-ietf-conneg-W3C-ccpp-01.txt would be good. I do note that that's
a fairly major change to the algebra (the consequences of which I
haven't thought through, hence my lack of an opinion), and furthermore
that any solution will require a comparably major change to the
algebra. I'm not that ambitious.  (Also, I'd have guessed that it
would be hard to make such big changes to the syntax.)

-------------------------------------------------------------------------------

> issues being addressed here.

-------------------------------------------------------------------------------

I'm not trying to say anything about the communication mechanisms either.
(At least not here. I did say some things about timeouts and connection
loss below.) All this point says is that if the text (as finally
received, by whatever mechanism) doesn't have the right hash, it's to
be rejected. I think this suffices to reduce any spoofing attack to 
denial of service, which is about the best we can do.

> be protocol-independent).

I'm not sure about this. I don't much mind leaving it out -- it's
sort of common sense for API design. But I thought it's something
which any implementation should be able to proved, and which I
(on some day when I'm wearing an application architect hat) would
like to know will be provided.

-------------------------------------------------------------------------------

> "machine readable" form as well as the registration documents.

Ted said something about this. I'm unclear on how this would work.
Formally, it could be done in the same way that we register features.
But as a practical matter, there are vastly more device feature sets
than there are features. It seems as though the feature set registry
would be enormous, sufficiently so that servers would not want to
store it. (By contrast, I expect the feature registry to be just a 
kilobyte or two.)

-------------------------------------------------------------------------------

> their design would IMO be outside the scope of this work.

I appreciate that caching is a can of worms. As far as I can tell, we
won't actually get into that can of worms with any reasonable proposal
(including mine). But if any proposal does get into it (or if mine
stumbles into it) I'd consider that a problem, so I thought it was
worth bringing up.

-------------------------------------------------------------------------------

> the capability semantics and ease gateways between the different systems.

No one would be happier than me if there's consensus that we don't
need to deal with this. But I thought I should bring it up rather than
ignoring it and hoping no one would notice.

-------------------------------------------------------------------------------

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

As I said above, I'm daunted by the idea of how big such a registry
would be.  Or are we not talking about a registry of all device
models?

-------------------------------------------------------------------------------

> capability expression rather than solely through some external mechanism.

Regardless of how much functionality the language provides, I think it
would be good to have a consensus about how we feel about CGI feature
sets. My preference would be to endorse them.

Extending the language to handle defaults would be good for other
reasons (esp. the font problem, which doesn't seem to be soluble by
this mechanism). But there will always be someone with something not
supported by the language. If we allow URLs, we should probably think
about whether we'll embrace the manufacturer of a tide-powered
interface wants his capability server to return a different value
depending on the phase of the moon.

-------------------------------------------------------------------------------

> http: probably is appropriate.

I just didn't want to require an implementation to have an ftp client,
gopher client, and so forth. I agree now that it would be better to
instead write "'http:' prefixes must be supported; other prefixes may
be supported."

-------------------------------------------------------------------------------

> referenced by the capability expression.  E.g.

My intent was not to impose a requirement, just to say that it's OK if
clients do this, and the protocol should deal with it gracefully,
instead of telling people that do it that they're different and
strange if they want to do this. And I thought it was sort of neat
that by supporting it properly, a simple version of client-side
default values falls out for free. (At least for free from our point
of view as protocol writers -- it doesn't need to be centrally
standardized in order to interoperate.)  But since there doesn't seem
to be any way to make the solution to the font problem
(i.e. server-side default values) fall out for free, we still probably
need default values in the language.

-------------------------------------------------------------------------------

Thanks for all your comments!

  Bill