RE: RFC 2534 list of ua-media and paper-size values
"Herriot, Robert" <[email protected]> Wed, 20 Oct 1999 18:17:20 -0700
| Newsgroups | gmane.ietf.medfree |
|---|---|
| Message-ID | <51B8ABCE456FD111899900805F6FD6EE054BCE41@MERCURY> |
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 protected]] Sent: Wednesday, October 20, 1999 2:59 AM To: Herriot, Robert Cc: Conneg WG; Manros, Carl-Uno B; Johan Hjelm; [email protected]; [email protected] 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 protected])