Re: a couple more thoughts about ccpp.tx

At 09:27 29/01/99 -0500, Reynolds Franklin NRC/Boston wrote:
[...]
>>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.

Do we wish to encourage different vocabularies at this level?  (i.e. media
feature descriptions.)

IF we are to support multiple feature vocabularies, then we need to have a
mechanism that indicates which is being used.  I believe XML/RDF has a
mechanism to do this in XML namespaces.  The conneg feature registration
does not (but see below).

The conneg feature registration process is designed to allow a large
namespace, with delegation through URI structures where needed.  (Though I
must concede that this mitigates somewhat against the non-redundant
vocabulary ideal.)  In a sense, I suppose this is an alternative approach
to achieving multiple vocabularies.

As things stand, we have flexibility to develop in a number of directions;
we're definitely not boxed in.

Finally, if multiple vocabularies are introduced, it occurs to me that the
"indirect reference" mechanisms suggested might be used to define
relationships/mapoings between vocabularies.

#g


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