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

Ted,

I'm not sure that I recognize the problem you are describing.

[Alert:  long message follows, probably belabouring some obvious points.
My conclusions appear at the end.]

At 11:13 15/09/99 -0700, [email protected] wrote:
[...]
>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.

I didn't see the assumption as "challenged";  not fully exploited, maybe.

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

OK so far.

>...  If a set is constrained by an
>unrecognized feature tag, we assume that the instances in the set are
>*not* possible.  

This bit I don't follow.  Suppose we have a sender and a receiver, and the
receiver offers capabilities containing a feature tag unrecognized by the
sender.  If the sender's options were constrained by that feature tag, then
it would need to understand it.  Therefore, the presence of this feature
tag in the receiver's capability expression does not affect what the sender
can send, and is effectively ignored.  Or that's the view I've taken.

Let me get even more specific.  Suppose the sender has two resource options:
   (& (foo=x) (bar=z) )
and
   (& (foo=y) (bar=z) )
And suppose the recipient has capability:
   (& (foo=x) (special=abc) )

The sender can match each of his resources with the receiver capability,
and finds that the one with (foo=y) does NOT match, but the resource with
(foo=x) does match, yielding the resultant capability expression:
   (& (foo=x) (bar=z) (special=abc) )

This is how the matching rules work, as defined.  The presence of an
unrecognized feature tag does not prevent a match being achived.

I think this assumption is necessary, since the alternative is to assume
that every party has total knowledge of the complete range of capabilities
that may determine whether a resource is usable, which I do not think is
reasonable.

For example, a simple web browser may say that it has a capability to
display colour images.  For most purposes, this is sufficient.  But there
may be a resource that is a full colour image, but that it also employs a
particular calibrated colour space for the representation of colours.  Most
web browsers run on relatively cheap video displays that don't offer
calibrated colour, so the colour calibration information is not really
important and specification of this information should not prevent the
transfer of an otherwise quite usable resource.  However, for a high
quality, high cost colour reproduction setup, which does understand
calibrated colour spaces, it probably is important to ensure that the
colour calibration features do match.

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.

This is true.  But consider this:
  Sender:   (h.abcdef)
  Receiver: (h.abcdef)
In this case, the two expressions are known to match, even if the expension
of (h.abcdef) is unknown.  Furthermore:
  Sender:   (& (foo=x) (h.abcdef) )
  Receiver: (& (foo=x) (h.abcdef) )
can only fail to match if either sender or receiver is expressing a null
capability (e.g. if the expansion of (h.abcdef) contains (foo=y) in every
conjuction.  I would argue that it is reasonable to treat this as a match.

Generalizing this idea, I would say that it is reasonable to allow feature
matching where the expansion of composite features is not known, because
the resulting expression is always correct; e.g.
  Sender:   (& (foo=x) (h.abcdef) )
  Receiver: (& (bar=z) (h.123456) )
when matched would yield the feature expression:
  (& (foo=x) (bar=z) (h.abcdef) (h.123456) )
It is possible that when the composite feature expressions are expanded,
this expression will actually yield (FALSE) --i.e. no match-- which means
that we cannot guarantee to fully detect this condition in all
circumstances until we have more specific knowledge of the composites.  BUT
THE RESULTING EXPRESSION IS STILL CORRECT.

I think this is not a issue that is specifically introduced by the feature
composites.  It is, I think, another aspect of handling unrecognized
feature tags.

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

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

I don't see us heading down any new path here.

I think its always been the case that with only coarse-grained information
about media capabilities, we detect the gross incompatibilities.  With more
fine-grained information, we can arrange a more accurate matching of
capabilities.   Only with complete information can we guarantee a perfect
match every time.

I feel we may wish to craft some additional text.  I would be interested to
hear if anything I say here helps to clarify the position to anyone.

#g

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