Subject: RE: draft-ietf-conneg-media-features-02.txt; LAST CALL comments

From: Graham Klyne <[email-masked]>
Date: Wed, 11 Nov 1998 16:33:44 +0000

At 16:40 10/11/98 PST, Larry Masinter wrote:
[...]
>I'm sorry to have misfiled your message, or I would have responded
>to it before.

I guessed as much.

>> >2.1 Image Size
[...]
>Graham, the use of pixel sizes to describe screen sizes is widespread,
>and the most useful metric for display applications.

I feel this is a very display-centric approach to media feature description...

[...]
>> Specifically, when a device offers several different resolutions these do
>> not usually correspond to a change in physical display size supported.  If
>> size is to be measured in pixels, a different size must be associated with
>> each supported resolution.
>
>The convenience of representation for multiple possible resolutions I think
>should take second priority to good fidelity representation of the
>capabilities
>of the device. Yes, you're right, it's more inconvenient to describe
>in -algebra- such combinations, but I think this is a difficulty with
>-algebra-, not a difficulty with the proposed media features.

I agree that good fidelity representation is the primary goal here.  But I
disagree that that has to be sacrificed if image sizes are related to some
physical size.

Further, I don't see the "inconvenience" as being a problem with the
algebra:  to me it seems a fundamental property of pixel+resolution
descriptions in a world where physical dimension is often constant.

You argue that there are circumstances when physical dimensions are
meaningless (e.g. displays).  I would argue that there are also
circumstances when pixel dimensions are equally meaningless (e.g. pen
plotters, non-raster image data).  Thus, if we choose two out of three
possible media features (physical size, pixel size, resolution) then there
will be circumstances in which one of the features will be somewhat
artificial (e.g. a notional screen size, or some notional pixel dimension).

A "compromise" way out of this would be to define both pixel- and
phyisical- dimensions, and allow an application to choose what it uses.
But I would prefer to find a consensus that satisfies our various
desiderata without creating duplicate ways to express the same feature set.

One approach I heard about was to use pixels/resolution as a measure.  I
like that approach very much, as in the absence of a resolution (the
natural case for a display image) the value can be interpreted as a pixel
size.  But when known physical dimensions are involved, the value is
related to those.

>> [...]
>> >   - Values appropriate for use with this feature tag:
>> >
>> >     Signed Integer
>>
>> Er... why *Signed*?
>>
>
>The template only allows a fixed number of choices, and "Positive Integer"
>was not one of them.

Not as such, I agree.  I was remiss in not checking the registration
template when IO wrote that.

But there is the following:

    | If there is a limited useful numeric range of result (2b, 2c), 
    | indicate the range.

I think it may be appropriate to indicate the useful range as >0.

>> >2.2 Resolution
>> >
>> >   - Media Feature tag name:
>> >
>> >     dpi
>>
>> As discussed elsewhere, I would like to see differential resolution
>> addressed in some way.
>>
>> The -fax-schema- draft contains such a proposal, which finds general
>> acceptance in the fax WG.  Should this be part of this "core" of media
>> features, since it is clearly not specific to just fax?
>
>This went back and forth in the discussion and in the draft.
>My impression is that while legacy fax devices have differential
>resolution in the two dimensions, this isn't actually common.

I am broadly happy with this:  I just wanted the final position to be
clearly recorded on the list.  Some of the fax-schema work has been
relatively recent compared with the media-features draft, so I thought it
could be helpful to bring experience from that work into this discussion.

For the fax-schema (in its current form), a new feature tag 'dpi-xyratio'
is introduced that allows differential resolution to be expressed.  Using
the 'n/m' notation for rational values, this allows a near direct
representation of x- and y- resolutions;  e.g. 204x391 dpi can be expressed
as:

    (& (dpi=204) (dpi-xyratio=204/391) )

>> [...]
>> >   - Values appropriate for use with this feature tag:
>> >
>> >     Rational
>>
>> As discussed elsewhere, I think we need to indicate somewhere (not
>> necessarily this document) an appropriate syntax for
>> rational/real numbers.
>
>> The -feature-syntax- draft now contains 'n/m' syntax for rational
>> values to
>> be expressed as a ratio of two integers.
>
>Right, so this issue has been handled.

Fine.  I just wanted to be clear what we were doing.

>The editorial issues can be handled by the RFC editor.

OK.

>> >     color
>> >     grey
[...]
>> >
>> >     The color capabilities of the recipient are indicated with
>> >     feature value describing the number of color (or greyscale)
>> >     channel bits available.
>>
>> I would prefer number of levels rather than number of channel bits.
>>
>> I believe that the use of channel bits for measuring colour depth is too
>> implementation-specific:  there are devices that offer a number of colour
>> levels that is not an exact power of 2.
>
>I know there are a few such devices, but
>
>a) they are not common; the goal isn't to capture the exact nuances
>   of all possible devices, but to simply describe those characteristics
>   that are common. How many color levels are there with 24 channel bits?

Off the top of my head:  about 16 million.

I feel that in this you are contradicting the point you made previously
with respect to image size when you said "...convenience of
representation...should take second priority to good fidelity...".

I would argue that such display systems are not uncommon:  for physical
devices, there are pen plotters (which is just a physical realization of
palettized colour, so still follow the model used for many color display
systems).  More importantly, I recall from the times when I used to program
Windows GDI interfaces, when using an 8-bit device-independent-bitmap, 16
of the available 256 palette slots are reserved for predefined colours, so
may be effectively unavailable for some image display applications.  Also,
on systems that use a hardware palette (such as many PC display systems)
the actual number of colors used might be important to determine whether
two more more separate images can be rendered on the same physical display.

>b) in the cases where there are a small number of color levels, the
>   characteristics of the device are not sufficiently captured merely
>   by enumerating the number of color levels. A finer level of description
>   is required. So changing this to "number of color levels" won't actually
>   help without additional attributes.

This is true to a lesser or greater extent irrespective of the number of
colour levels available.  Hence the proposal noted and posted separately
for dealing with colour representation.

>> >   - Values appropriate for use with this feature tag:
>> >
>> >     Integer
>>
>> Qualify as Unsigned.
>
>Again, I didn't think that was an option. Positive Integer would be better.

Yes.  By which I understand: indicating a useful range >0.

>> >3. Examples of use of features
>> [...]
>> >   dpi<=72
>> >      indicates a 72 dpi display
>>
>> In this case: dpi=72, I think.
>
>I suppose; the original idea was that the device was capable of
>rendering any image that required dpi of 72 or less, with some
>amount of inaccuracy in the image size. (A 72 dpi display can
>display a 36 dpi image.)

If that is what you meant, then I agree.

I would take the approach that the display resolution is fixed, and that
image would indicate the minimum resolution that it needs.

Also, I note that:
    dpi<=72
is not the same as:
    dpi=[72,36]

#g

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

---

From: [email-masked] (Koen Holtman)
Date: Tue, 17 Nov 1998 18:36:42 +0100 (MET)

Graham Klyne:
[...]  
>   Thus, if we choose two out of three possible media features
>(physical size, pixel size, resolution) then there will be
>circumstances in which one of the features will be somewhat
>phyisical- dimensions, and allow an application to choose what it
>uses.  But I would prefer to find a consensus that satisfies our
>various desiderata without creating duplicate ways to express the
>same feature set.

I would prefer this "compromise" of having all three over having just
two, even if having just two can be made to work (and we have seen
that this is not easy).  In the web scenarios I have in mind, having
all three would be easier on content authors: they can always use the
tags which most naturally describe their content.

One could argue that having three tags which are non-orthogonal would
be more difficult on negotiation protocols.  However, if you are going
to make an extensible negotiation protocol coupled to an essentially
open registry like the feature tag registry, you will have to deal
with non-orthogonality anyway, because sometime, probably very soon,
someone is going to register a tag that is non-orthogonal to other
existing tags.

Now, in the case of fax negotiation, maybe orthogonality of tags
(which implies that any feature set can be expressed in only one way)
is more desirable than extensibility of the tag set by an open
process.  But in that case I would argue that fax negotiation should
not focus on the initial set of features for the feature tag registry
created by the conneg group.  In that case the fax group should define
a closed `fax feature set', with very strict rules for extensibility.
Of course the resulting fax tags should be put in the more open conneg
registry too, but that is besides the point.

On a historical note: The MIME type namespace used to be a fairly
closed one, in that it was difficult to add a new type unless it was
fundamentally different from other types.  This closedness was the
best way to go for e-mail, the intended application for MIME.  Some
believe however that re-using the closed MIME namespace for the web
significantly hurt the web, for example because the closedness blocked
one easy route to sub-negotiation on HTML versions.

The point is that different negotiation protocols (like web and fax
negotiation) could end up hurting each other if they share the same
registration procedure while they really need different ones.  I don't
know enough about fax to tell if there is a real need for a procedure
more restrictive than the one envisaged for the web, but this is
something we need to find out before we proceed with a single
procedure.  A shared namespace is always good, but maybe getting a
`web seal of approval' on a tag should be a different procedure from
getting a 'fax seal of approval'.

Koen.