Hi Michael,
First, I suggest that any Subscription with a missing/empty
"notify-recipient-uri" MUST support retrieval of those
notifications via IPPGET in-band and MAY support one or
more other client pull methods for notification retrieval.
Second, I agree that we have an ambiguity about WHICH are
the supported client pull methods, so how about a second
attribute (strictly alternate to "notify-recipient-uri",
so that one or the other MUST be in every Subscription),
called "notify-pull-method (1setOf keyword)", so that the
Printer attribute "notify-pull-method-supported" can enumerate
all the client pull methods supported by an implementation.
OK?
Cheers,
- Ira McDonald
-----Original Message-----
From: Mike Sweet [mailto:mike at easysw.com]
Sent: Thursday, October 25, 2001 8:46 PM
To: McDonald, Ira
Cc: Hastings, Tom N; ipp (E-mail); IPP FAX DL (E-mail)
Subject: Re: IPP> NOT - IPPGET Delivery Method - ISSUE 02 'ippget' URI
McDonald, Ira wrote:
> ...
> So let's just say that methods that are client pull (not server
> push) MUST NOT specify "notify-recipient-uri" in the Subscription
> attributes group.
>> OK?
No argument here.
> PS - Recall that we can tell if IPPGET is supported (even though
> it MUST NOT appear in 'notify-uri-schemes-supported') because of
> 'operations-supported'.
Right, but that doesn't tell us what operation to use for a
specific subscription, right? :)
Currently we can say that if there is no notify-recipient-uri,
then use IPPGET and Get-Notifications for the subscription, but
what about other methods that might need the same treatment?
I know I'm nitpicking, but we need to make sure that the spec
addresses these issues so that future extensions (and there *will*
be more extensions I'm sure) can work together and not confuse
clients...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com