Re: a couple more thoughts about ccpp.tx

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

I think understand your concerns a little better now. I appreaciate the
problems caused by redundant features within a vocabulary. In the
original document only the CONNEG vocabulary was supported. If
we support multiple feature vocabularies and argue against redundant
features within a feature vocabulary then I am happy.

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

This example clears things up nicely. I agree that there are definite
similarities to the XML approach.

Franklin Reynolds
Nokia Research Center