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

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

mjoel at netreon.com mjoel at netreon.com
Fri Jul 20 11:31:22 EDT 2001


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 at process.com>@pwg.org on 07/20/2001 08:07:42 AM

Sent by:  owner-ipp at pwg.org


To:   ipp at 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 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
>
>
>






More information about the Ipp mailing list