Re: response to Graham's comments

Bill,

Having read your responses, I think the only real difference between our
positions is the scope that should be tackled by a specification.  Reading
your suggestions, they seem to be framed in terms of feature sets applied
to a web application.  My view is that the basic capability expression
should be application- and protocol- neutral, requiring some further
clarification to define use in the context of some given aplication.

The original work on media features was an attempt to provide a common
*vocabulary*, and I personally see the feature set proposal as an extension
of that idea.

I have suggested that this work could focus on defining a way to introduce
auxiliary predicate definitions into an existing capability expression.
The -syntax- draft is deliberately flexible about how auxiliary predicates
may be introduced, and it was my view that this is a natural way to
incorporate feature set definitions without changing the fundamental
syntax.  (But for this to work, it would need to be specified in an
application profile.)

We have both floated ideas that modify the capability expression syntax to
allow external references.  Another approach would be to define a
surrounding mechanism that embeds an existing capability expression into an
environment that provides the additional information required.  If such a
mechanism can provide "scoping" then we get the "default override"
capability.  E.g.

    LET
       <external-reference-URI>
    IN
       <capability-expression>

The idea would be that <capability-expression> is evaluated, but that any
featire and/or auxiliary predicate definitions not provided there that can
be provided from the <external-reference-URI> would be so provided.  Thus,
the <capability-expression> syntax and/or semantics itself is not changed,
but placed in a "wrapper" that extends the ways in which it can be evaluated.

In this case, the exact allowable form of <external-reference-URI> would be
determined by an application profile.  For passing capability expressions
between applications, the resulting capability expression would be fully
determined so the "LET" wrapper can be discarded.

I think this sort of approach addresses both your point about minimizing
changes to capability axpression syntax, and mine about separating external
references from the capability expression in some way.

Anyway, some specific comments...


At 11:48 14/01/99 -0800, Bill Newman wrote:
>[...]  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.

Absolutely:  the intention was not to change the original -syntax-
document, but to suggest conceivable ways in which it might be extended,
without invalidating applications that use the features currently in last
call.

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

Whatever else, I'm certainly not claiming the changes in my draft are the
*right* changes.  Indeed, I think they're probably *not* right;  just
illustrative of how the different works might be combined.

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

That's a ressonable view.  My own preference is for clear separation
between statements of capability and statements that *access* such
information.


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

I think the <draft-ietf-conneg-W3C-ccpp-01.txt> proposal is probably
over-complex.  And I agree that there are too many syntax extensions there.

The main point I think that it makes is that solving the "font problem" may
use exactly the same solution as solving the "overridable defaults" problem.

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

Yes, in the context of some *particular application* these issues need to
be well defined.

See, for example, how <draft-ietf-fax-feature-schema-05.txt> profiles the
capability expression for Internet fax, and other drafts
<draft-ietf-fax-eifax-xx.txt, draft-ietf-fax-mdn-extensions-xx.txt>
indicate mechanisms for communicating such information.


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

Yes, but I think that not all servers would store all feature sets.  For
example, I could imagine one server to store formally registered feature
sets, then arbitrarily many others to store application-, manufacturer- or
device- specific information.

I, too, am not clear how this would work.  The W3C CC/PP work shows one
clear scenario that could inform the debate (i.e. providing shorthand for
specific device characteristics).  The memo
<draft-ietf-fax-feature-schema-05.txt>, Appendix B, indicates another
scenario, namely to capture informatiom about commonly used profiles (in
this case, those defined in RFC2301 for TIFF usage).

These suggest two distinct possible usages for feature set registration:
(1) registration of "standard" feature sets.
(2) registration of "private use" feature sets.

For "private use" feature sets there seems to be a clear advantage to being
able to use the feature set identifier to access a machine-readable
expression.  No application can reasonably have prior knowledge of all
applicable private feature sets.

For "standard" feature sets, the advantage is less clear, but I can still
see some advantage in an application being able to pick up feature sets
that are standardized *after* the application is shipped.

Before pursuing this line too much further, I'd like to know if there are
any other scenarios that need to be considered.

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

Yes.  I think we are agreed!

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

My view is that this is important, but needs to be determined
per-application, so should not be addressed (in other than very general
terms) in a 'conneg' proposal.

Maybe we do need to be clear, somewhere, about the specific issues that
applications that use the 'conneg' framework do need to specify.


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

Endorsing them in the context of Web access is fine by me.  But they seem
somewhat irrelevant in the context of, e.g., an e-mail based protocol.

Again, I see a separation here between generic capability expressions and
their use in a specific application.

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

I don't think this should be absolutely prohibited without good reason.
(But not necessarily "embraced".)

I'm not clear where this leads.


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

Sure:  I think it is appropriate to impose such constraints in an
application profile.  Thus, the use of URIs in a capability expression
would be generally allowed, but subject to constraints that may be imposed
by some particular application.

This gives us a hint that capability expressions that are passed between
applications (e.g. Web-to-email gateway) should probably not contain URIs
(rather should have the appropriate capability expression substituted).


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

Fair enough.


#g

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