IPP Mail Archive: IPP> NOT - Updated Notification Specificat

IPP Mail Archive: IPP> NOT - Updated Notification Specificat

IPP> NOT - Updated Notification Specification down loaded

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Tue Mar 07 2000 - 20:18:02 EST

  • Next message: Hastings, Tom N: "RE: IPP> NOT - Few minor remaining issues in IPP Notification Spe c"

    I've updated the Notification Specification as agreed at the February IPP WG
    meeting and on the mailing list. The documents are available at:

    ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000306.doc
    ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000306.pdf
    ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000306-rev.doc
    ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000306-rev.pdf

    There are 5 minor issues (and one major one). I'd like to resolve all but
    ISSUE 02 before making the next Internet-Draft Wednesday or Thursday. We
    want to do an IPP WG Last Call on that Internet-Draft.

    Here are the issues:

    ISSUE 01 - Ok to include the notification delivery scheme names 'ipp:',
    'indp:', 'mailto:', and 'snmp:' that are in progress as example values of
    the "notify-recipient" (uri) attribute?

    ISSUE 02 - Once a number of delivery solutions have been developed and
    evaluated, we may want to make one or several of them REQUIRED for
    implementation to ensure a minimum set of interoperability. Which one or
    ones should be REQUIRED?

    ISSUE 03: OK to allow the "persistent-jobs-supported" (boolean) Printer
    Description attribute to be settable?

    ISSUE 04: OK to allow the "persistent-subscriptions-supported" (boolean)
    Printer Description attribute to be settable?

    ISSUE 05 - Can an implementation extend the Notification Content to include
    an attribute that uses the 'collection' attribute syntax? If so, should we
    REQUIRE that Notification Recipients that can accept Machine Consumable
    Notifications, be able to accept the 'collection' attribute syntax?

    ISSUE 06: Ok that "notify-charset" and "notify-natural-language" member
    attributes don't follow the "xxx-supported" rule for collection member
    attributes, since the "xxx-supported" attributes are "charset-supported" and
    "generated-natural-language-supported", respectively, instead of
    "notify-charset-supported" and "notify-natural-language-supported"?

    18.1 Changes to the February 2, 2000 version to create the March 6, 2000
    version
    The following changes were made to the February 2, 2000 version to create
    the March 6, 2000 version based on the agreements reached on the mailing
    list, at the February IPP WG meetings, and reflected in the minutes:
    1. Clarified that this extension is intended as an extension to
    IPP/1.0, IPP/1.1, and future versions.
    2. Allocated the operation-id 0x0016 to 0x001B values for the
    Notification operations defined in the document.
    3. Pre-pended the word "subscription-" on the front of the "request-id"
    Subscription object attribute to distinguish it from the "request-id"
    parameter that is sent in every request and response.
    4. Added the term "settable" for describing attributes that are not
    READ-ONLY.
    5. Added the term "Subscription Creation operation" to stand for any
    operation that can create a Subscription object: Job Creation operations
    (Create-Job, Print-Job, and Print-URI), Create-Job-Subscription, and
    Create-Printer-Subscription.
    6. Changed the "subscriber-user-name" (name(MAX)) Subscription object
    attribute from OPTIONAL to REQUIRED.
    7. Changed the name and semantics of
    "notify-printer-up-time(integer(1:MAX)) to notify-server-up-time so that it
    can be either the Printer's uptime or a Notification Delivery Service
    uptime.
    8. Added the 'ipp:', 'indp:', 'mailto:, and 'snmp:' notification
    delivery schemes to the definition of the "notify-recipients" to indicate
    possible schemes.
    9. Changed the name and semantics of "notify-text-format"
    (mimeMediaType) to "notify-format" so that it can be used to specify either
    Human Consumable or Machine Consumable formats where the implementation
    supports both. Clarified that this attribute controls whatever variable
    Notification Content that the implementation supports, which may be an
    attachment to the fixed content format or the contents of the
    "human-readable-report" (text(MAX)) attribute. Clarified that an
    implementation NEED NOT support all of its supported Notification Content
    formats with all of its supported delivery methods.
    10. Added 'text/xml', 'application/ipp', 'application/postscript', and
    'image/tiff' and additional example MIME media types for "notify-format"
    (mimeMediaType).
    11. Clarified that the recommend way for a client to determine whether
    or not a Printer supports Per-Job Subscriptions is to query the Printer's
    "max-job-subscriptions-supported" attribute, since Create-Job-Subscriptions
    is an OPTIONAL operation.
    12. Clarified that the recommend way for a client to determine whether
    or not a Printer supports Per-Printer Subscriptions is to query the
    Printer's "operations-supported" attribute to see if the
    Create-Printer-Subscriptions operations is supported, since this is the
    usual way to determine a Printer's capabilities.
    13. Clarified that if "persistent-jobs-supported" (boolean) and
    "persistent-subscriptions-supported" (boolean) are settable, then setting
    them must affect whether or not jobs and subscriptions are persistent.
    14. Allowed delivery methods to send operations with or without a
    response, depending on the definition of the delivery method.
    15. Indicated that a deliver method definition is free to REQUIRE that
    the client supply the "subscriber-user-data" attribute.
    16. Required that the Printer support the "job-uri" operation attribute
    as a target, in addition to "printer-uri"&"job-id", i.e., keep consistent
    with all Job operations.
    17. Changed the 'none' out-of-band value to be a reference to the
    collection document [ipp-coll], since the use for it in this document is
    with the 'collection' attribute syntax.
    18. Clarified that a conforming implementation MUST support the
    'collection' attribute syntax, since that is required in Job Creation
    operations.
    19. Allocated the values to the new status codes defined in this
    document.

    20. Allocated the [ipp-pro] subscription-attributes-tag and
    notification-attributes-tag delimiter tags to delimit Subscription
    attributes and Notification Content attributes in requests and responses.

    21. Changed the 'server-error-too-many-subscriptions' and
    'server-error-too-many-events' to be client errors, i.e.,
    'client-error-too-many-subscriptions' and 'client-error-too-many-events',
    since other errors of this type are client errors.



    This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 20:24:12 EST