Re: a couple more thoughts about ccpp.txt

(I assume that you are leaving it to me to decide whether to publish my
previous response to your comments.  Here it is, so the ideas from our
debate can receive due review.)

At 14:28 27/01/99 -0500, Reynolds Franklin NRC/Boston wrote:
>1. Perhaps it would be reasonable to split the ccpp.txt document into two
>   separate documents. One to deal with specific W3C CC/PP issues. I
>   think these would be primarily XML encoding issues. The second
>   document could deal with extensions to the algebra. This would
>   include defaults, etc.

My CCPP document was never intended to be more than a discussion document.
The structure was not expected to be preserved!  If there are parts that
can usefully be transplanted into some deliverable document, then great.

>2. I was puzzled reading section 2. I would have thought that both
>   parties would need to know the tags (similar to how both parties
>   involved in network communication have to understand the protocol
>   headers) or confusion would reign.

I don't think that both parties need to "know the tags", only recognize
their form and allowable operations.   (This assumes that the communicating
parties are operating in some common feature tag namespace, such as that
provided by the media feature registration procedures.)

This is why, in its current form, LE/GE relations are defined only for
numerics, because they are common operations.  For tokens and strings, one
must have specific knowledge of the feature to perform the processing.

Clearly, at some level, an application must know what the tag means or
there is no point in using it.  What I am arguing is that negotiating
parties (i.e. those that actually exchange negotiation metadata) don't have
to fully understand all the tags in order to conduct a succesful
negotiation.   I am trying to relax the absolute need for end-to-end
interactive exchange of information.

(Remember, I come to this from more of an e-mail perspective than a WWW
perspective, so I place far less reliance on end-to-end virtual circuit
connection.  I'm not trying to say that specific application profiles
cannot use end-to-end connections, but I am trying to avoid embedding that
assumption in the capability expression processing.)

This area may need further exploration.

>3. In section 2.3 you mention two consequences of the need for content
>   negotiation. The first I understand. But I don't see how the second
>   consequence is derived for the discussion in section 2.

Extract from section 2.3:

  o  The capability description should be able to describe

dependencies between content features in such a way that they can
     be
handled by the negotiation protocol.

  o  The vocabulary used to describe content features should avoid

having multiple ways to describe the same capabilities.

OK, the derivation of the 2nd is not obvious, is it!

The ratonale is this:  if there are multiple ways of describing the same
features, then the only way to absolutely recognize that two different
expressions have the same meaning is to know about the relationship between
the feature tags used.  This implies that the "negotiation protocol" must
know about specific feature tags in order to function in all possible cases.

In practice, the goal of eliminating all possible forms of equivalence is
proving somewhat elusive, in that it is very difficult to define a single
set of feature tags that work well for all applications.  But I still feel
it's worth trying to avoid gratuitous redundancy.  I also think that
application profiles should indicate the appropriate usage (e.g. see
<draft-ietf-fax-feature-schema-xx.txt>) so that redundancy within a single
application is avoided.  Then it may be that application gateways need to
know enough about the feature tags to translate, but that's better than
requiring that every negotiating component have such knowledge.

>4. In section 3.2 you describe a message transmission model that
>   appears reduce to a two party communication channel. (S) is the
>   message sending system and (R) is the receiving system. I don't
>   believe this is necessarily true, when there are other sources of
>   profile data such as Vendor supplied default values.

Your first sentence is essentially true.  But I do not mean to imply that
profile data cannot be provided by parties who are not directly on the
communication path.

>   I am unclear on how things, except for specific features, are named
>   in the CONNEG algebra. What if we are dealing with a Mac and there
>   are two displays? What if I change the characteristics of the
>   display? How do I name the specific feature, for example - color,
>   that I have changed?

The features are identified by feature tags.  These may be registered, or
may be locally defined (i.e. application- or environment-specific) URIs
preceded by 'u.' per <draft-ietf-conneg-feature-reg-xx.txt>.

My goal is that the combining syntax does not depend upon the specific
feature tags used.  This is quite like the XML approach, isn't it?

>   Named predicates might work, but I am unclear on the
>   concept. Consider a sample VGA description:
>
>   (SONY_VGA_MODELXXX) :-
>      (| (& (pix-x=640)
>            (pix-y=280)
>            (color=256))
>         (& (pix-x=1028)
>            (pix-y=1028)
>            (color=256)))
>
>    There are apparently two VGA modes, but they aren't named. If I
>    want to change the value of the color feature in the second mode,
>    do I have to send the entire predicate?

At this level, yes.  But also consider:

#   (SONY_VGA_MODELXXX) :-
#      (| (SONY_VGA_STDRES) (SONY_VGA_HIRES) )
#
#   (SONY_VGA_STDRES) :-
#         (& (pix-x<=640)
#            (pix-y<=280)
#            (color<=256) )
#
#   (SONY_VGA_HIRES) :-
#         (& (pix-x<=1028)
#            (pix-y<=1028)
#            (color<=256) )

Now, you can identify the modes separately.

Alternatively, given some "delegation" mechanism (see other messages), one
might write something like:

#   DEFAULTS
#     (SONY_VGA_MODELXXX)
#   IN
#     (& (pix-x<=1028)
#        (pix-y<=1028)
#        (color<=16) )

I am assuming that any feature tag that is not defined by the main
expression takes its value from the SONY predicate.

Suppose you do a feature match with a resource that has:

#        (color=128)

then the main expression is not matched, and none of the feature tags
mentioned there can be applied so the default mechanism must be invoked to
find a matching value.  This in term would match (only) the alternative
containing:

#         (& (pix-x<=640)
#            (pix-y<=280)
#            (color<=256) )

Thus, the final result of the match per ules set out in -feature-syntax-
would be:

#         (& (pix-x<=640)
#            (pix-y<=280)
#            (color=128) )


So there we have much raw material of our debate to date.

#g

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