IFX Mail Archive: RE: IFX> ippget Spec Change Request

IFX Mail Archive: RE: IFX> ippget Spec Change Request

RE: IFX> ippget Spec Change Request

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Wed Jul 11 2001 - 11:58:36 EDT

  • Next message: Hastings, Tom N: "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.

    - 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


    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.


    Marty Joel

    This archive was generated by hypermail 2b29 : Wed Jul 11 2001 - 12:04:38 EDT