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

First off, thanks to Graham for his revision of the current draft.
After having a chance to review it, I find that moving the "birthday"
problem to an appendix and the other clarifications have made this
easier to follow than previous versions.

Reading through the new version, it seems to me that we are struggling
between the URL and hash version because they both challenge the
assumptions in RFC2533, section 3.3.  Predicate matching in the CONNEG
framework starts from the idea that anything is possible, and that you
name constraints to remove instances from the
set-which-has-everything.  If a constraint is not named at all, we
assume the instance remains possible.  If a set is constrained by an
unrecognized feature tag, we assume that the instances in the set are
*not* possible.  

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.
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 am not sure that the CONNEG
syntax and structure are usable with that assumption.

If we accept the shift, there are pros and cons to both methods.  My
question to the group, though, is whether others are as concerned
about this shift as I am.  Do we have agreement that we should head
down this path at all, never mind which fork?

				regards,
					Ted Hardie