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

From: Graham Klyne <[email-masked]>
Date: Thu, 16 Sep 1999 11:18:43 +0100

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

---

From: [email-masked]
Date: Thu, 16 Sep 1999 10:24:49 -0700 (PDT)

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

> 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