"Hastings, Tom N" wrote:
> ...
> 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).
> ...
I think that we need to make each part a valid/standard
IPP message of its own:
1. The application/ipp type defines an IPP "message" that
can be a request or response. The format is identical
save for a different interpretation of the operation
or status code field.
2. It will simplify client and server implementations -
only 1 type of IPP data stream needs to be supported.
3. It will allow the parts to be received in any order -
not too important for the current HTTP transport, but
might be important for other types of transports.
4. It mirrors what the mailto and indp methods do - that
is, one standard message format for each collection of
events.
I think the only issue is what the status code field will
contain in the parts - should they all contain the same code,
or should each IPP message contain the current server status
(e.g. successful-ok-too-many-events)?
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com