Subject: Re: RFC 2534 list of ua-media and paper-size values

From: Graham Klyne <[email-masked]>
Date: Fri, 15 Oct 1999 21:08:18 +0100

At 18:10 15/10/99 +0200, Koen Holtman wrote:

>In this particular case, however, I agree that merging them is an
>appropriate way to go currently, as there are no deployed uses of the
>ua-media tag (I know of) yet.

ua-media is cited by RFC 2531 (Internet fax feature schema).  I don't know
about deployment, but I understand there are fax engineers working on it.

>Transforming the ua-media value set into an open-ended set, to which
>new values can be added at will in future even after some deployment,
>is a much bigger step, and one that I would not want to take.  There
>is a definite advantage to application and content authors in having a
>small, stable set of values with a guarantee that, for example, a
>value like 'screen' will not be superceded by 3 alternative other
>values in future.

I agree that superseding existing values would be poor form, but adding new
values for new media is something I would expect to happen over time.

#g

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

---

From: Graham Klyne <[email-masked]>
Date: Fri, 22 Oct 1999 16:47:18 +0100

Robert,

I don't think that's what I'm saying.  Mainly I'm trying to suggest that
different applications (such as HTML display and print) use the same to
describe the same feature.  For example, 'color' is something that I think
applies equally to print and HTML display.

I think that I maybe misinterpreted what you were saying:

For example, the 'color' tag describes colour in a broad sense, but there
are other tags that refine this broad sense for more precise colour
reproduction.  I think you may be proposing a similar approach for "media",
in which case I fully agree.

(In following this path, there is an important principle articulated by
Larry some time ago that should be observed:  the meaning of one feature
tag should never be modified by the presence or value of another.  So care
is needed to ensure that feature tags that refine the meaning given by
other tags do not attempt to impose a fundamentally different meaning to
that given by the other tags.)

#g

At 18:17 20/10/99 -0700, Herriot, Robert wrote:
>Are you suggesting that the "print-media" attribute is too narrow and that
>it implies some more general concepts, such as "media-size".
>
>Perhaps, as Larry suggested, there should be a "media-size" which applies to
>some of the media, e.g. "printer" and "screen", but not to "aural".  For
>printers there could be additional "media" attributes, such as "color" and
>"opacity". If we adopt this solution, the IPP "media" values are names for
>particular "media-size", "color", "opacity", etc.
>
>-----Original Message-----
>From: Graham Klyne [mailto:[email-masked]]
>Sent: Wednesday, October 20, 1999 2:59 AM
>To: Herriot, Robert
>Cc: Conneg WG; Manros, Carl-Uno B; Johan Hjelm; [email-masked];
>[email-masked]
>Subject: RE: RFC 2534 list of ua-media and paper-size values
>
>
>At 18:31 19/10/99 -0700, Herriot, Robert wrote:
>>It doesn't seem reasonable to merge the values of HTML "media" and IPP
>>"media". The former describes media in a large sense. The latter desribes
>>media in the context of a printer.
>>
>>I agree that all of the print related values of RFC 2534 should be
>>deprecated and that the word "print" should be used instead as a value of
>>"media"  It would be reasonable to add a new attribute "print-media" which
>>contains the values of the IPP "media" attribute.
>
>Robert,
>
>This would seem a reasonable approach if one takes a view that it is always
>known a priori in what kind of environment a resource will be used.  But I
>do not share that view.
>
>The original CONNEG work was motivated in part by a desire to have a way to
>express common media features that could used across a range of transfer
>protocol environments.  This in turn, I belive, creates an environment in
>which it becomes easier to build integrated services that use a variety of
>protocols;  e.g. web servers for e-mail collection, IPP for quality
>document transfer, e-mail for fax transmission, etc.
>
>The model that we have evolved for Internet fax, and which I believe could
>usefully be employed in other scenarios, is to use common vocabulary for
>features that are common across a variety of service environments (e.g. per
>RFC 2534), and to develop a more specialized vocabulary for features that
>more more specific to the fax environment.  This approach is realized by
>having the generic feature tags be very broadly defined, and using
>specialized feature tags to refine them (in the sense of constraining
>rather than revising).
>
>In summary, I would suggest resisting a divergence of vocabulary for
>features that are common across a range of services.
>
>#g
>
>------------
>Graham Klyne
>([email-masked])
>
------------
Graham Klyne
([email-masked])