IPP Mail Archive: IPP> Re: IPPGET allowing the Printer to re

IPP Mail Archive: IPP> Re: IPPGET allowing the Printer to re

IPP> Re: IPPGET allowing the Printer to request the client to disconne ct

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Mon Jul 16 2001 - 17:22:36 EDT

  • Next message: mjoel@netreon.com: "RE: IPP> Re: FW: IPPGET inconsistency on comparing URLs"

    Marty,

    So to be clear, if there are more connections than the Printer wants to
    commit to IPPGET wait connections, the Printer can return the
    "suggested-ask-again-time-interval" along with any events that haven't
    elapsed. The client should then disconnect AFTER getting the response. My
    understanding is that if the Printer disconnects right way, that the
    response may not get back to the client.

    However, if the client doesn't disconnect soon, the Printer MAY.

    Also, lets continue to REQUIRE that the Printer support the wait mode for an
    IMPLEMENTATION DEFINED number of connections, but allow the Printer to use
    the above mechanism if the number of connections exceeds this limit. OK?

    Here is the current description of the "suggested-ask-again-time-interval"
    attribute:

    "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.

    OK to change it to the following:

    "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'.

    c) the Printer returns the 'successful-ok' status code and the client
    supplied the "notify-no-wait" attribute with a value of 'false' or omitted
    it (meaning that the client is requesting the printer to continue to send
    responses), but the Printer wishes the client to close the connection
    because the number of connections has exceeded an IMPLEMENTATION DEFINED
    number. If the client does not close the connection after receiving this
    response, the Printer MAY do so.

    This value is intended to help the client be a good network citizen.

    COMMENTS?

    Thanks,
    Tom

    -----Original Message-----
    From: mjoel@netreon.com [mailto:mjoel@netreon.com]
    Sent: Monday, July 16, 2001 13:24
    To: ipp@pwg.org
    Subject: RE: IPP> NOT - substantive clarification about order Printer
    send s Event Notifications

    Hi Tom,

    Regarding allowing the printer to return
    "suggested-ask-again-time-interval" with a reply containing events and then
    disconnect, even if the client wanted push mode, I like it. This approach
    allows server implementors to either not support push mode, or support it
    with a limited number of tied-up connections. It also works with existing
    client implementations, which will simply respond to what looks to them
    like a lost connection (although they won't wait to reconnect, and I see
    nothing we can do about that). Good solution.

    Regards,

    Marty

    "Hastings, Tom N" <hastings@cp10.es.xerox.com> on 07/16/2001 12:51:31 PM

    To: mjoel@netreon.com
    cc: "Bob Herriot (E-mail)" <rherriot@pahv.xerox.com>, "Tom Hastings
          (E-mail)" <hastings@cp10.es.xerox.com>, "McDonald Ira at Sharp
          (E-mail)" <imcdonald@sharplabs.com>, "Ira at Xerox XR&T McDonald
          (E-mail)" <IMcDonald@crt.xerox.com>, "Lewis Harry (E-mail)"
          <harryl@us.ibm.com>

    Subject: RE: IPP> NOT - substantive clarification about order Printer send
          s Event Notifications

    Marty,

    You make a good technical and process argument here to make the order
    implementation dependent. Then no current implementations of Printers
    would
    be affected.

    What about your other suggestion for IPPGET to have a way to return some
    events and request the client to disconnect if the Printer finds that there
    are currently too many ports tied up?

    Do we need to schedule a telecon this Wednesday 10:00 AM PDT on this issue?
    The deadline for the I-Ds, is this Friday!!!!!

    Instead of the drastic change to make wait mode OPTIONAL to support [and
    invert the sense of the "notify-no-wait" (boolean) and change the name),
    how
    about the following relaxation of the IPPGET spec:

    Allow the Printer to return the "suggested-ask-again-time-interval"
    attribute along with Event Notifications even when the client had requested
    wait mode if the Printer finds that the number of connections is too high.
    Currently, the "suggested-ask-again-time-interval" can only be returned if:

      a) the Printer returns "server-error-busy' OR
      b) the Printer returns 'successful-ok' status code and the client
    supplied
    the "notify-no-wait" attribute with a value of 'true'.

    We could allow the Printer to return "suggested-ask-again-time-interval"
    attribute even when the client supplied the "notify-no-wait' = 'false' or
    omitted it, in which case the client is kindly requested to disconnect (or
    the Printer will).

    Thoughts?

    Tom

    -----Original Message-----
    From: mjoel@netreon.com [mailto:mjoel@netreon.com]
    Sent: Wednesday, July 11, 2001 18:02
    To: ipp@pwg.org; ifx@pwg.org
    Subject: RE: IFX> ippget Spec Change Request

    Hi Tom,

    Thanks for your comments. I'm glad to know the spec can still be changed,
    although Ira raised a good point, that we shouldn't break existing ippget
    implementations.

    Regarding notify-no-wait, I thought about having the printer just
    disconnect, but then the client would probably reconnect immediately. The
    spec says that suggested-ask-again-time-interval is only for
    notify-no-wait=true or server-error-busy, so that seems to mean that for
    notify-no-wait=false, if the printer disconnects, the client should just
    reconnect without waiting. It would be nice if the printer could return
    events with server-error-busy, but that might confuse existing ippget
    clients. The spec seems vague regarding if that is possible. What I don't
    want to see happen is for a client to hammer on a printer that either
    doesn't support pushing or that has a limited number of sockets it will tie
    up for pushing. I think it's a bad assumption that if the client keeps
    getting server-error-busy every time it asks for notify-no-wait=false, it
    will try notify-no-wait=true, although that would be another solution.

    Marty

    "Hastings, Tom N" <hastings@cp10.es.xerox.com> on 07/11/2001 04:59:34 PM

    To: "'mjoel@netreon.com'" <mjoel@netreon.com>
    cc: ipp@pwg.org, ifx@pwg.org

    Subject: RE: IFX> ippget Spec Change Request

    Marty,

    You bring up some good points. I've talked with Bob Herriot, Harry Lewis,
    Ira McDonald, and left a message for Carl Kugler who is on vacation until
    next Wednesday. Harry is talking with his implementers. We can change the
    spec even though it is in the IESG queue if there is general agreement on
    the IPP DL that it is broken and needs to be fixed. Another alternative
    would be to change the conformance ippget requirements for just IPPFAX, but
    not IPP.

    1. About "notify-no-wait":

    We may want to make some changes to make ippget easier for Printers to
    support by making the notify-no-wait OPTIONAL (or maybe RECOMMENDED)
    instead
    of REQUIRED for IPP and IPP FAX. If we do make it OPTIONAL or RECOMMENDED,
    we probably need to invert the sense of the attribute from "notify-no-wait"
    (boolean) to "persistent-operation" (boolean), so that the omitted case is
    the same as the 'false' case which is the simpler no persistent operations.

    However, a question to you: If the IPPFAX Printer that is concerned about
    using too many connections (as you indicate in your mail), can simply
    disconnect after sending the first Get-Notifications response back,
    wouldn't
    that solve your problem? (The Printer would need to wait at least 5
    seconds before disconnecting to make sure that that response did get back
    to
    the Notification Recipient). Or better still the Printer could keep the
    connection open until the number of channels being tied up gets too great
    and then disconnect one.

    So are you concerned about the complexity of the IPPFAX Printer
    implementation of the "notify-no-wait" attribute, or tying up too many
    channels in certain cases?

    2. About getting Job events after Job completes

    Also we need to clarify that the Subscription object which has ippget MUST
    stay around at least for the "begin-to-expire-time-interval" time AFTER the
    job completes. Also the Job SHOULD stay around for at least that time plus
    15 seconds or so, so that a Notification Recipient can go and get any Job
    information, such as the "job-name" AFTER getting the event (and the
    "job-id").

    3. Your question about the 'redirection-other-site' and the
    "notify-ippget-redirect" operation attribute. The reason for this for
    ippget, is that the actual Notification Server MAY be in a different server
    than the Printer. The Printer sends events to this Notification Server
    which keeps the Subscription objects and actually delivers the events. See
    [ipp-ntfy] Appendix B and Figure 3. However, if we make other changes in
    the spec, maybe we should change the name of the "notify-ippget-redirect"
    (uri) to something that could be used with any IPP operation:
    "redirect-uri"
    (uri).

    Comments?

    Tom

    -----Original Message-----
    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Wednesday, July 11, 2001 08:59
    To: 'mjoel@netreon.com'; ipp@pwg.org; ifx@pwg.org
    Subject: RE: IFX> ippget Spec Change Request
    Hi Marty,

    Thanks very much for your close reading of IPPGET and comments.

    I'll let the editors of IPPGET (Tom Hastings and Harry Lewis)
    answer your technical questions.

    But for context, note that IPPGET has successfully passed an
    IPP WG 'last call' and has already been forwarded to the IESG
    for publication as a 'standards track' RFC. Which means any
    technical content changes would have to be submitted as comments
    during the Internet-wide 'last call' (whenever it is announced).

    There are existing implementations of IPPGET from several vendors,
    so changes that are not backwards compatible will be very hard
    to make.

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

    -----Original Message-----
    From: mjoel@netreon.com [mailto:mjoel@netreon.com]
    Sent: Wednesday, July 11, 2001 2:32 AM
    To: ipp@pwg.org; ifx@pwg.org
    Subject: IFX> ippget Spec Change Request

    Greetings.

    Can the spec of the ippget event notification delivery method please be
    changed so that an implementation can either support only pull mode, or can
    drop to pull mode as needed? An implementation might only be able to
    support a limited number of simultaneous connections.

    It seems to me that the way the spec is currently proposed, if the printer
    receives a Get-Notifications request with notify-no-wait set to false or
    omitted, if the printer doesn't want to tie up a socket, it must return
    server-error-busy which I assume means it cannot at the same time return
    any events, but please correct me if that assumption is wrong. It seems to
    me that a new error code is needed that tells the client that it is too
    busy for push mode, but that if the request is made again with
    notify-no-wait set true, it would be honored. Even better, please add a
    status code like successful-ok-too-busy-for-no-wait, so that the events can
    at the same time be returned.

    Another change I would like to this spec is removal of
    client-error-not-found as a possible status code returned by a
    Get-Notifications request. When a job ends that had per-job subscriptions,
    those subscription objects will be deleted, but there could be event
    notification objects that had been created by those subscriptions that will
    last for some amount of time. Just because the subscription objects are
    gone shouldn't mean the client cannot receive the events.

    Finally, please explain why redirection-other-site would be used, and why
    it wouldn't apply to all IPP requests. Thanks.

    Regards,

    Marty Joel

    -----Original Message-----
    From: mjoel@netreon.com [mailto:mjoel@netreon.com]
    Sent: Monday, July 16, 2001 11:25
    To: ipp@pwg.org
    Subject: Re: IPP> NOT - substantive clarification about order Printer
    sends Event N otifications

    Hi Tom, et al,

    The whole purpose of defining an event order seems to be to make coding
    easy for the client implementors, at the expense of the server
    implementors. I'm wearing both hats, so it's all the same to me. I
    suppose that theoretically there could be more client than server
    implementations, which might be the only rational for all this. As I see
    it, for implementing a client, it's as difficult to handle the events
    grouped by subscription as it would be if the event order was random. For
    that reason, I propose that algorithm option (a) below be discarded.

    If I was to decide between forcing the events to be in chronological order
    (option (b) below) or that they be random (implementation-specific), I
    would choose random. I think it is more important that the server be able
    to process requests as quickly as possible, than to make it easy for the
    client impementors to code. If sorting is to be done, for performance
    reasons it makes more sense to me that it be done at the client.

    For these reasons, and for the fact that existing implementations may be
    ordering events differently than the proposals below, I propose that the
    specifications be changed to state that the event order is determined by
    the implementation, and that if the client needs them chronological it
    should sort them.

    Regards,

    Marty Joel

    "Hastings, Tom N" <hastings@cp10.es.xerox.com>@pwg.org on 07/16/2001
    10:23:36 AM

    Sent by: owner-ipp@pwg.org

    To: ipp@pwg.org
    cc: mjoel@netreon.com

    Subject: IPP> NOT - substantive clarification about order Printer sends
          Event N otifications

    As Marty and others have pointed out, we need to see if specifying the
    order
    that a Printer sends separate Event Notifications and Event Notifications
    within a Compound Event Notification will affect current implementations of
    ippget, indp, and mailto.

    Bob, Ira, and I have collaborated on defining the order that the Printer
    sends Event Notifications. We suggest that implementations have two
    choices
    for ordering that should cover the likely implementation approaches. See
    "Printer Event Sending Algorithm" below.

    ***********************************************************************
    Please review these proposals to see if you agree on including them in the
    next version of the Event Notification spec and the three Delivery Method
    documents.
    The deadline for I-Ds is this Friday, so I'd like to hear by Tuesday PM,
    July 17.
    ***********************************************************************

    General comments:

    1. 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.

    ************** Beginning of proposed new text *****************
    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.

    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.

    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:

    In 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.

    In 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.]

    ************** End of proposed new text *****************

    Tom



    This archive was generated by hypermail 2b29 : Mon Jul 16 2001 - 17:25:14 EDT