IPP Mail Archive: RESEND: IPP> NOT - Notification Specificat

IPP Mail Archive: RESEND: IPP> NOT - Notification Specificat

RESEND: IPP> NOT - Notification Specification posted

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Jun 30 2000 - 04:15:32 EDT

  • Next message: Satoshi Fujitani: "RE: IPP> ADM - Pick your favorite notification delivery method by July 7"

    We hurried the final proof reading a little too much in order to give people
    copies of the spec before they left for vacations this Friday. We found a
    small number of small glitches in what we posted yesterday. So we've
    re-posted the documents tonight. Sorry about that. The issues and change
    history are unchanged.

    There is a version with revisions to show these minor fixes from the June 29
    version posted yesterday. There won't be any further updates, except to
    resolve the issues in the document and any other issues raised by you.
    Please read this document. Initial feedback is that it is greatly improved
    from the May version. It should significantly help implementers for the
    interoperability bakeoff in October.

    The files are available at:

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

    Tom and Bob

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Thursday, June 29, 2000 02:37
    To: ipp
    Subject: IPP> NOT - Notification Specification posted

    Bob and I have gone over the Event Notification Spec with a fine toothed
    comb and have made an effort to shrink the size of the document. The
    important part of the specification is contained in the first 55 pages.

    There is no version with revision marks, since the document was edited so
    heavily. The Change History is shown below. There are also 7 minor issues,
    mostly asking to see if you agree with additions or changes we made in
    carrying out the agreements from the NYC meeting and telecons.

    The files are located at:

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

            Changes to the May 10, 2000 version to create the June 29, 2000
    version
    The following changes were made to the May 10, 2000 version to create the
    June 29, 2000 version based on the agreements reached at the May IPP WG
    meetings and subsequent teleconferences:
    1. Editorially reorganized and revised the document so that information
    is stated only once. Moved supplementary material to appendices.
    2. Cleaned up the terminology so that it is used consistently
    throughout the document; capitalized such terms. Simplified the
    descriptions of each term.
    3. Recast the Subscription attributes to be Subscription Template and
    Subscription Description attributes following the IPP/1.1 model for Jobs.
    Therefore, a few attribute names were changed to make them consistent.
    4. Reworked the operation descriptions to align with the style in
    [ipp-mod].
    5. Made the validation and processing of Subscription Template
    attributes be the same for Job Creation Operations,
    Create-Job-Subscriptions, and Create-Printer-Subscriptions operations (and
    defined in one place) and as similar to validation of jobs as possible
    (though there are some differences since one request can generate multiple
    Subscription objects.
    6. Clarified the error handling for all operations.
    7. Removed the "notify-text-format" and "notify-additional-formats"
    Subscription Template attributes and added the "notify-job-id" Subscription
    Description attribute.
    8. The client can supply one or more Subscription Template Attribute
    Groups in all Subscription Creation requests and the printer returns
    Subscription Object Attributes groups for each Subscription object created.
    Consequently, an "s" was added to Create-Job-Subscriptions and
    Create-Printer-Subscriptions operations.
    9. Reorganized the Events, so that some of the Events represent a group
    of events and the rest are sub-events. This reduces the number of
    Subscribed Events that a Printer needs to support in one Subscription from 5
    to 2. It also means that the event that is delivered is one of the
    Subscribed events, not necessarily the trigger event, so
    "notify-trigger-event" was renames to "notify-subscribed-event" in the Event
    Notification.
    10. Added the 'printer-full' and 'printer-not-almost-idle' Events to go
    along with the 'printer-no-longer-full' and 'printer-almost-idle' Events.
    Renamed the 'printer-queue-changed' Event to 'printer-queue-order-changed'.
    11. Clarified what MUST be in a Delivery Method Document.
    12. Removed "persistent-jobs-supported" Printer Description attribute,
    since it has nothing to do with Notifications and is not needed to describe
    Subscription object persistence.
    13. Changed notify-max-printer-subscriptions-supported (integer(0:MAX))
    and notify-max-job-subscriptions-supported (integer(0:MAX)) so that MAX
    means no limit and 0 means no subscriptions are (currently) allowed, so as
    to give a way to turn off accepting new subscriptions.

    Here are the remaining issues:

    ISSUE 01: OK that we changed the minimum number of events that a Printer
    MUST support in a Subscription object from 5 to 2 because we have rearranged
    the categories of Events to have group events?

    ISSUE 02: OK that we added the 'printer-full' Event?

    ISSUE 03: OK that we added the 'printer-not-almost-idle' Event?

    ISSUE 04: it would be better for the "notify-persistence" (boolean)
    Subscription Template attribute to be changed to be a Subscription
    Description attribute instead, that the Printer sets to show whether the
    Object is persistent or not. Agree?

    ISSUE 05: OK that we added the REQUIRED "notify-job-id" attribute because it
    is needed for a Notification Recipient to determine from a random
    subscription-id whether a Subscription is Per-Printer or Per-Job and if the
    latter which Job.

    ISSUE 06 & 07: We changed notify-max-printer-subscriptions-supported
    (integer(0:MAX)) and notify-max-job-subscriptions-supported (integer(0:MAX))
    so that MAX means no limit and 0 means no subscriptions are (currently)
    allowed, so as to give a way to turn off accepting new subscriptions. OK to
    use MAX to mean no limit and 0 to mean that an admin has turned off
    subscriptions?

    Send comments to the mailing list.

    Tom and Bob



    This archive was generated by hypermail 2b29 : Fri Jun 30 2000 - 04:24:33 EDT