I sent the first draft of the Resource Object Specification to the UPDF
group for their consideration for fonts, etc.
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Saturday, July 08, 2000 12:39
To: upd
Subject: UPD> UPDF and IPP Collaboration - Resource object for fonts
This note is an idea for possible collaboration of the UPDF and IPP work.
Attached is the first draft of an IPP extension for a Resource object and
operations to get the attributes and/or opaque data. The Get-Resources
operation includes a filter mechanism that uses the attributes defined for
the Resource.
Here is the Abstract:
This IPP Get Resource document specifies an extension to IPP/1.0
[RFC-2565] [RFC-2566] and IPP/1.1 [IPP-MOD] [IPP-PRO]. This document
extends the current closed IPP object model with a passive
polymorphic object that is intended to satisfy most needs for new
object types in the long-term evolution of IPP via an extensible
object framework.
This document defines: Resource object (passive polymorphic object);
Resource get operations (e.g., Get-Resource-Attributes); Resource
attributes (e.g., "resource-name"); new Printer attributes (e.g.,
"resource-type-supported"); Resource type of Driver (a morph of the
Resource object); methods for supporting 'driver download' to IPP
Client systems.
The Resource object has a number of REQUIRED and OPTIONAL attributes that
are independent of the resource type. We envision that one such resource
type would be 'font'. Each resource type would also define additional
attributes that are specific to that resource type. One of the Resource
attributes is resource-document-formats (1setOf mimeMediaType) which
indicates which document-formats each Resource instance is defined for,
e.g., 'application/postscript', 'application/vnd.hp-PCL', etc. So a client
could filter on the "resource-document-format" attribute to list, say, only
the PostScript fonts.
The resource data for a Resource object instance is envisioned being a
collection of files, packaged as a single file, using, say, zip. Thus font
metrics and font data could be separately represented. The IPP WG needs
review by the UPDF WG to see if the basic mechanism is a good foundation for
fonts and would meet your requirements for defining the 'font' resource
type. For example, the attributes for different types of fonts needs to be
different (we understand that the attributes for PostScript fonts and PCL
fonts have something in common, but a lot that is different).
Questions for the UPDF WG:
1. Is the basic framework sufficient for fonts?
2. Would you like to define the attributes for a 'font' resource-type?
3. For which document-formats?
4. What about other resources, such as device constraints?
<draft-ietf-ipp-get-resource-00.doc>