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

From: Graham Klyne <[email-masked]>
Date: Tue, 10 Nov 1998 20:12:19 +0000

All,

I note that IETF last-call for -media-features- has ben issued.  The points
raised below were posted in a message on 5th October, and I have not yet
seen any response to these.  I have slightly expanded some points from the
original posting.

#g

>2. Media Feature Registrations
>
>This section defines several media features, using the form
>specified in [REG].
>
>2.1 Image Size
>
>   - Media Feature tag name(s): 
>
>     pix-x
>     pix-y

As discussed elsewhere, I have doubts about size measured in pixels.

I would prefer physical units (or equivalent) to be used.  The reason is
that this would often help to simplify compound capability descriptions.

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.

[...]
>   - Values appropriate for use with this feature tag:
>
>     Signed Integer

Er... why *Signed*?

>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?
     
[...]
>   - Summary of the media features indicated by this feature tag:
>
>     This feature indicates the resolution that the recipient can
>     display or print without loss, measured in pixels per inch.
>     Typically resolution capability is represented as dots-per-inch
>     rather than in SI units [SI]. Values for dpi may be expressed as
>     a rational to accomodate resolution of SI-based devices; for
>     example dpi=19558/100 can be used to represent a resolution of 77
>     dots per centimeter.
>  
>   - 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.

[...]
>2.3 Registration of 'media'
>   - Media Feature tag name(s):

Minor formatting inconsistency: missing blank line.

[...]
>   - Summary of the media features indicated by this feature tag:
>     
>     This feature indicates the recipients device media, indicated
.................................^^^^^^^^^^
I think recipient's or recipients' is meant.

[...]
>2.4 Paper Size
[...]
>   - Examples of typical use:
>     
>     Choosing between a4 and letter size renditions of the
>     same printable document.

Capitialize 'A4'.

>2.5 Color and greyscale     
>   - Media Feature tag name(s):

Minor formatting inconsistency: missing blank line.

>     
>     color
>     grey
>
>   - ASN.1 identifier associated with this feature tag:
>     
>     ***New assignments by IANA***
>     
>   - Summary of the media features indicated by this feature tag:
>
>     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.

Also note:  I post elsewhere another proposal for describing colour
attributes of an image, based on work that has been done for Internet fax.
     
>   - Values appropriate for use with this feature tag:
>     
>     Integer

Qualify as Unsigned.
     
>     Values are typically (but not limited to) 2, 8, or 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.
>     
>   - The feature tag is intended primarily for use in the following
>     applications, protocols, services, or negotiation mechanisms:
>     
>     Web applications may choose between color, greyscale, or binary
>     representations. Fax applications may choose between color
>     and non-color renditions.

By 'binary', I assume bi-level is meant (to borrow the fax terminology)?

Add a note to indicate how bi-level is indicated?

See separate posting about color capability description.

>3. Examples of use of features
[...]
>   dpi<=72
>      indicates a 72 dpi display  

In this case: dpi=72, I think.
    
>   color<=24
>      indicates the display supports 24-bit (8-bit/channel) color.   

Where is 8-bit/channel specified?  I think that is an implementation issue
and should not necessarily be inferred.

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

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 10 Nov 1998 16:40:55 PST

> I note that IETF last-call for -media-features- has ben issued.
> The points raised below were posted in a message on 5th October, and I
have not yet
> seen any response to these.  I have slightly expanded some points from the

I'm sorry to have misfiled your message, or I would have responded
to it before.

> that this would often help to simplify compound capability descriptions.

Graham, the use of pixel sizes to describe screen sizes is widespread,
and the most useful metric for display applications. In fact, no other
measure of size is useful for a display. It is true that in some print
and fax situations, physical size + resolution correspond more directly
to how the product design works or is thought of, but the pixel width
and height is, in practice, the most practical of all of the measures
for a sender to have in order to create the appropriate rendition of
the content.

This is even the case for printed media, e.g., when printing posters
or T-shirts.

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

> >   - Values appropriate for use with this feature tag:

The template only allows a fixed number of choices, and "Positive Integer"
was not one of them.

> As discussed elsewhere, I would like to see differential resolution

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.

> be expressed as a ratio of two integers.

Right, so this issue has been handled.

The editorial issues can be handled by the RFC editor.

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

> attributes of an image, based on work that has been done for Internet fax.

.... as you have done ...

> >   - Values appropriate for use with this feature tag:

Again, I didn't think that was an option. Positive Integer would be better.

> By 'binary', I assume bi-level is meant (to borrow the fax terminology)?

yes.

> Add a note to indicate how bi-level is indicated?

Is that really necessary?

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

> and should not necessarily be inferred.

This should probably say 'e.g.'.

---

From: [email-masked] (Koen Holtman)
Date: Fri, 13 Nov 1998 18:06:47 +0100 (MET)

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

Note that there are some more editorial issues in my comments on the
-02- draft from 23 September, see

http://www.imc.org/ietf-medfree/mail-archive/msg00283.html

I had more or less expected to see a -03- draft fixing these editorial
things but I guess I failed to catch the absence of a revision on the
WG last call.

Please *do* make sure that the dpi= examples will conform to whatever
`rational' syntax will be defined in the registration draft (or
alernatively give examples with integers only), and also that the
following gets resolved:

| The example paper-size=iso-a4 does not conform to the current
| definition of the paper-size tag, it should be paper-size=A4.

I feel that getting all the examples absolutely right is critical.
There will be no end of interoperability problems if some of the
examples are wrong.

Koen.