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

RE: IPP> NOT - Agreements on the ISSUES in the IPPGET spec and IP P base spec

From: mjoel@netreon.com
Date: Fri Jul 20 2001 - 11:31:22 EDT

  • Next message: James Kempf: "RE: IPP> FW: [Srvloc-discuss] [Multiple registrations for a singl e print device]"

    Hi Mike,

    That's very important to know! That means (Michael and I were right and)
    we do need some end-of-event-notification-attributes-group-tag.

    Tom: I don't think the ippget design is ready for prime time.

    Marty

    Mike Bartman <bartman@process.com>@pwg.org on 07/20/2001 08:07:42 AM

    Sent by: owner-ipp@pwg.org

    To: ipp@pwg.org
    cc:

    Subject: RE: IPP> NOT - Agreements on the ISSUES in the IPPGET spec and IP
          P base spec

    I believe there is a problem with relying on chunking as a way to convey
    any
    information in IPP.

    I could be mis-remembering, but I believe the HTTP 1.1 RFC says that
    intermediate links in a transmission, such as a proxy server, may remove
    the
    chunked nature of an HTTP 1.1 transmission if it chooses to. I remember
    there being some discussion of the method for doing this in the RFC.

    This would mean that a printer could send out a chunked message, but that a
    link in the path to the client can convert the message to a non-chunked
    message, eliminating any semantic information based on the chunk
    boundaries.
    If I'm reading things correctly here, that would be a problem.

    Spreading semantic information between the transmission layer and the
    application layer is a bad idea in a protocol anyway. Causes no end of
    implementation headaches and limits flexibility in future.

    -- Mike Bartman
       Process Software
       bartman@process.com

    > -----Original Message-----
    > From: mjoel@netreon.com [mailto:mjoel@netreon.com]
    > Sent: Friday, July 20, 2001 10:18 AM
    > To: ipp@pwg.org
    > Subject: Re: IPP> NOT - Agreements on the ISSUES in the
    > IPPGET spec and
    > IPP base spec
    >
    >
    >
    > Hi Michael,
    >
    > 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).
    >
    > The nice division between HTTP processing and IPP processing has been
    > blurred a little on both client and server. On the server,
    > if the printer
    > decides to support a request for Get-Notifications with
    > waiting, it will
    > start a chunked HTTP reply. It will then send one chunk
    > containing the
    > first part of the IPP reply including any event notification attribute
    > groups for events that have already occurred (which is not
    > terminated by
    > end-of-attributes-tag). As each event occurs it will send a chunk
    > containing only an event notification attributes group. If
    > the printer
    > decides to stop sending events when an event occurs, it will
    > send a chunk
    > which contains the event notification attributes group
    > containing the event
    > that occurred, another group containing just a notify-get-interval
    > attribute, and an end-of-attributes-tag. If the printer
    > decides to stop
    > sending events when an event has not just occurred, it will
    > send a chunk
    > which contains an event notification attributes group
    > containing just a
    > 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.
    >
    > Note to Tom: maybe the ippget spec should explain this.
    >
    > Regards,
    >
    > Marty
    >
    >
    >
    >
    >
    >
    > Michael Sweet <mike@easysw.com>@pwg.org on 07/19/2001 06:55:20 PM
    >
    > Sent by: owner-ipp@pwg.org
    >
    >
    > To: "Hastings, Tom N" <hastings@cp10.es.xerox.com>
    > cc: mjoel@netreon.com, ipp@pwg.org
    >
    > Subject: Re: IPP> NOT - Agreements on the ISSUES in the
    > IPPGET spec and
    > IPP base spec
    >
    >
    > "Hastings, Tom N" wrote:
    > > ...
    > > TH> Anyone have any thoughts?
    > >
    > > TH> One possibility would be to add a "notify-status-code"
    > > attribute that can be returned in an Event Notification Attributes
    > > group along with Event Notification attributes. The value would
    > > indicate that this is the last group for now. We've done a similar
    > > status code in a Group thing for INDP Send-Notifications Attribute
    > > Groups.
    >
    > After thinking on this a while, I think we need something like this
    > or another special value tag ("end-of-group" tag?) so that the client
    > knows that it can go off and process the event data and check back
    > later for more info (with the same connection...)
    >
    > --
    > ______________________________________________________________________
    > 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:34:11 EDT