IPP Mail Archive: Re: IPP> NOT - Agreements on the ISSUES in

IPP Mail Archive: Re: IPP> NOT - Agreements on the ISSUES in

Re: IPP> NOT - Agreements on the ISSUES in the IPPGET spec and IPP basespec

From: Michael Sweet (mike@easysw.com)
Date: Fri Jul 20 2001 - 11:12:28 EDT

  • Next message: Michael Sweet: "Re: IPP> NOT - Agreements on the ISSUES in the IPPGET spec and IPP base spec"

    [I *wish* I had been able to participate in the phone conference;
     unfortunately I was stuck in another meeting...]

    mjoel@netreon.com wrote:
    > ...
    > I argued about this for a while in the teleconference call. It seemed to
    > me that the client needed to know when it got the end of the bytes of an
    > event notification attributes group. It turns out that Get-Notifications
    > with waiting requires the use of HTTP 1.1's chunking. Each returned chunk
    > will contain 1 or more event notification attributes groups (although I
    > expect that for most implementations it will only be 1).

    OK, this needs to be explicitly spelled out in the spec - some
    implementations (CUPS included) will buffer a certain amount of data
    (for CUPS it is 64k) and if the attributes in the buffer exceed the
    size of the buffer, you have to write a chunk containing the data
    so far and then continue filling the buffer with more data.

    This could potentially mean that event notifications could end up in
    multiple chunks, so the spec should specify that event notifications
    cannot span multiple chunks, and maybe set a maximum size for the
    notification data...

    > ...
    > notify-get-interval attribute, and an end-of-attributes-tag. Any function
    > that does encoding must now be told if it should build a complete reply, a
    > first chunk, an intermediate chunk, or a last chunk. On the client, when
    > it issues Get-Notifications with waiting, it needs to be prepared to
    > receive the HTTP chunks.

    As long as the boundaries of each event are clearly delineated, the
    client implementation shouldn't be too bad. The server, on the other
    hand, will be more difficult to implement...

    [FWIW, multi-part encoding would make this a whole lot easier!]

    -- 
    ______________________________________________________________________
    Michael Sweet, Easy Software Products                  mike@easysw.com
    Printing Software for UNIX                       http://www.easysw.com
    



    This archive was generated by hypermail 2b29 : Fri Jul 20 2001 - 11:16:23 EDT