1.mailto and indp are used by clients for totally different purposes - you can
do things with indp that you absolutely cannot do with mailto and vice versa.
They are not overlapping they are complimentary. Therefore there is no bloat
issue as such
2. I did not suggest that a client implement ALL notification mechansisms - just
2.
3. I am surprised that CUPS would want to use mailto from the actual printer
back to the cups end user. I would have thought that you would want to generate
mail to your clients and administartors youself. In this way you can ensure that
they get consistent messages from you. By delegating it to the printers your
clients will get a mix of differnt messages from different vendors, some smart
devices will have quite good text, some will have poor text, some might be
localized if you are lucky. The clean thing to do would be to get indp messages
from the device into the spooler and then generate the email yourself - you can
then have consistent configurable text accross the entire set of devices. You
can also do polling for those device that dont support notifactions at all and
your users will still get the same great experience.
[I know I should butt out of the design of your product but I cant help it :-) ]
4. even if we mandate mailto, not all printers will support it. In order for it
to work the printer must have its SMTP gateway configured by somebody. In some
cases this will not have been done so the mailto method wont work - interesting
question about how a printer should deal with this case. Presumably it must not
say it can do mailto - or perhaps it will accept the requests and throw them
away. Clients will always have to be smart.
5. INDP does go over fire walls - this is true. The main use cases for INDP are
not Internet casses (ie. spooler talking to actual printer).
6. For me the mailto method is more useful when the spooler if proxying the
printers via IPP. Ie. the spooler clients send requests via IPP that it then
sends to printers (maybe via IPP )
client-----IPP (mailto)--->spooler------IPP(indp)----->printer. or
client-----IPP(mailto)---->spooler------(LPR, 9100, parallel)------>printer
7.Mandating a method does not gurantee interop. THe two methods do totally
different things. If my client needs machine readable notifications (for example
I have a rendering pipeline driven by page complete messages) then telling me
that mailto is available does nothing to help me. Its like saying "we have
mandated SMTP why the heck do you want to do HTTP" - they do different things.
8. In real life there will be printers that do notifactions that dont support
mailto. I am just trying to get the standard to conform to what the actual
situation will be rather than to some ideal case. Lying to client developers is
not useful.
9. Notifiactions is completey optional- all clients will have to behave smartly
in the situation where thier favorite method is not available.
Michael Sweet <mike@easysw.com> on 07/21/2000 06:44:51 AM
To: pmoore@peerless.com
cc: ipp@pwg.org (bcc: Paul Moore/AUCO/US)
Subject: Re: IPP> notification methods
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 - 11:33:54 EDT