Why require wait mode at all?
Also, I commented about notify-get-interval on an earlier reply. I'd
prefer replacing it with a boolean or a status code.
"Hastings, Tom N" <firstname.lastname@example.org>@pwg.org on 08/01/2001
Sent by: email@example.com
Subject: RE: IPP> NOT - ISSUE 05 [return successful-ok-events-complete']
With this simplified Get-Notifications that only takes subscription-ids,
would it be possible to REQUIRE a Printer to support Event Wait Mode for at
least one connection as long as the identified Subscription Objects exist?
A Notification Recipient client MUST still accept a "notify-get-interval"
response from the Printer and try the Get-Notifications that many seconds
later, if still interested in the events.
From: Michael Sweet [mailto:firstname.lastname@example.org]
Sent: Wednesday, August 01, 2001 10:53
To: Hastings, Tom N
Cc: ipp (E-mail); McDonald, Ira; email@example.com
Subject: Re: IPP> NOT - ISSUE 05 [return successful-ok-events-complete']
"Hastings, Tom N" wrote:
> So lets simplify Get-Notifications as follows:
> 1. drop the "notify-recipient-uri" as an input operation attribute.
> 2. drop the "notify-search" (boolean) operation attribute.
> 3. Sender MUST supply one or more subscription-ids in the
> "notify-subscription-ids: (1setOf integer(1:MAX)) operation attribute.
> 4. Sender MAY supply one or more parallel sequence-numbers in the
> "notify-sequenced-numbers" (1setOf integer(1:MAX)) to eliminate getting
> duplicates for the corresponding Subscription Object.
Sounds good to me!
-- ______________________________________________________________________ Michael Sweet, Easy Software Products firstname.lastname@example.org Printing Software for UNIX http://www.easysw.com
This archive was generated by hypermail 2b29 : Sat Aug 04 2001 - 05:03:54 EDT