Re: Graham's comments on feature-sets-at-urls-00

At 09:56 04/03/99 -0800, Bill Newman wrote:

[...]
>but I don't understand the application of 
>
>+  o  for protocol processors that conform to [1] to be able to
>+     sensibly handle a feature set reference without explicit
>+     knowledge of its meaning (i.e. the introduction of feature set
>+     references should not break existing feature expression
>+     processors).

A fair question:  I'll try and explain waht I had in mind.

First, I must acknowledge that in the general case, final determination of
a feature handling capabilities is not possible without resolution of the
feature set abbreviation.  In this, I think we agree.

But, I think that in some circumstances some useful progress can be made in
the
absence of full knowledge.  If a feature set abbreviation can be treated
somewhat like an unknown feature tag, then the feature set matching can
produce a result that may not be perfect, but may be better than no result
at all:

Example 1:
  Party A asserts:  (& (type="image/TIFF") (h.foo) )
  Party B asserts:  (& (type="audio/wav") (h.foo) )
Now whatever the meaning of "h.foo", these parties don't have media
features in common.

Example 2:
  Party A asserts:  (& (type="image/TIFF") (dpi=[100,200,400]) (h.foo) )
  Party B asserts:  (& (type="image/TIFF") (dpi=[50,100]) (h.foo) )
In this case, the feature capabilities can be partially resolved to:
  (& (type="image/TIFF") (dpi=100) (h.foo) )
In this circumstance, a sender *may* choose to assume the (h.foo)
constraint is satisfied and send a 100dpi image in any case.

This kind of partial resolution is possible in my proposal because the
basic feature expression syntax is not extended.  This is what I mean by
"sensibly handle a feature set reference without explicit knowledge of its
meaning".

>and I don't understand how 
>
>+  o  to allow, but not require, some indication of how to dereference
>+     a feature set reference to be included in a feature set
>+     expression.
>
>can be the basis of an interoperable system.

I am trying to separate *meaning* from *mechanism*.

To put this in concrete terms, if a feature set reference takes the form of
a URL, then that URL contains an "indication" of how it may be dereferenced
(e.g. http).  But, the meaning of that URL does not have to depend on the
availability of that dereferencing mechanism;  in an e-mail environment,
the URL might be used as a key into an LDAP or RESCAP lookup mechanism.

Simply because an identifier contains the name "http" should not be taken
to mean that the http protocol is the only means by which it can be resolved.

Does this help?

>> My primary observation is that your draft covers two matters which I would
>> prefer to see treated separately:
>>   (1) feature set syntax extensions, and
>>   (2) profiling of mechanisms for resolving URLs in feature set expressions
>> I think that matters of representation and mechanism should be separated so
>> that they can be developed independently of each other.
>
>Graham also wrote (I'm quoting slightly out of sequence here) 
>
>> The profiling of resolution mecahisms is a reasonable goal that I have not
>> addressed.  This suggests that between us we might aim for two WG
submissions:
>> 
>>    Syntax extensions for abbreviating media feature sets ...
>>    Resolving URLs in media feature sets
>> 
>
>I agree that they could be developed independently of each other.
>However, in the current situation, I think it makes some sense to do
>it as a single document. The single document addresses a problem, the
>feature-sets-over-thin-pipes scenario that Ted talked about in
>Orlando. If we split it into two, neither half by itself address any
>problem. For a complicated proposal, I'd be strongly in favor of the
>two-way split, or maybe a three-way split (scenarios/requirements
>document, extensions document, and resolution mechanism document). But
>for this little proposal it seems like overkill -- it's a sufficiently
>simple proposal that (modulo my difficulties in expressing myself:-)
>it can be easily understood in its entirety.

I think we have different problems in mind (which is good).

I anticipate an e-mail scenario in which some feature expression
*representation* that we agree is used in conjunction with some mechanism
that is not being considered in this group.  The original thrust of this WG
was that media features be protocol independent.  We are now considering
bringing some protocol specific into the frame:  I'm not arguing with that,
but I really would like to keep some clear separation.

The fact that a common representation may be used with several different
mechanisms actually *requires* that there are multiple documents.  Even if
we proceed and put the expression format and http resolution into one
document, other documents will still be required to deal with other
mechanisms.

>Any comments from Ted or anyone else on this one?

Yes please!

I'll leave this here, and pick up any other points separately.

#g


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