IPP Mail Archive: RE: IPP> machine readable etc. - why Harry

IPP Mail Archive: RE: IPP> machine readable etc. - why Harry

RE: IPP> machine readable etc. - why Harry is right

From: pmoore@peerless.com
Date: Tue Aug 22 2000 - 12:57:58 EDT

  • Next message: McDonald, Ira: "RE: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM - The IPPNotification I-Ds will now go the IESG)]"

    I felt that the nail in the coffin of multi-part response was the radical change
    in the data flow - it was too much of a change (at least to my mental model of

    Regarding the problems you cite

    1. What is a buffering proxy. If it doesnt allow what I described then it will
    break instant messegner systems and hence wont survive in the market place very
    long. IN fact this proposal has the same requirements as instant messgener
    systems (and they definitely work).

    2. Ditto

    3. What does that means -proxies are limited to 2 per server (by spec). Do you
    mean HTTP proxies? Well this wont be using HTTP proxies - they will have to be
    direct (socks or winsock) proxies.

    4. is a good point. But then the printer probably isnt going to have a lot of
    clients talking directly to it.

    "Carl Kugler/Boulder/IBM" <kugler@us.ibm.com> on 08/22/2000 09:35:44 AM

    To: pmoore@peerless.com
    cc: "Harry Lewis/Boulder/IBM" <harryl@us.ibm.com>, bwagner@digprod.com,
          ipp@pwg.org, "Herriot, Robert" <Robert.Herriot@pahv.xerox.com> (bcc: Paul

    Subject: RE: IPP> machine readable etc. - why Harry is right

    Paul wrote:
    >There are two workable possibilities - one is ipp-get. This already exists but
    >is polling - and people have a visceral dislike of polling to say the least!
    It is a little better than polling, in that it introduces some message
    queuing. With Get-Job-Attributes polling, you just get a periodic snapshot
    of the state. With ipp-get, you can reconstruct the sequence of events
    (e.g., Job history), even if you don't get them in real time.

    >The other alternative is a tweak to indp. Instead of the client sending in a
    >and the printer connecting to that URL we could have a client-opened
    >i.e. the client opens the connection
    >it subscribes on the 'normal' operation url,
    >in the subsription the notification url is 'indp:'
    >the lack of an address in the url causes the printer to use the exisitng
    >connection rather than open a new one.
    This solution has all the problems that killed the multi-part response solution:

    1. Buffering proxies. (Although I strongly doubt their existence.)
    2. Proxy time outs. (Although this could be handled with reconnects and
    sequence numbers.)
    3. Proxies being limited (by spec) to two(?) connections to any particular
    4. Tiny printers that can't handle more than a few active connections at a

    Ipp-get might be as good as it gets.


    This archive was generated by hypermail 2b29 : Tue Aug 22 2000 - 13:10:24 EDT