"McDonald, Ira" wrote:
> ...
> Doesn't the empty string do that, too? :)
>> <ira>
> No - the empty string says there is NOT a destination for Printer
> pushed notifications.
> </ira>
Hmm, then we'd be better off specifying that an IPPGET subscription
should not specify a recipient then, right? :)
> ...
> (1) Redefine 'notify-recipient-uri' to allow empty string
> to indicate "client fetches notifications in-band via IPP or
> out-of-band by some non-IPP protocol".
See my comment above...
> (2) Add a new boolean operation attribute and Subscription
> Description attribute such as 'notify-ippget' (method
> specific, as we already did with email notifications)
> that is an ALTERNATIVE to the presence of 'notify-recipient-uri'
> in the Job Creation operation and on the Subscription object.
I really, really, really, really, (really!) don't like this
approach. It fosters so much bloat and non-standardization it
isn't funny. Imagine a couple dozen of these "notify-xyz"
attributes floating around, with no interoperability.
*If* we need to have an extra attribute to indicate the type
of subscription, it should be something generic like "notify-scheme"
which refers to the method name (usually the URI scheme name, but
"ippget" for IPPGET, etc.) so that future additions don't involve
attribute creep. It also neatly sidesteps the IETF registration
issue with "ippget".
In short, here is my proposal:
1. Add a notify-scheme (type2 keyword) attribute to the
notification spec. This will be a REQUIRED subscription
attribute (i.e. returned with Get-Subscriptions or
Get-Subcription-Attributes)...
2. REQUIRE *either* notify-recipient-uri *or* notify-scheme
in the subscription creation request.
3. Make notify-recipient-uri REQUIRED in the mailto and indp
specs, and notify-scheme REQUIRED in the ippget spec
(for the subscription creation request).
Comments?
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com