"Hastings, Tom N" wrote:
>> So there are now two more issues for the IPPGET spec from the mailing list:
>> ISSUE 08: Allow the client to supply a list of subscription-ids and
> notify-sequence-numbers so the Printer filters out duplicates? From Marty
> Joel's Fri 07/27/2001 21:15 email:
> ...
MS> Isn't this a duplicate of Issue 7?
> ISSUE 09: Make Event Wait Mode OPTIONAL for a Sender and a Receiver?
> Currently the spec REQUIRES the Receiver to support both values of the
> "notify-wait" operation attribute ('true' and 'false').
>> With the Notification Recipient being able to request the Receiver to filter
> out duplicates, is it ok to allow the Receiver to always force the
> Notification Recipient back to Event No Wait Mode with the
> "notify-get-interval" operation attribute of when to poll next?
>> Of should Event Wait Mode be RECOMMENDED for the Receiver?
> What about RECOMMENDED for the Sender?
> ...
MS> I think event-wait-mode should be OPTIONAL but RECOMMENDED. There
will always be client and server implementations that can't do the
multipart encoding, or can't spare the extra socket resources.
MS> Since we already have defined the fallback behavior for both client
and server, this should not pose a problem.
MS> It might be useful to provide a new "notify-wait-supported"
attribute that the client can query with the Get-Printer-Attributes
request to see ahead of time if the server can support wait mode,
although with the caveat that the server may choose not to honor
individual requests in the interests of resource management.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com