Subject: Handling closed sets of feature values

From: Graham Klyne <[email-masked]>
Date: Wed, 09 Sep 1998 18:47:22 +0100

All,

As mentioned at the IETF meeting, there is (among others) an outstanding
issue with the -algebra- draft.

The example cited was how a receiver can indicate that they have some given
set of fonts, *and no others*.

Some possible solutions that I can see are:

(a) Do nothing.  It may be that the problems are not serious in practice.

(b) Introduce set-valued features.  Comparison would be based on set
equality and inclusion.  This introduces a possible complication that the
resulting set is partially ordered -- I'm not fully sure of the
implications of that fact.

This would lead to a recipient predicate like this:
    (Font<={"Times","Swiss"})
which would match this document predicate:
    (Font={"Times","Swiss"})
but not this:
    (Font={"Times","Rarity"})
(where '<=' operates as a subset comparison)

(c) Introduce a way of tagging "required" features.  If one party indicates
that some feature must be present for feature set matching to proceed, then
the feature set matching process could be modified to ensure that the
feature exists with a default value in each feature set that is being
matched.  I think this would tend to confuse the feature set matching
prodcess by changing it away from being a simple process of pure logical
manipulation.

(d) Feature tag schemata:  for example, defining a feature tag of the form
"Font-*" so that any Font-xxx value can be matched.

Thus, to describe the font capabilities of a recipient, one might use:
    (& (Font-Times=TRUE) (Font-Swiss=TRUE) (Font-*=FALSE) )
which would match a document described as:
    (& (Font-Times=TRUE) (Font-Swiss=TRUE) )
but which would not match a document described as:
    (& (Font-Times=TRUE) (Font-Rarity=TRUE) )

Defining exact rules to make this work could be a challenge.

(e) Use auxiliary predicate as a feature tag.

A recipient might define:
    (Font X) :-
      (| (X="Times") (X="Swiss") )
Then a document might assert:
    (& (Font "Times") (Font "Swiss") )
which would match, or
    (& (Font "Times") (Font "Rarity") )
which would not match.

I see the challenge in this case is to define clear scoping rules for
locating the auxiliary predicate.  I view this as a 'cleaner' version of
solution (d) above.

#g

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

---

From: Graham Klyne <[email-masked]>
Date: Wed, 09 Sep 1998 18:44:23 +0100

I apologize for the delay in posting these comments.  As usual, they're
mostly nits.

#g

[...]
>Introduction
>    
>This work was originally motivated by the requirements from web
>browsers to send the browser's display characteristics to the web
>server to allow the server to choose an appropriate representation.
>     
>This specification defines some common media features [REG] by which a
..............................................<------>
I would suggest "feature tags".

>recipient may inform a sender as to the characteristics of its message
>handling.  The sender may then provide the variant of the message that
>is most suitable for the recipient.

[...]
>dpi (integer)
>
>  This feature indicates a resolution that the recipient can display
>  or print without loss, measured in pixels per inch; resolution is
>  typically represented as 'dpi' (dots-per-inch) rather than in SI
>  units [SI]; however 254 dpi is equivalent to 100 dots per centimeter.

I think we need separate x- and y- resolutions, for fax if nothing else.

In the absence of support for unit conversions, I'd also cut down the text
about units to something like:  "resolution is represented as 'dpi'
(dots-per-inch);  25.4 dpi is exactly equivalent to 1 dot per millimetre."

>media (token)
>    
>  This feature indicates the recipients device media, indicated with
>  an simple token.  All (except for "screen" and "screen-paged") are
...^^ = "a"

>  taken from the Printer MIB MediaType set defined in RFC 1759
>  [PRINTMIB].  Other tokens may be registered and used as needed.

[...]
>papersize (token)
>
>   For stationery, it is often useful to have information about the
>   size of display used.  While it is more precise and predictable to
....<-------------> "physical size of the medium"

>   use absolute resolution and pixel sizes, some applications find it
>   useful to provide paper size in addition to this information.
>   (Note that not all of the paper may have a printable area.)  Paper
........................................<--> do you mean "be"?

>   sizes names and definitions are taken from RFC 1759 [PRINTMIB],
>   which in turn imported the definitions from ISO/IEC 10175.

[...]
>color (integer) 
>grey (integer)
>    
>   The color capabilities of the recipient are indicated with feature
>   tag and a parameter describing the number of color channel bits
>   available.  Values of n are typically (but not limited to) 2, 8, or
....................................................................^ "16," ?

>   24.  For example: grey=8 indicates a display capable of
>   representing an image in 256 levels of a single color, while
>   color=8 indicates a display capable of representing an image with a
>   palette of 256 colors.

>tiff (token)

Will 'tiff' be removed from this draft?

[...]
>Examples of use of features
>
>   The following examples of feature comparison show how these features
>   can be used to describe various capabilities. The syntax used to 
>   express combinations of features is purely illustrative and not 
>   normative:
>   pix-x<=1024, pix-y<=768 
>      indicates a 1024x768 display 
>    
>   dpi<=72
>      indicates a 72 dpi display  

I think that should be "dpi=72".  (A typical display would not be able to
display 39 dpi or 71 dpi, for example.)

>   media=stationery 
>      indicates the display is a cut sheet of opaque material, such as   
>      paper.  
>  
>   papersize=iso-a4
>      indicates the display size is 210x297mm. 
>   
>   color<=24
>      indicates the display supports 24-bit (8-bit/channel) color.   
>       
>   papersize=na-letter,dpi<=200,tiff=S
>      might be used for a fax machine with 'simple mode'.
>   papersize=na-letter,dpi<=400,tiff={S,F,C,M}
>      might be used for a fax machine with enhanced capabilities.

Is it helpful to suggest one syntax for combined features here when another
draft is planned to define a different syntax for that purpose?  (I'm just
asking -- if it is felt to be helpful then that's fine with me.)

#g

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

---

From: [email-masked] (Ted Hardie)
Date: Wed, 9 Sep 1998 14:20:25 -0700 (PDT)

Graham,
	Larry recently sent a -02 version of the media features
draft to the list, and it will probably arrive in the standard directories
in the next few days.  It addresses some of your concerns (the presence
of TIFF, for example), and it changes the format of the draft considerable,
to meet the registration draft requirements.  You can get the draft
from the mail archives, if you want it immediately.  I hope you, and
all of our other list participants, can comment on that draft as soon
as possible.  It contains some of the most basic features for content
negotiation, and getting it right is vital to the success of this effort;
it also gives a chance to see how actual registrations fit the procedures
we've created, before they are fully and finally set.
	Thanks very much for you close readings,
			regards,
				Ted Hardie
				NASA/STX

On Sep 9,  6:44pm, Graham Klyne wrote:
> Subject: draft-ietf-conneg-media-features-01.txt

---

From: [email-masked] (Ted Hardie)
Date: Wed, 9 Sep 1998 14:41:45 -0700 (PDT)

I have made comments on Graham's proposals below; let me state
at the outset, though, that solving this problem will greatly increase
the utility of what we are doing and that it deserves careful
attention.
		regards,
			Ted Hardie
			NASA/STX

On Sep 9,  6:47pm, Graham Klyne wrote:
> Subject: Handling closed sets of feature values
> All,
>

Your font examples are quite enough to demonstrate to me that we
cannot do nothing.  If we do we will either end up with a ridiculously
large set of feature tags or a system which flat does not work.

> (where '<=' operates as a subset comparison)

Just to make sure that the use of these symbols in this context does
not confuse, let me translate this into English as:

Recipient capabilities
(Fonts available are {"Times", "Swiss"})

Matching document predicate
(Fonts required are {"Times", "Swiss"})

Non-matching document predicate
(Fonts required are{"Times", "Rarity"})

I am afraid I don't quite understand above when you say that
the resulting set will be partially ordered.  Can you clarify
that?

> prodcess by changing it away from being a simple process of pure logical

I think we are going to have enough problems with preference indicators
that using a required tag to indicate set values is a bad idea.

> Defining exact rules to make this work could be a challenge.

I can't see how it would work at all for tags in the faceted group.  How
will someone using a u. feature tag create or indicate that a tag was
part of one of these schemes?

> locating the auxiliary predicate.  I view this as a 'cleaner' version of

This clearly would work better for the faceted groups, because the
definition would take place prior to the use of the auxilary predicate,
but within the same exchange.

My first take is that (b) and (e) are the most promising candidates,
and that (b) looks simpler than (e).  Which would you see as easier
to fit into the larger construct?
			regards,
				Ted Hardie
				NASA/STX

---

From: [email-masked] (Koen Holtman)
Date: Tue, 15 Sep 1998 19:25:36 +0200 (MET DST)

>(a) Do nothing.  It may be that the problems are not serious in practice.

(a) is not that bad in my view. Transparent content negotiation has no
way for the recipient to indicate the *no others* on the wire, but I
have never found a use case where the recipient would need to indicate
that.

Note that there does exist a clear "and no others" concept in the
algebra used by TCN: this is in user agent feature sets (see section
6.2 of rfc2295), which never appear on the wire. Your predicate

would correspond to a feature set like
      { ( "frames" , { } ) ,
        ( "font"  , { "times" , "swiss" } ),
        [lots of other (tag,set of tag values) tuples here]
      }
and when the feature predicate
     {features font=times font=rarity}
is evaluated against the above feature set, the result is false.

Speaking from my background in symbolic logic, it is advisable to have
an algebra in which it is possible to say things like "all these
atomic predicates are true and no others are true", and to build your
semantics on top of such statements.  If you try to go for a system
which has no concept of "these are true and all the others are false",
not even on a meta level, you end up with something that may work for
negotiation, but will be too difficult for the average user to
understand and for the average program to bother implementing.

I do not know if the above is actually helpful, and in any case I must
admit that it has been a while since I read a version of the algebra
draft, so feel free to ignore this message.

Koen.