Subject: Re: Comments on draft-ietf-conneg-media-features-02.txt

From: Graham Klyne <[email-masked]>
Date: Tue, 29 Sep 1998 14:47:00 +0100

At 19:09 28/09/98 +0200, Koen Holtman wrote:
[...]
>>>dpi values are supposed to be 'rational'. You give the example
>>>dpi=19558/100 which is a fraction.  I an quite surprised by this
>>>because I thought that rational meant 'floating point', as in
>>>dpi=195.58 .  I guess maybe this is more of a registration draft
>>>problem.
>>
>>I always understood "rational" to mean "expressible as a ratio of two
>>integers" (which includes all fractions and non-recurring decimals), as
>>opposed to "irrational" that means numbers like SQRT(2) and PI and E that
>>cannot be so expressed.
>
>Do you assume any standard notation for rational numbers?

No.  But I note that (non-recurring) decimal notation is not sufficient.
E.g. 1/3.  I also note that the fractional form (n/m) is sufficient if
there are no limits on the size of n and m.

In practice, the fixed-point decimal notation seems to be adequate for many
purposes.

>[....]
>To me 'textonly' would also include
>things like speech and braille devices.
[...]

Good point.

>I guess that most web sites would only provide a single textonly
>version of a page, if any.  Nobody would sub-negotiate on things like
>overstrike.

Factors in a 'textonly' document that are sometimes important to its
display are typically page width, page height (in characters) and whether
or not it assumes a proportional font.  This comment is based largely on
issues I observe in printing and using Internet drafts, RFCs, etc.  Also,
whether the text includes line breaks or assumes that the receiver will wrap.

But I can live with your position.  Whether one would wish to negotiate on
these things is certainly questionable.

#g

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

---

From: Al Gilman <[email-masked]>
Date: Tue, 29 Sep 1998 11:31:22 -0400 (EDT)

[Sorry not to have read the background for this.  Hope I get a
chance to do so.  But there seem to be some over-limiting
assumptions being made here w/o consulting those who would know
(not meant to mean me) - Al]

> these things is certainly questionable.
Au contraire.

Audio users are interested in document forms containing a
mix of sound files and text.

Braille users will be interested in some graphics particularly
for quantitative and technical topics.

You may be thinking of a "text-ready" class of things like
web pages where the text suffices for the basic function of
the doucument.  This is often what the user cares about and
is applicable to some graphical pages as well as well-done
text-only pages.

I think that the basic bug in this thread is that alternatives to
be negotiated on are thought of as pre-compiled canned files.
How much have you considered the possibility that HTTP
negotiation could take market share away from CGI parameters?  Or
that CGI services might want to use the properties in the media
features vocabulary as parameter types by preference?

If one includes on-the-fly generated documents, the range of
features on which one would be interested in negotiating
skyrockets.  Braille users would want to indicate the grade level
of contraction to be applied, for example.

Al

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 29 Sep 1998 10:25:03 PDT

I think the issues of 'text only' content negotiation are sufficiently
complex and affect a sufficiently different review article that 
'textonly' features should be handled in a separate media feature document.

I've always assumed 'rational' meant 'expressed as a ratio' and suggest
that the registry draft be updated to make that determination. Even if you'd
prefer decimals, 256/100 == 2.56 easily enough.
Larry
--
http://www.parc.xerox.com/masinter

---

From: Al Gilman <[email-masked]>
Date: Tue, 29 Sep 1998 14:23:53 -0400 (EDT)

> 'textonly' features should be handled in a separate media feature document.

Amen.  Good suggestion.  I concur.  I have this fuzzy notion of
the severability of text-centric issues such as i18n and
layout-centric issues such as characterizing the print/display
resource.  You said it better.

Al

---

From: [email-masked] (Koen Holtman)
Date: Wed, 30 Sep 1998 13:10:51 +0200 (MET DST)

>'textonly' features should be handled in a separate media feature document.

Hmm, I think that would be overkill.  I think I'll just register my
textonly tag when the registry is open.  I am interested in the use
case of labling the version best suited for lynx/speech/braille users,
in the limited scenario of a (web) server that has a few static
versions available.  I am not interested in writing a document that
provides tags for the server-side fine-tuning of rendering on
terminals, braille devices etc.  I think the internet community needs
a textonly tag on a short term basis, while there is no big need for
server-side fine-tuning of textonly content.

This still leaves us with my observation that the draft would be
better as a style guide if a boolean tag were included.  Any ideas on
less controversial boolean tags?

>prefer decimals, 256/100 == 2.56 easily enough.

Let me put it this way: I think the registration draft either needs to
define a standard (ASCII) representation for the rational type, or else
it needs to declare explicitely that the choice of representation is
left to the individual negotiation protocols using such tags.  I would
prefer if a standard representation were defined, as this is better
for overall interoperability.

Question to the chair: I see that the -registration- draft is now in
IESG last call.  Do you want me to announce/forward the above comment
in a more formal way?

>Larry

Koen.

---

From: Al Gilman <[email-masked]>
Date: Wed, 30 Sep 1998 07:54:31 -0400 (EDT)

to follow up on what Koen Holtman said:

> versions available.  

For that, you may as well use media=tty in the vernacular of HTML 4.

   Linkname: Basic HTML data types
        URL:
     http://www.w3.org/TR/REC-html40/types.html#type-media-descriptors

Al

---

From: [email-masked] (Koen Holtman)
Date: Wed, 30 Sep 1998 14:04:38 +0200 (MET DST)

Al Gilman:
[....textonly....]
>be negotiated on are thought of as pre-compiled canned files.

Well, I am only interested in that particular use case, but I consider
that to be a feature, not a bug.  I feel that this single use case is
important enough by itself.

>features vocabulary as parameter types by preference?

Such things were considered quite carefully some time ago before the
TCN drafts gelled.  See section 9 of RFC2295

http://gewis.win.tue.nl/~koen/conneg/rfc2295.html#4.9

and in particular appendix 19.3B (Server-side rendering engines) in an
older draft:

http://gewis.win.tue.nl/~koen/conneg/draft-holtman-http-negotiation-04.html#19.3B

Basically the idea is to that to save bandwidth, we should discourage
server-side fine tuning and encourage client-side fine tuning.  Aside
from bandwidth, this also seems to be where the market is going, both
in the mainstream and in niche markets for access by the disabled.  It
is easier to have a specialised speech or braille converter in a
single custom browser than to have it incorporated in all existing web
sites.  So I don't think the case for server-side tuning tags is that
compelling.

Koen.

---

From: Al Gilman <[email-masked]>
Date: Wed, 30 Sep 1998 08:25:26 -0400 (EDT)

> TCN drafts gelled.  See section 9 of RFC2295

Thanks for the references.
> sites.  So I don't think the case for server-side tuning tags is that

That is your perception of the market trends, is it?  I am not
sure I know which way that wind is blowing.  And I do think the
end-user is better served if the technology platform offered by
the standards does not try to outguess the market on points like
this, but tries to support all (patterns of functional allocation
for this service) in the competitive range.  I have seen too many
technology candidates straggle onto the library shelves down a
road paved with "we should discourage" stepping stones.

This gets back to my prior point, that the vocabulary in
negotiating on this topic between HTTP client and HTTP server
should be drawn from the vocabulary used by the Braille-device to
HTTP-client negotiation.  We need one mechanism for amassing the
necessary vocabulary for all negotiations along the path of the
information; not a peculiar stunted vocabulary that only serves
the HTTP segment.

Al

---

From: [email-masked] (Ted Hardie)
Date: Wed, 30 Sep 1998 18:11:19 -0700 (PDT)

> IESG last call.  Do you want me to announce/forward the above comment

No, there is no need to forward the comment in any special way; it
counts as "comments received during the last call period" because
it was made to the list.

I will do some research on how other protocols represent rational
numbers and ping IANA on their preferences (I assume they would
be relieved to have a technical question for a change....).

		regards,
			Ted Hardie
			NASA/STX