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 at process.com
> -----Original Message-----
> From: mjoel at netreon.com [mailto:mjoel at netreon.com]
> Sent: Friday, July 20, 2001 10:18 AM
> To: ipp at 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 at easysw.com>@pwg.org on 07/19/2001 06:55:20 PM
>> Sent by: owner-ipp at pwg.org>>> To: "Hastings, Tom N" <hastings at cp10.es.xerox.com>
> cc: mjoel at netreon.com, ipp at 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 at easysw.com> Printing Software for UNIX http://www.easysw.com>>>