Re: draft-ietf-conneg-feature-hash-03.txt

Graham,

Thanks for your message.  I've extracted two bits, rather than do
comments in-line, just for convenience of connecting the two ideas.  I
encourage anyone following the discussion to read the original message
in its entirity.  I also apologize for introducing some confusion
here, because I believe the term "recognize" was not clear enough to
get across exactly where in the predicate comparison process I saw the
problem.  I compounded that problem by using the term feature tag in a
couple of places in the original message where I meant to refer to the
values associated with the tag.

<big snip>
gk writes, quoting me:
> So, the non-recognition of a feature tag is taken to mean that its value is
> not important.  This leaves us with no way to express "mandatory features",
> a problem that has been documented elsewhere, and one that I was assuming
> we were prepared to defer for further study.
> 
> >With composite feature sets, the assumption that unrecognized feature
> >tags do constrain the set creates a problem, because the conneg
> >predicate alone can no longer tell you what feature tags are present.

Here is the nut of the problem.  With a feature tag present in only
one of the two predicates being compared, the assumption is that the
value of the tag does not constrain the match.  With a feature tag
present in both of the predicates, the assumption is that the values
of the tags must be considered when determining a match.  From a
participant point of view, that means that unknown tags do not
constrain matching, but unknown values do.  ("know", it strikes me, is
a synonmym for recognize, so I don't think I've gotten far past my
terminology problem.  More exact terms are welcome).

Composites aren't composite values or composite tags, however, they
are composite predicates.  So if composites don't match, we don't know
whether we have a bunch of unknown tags (which *would not* constrain
matching) or a bunch of known tags with unknown values (which *would*
constrain matching).  

> >You must have a dereferencing method for either the URI or the hash to
> >determine the feature tags and values.  Fundamentally, I believe that
> >that has made me uneasy because it seems to shift us to the opposite
> >assumption, that we must presume that something is constrained until
> >it has been shown to be possible.
> 
> I do not recognize this shift.  Rather, I think the original presumption of
> possible until known to be constrained is applied here at a much coarser
> level.  Ultimately, in the absence of full information, the system as
> defined tends to err on the side of being permissive.

I think it is really the note in 3.3.2 that caused me to see a shift
here.  It describes a scenario in which the recipient of a composite
replies that it does not understand h.1234567890 and gets the
composite broken back out for it.  I think I read into that statement
that the application would treat h.1234567890 as something it could
not handle if it did not get the original predicate.  This may well
have been derived from my own presumptions of use, rather than
something you intended in the draft.  My presumption made me believe,
however, that the application would treat the composite as if it were
a bunch of known tags with unknown values.


I'm trying to come up with some other way of describing the problem,
but all I've come up with is:

Since the current composite methods reference both feature tags and
feature values with a single pointer, the presence of a composite in a
predicate complicates the application of the matching rules unless
the same composite is present in both predicates being compared.

This complication would not arise if the construction of composites
always allowed in-place expansion.  This, however, cannot be
accomplished with pointers which require external dereferencing.

Should we retain external pointers (hash, URI), and make brutally
clear how to handle the predicate matching in the presence of
composites?  If so, is the handling the same for both types of
pointers?  

Or should we shift the field to in-place compression, or some other
composite method for which the problem does not arise?

	  I hope this is more clear than my original question.  If
not, please feel free to beat me up until I get it clear :)
				 Ted