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).
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
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