IPP Mail Archive: Re: IPP> NOT - 6 Notification ISSUES Agend

IPP Mail Archive: Re: IPP> NOT - 6 Notification ISSUES Agend

Re: IPP> NOT - 6 Notification ISSUES Agenda: Telecon Wed 7/18, 10-11 PDT (1-2 EDT )

From: mjoel@netreon.com
Date: Wed Jul 18 2001 - 09:26:04 EDT

  • Next message: Michael Sweet: "Re: IPP> NOT - 6 Notification ISSUES Agenda: Telecon Wed 7/18, 10-11 PDT (1-2EDT )"

    Hi all,

    My comments regarding today's upcoming discussion are marked below with
    MJ>.

    Marty

    "Hastings, Tom N" <hastings@cp10.es.xerox.com>@pwg.org on 07/17/2001
    06:50:14 PM

    Sent by: owner-ipp@pwg.org

    To: "ipp (E-mail)" <ipp@pwg.org>
    cc:

    Subject: IPP> NOT - 6 Notification ISSUES Agenda: Telecon Wed 7/18, 10-11
          PDT ( 1-2 EDT )

    Here is the document for tomorrow's telecon that describes each issue in
    detail, lists PRO and CON, and provide the explicit text for each change.
    Several issues have two alternatives (A) and (B).

    Time: Wednesday, 7/18/01, 10-11 PDT (1-2 EDT)
    Phone: 1(712)884-1555 (Xerox folks: 8*596-5170
    Passcode: 654970

    This mail message is also provided as a .doc file at:

    ftp://ftp.pwg.org/ftp/pub/pwg/ipp/new_NOT/notification-clarifications.doc

       SUBJECT: 6 ISSUES with IPP Notification specs
       Date: 7/17/01
       File: notification-clarifications.doc

       There have been a number of issues (some changes and some
       clarifications) of the IPP Notification Specification and mostly the
       ippget Delivery Method spec. This note is an attempt to summarize
       them and indicate support so far for each. The summary of the 6
       issues are:

       1A. Base Notification Spec: Clarify that the Printer MAY send Event
       Notifications in any order.

    MJ> Are there existing client implementations that will break if we impose
    ordering now?

       1B. Base Notification Spec: Clarify that the Printer MUST send Event
       Notifications for any given Subscription Object in time stamp order,
       but MAY interleave Event Notifications from other Subscription
       Objects

    MJ> I think that 1B means that all events are ordered, regardless of what
    subscription they came from, at least that's what "interleave" implies.
    That would differ from the original proposal that they be sorted
    chronologically within subscription groups. On looking below at the
    proposed text for this, it's saying that events can either be sorted
    chronologically regardless of what subscription caused them, or that they
    can be sorted chronologically in groups by subscription. You might as well
    say that they can either be sorted or not, since
    sorted-within-subscription-groups requires as much work at the client as
    sorting unordered events.

    MJ> 1C. The 3rd option is that events be ordered, which I think makes more
    sense than 1B, although I'd prefer 1A. 1B puts sorting onto the client,
    and if you're going to do that anyway, you might as well go with 1A.

       2. IPPGET spec: Get-Notification matching "notify-recipients-uri"
       with Subscription objects: octet-by-octet versus URI matching rules.
       (IPPGET currently says both).

    MJ> I'm clearly the minority on octet-by-octet, and I don't feel strongly
    enough to argue it. From an implementation view, I suppose the most
    efficient way to handle the URI-type comparison is to convert everything up
    to the first '/' to lower case and store it that way in the notification
    object, and on receiving Get-Notifications, do the same thing to the given
    notify-recipient-uri before starting the (octet-by-octet) comparisons. The
    down side of doing that is that then the case could be changed on the
    notify-recipient-uri returned by Get-Notification-Attributes. However,
    storing both the original and the lower-case-to-slash versions in the
    notification object is a waste of space, and having to do the conversion of
    the notify-recipient-uri in each subscription object every time
    Get-Notifications is received is a waste of time. Comments?

       3. IPPGET spec: In a Get-Notifications response when the client has
       requested the wait mode (persistent operation), allow a Printer to
       return the unexpired Notification Events, but also indicate to the
       client to please disconnect and try again at the indicate interval
       ("suggested-ask-again-time-interval"). (IPPGET currently only allows
       the interval to be returned if the client didn't ask for wait mode or
       if the Printer is too busy to return any Notification Events).

       4A. IPPGET spec: Clarify that the Get-Notifications operation is for
       querying any kind of unexpired Events, not just ippget Events. Thus
       the "notify-recipients-uri" operation attribute can match any
       Subscription object including the scheme. Also all Events have a
       life time, not just ippget Events, if the Printer supports Get-
       Notifications (which requires ippget scheme at least).

       4B. IPPGET spec: Same as 4a, but make it OPTIONAL for a Printer to
       support other schemes with Get-Notifications.

    MJ> 4C. Rename Get-Notifications to Get-Ippget-Notifications. If some
    future delivery method needs something similar, Get-<future deliver method
    name>-Notifications can be added.

    MJ> 4D. Allow something like 4A but only for delivery methods that
    support both PUSH and PULL like ippget. Letting Get-Notifications support
    a delivery method that doesn't support both PUSH and PULL like ippget
        1) is unnecessary because events generated by subscriptions for other
    delivery methods are going to be delivered anyway, according to the rules
    of their delivery method
        2) puts additional memory and processing burden on the printer for
    something that's unnecessary anyway (see above)
        3) Breaks existing implementations, which currently aren't storing
    event objects.

       5. IPPGET spec: Change the sense of the Get-Notifications "notify-no-
       wait" (boolean) operation attribute to a positive "persistent-
       operation" (boolean), so that omitted and 'false' mean the easier
       non-persistent operation.

    MJ> I like this idea, but not if it breaks existing implementations.

    MJ> I've got some real problems with the whole PUSH issue for ippget.
    From a design perspective it's probably cut and dry, but I'm losing hair
    trying to implement this. Specifically:
        a) How am I supposed to handle HTTP's Content-Length?
        b) Won't this only work with HTTP's Keep-Alive?
        c) Can this even work with HTTP 1.0?
        d) How is the client supposed to know when it's done receiving some
    events? If clients used Content-Length before, now do they have to add a
    timeout?
        e) It seems that HTTP's multi-part should be used, 1 part for the first
    blast and another either for each event or for each group of events. I
    really don't want to have to add HTTP multi-part support just for this.

    MJ> I'm tempted to always use the mechanism I proposed for issue 3 and
    simply not support PUSH, if I cannot solve the HTTP issues.

       6. IPPGET spec: Rename some attributes but keep the same semantics:
              "notify-ippget-redirect" (uri) to "notify-redirect-uri" (uri),
              "suggested-ask-again-time-interval" (integer(0:MAX)) to
              "notify-get-interval", and
              "begin-to-expire-time-interval" (integer(0:MAX)) to "event-
              life-time" (integer(0:MAX)).

    MJ> I like these changes, but not if they break existing implementations.

       I've talked with the following folks individually about the above and
       have the following positions (blank means they weren't asked or didn't
       have an opinion):

       ISSUE HL IM BH TH MJ TT CM MS
       1A.Clarify no Event ordering Y N Y N Y N N
       1B.Events MUST be ordered by SO N Y Y N Y Y
       2. URI match rules Y Y Y Y N Y Y
       3. Printer suggest disconnect Y Y Y Y Y Y
       4A.Poll for any scheme N Y N N N N N
       4B.Poll for any scheme OPTIONALLY N Y N Y N
       5. change wait sense Y Y Y N Y Y
       6. rename some attributes Y Y N N N Y N Y

       Now comes the detailed discussion and the actual text change for each
       proposal:

    1. Notification spec [ipp-ntfy]: General comments about ordering:

         a. We need to say something about the ordering of Event
         Notifications as sent by the Printer, both for separate Event
         Notifications and within Compound Event Notifications.

         2. We also need to say that depending on the underlying transport,
         the order received of separate Event Notifications by a
         Notification Recipient MAY be different.

         3. ippget and mailto don't even mention Compound Event
         Notifications, so we need to update the text and refer back to
         [ipp-ntfy] for all three delivery methods for the ordering
         requirements. See the proposed text below.

       There are two alternatives: 1A: No ordering requirements and 1B:
       ordered by time stamp for each Subscription object, whether
       interleaved or not.

       Discussion: Most Notification standards require time sequencing.
       Requiring the Printer to order by time stamp for each Subscription
       object, but allowing interleaving, is not a burden on the Printer and
       allows simple clients to deal with events without having to sort.
       Complicated accounting clients may still have to sort.

    MJ> Sorting most definitely puts a burden on the printer.

    1A. Base Notification Spec: Clarify that the Printer MAY send Event
    Notifications in any order.

       For the Base Event Notifications spec [ipp-ntfy] section 9 after
       paragraph 2 add the following text:

       Printer Event Sending Algorithm:

       When a Printer processes multiple pending Events, the Printer MAY
       send the Event Notifications in any order. There is no requirement
       that they be sent in time stamp order, i.e., there is no requirement
       that they be sent in the order of increasing "printer-up-time"
       attribute value in the Event Notification (see Table 5).
       Notification Recipients MUST accept the Event Notifications in any
       order.

       There is no need to add any text to any of the Delivery Methods.

    1B. Base Notification Spec: Clarify that the Printer MUST send Event
    Notifications for any given Subscription Object in time stamp order, but
    MAY interleave Event Notifications from other Subscription Objects.
    Notification Delivery Method documents refer to the Base Spec for
    ordering.

       For the Base Event Notifications spec [ipp-ntfy] section 9 after
       paragraph 2 add all of the following text:

       Printer Event Sending Algorithm:

       When a Printer processes multiple pending Events, the Printer MUST
       send Event Notifications in one of the following orders, whether as
       multiple separate Event Notifications or together in a single
       Compound Event Notification:

         a) The Event Notifications are grouped by the Subscription Object
         from which the Event Notifications are generated. Within each such
         grouping, the Event Notifications are in time stamp order, i.e., in
         order of increasing "printer-up-time" attribute value in the Event
         Notification (see Table 5). Between such groupings, the order of
         Event Notifications is IMPLEMENTATION DEPENDENT.

    MJ> a) might as well say that events can be in any order, since that's the
    effect on the client, which will most likely have to sort the events.

         OR

         b) The Event Notifications are in time stamp order (order of
         increasing "printer-up-time" attribute value), even when generated
         from multiple Subscription Objects.

       Note that with either variant a) or variant b) of the Printer Event
       Sending Algorithm, the Printer always sends the Event Notifications
       generated from a given Subscription Object in time stamp order, even
       when the Printer sends intervening Event Notifications generated by
       other Subscription objects. If a Subscribing Client wants to ensure
       that the Printer sends certain Event Notifications in time stamp
       order, the Subscribing Client must ensure that the subscription for
       the Events are in the same Subscription Object. Even so, depending
       on the underlying transport, the actual order that a Notification
       Recipient receives separate Event Notifications MAY differ from the
       order sent by the Printer.

       A variant wording which is shorter and has examples is the following:

       Printer Event Sending Ordering:

       When a Printer sends Event Notifications, the Event Notifications
       from any given Subscription Object MUST be in time stamp order, i.e.,
       in order of increasing "printer-up-time" attribute value in the Event
       Notification (see Table 5). These Event Notifications MAY be
       interleaved with those from other Subscription Objects, as long as
       those others are also in time stamp order. The Printer MUST observe
       these ordering requirements whether sending multiple pending Events
       as multiple separate Event Notifications or together in a single
       Compound Event Notification.

       If a Subscribing Client wants the Printer to send certain Event
       Notifications in time stamp order, the Subscribing Client ensures
       that the subscription for the Events are in the same Subscription
       Object. Even so, depending on the underlying transport, the actual
       order that a Notification Recipient receives separate Event
       Notifications MAY differ from the order sent by the Printer.

       Example: Consider two Per-Printer Subscription Objects: SO1 and SO2.
       SO1 requests 'job-state-changed' events and SO2 requests 'printer-
       state-changed' events. The number in parens is the time stamp. Any
       of the following Event Notification sequences conform to the ordering
       requirements for the Printer to send the Notification Events:

       (a) 'job-created' (1000), 'job-stopped' (1005), 'job-completed'
       (1009), 'printer-stopped (1005)'

       (b) 'job-created' (1000), 'job-stopped' (1005), 'printer-stopped'
       (1005), 'job-completed (1009)'

       (c) 'job-created' (1000), 'printer-stopped' (1005), 'job-stopped'
       (1005), 'job-completed (1009)'

       Examples (b) and (c) are interleaved, (a) is not.

       IPPGET:

       Make the following changes to the first paragraph in the Get-
       Notifications Response, section 5.2 (I put [] around new text, but
       deleted old text without indication):

       Group 3 through N: Event Notification Attributes

       The Printer responds with one Event Notification Attributes Group per
       matched Event Notification. [The entire response is considered a
       single Compound Event Notification (see [ipp-ntfy]).] The initial
       matched Event Notifications are all un-expired Event Notifications
       associated with the matched Subscription Objects [and MUST follow the
       ordering requirements for Event Notifications within a Compound Event
       Notification specified for the "Printer Event Sending Algorithm" in
       [ipp-ntfy] section 9].

       If the Notification Recipient has selected the option to wait for
       additional Event Notifications [(the "notify-no-wait" attribute was
       set to 'false' or was omitted)], the Printer {sends} subsequent Event
       Notifications in the response [each time it processes additional
       Events]. [Each time the Printer sends such Event Notifications,
       their ordering MUST be the ordering specified for the "Printer Event
       Sending Algorithm" in [ipp-ntfy] section 9.]

       [ Note: If a Notification Recipient performs two consecutive Get-
       Notifications operations, the time stamp of the first Event
       Notification in the second Get-Notifications Response may be less
       than the time stamp of the last Event Notification in the first Get-
       Notification Response. This happens because the Printer sends all
       unexpired Event Notification according to the ordering specified in
       [ipp-ntfy] and some Event Notifications from the first Get-
       Notifications operation may not have expired by the time the second
       Get-Notifications operation occurs. ]

       INDP:

       In INDP section 8.1 Send-Notifications Request, 2nd paragraph (I put
       [] around the new text):

       The Printer composes the information defined for an IPP Notification
       [ipp-ntfy] and sends it using the Send-Notifications operation to the
       Notification Recipient supplied in the Subscription object. [The
       ordering of separate Send-Notifications operations that a Printer
       sends MUST be the ordering specified for the "Printer Event Sending
       Algorithm" in [ipp-ntfy] section 9.]

       In INDP section 8.1.1 Send-Notifications Request (I put [] around the
       new text):

       Group 2 to N: Event Notification Attributes

       In each group 2 to N, each attribute is encoded using the IPP rules
       for encoding attributes [RFC2910] and [the attributes within a group]
       MAY be encoded in any order. [The entire request is considered a
       single Compound Event Notification and MUST follow the ordering
       requirements for Event Notifications within a Compound Event
       Notification specified for the "Printer Event Sending Algorithm" in
       [ipp-ntfy] section 9.] Note: the Get-Jobs response in [RFC2911] acts
       as a model for encoding multiple groups of attributes.

       MAILTO:

       MAILTO section 6, add the following after the existing 2nd paragraph:

       While the "Printer Event Sending Algorithm" in [ipp-ntfy] section 9
       specifies ordering requirements for Printers when sending separate
       Event Notifications, email messages are not guaranteed to arrive in
       the order sent so that the Notification Recipient may not receive
       them in the same order.

       MAILTO section 6 Event Notification Content, right before section 6.1
       (I put [] around the new text):

       The Event Notification content has two parts, the headers and the
       message body. The headers precede the message body and are separated
       by a blank line (see [RFC 822]).

       [A Printer implementation MAY combine several Event Notifications
       into a single email message body. Such an email message is
       considered a single Compound Event Notification and MUST follow the
       ordering requirements for Event Notifications within a Compound Event
       Notification specified for the "Printer Event Sending Algorithm" in
       [ipp-ntfy] section 9.]

    2. IPPGET spec: Get-Notification matching "notify-recipients-uri" with
    Subscription objects: octet-by-octet versus URI matching rules. (IPPGET
    currently says both).

       Discussion: PRO: Its needed in order to get our ippget scheme
       accepted by the IETF and is more user friendly, in case a different
       human is supplying the Notification Recipient URI than the
       Subscribing Client. CON: Its harder to implement. REBUTTAL: Most
       platforms have a compare URI routine.

       Change IPPGET Section 5.1 from:

          "notify-recipient-uri" (url):
            The client MUST supply this attribute. The Printer object MUST
            support this attribute. The Printer matches the value of this
            attribute (byte for byte with no case conversion) against the
            value of the "notify-recipient-uri" in each Subscription Object
            in the Printer. If there are no matches, the IPP Printer MUST
            return the 'client-error-not-found' status code.

            to:

          "notify-recipient-uri" (url):
            The client MUST supply this attribute. The Printer object MUST
            support this attribute. The Printer matches the value of this
            attribute against the value of the "notify-recipient-uri" in
            each Subscription Object in the Printer following the normal
            URI comparison rules (see section 9.5.2). If there are no
            matches, the IPP Printer MUST return the 'client-error-not-
            found' status code.

    3. IPPGET spec: In a Get-Notifications response when the client has
    requested the wait mode (persistent operation), allow a Printer to
    return the unexpired Notification Events, but also indicate to the
    client to please disconnect and try again at the indicate interval
    ("suggested-ask-again-time-interval"). (IPPGET currently only allows
    the interval to be returned if the client didn't ask for wait mode or if
    the Printer is too busy to return any Notification Events).

       Discussion: PRO: For simple Printers, especially IPPFAX, this
       allows them not to have to support unlimited numbers of connections
       with the REQUIRED ippget Delivery Method. CON: Another thing for
       the client to check. REBUTTAL: but the client needs to check this
       anyway.

       Change section 5.2:

          "suggested-ask-again-time-interval" (integer(0:MAX)):
             The value of this attribute is the number of seconds that the
             Notification Recipient SHOULD wait before trying this operation
             again when
              a) the Printer returns the 'server-error-busy' status
    code OR
              b) the Printer returns the 'successful-ok' status
    code
    and the
                client supplied the "notify-no-wait" attribute with a value
                of 'true'.
             This value is intended to help the client be a good network
             citizen.
       to:

          "suggested-ask-again-time-interval" (integer(0:MAX)):
             The value of this attribute is the number of seconds that the
             Notification Recipient SHOULD wait before trying this operation
             again when
              a) the Printer returns the 'server-error-busy' status
    code OR
              b) the Printer returns the 'successful-ok' status
    code
    and the
                client supplied the "notify-no-wait" attribute with a value
                of 'true' (the no wait case).
              c) the Printer returns the 'successful-ok' status
    code
    and the
                client supplied the "notify-no-wait" attribute with either
                'false' value or omitted the attribute all together (the
                wait case) and the Printer wants the client to disconnect,
                instead of staying connected. The client MUST accept this
                response and MUST disconnect. If the client does not
                disconnect, the Printer SHOULD do so. The Printer returns
                this attribute for this case only if the implementation
                does not want to keep the connection open at this time. If
                the Printer wants the client to keep the connection open,

                then the Printer MUST NOT return this attribute in the
                response.
             This value is intended to help the client be a good network
             citizen.

    4A. IPPGET spec: Clarify that the Get-Notifications operation is for
    querying any kind of unexpired Events, not just ippget Events. Thus the
    "notify-recipients-uri" operation attribute can match any Subscription
    object including the scheme. Also all Events have a life time, not just
    ippget Events, if the Printer supports Get-Notifications (which requires
    ippget scheme at least).

       Discussion: PRO: Other notification mechanisms, like SNMP, have both
       polling and traps for the same events. Also the client supplies a
       fully general "notify-recipient-uri" operation attribute in the Get-
       Notifications operation. CON: Its more complications and not that
       useful with our INDP and mailto methods.

    MJ> My comments are above in the overview for 4. I'm opposed to both the
    4A and 4B proposals.

       Add to IPPGET section 5.1, Get Notifications Request, "notify-
       recipient-uri" (uri) operation attribute:

       The Printer MUST accept this request for any URI scheme that it
       supports for Notification, not just the 'ippget' scheme, i.e., for
       any value of the Printer's "notify-schemes-supported" Printer
       Description attribute. If the URI scheme is not among the values of
       the Printer's "notify-schemes-supported" Printer Description
       attribute, the Printer rejects the request and returns the 'client-
       error-uri-scheme-not-supported' status code.

       Change Section 7.3 begin-to-expire-time-interval (integer(0:MAX))
       from:

       This Printer Description attribute specifies the number of seconds
       that a Printer keeps an Event Notification that is associated with
       the 'ippget' Delivery Method.

       The Printer MUST support this attribute if it supports the 'ippget'
       Delivery Method.

       The value of this attribute is the minimum number of seconds that
       MUST elapse between the time the Printer creates an Event
       Notification object for the 'ippget' Delivery Method and the time the
       Printer discards the same Event Notification.

       to:

       This Printer Description attribute specifies the number of seconds
       that a Printer keeps an Event Notification that is associated with
       any Delivery Method.

       The Printer MUST support this attribute if it supports the 'ippget'
       Delivery Method or the Get-Notifications operation.

       The value of this attribute is the minimum number of seconds that
       MUST elapse between the time the Printer creates an Event
       Notification object for any Delivery Method and the time the Printer
       discards the same Event Notification.

    4B. IPPGET spec: Same as 4a, but make it OPTIONAL for a Printer to
    support other schemes with Get-Notifications.

       Discussion: PRO: Other notification mechanisms, like SNMP, have both
       polling and traps for the same events. Also the client supplies a
       fully general "notify-recipient-uri" operation attribute in the Get-
       Notifications operation. CON: Its more complications and not that
       useful with our INDP and mailto methods AND its another
       interoperability OPTION, thereby reducing the chances that a client
       would both supporting it.

       Add to IPPGET section 5.1, Get Notifications Request, "notify-
       recipient-uri" (uri) operation attribute:

       The Printer MUST accept this request for any URI scheme that it
       supports for use with the Get-Notifications operation, not just the
       'ippget' scheme, i.e., for any value of the Printer's "notify-
       schemes-supported" Printer Description attribute for which the
       Printer supports the Get-Notifications operation. If the URI
       scheme is not one of the values that the Printer supports for the
       Get-Notifications operation, the Printer rejects the request and
       returns the 'client-error-uri-scheme-not-supported' status code.

       Change Section 7.3 begin-to-expire-time-interval (integer(0:MAX))
       from:

       This Printer Description attribute specifies the number of seconds
       that a Printer keeps an Event Notification that is associated with
       the 'ippget' Delivery Method.

       The Printer MUST support this attribute if it supports the 'ippget'
       Delivery Method.

       The value of this attribute is the minimum number of seconds that
       MUST elapse between the time the Printer creates an Event
       Notification object for the 'ippget' Delivery Method and the time the
       Printer discards the same Event Notification.

       to:

       This Printer Description attribute specifies the number of seconds
       that a Printer keeps an Event Notification that is associated with
       any Delivery Method for which it supports the Get-Notifications
       operation.

       The Printer MUST support this attribute if it supports the 'ippget'
       Delivery Method or the Get-Notifications operation.

       The value of this attribute is the minimum number of seconds that
       MUST elapse between the time the Printer creates an Event
       Notification object for any Delivery Method for which it supports the
       Get-Notifications operation and the time the Printer discards the
       same Event Notification.

    5. IPPGET spec: Change the sense of the Get-Notifications "notify-no-
    wait" (boolean) operation attribute to a positive "persistent-operation"
    (boolean), so that omitted and 'false' mean the easier non-persistent
    operation.

       Discussion: PRO: Boolean attributes should be names with positive
       names, else they are likely to be mis-implemented. The harder, more
       unusual value should be the 'true' and the normal, easier value
       should be 'false' or omitted, i.e., the default behavior. CON: This
       will affect any implementations not currently participating in the
       discussion and our chair may require us to do another WG Last Call,
       thereby further delaying our getting the IPPGET spec out (though its
       still in the AD's queue).

       Change section 5.1, "notify-no-wait" (boolean) from:

          "notify-no-wait" (boolean):
             The client MAY supply this attribute. The Printer object MUST
             support this attribute. If the value of this attribute is
             'false', the Printer MUST send all un-expired Event
             Notifications (as defined in the previous attribute) and it
             MUST continue to send responses for as long as the Subscription
             Objects associated with the specified "notify-recipient-uri"
             continue to exist. If the value of this attribute is 'true',
             the Printer MUST send all un-expired Event Notifications (as
             defined in the previous attribute) and the Printer MUST
             conclude the operation without waiting for any additional
             Events to occur. If the client doesn't supply this attribute,
             the Printer MUST behave as if the client had supplied this
             attribute with the value of 'false'.

       to:

          "persistent-operation" (boolean):
             The client MAY supply this attribute. The Printer object MUST
             support this attribute. If the value of this attribute is
             'false' or omitted, the Printer MUST send all un-expired Event
             Notifications (as defined in the previous attribute) and the
             Printer MUST conclude the operation without waiting for any
             additional Events to occur. If the value of this attribute is
             'true', the Printer MUST send all un-expired Event
             Notifications (as defined in the previous attribute) and it
             MUST continue to send responses for as long as the Subscription
             Objects associated with the specified "notify-recipient-uri"
             continue to exist.

    MJ> This wording looks good, and I like that omission of this attribute
    means false.

    6. IPPGET spec: Rename some attributes but keep the same semantics:
           "notify-ippget-redirect" (uri) to "notify-redirect-uri" (uri),
           "suggested-ask-again-time-interval" (integer(0:MAX)) to "notify-
           get-interval", and
           "begin-to-expire-time-interval" (integer(0:MAX)) to "event-life-
           time" (integer(0:MAX)).

       Discussion: CON for all 3 changes: This will affect any
       implementations not currently participating in the discussion and our
       chair may require us to do another WG Last Call, thereby further
       delaying our getting the IPPGET spec out (though its still in the
       AD's queue).

       PRO: The "notify-ippget-redirect" doesn't have "uri" in the name,
       like all our other IPP attribute names. Also while the attribute is
       restricted to the Get-Notifications operation (and maybe ippget), it
       could in principle be used with other operations, so the "ippget"
       should be dropped from the name.

       PRO: The "suggested-ask-again-time-interval" is too long and doesn't
       have anything about notification in the name.

       PRO: The "begin-to-expire-time-interval" is too long and doesn't
       have anything about events in the name. Also "life-time" is a common
       term for this interval.

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Tuesday, July 17, 2001 13:31
    To: ipp (E-mail)
    Subject: IPP> NOT - 6 Notification ISSUES: Telecon Wed 7/18, 10-11 PDT
    (1-2 EDT )
    Importance: High

    There have been 6 issues (some changes and some clarifications) of the IPP
    Notification Specification and the three Delivery Methods (ippget, indp,
    and
    mailto). Some of these issues have come up as folks implement IPP FAX
    which
    REQUIRES the ippget Delivery Method. We are close to consensus on the
    mailing list and my calling those who have sent email. However, I want to
    make sure and each time I talk to someone they bring up some more good
    points. So I'd like to have a quick telecon tomorrow to make sure we
    agree.
    I'll send out the specific text changes later today for the following 6
    issues.

    Time: Wednesday, 7/18/01, 10-11 PDT (1-2 EDT)
    Phone: 1(712)884-1555 (Xerox folks: 8*596-5170
    Passcode: 654970

    If you can't make the telecon, please send email. We don't want to impact
    any implementations underway, unless you participate. I want to update
    these specifications before the next Internet-Draft deadline which is this
    Friday.

    The summary of the 6 issues are:

    1. Clarify that the Printer MAY send Event Notifications in any order.

    2. IPPGET spec: Get-Notification matching "notify-recipients-uri" with
    Subscription objects: octet-by-octet versus URI matching rules. (IPPGET
    currently says both).

    3. IPPGET spec: In a Get-Notifications response when the client has
    requested the wait mode (persistent operation), allow a Printer to return
    the unexpired Notification Events, but also indicate to the client to
    please
    disconnect and try again at the indicate interval
    ("suggested-ask-again-time-interval"). (IPPGET currently only allows the
    interval to be returned if the client didn't ask for wait mode or if the
    Printer is too busy to return any Notification Events).

    4a. IPPGET spec: Clarify that the Get-Notifications operation is for
    querying any kind of unexpired Events, not just ippget Events. Thus the
    "notify-recipients-uri" operation attribute can match any Subscription
    object including the scheme. Also all Events have a life time, not just
    ippget Events, if the Printer supports Get-Notifications (which requires
    ippget scheme at least).

    4b. Same as 4a, but make it OPTIONAL for a Printer to support other schemes
    with Get-Notifications.

    5. Change the sense of the Get-Notifications "notify-no-wait" (boolean)
    operation attribute to a positive "persistent-operation" (boolean), so that
    omitted and 'false' mean the easier non-persistent operation.

    6. IPPGET spec: Rename some attributes but keep the same semantics:
              "notify-ippget-redirect" (uri) to "notify-redirect-uri"
    (uri),
              "suggested-ask-again-time-interval" (integer(0:MAX)) to
    "notify-get-interval", and
              "begin-to-expire-time-internal" (integer(0:MAX)) to
    "event-life-time" (integer(0:MAX)).



    This archive was generated by hypermail 2b29 : Wed Jul 18 2001 - 09:28:33 EDT