IPP Mail Archive: RE: IPP> RES - Updated Resource [bad dates

RE: IPP> RES - Updated Resource [bad dates in filenames]

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Thu Sep 07 2000 - 14:56:38 EDT

  • Next message: Hastings, Tom N: "IPP> REG - Proposal for "job-recipient-name" Job Template attribute"

    Hi folks,

    As you'll see below, Tom dated the '.pdf' and .'doc' files
    '-000901' (1 Sept) and not '-000907' (7 Sept).

    To avoid confusion I copied the binary of the '.pdf' down
    and put it back WITHOUT a date infix with the simple name:

    draft-ietf-ipp-get-resource-01.pdf

    This shorter filename is reflected in my release note of a
    few minutes ago.

    Good luck next week in Chicago.

    Cheers,
    - Ira McDonald, consulting architect at Xerox and Sharp
      High North Inc

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Thursday, September 07, 2000 11:14 AM
    To: ipp (E-mail)
    Subject: IPP> RES - Updated Resource object spec down-loaded

    Ira and I have updated the Resource objects paper from the last meeting for
    consideration at the Chicago meeting.

    The Resource object is a passive object that has defined types: 'font',
    'form', 'image', 'logo', and 'media'. Some of these object types are just
    attributes, such as 'media', and some include attributes and data, such as
    'font' and 'image'. Additional resource types could be defined for such
    things as ICC Color Profiles, Imposition Templates, etc.

    This spec does NOT contain any resource type specific attributes. They will
    be defined in separate documents, analogous to the way we've done with the
    Notification spec and the Notification Delivery Method documents.

    We've removed the driver download as one of the resource types, since the
    IPP WG agreed at the July meeting to go with Hugo's proposal that is
    specific to drivers.

    We've tried to build on the models of the Job and Subscription objects and
    their operations.

    This spec has REQUIRED operations: Get-Resource-Attributes,
    Get-Resource-Data, and Get-Resources.

    We've also added a second OPTIONAL package of administrative operations:
    Create-Resource, Renew-Resource, Refresh-Resource, and Delete-Resource.

    The documents are available at:

    ftp://ftp.pwg.org/pub/pwg/ipp/new_RES/draft-ietf-ipp-get-resource-01-000901.
    doc
    ftp://ftp.pwg.org/pub/pwg/ipp/new_RES/draft-ietf-ipp-get-resource-01-000901.
    pdf
    ftp://ftp.pwg.org/pub/pwg/ipp/new_RES/draft-ietf-ipp-get-resource-01.txt

    Here is the Abstract:

       This document is a submission to the Internet Printing Protocol
       Working Group of the Internet Engineering Task Force (IETF). The
       open issues in this document each begin 'ISSUE_n:'. Comments should
       be submitted to the ipp@pwg.org mailing list.
       
       This IPP Resource Objects 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 IPP object model with a passive polymorphic
       object type - Resource - to support the long-term evolution of IPP.
       
       This document defines:
       - Resource object (passive polymorphic object);
       - Resource query operations (e.g., Get-Resource-Attributes);
       - Resource admin operations (e.g., Create-Resource);
       - Resource template attributes (e.g., "resource-charset");
       - Resource description attributes (e.g., "resource-name"); and
       - new Printer attributes (e.g., "resource-type-supported").

    There are a number of issues:

         ISSUE_1: The target of all IPP Resource operations is always
         simply "printer-uri" and separate required operation attributes are
         used to specify resource type and name or ID. This is like IPP
         Subscription objects but unlike the earlier IPP Job objects.
         Should we continue to follow the IPP Subscription object model?

         ISSUE_2: What mechanism should we use for filters, multiple Resource
         Attribute Groups, collection, some subset of LDPA filters, other?

       ISSUE_3: Should we require that Resource object instances are always
       returned sorted by "resource-id" (as stated above) and not by
       "resource-name" (more user-friendly). Should we add an operation
       attribute to control the choice of sort order?

         ISSUE_4: Should we make Resources more like Subscriptions (and Jobs)
         and just drop the "requested-attributes" from all of the Resource
         admin operations? Then "requested-attributes" would only be
         permitted in the Resource query operations.

       ISSUE_5: This 'lazy refresh' behavior may have performance and
       'stale data' consequences for IPP Clients. Because the manufacturer
       may also be slow to inform installed IPP Printers of a new version of
       a Resource (for update by means outside of this specification) the
       'stale data' problem may also apply to IPP Printers. Should we add
       an operation attribute to PREVENT this 'lazy refresh' behavior?



    This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 15:09:16 EDT