IPP Mail Archive: IPP> More on UPDF and IPP Collaboration

IPP> More on UPDF and IPP Collaboration

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Sun Jul 09 2000 - 13:31:58 EDT

  • Next message: don@lexmark.com: "RE: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and Printer A dmin (Set2) spec"

    I wasn't very clear in my previous note about UPDF and IPP Collaboration.

    1. Firstly, there are lots more areas for collaboration that just fonts. It
    should be possible for a driver that interprets a UPDF file to generate an
    'application/ipp' MIME type payload for a Print-Job request that conforms to
    IPP/1.1. Also a UPDF file for IPP/1.0. See (1)
    <draft-ietf-ipp-model-v11-07.txt> and <draft-ietf-ipp-protocol-v11-06.txt>
    and (2) RFCs 2566 and 2565, respectively.

    2. For fonts, the area of collaboration is to have a semantic description of
    the font attributes, such as the ones that describe the font and the ones
    that describe the font metrics. This semantic description would have
    several parts:

      a. Attributes that are common to all fonts
      b. Attributes that apply to a particular document format, such as
    Postscript or PCL

    3. Then these semantic description documents would have separate encoding
    documents:

      a. IPP encoding for use in the Get-Resource-Attributes, Get-Resource-Data,
    and Get-Resources operation requests and responses.

      b. XML encoding for use by font vendors when publishing their fonts and
    for use in a UPDF file for use by Printer vendors when publish their UPDF
    Printer Description files.

    Tom

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@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?

     <<UPDF and IPP - resource object.doc>>



    This archive was generated by hypermail 2b29 : Sun Jul 09 2000 - 13:41:37 EDT