pmoore@peerless.com wrote:
>
> Following the SF meeting I would like to formally propose the
> following.
>
> 1. If a device wants to expose human readable events then it MUST
> support the mailto method
>
> 2. If a device wants to expose machine readable events then it MUST
> support the INDP method
>
> But we do not UNCONDITIONALLY require either.
The only problem with this is that there than becomes no standard
notification method for IPP, which means that clients will:
1. Only work with printer objects that support their particular
notification method of choice,
2. Try to implement reception via all notification methods,
causing bloat, increased complexity, etc. which will
likely lead to a less stable product,
3. Not use notification at all, and poll the printer object
to provide status information to the user.
There is also the issue of whether a notification method is
truly available to the client - e.g. a remote client asks for
indp notifications, but the firewall(s) between the client and
server won't pass them through!
For CUPS, we'll probably implement both mailto and indp to support
existing email notifications and allow better web/GUI clients, so
I'm not so concerned about what happens on systems running CUPS.
However, I do think we need to mandate at least one method to
ensure interoperability.
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com
This archive was generated by hypermail 2b29 : Fri Jul 21 2000 - 09:53:11 EDT