IPP Mail Archive: RE: IPP> MOD> A New View of Notification Requirements

RE: IPP> MOD> A New View of Notification Requirements

Turner, Randy (rturner@sharplabs.com)
Tue, 10 Feb 1998 21:55:11 -0800

These requirements are a perfect example of taking a simple idea like an
email address to notify on job completion, and turning into an
"architecture". Do we really need this complexity? I think just a simple
email address to notify when a job completes would be sufficient to meet
the needs of the majority of people that use this facility. I'm assuming
that job completion notification is in addition to a separate method for
general IPP async notification.

Also, the last requirement about a URI to notify regarding printer
problems is device management, and we (and the rest of the networking
community) already have a solution for device management. I would like
to see IPP remain a job submission, and later, a job management
protocol. I'm hoping I didn't spend the last 3 - 4 years of my life
developing the Printer MIB for no reason...

Randy

-----Original Message-----
From: Jay Martin [SMTP:jkm@underscore.com]
Sent: Tuesday, February 10, 1998 3:11 PM
To: Ron Bergman
Cc: ipp@pwg.org
Subject: Re: IPP> MOD> A New View of Notification
Requirements

Ron,

> 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.

Can (should?) the URI attributes be multi-valued?

In particular, I'm thinking the
"printer-service-notification-uri"
attribute would greatly benefit from having multiple URI
targets,
so as to support delivery of printer device problems to multiple
operations personnel.

Or is the "printer-service-notification-uri" attribute to be
used
for other reasons?

...jay

----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com

--
	--  Underscore, Inc.        |  Voice:   (603) 889-7000

--
	--  41C Sagamore Park Road  |  Fax:     (603) 889-2699

--
	--  Hudson, NH 03051-4915   |  Web:
http://www.underscore.com   --


----------------------------------------------------------------------