Subject: Re: draft-ietf-conneg-media-features-02.txt; LAST CALL

From: Graham Klyne <[email-masked]>
Date: Tue, 24 Nov 1998 19:36:08 +0000

Koen,

Thanks for the ack of the revised wording.

At 19:12 24/11/98 +0100, Koen Holtman wrote:

>>In the current version, there is no way to deal with non-orthogonality
>>_within_ the capability description framework.  
>
>I think you are underestimating the framework.  For one thing I don't
>think there would be any trouble in it dealing with the
>inches/pixels/dpi non-orthogonality, provided that one of the two
>parties in the negotiation process knows about all three of these tags
>(and the party which renders the content generally will know about all
>three).  pix-x and pix-y are also somewhat non-orthogonal (in a
>different way) and the framework can deal with that too.
>
>Am I missing something?

I think we are saying exactly the same thing, but with different
interpretation of _within_ the framework.  You say "...provided that one of
the two parties in the negotiation process knows...":  it is precisely this
kind of application-embedded knowledge embedded that I would like to avoid;
 but that is a difficult goal, and for now I think some must be allowed.
In future... who knows?

When I say "... _within_ the framework", I mean within the capability
description, without reference to the aplications that use it.  Here is an
extract from my draft <draft-ietf-conneg-W3C-ccpp-00.txt>:

  Consider a WWW transaction scenario that involves content
  negotiation:

     Resource-1 ->-   +--------+         +--------+   ->- Plugin-1
                    \ | Origin |         |        | /
     Resource-2 ->----| Server |--<--->--| Client |---->- Plugin-2
                    / |        |         |        | \
     Resource-3 ->-   +--------+         +--------+   ->- Plugin-3

  In this scenario, the active negotiation takes place between the
  origin server and the receiving client.

  The resources available to the origin server are possibly passive
  data files, with no opportunity for interaction between data
  resource and server.

  The plugins available to the browser may well be dispatched as
  separate programs, with limited opportunity for ongoing interaction
  between the plugin and the client.  Also, there may be a high
  overhead associated with activating a plugin, so it is not
  desirable to activate one or more plugins simply to determine
  whether a data resource is acceptable to that plugin.

I am trying to argue here that there is real value in having full knowledge
of resource dependencies contained within the capability descriptions used
by the negotiating parties (origin server and client) that themselves may
know nothing about the features described by the tags.  

>It is true of course that non-orthogonality does prevent certain types
>of simplifications in the framework.  I always thought that you wanted
>non-othogonality to allow for (fax) negotiation protocols which are
>much simpler than the framework.

I think I can see why you have that view, but that was not my intention.
It is certainly true that I want the framework to be simply applicable to
description of the capabilities that are carries by the fax T.30 protocol.
But I also would like to see a good degree orthogonality which, I believe,
will make interoperable negotiation between different protocols easier to
achieve (web-to-fax gateways, anyone?).

I have since conceded that full orthogonality is not always a useful goal.
In the short term, this implies some application knowledge will be
required.  Longer term, maybe some practical method for capturing the
dependencies may be devised?

#g

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