IPP Mail Archive: IPP> NOT - Comments on the IPP Notificatio

IPP Mail Archive: IPP> NOT - Comments on the IPP Notificatio

IPP> NOT - Comments on the IPP Notification Spec, 'indp' and 'mailto' Delivery Method Documents

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Jul 12 2000 - 01:00:03 EDT

  • Next message: Hastings, Tom N: "RE: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and P rinter A dmin (Set2) spec"

    Subj: Comments on the Notification Specifications
    From: Tom Hastings
    Date: 7/10/00
    File: ipp-not-comments.doc
    1. IPP Event Notification Specification
    1.1. Need "job-recipient" (name(MAX)) operation and Job Description
    attribute
    Section 11.1: After reading some of the delivery methods, it is clear that
    when sending a job across a firewall to some other user, the client needs to
    be able to specify that person in an operation attribute. The Printer can
    then use that attribute to print on the banner page for example. So we need
    to add a "job-recipient" (name(MAX)) operation attribute to the Job Creation
    operations which the Printer copies to a Job Description attribute of the
    same name. If the client omits this attribute, then the Printer assumes
    that the "requesting-user-name" operation attribute (which [ipp-mod] says a
    client SHOULD supply) is the intended job recipient. Both attributes would
    be OPTIONAL to support.

    1.2. Add 'job-stopped' and 'printer-stopped' REQUIRED sub-events
    Page 20 and 22. After reading the mailto Delivery Method Document, the
    'job-state-changed' and 'printer-state-changed' don't work very well for
    mailto. There would be too many mail messages send. It would be very
    helpful for a user to be able to supply a Per-Job Subscription with either a
    'job-stopped' sub-event of the 'job-state-changed' to get a notification
    (perhaps by a gateway to a beeper service) when the user's job stopped,
    i.e., the job entered the 'processing-stopped' state. Or for the really
    eager to supply 'printer-stopped' sub-event of the 'printer-state-changed'
    to get a notification when any job (ahead of the user's job or the user's
    job) stopped the Printer, i.e., the Printer entered the 'stopped' state.
    This latter event would be useful for an operation to supply in a
    Per-Printer subscription too, in order to be beeped when to fix the Printer.
    Both of these events should be REQUIRED in order for Subscribing Clients to
    be able to count on them.

    1.3. The "notify-subscription-id" isn't used for 'snmpnotify' Method
    Page 36, Table 5: REQUIRES the "notify-subscription-id" to be supported,
    but the 'snmpnotify' doesn't. Should we change the MUST to SHOULD?

    2. The 'indp' Notification Delivery Method Document
    2.1. Notification might become REQUIRED in a future version of IPP
    So line 22-23 should say OPTIONAL for IPP/1.0, IPP/1.1, and future versions.
    2.2. Table specifying how the Delivery Method Document meets the
    [ipp-ntfy] requirements

    Table 1 on pages 6-8 lists the requirements from [ipp-ntfy] in column 1 and
    how 'indp' meets each requirement. In the 'mailto', section 4 combines the
    requirement and the answer into single statements.

    2.3. Should we add Notification Recipient Conformance Requirements?
    The [ipp-mod] has conformance requirements for clients and Printers, i.e.,
    senders and receivers. So shouldn't indp have conformance requirements for
    Printers (senders) and Notification Recipients (receivers)?

    3. The 'mailto:' Notification Delivery Method Document
    3.1. Shouldn't mailto be the REQUIRED Delivery Method?
    Line 175, says 'mailto' is OPTIONAL.

    3.2. "notify-mailto-text-only" (boolean) always include plain text,
    correct?
    Lines 198 and 208 seems to allow the 'false' (and default) value to omit
    plain text. So do lines 316 and 319.

    3.3. Does 'mailto' imply SMTP or not?
    Line 218 (and else where) seem to allow 'mailto' to specify other protocols
    than just SMTP.

    3.4. Syntax of value would allow multiple mailto Notification Recipients
    Line 220 and line 300: But [ipp-ntfy] became simpler when we only allowed
    one recipient per Subscription. What about retrying some that failed? Gets
    much more complicated for the Printer.

    3.5. Who adds the date and time? Printer or mail server?
    Line 253 says what the Printer MUST include and doesn't need to if the
    Printer doesn't support "printer-current-time". However, if the mail server
    adds the date and time, then it gets there.

    3.6. Subject line should include the Printer's name
    For completion, the examples should include the Printer name in the Subject
    Line. Then all of the information is in the Subject line, making it much
    easier for a user looking at the received mail messages without having to
    open them.

    3.7. Message body could be the same as Subject line
    Also I suggest that the message body be the same as the Subject Line, i.e.,
    a simple statement about what happened, not fields with field names and
    colons that some Notification Recipients would be tempted to parse.



    This archive was generated by hypermail 2b29 : Wed Jul 12 2000 - 01:08:14 EDT