Re: a couple more thoughts about ccpp.tx

I am confused (this, as you have probably noticed by now, is a typical
state of affairs) about  CONNEG support for multiple namespaces. In

       http://www.ietf.org/internet-drafts/draft-ietf-conneg-feature-reg-03.txt

I read the following:

   3.1.3 URI tree

     A feature tag may be defined as a URI using the restricted character
     set defined above. Feature tags in the URI tree are identified by the
     leading facet "u.". The leading facet u. is followed by a URI [9]
     which conforms to the character limitations specified in this
     document.  The author of the URI is assumed to be registration
     authority regarding features defined and described by the content
     of the URI.  These tags are considered unregistered for the
     purpose of this document.

This seemed to me to be roughly equivalent to the XML namespace
mechanisms.

Franklin Reynolds
Nokia Research Center

 ----------
From: Graham Klyne
To: Reynolds Franklin (NRC/Boston)
Cc: ietf-medfree
Subject: Re: a couple more thoughts about ccpp.tx
Date: Monday, February 01, 1999 9:17AM


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