I have tried to respond to some of your comments below. My intent in the
original posting was to get people to stop thinking that all notifications
need to pass through a firewall. I believe that some of these ideas have
found their way into the recent document by Roger Debry. Roger's paper
does provide significantly more detail on this subject.
You certainly did point out some interesting area for further discussion,
so I am copying the DL with this message.
Ron Bergman
Dataproducts Corp.
On Thu, 12 Feb 1998 papowell@astart.com wrote:
> Ron, I like your ideas, and have just a few
> keyboard in cheek comments. These are not meant too seriously,
> but do open some points for discussion.
>
> > From ipp-owner@pwg.org Mon Feb 9 09:26:56 1998
> > Date: Mon, 9 Feb 1998 08:39:39 -0800 (Pacific Standard Time)
> > From: Ron Bergman <rbergma@dpc.com>
> > To: ipp@pwg.org
> > Subject: IPP> MOD> A New View of Notification Requirements
> >
> > A major point missing from the previously posted notification
> > requirements concerns the location or intent of the user. I believe
> > this to be the most important factor to be considered, and should
> > minimize much of the discussion concerning firewalls. This analysis
> > assumes, as in the previously posted requirements, that submission
> > problems such as transmission errors and acceptance of the job are
> > handled by the job submission protocol.
> >
> > REMOTE USER:
> >
> > - The remote user is always the submitter of the job.
> > - A firewall may or may not exist between the remote user and the
> > printer.
> > - The document will not be directly retrieved by the remote user.
>
> Huh? Do you mean 'physically picked up'? I am missing something...
Yes. One example is scenario #4 from Roger Debry's "Requirements
Statement for IPP Notification". Here the user submits a job from a hotel
room to be printed at a local Kinko's. He will retrieve the document at
some point in time after it is printed, but the document is removed from
the printer by a Kinko's employee and delivered to the user when he
arrives at the store.
>
> > - The remote user does not require any notifications other than an
> > indication that the job has completed. The remote user may desire
>
> Or not completed. Or completed with errors. Or is still printing
> after so many minutes.
>
> This is a 'well, we need this option' type of problem that has led to
> the current throwing up of hands and washing them of the problem.
> (Neat trick that, washing your hands after throwing them up...
> but I digress.)
Completed with errors or not able to complete certainly should be part of
the notification to a remote user only for conditions that he can resolve.
For printer problems, not related to the data stream, this could be
optional since he cannot fix any problems if is not physically close to
the printer.
>
> > additional notifications, but since he is remote from the printer,
> > he will be unable to perform any required actions. For simplicity,
>
> Say again? I am lost. I have two firewalls here, internally.
> The printer (on the other side of the firewall for most folks here)
> is right beside my office. And there is an EXTERNAL firewall on
> our connection to the Big Bad Internet.
This is a situation I did not anticipate. Does the internal firewall have
the same protection characteristics as the external? I would guess that
the internal firewall could be configured so that notification messages
would pass through to known users. In this case, the user would be local.
>
> Also, some system administration types want to have their staff in
> sites that are outside an internal firewall. Or inside an internal one.
>
> > I propose that we restrict notification to a remote user to job
> > completion.
>
> Or that the printer is not working. And send some to the adminstrators
> as well. Oh. Perhaps MULTIPLE administration sites if the first is down.
> Sigh... The mind boggles at the wonderful possibilities... :-)
In some cases other notifications may be required. A printer not working
may be a good example if the job cannot be printed on another printer by
local administration.
>
> > - The submitter does not require immediate notification of job
> > completion. Again he may desire immediate notification but, since
> > he is not the person that will retrieve the job, this should not be
> > a high priority.
>
> Huh? Say what? I think you are confusing firewall, physical proximity,
> and logical responsibility.
I hope not!
>
> >
> > LOCAL USER:
> >
> > - The local user will never encounter a firewall in the path to the
> > printer.
>
> Nonsense. In fact, we have a firewall pointing INTO the engineering
> group due to their habits of screwing up the network... :-). They would
> get frosted if they could not print to the printer outside their local
> network.
See above. Your situation should be different than a user completely
outside of the system. Or am I missing something?
>
> > - The local user may or may not be the submitter of the document to be
> > printed. He is always the recipient of the document.
>
> Say what? I just picked up a report from the guys in engineering... and printed
> one for him. :-( sigh...
Helpful coworkers are beyond the scope of the analysis ;-)
>
> > - The local user should have the option of receiving all possible
> > notifications regarding the progress of the job and any problems or
> > errors encountered. Maintenance or support personnel may also
> > receive problem and error notifications in addition to or instead
> > of the local user.
>
> Ahh... but where are the maintenance and support personnel? On which
> side of the firewall?
Inside of an extenal firewall. There could be a situation where the
maintenace personnel are outside of the firewall. In this situation, the
firewall must be configured so that they can receive immediate
notification. There will always be exceptions, but they will be known and
can be defined in the configuration. The exceptions must not be dynamic.
>
> > - The local user requires prompt notification of job completion and
> > possibly problems and error conditions.
> >
> > Since only the remote user must deal with a firewall and he does not
> > require any notification other than job completion, the protocol
> > requirements are greatly simplified. For the remote user, email
> > notifications should be a perfect match. I have not seen any other
> > methods proposed that everyone agrees are firewall *safe*.
>
> Make sure your spam filters are tuned up lads, I can see a new wave
> of spam coming:
>
> mail from: printer@kinko.darkside.com
> your job: &*()&*()(*&*()&&*() has just been completed.
>
> Perhaps we need to add some 'user authentication' to this as well?
> Sigh. And what about folks whose email and network address are different?
>
> >
> > Notification for the local user are open to any reasonable protocol, no
> > firewall is ever encountered in this case. The is the area that will
> > require the most effort to resolve the notification issue.
>
> I agree. This is because everbody who has tried to do a good job has
> discovered that it is a HORRIBLE complex problem.
>
> So rather than do a poor job and get the blame, they rapidly retreat,
> throwing up hands, etc etc
>
> >
> > The model document should include the following attributes to support
> > these requirements.
> >
> > 1. remote-notification-uri (Job Template Attribute) No job
> > completion notification is returned to the remote user if this
> > attribute is not included in the job submission request.
> > 2. local-notification-uri (Job Template Attribute) No job
> > notifications are returned to the local user if this attribute is
> > not included in the job submission request.
> > 3. Local-notification-types-requested (Job Template Attribute) An
> > enum or bit map which defines the types of notifications
> > requested. Includes job completion, job progress, job errors,
> > printer errors, printer warnings, etc.
> > 4. local-notification-types-default (Printer Description Attribute)
> > 5. printer-service-notification-uri (Printer Description Attribute)
> > All printer problems are reported to this URI.
> >
> > This is not intended to be a complete notification solution for IPP. My
> > only intent is to minimize the discussion regarding firewalls. (This
> > discussion (firewalls) appears to be making very little progress.) There
> > is still a significant amount of work remaining to complete the IPP
> > notification effort.
> >
> > Comments invited!
> >
> >
> > Ron Bergman
> > Dataproducts Corp.
>
> Thanks Ron. I am glad that SOMEBODY is still thinking about this.
>
> Patrick Powell
>
>