IPP Mail Archive: RE: IPP> ippget Design Needs Work [use mul

IPP Mail Archive: RE: IPP> ippget Design Needs Work [use mul

RE: IPP> ippget Design Needs Work [use multi-part/related?]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Jul 20 2001 - 14:44:29 EDT

  • Next message: Hastings, Tom N: "RE: IPP> RE: IPPGET Document Review"

    Marty and Michael,

    I think we all agree that HTTP chunking cannot convey any semantics for IPP.
    We need to keep the layers separate. We have tried to design the IPP Model
    and Semantics, so that it could be conveyed on other transports besides

    Your idea of using multi-part/related with each part being an
    application/ipp part. The first part is the initial response with all the
    pending Event Notifications (and doesn't end with the
    'end-of-attributes-tag'). Each subsequent part is one or more additional
    Event Notification Attributes Groups that have occurred as a "bunch" (and
    doesn't end with the 'end-of-attributes-tag'). The last part will contain
    one or more Event Notification Attributes Groups and an
    'end-of-attributes-tag' when there are no more events possible (all
    Subscription objects in the scope of the Get-Notifications are gone or the
    Printer wants to end wait mode and returns the "notify-get-interval"
    attribute in a separate Event Notification Attributes Group).



    -----Original Message-----
    From: mjoel@netreon.com [mailto:mjoel@netreon.com]
    Sent: Friday, July 20, 2001 08:53
    To: ipp@pwg.org
    Subject: IPP> ippget Design Needs Work


    Mike just brought up an important point, that chunking can be removed when
    the client receives it. Michael just raised the suggestion that multi-part
    be used. I like that idea.

    I had thought that using a tag to mark the end of each event notification
    attributes group was a good idea, but I'm now thinking differently.

    A well-designed client or server will separate http processing from ipp
    processing. When the client asks for Get-Notifications with waiting, one
    layer should be handling receiving the http, and when a complete event
    group is received, pass it to the ipp processor to parse and handle. But
    the http parser shouldn't need to be doing ipp parsing to know when it's
    done receiving a full event group, which is why the
    end-of-event-notification-attributes-group-tag idea isn't good. Mike's
    point prevents the client from using chunking to determine the end of an
    event group.

    Short of doing away with wait mode, is there anything besides multi-part
    that solves this problem?


    This archive was generated by hypermail 2b29 : Fri Jul 20 2001 - 14:50:47 EDT