The real problem is that IPP is aimed at several different problem spaces and
advocates of different features are arguing from these different zones.
Zone 1 - real network printers. I.e something that fills the same space as
TIPSI, 9100 etc.
Zone 2 - sophisticated intranet printers. Fills the same space as DPA
Zone 3 - Sophisticated Internet printing - the 'kinkos.com' model
Zone 4 - Simple Internet Printing - Internet Fax, sending newspapers to people's
house, ...
Zone 5 - sophisticated network spoolers (netware, CUPS, NT) fronting sets of
printers (IPP or otherwise)
A zone 1 advocate sees a completely different problem set from a zone 3 person.
Requiring z1 printers to send email seems like overkill - in many cases it will
be a server that is spooling to the printer and the server will send out human
readable notifications. Whereas to a z3 person the ONLY reasonable solution is
email.
The 'SDP' effort was started in recognition that z1 is very different from, say,
z3 - but it has stalled (really never started), principally because we had never
reached a significant parting of the ways - i.e. some feature where z1 and z3 (I
use z1 and z3 becuase they are extremes) had opposing needs. It seems that
notifications are such a feature.
I dont propose a solution - but it seems useful to try to express the
fundamental problem. I am not sure that the different zone camps are always
aware of the mind-set of their 'opponents' in other camps.
Secondly - do we need to mandate a method? Since the whole feature is optional
any client will have to deal with the possibility that its favorite notification
method is not available. We do have a way for a client to discover the supported
methods - that seems to be enough. The group's job is therefore to define the
'well known' set of methods. The TES task then becomes a matter of deciding
which ones to test first based on other criteria than mandatory or not.
My vote would be to test email first. The sinks exist, its clearly useful (at
least in some zones) and the printer side implementation is relatively
straightforward.
Paul
"McDonald, Ira" <imcdonald@sharplabs.com> on 06/21/2000 08:43:21 AM
To: "'Zehler, Peter'" <Peter.Zehler@usa.xerox.com>, henrik.holst@i-data.com,
ipp@pwg.org, peter.ultved@i-data.com
cc: (bcc: Paul Moore/AUCO/US)
Subject: RE: IPP> TES: Mandatory IPP notification agreement
Hi Peter and Henrik,
As a reminder to all - this is an IETF chartered working
group - such working groups do NOT make decisions in
face-to-face meetings (even at IETF Plenary sessions).
Decisions are made (and ratified) ONLY on the public
email discussion list.
The IPP mandatory notification method MUST be able to
politically survive the IESG review process.
While I think the INDP is a good effort technically, I
strongly doubt that the IESG will like it as the mandatory
IPP notification method. Unlike Email (SMTP) or MIBs (SNMP)
it interworks with no existing infrastructure, which is bad.
This mandatory notification method issue has also been
discussed at some IPP WG weekly telecons (some I've attended).
But this is also NOT the forum for final decisions.
Lastly, Peter you jumped from port filtering by firewalls
to MIME type filtering - but the latter requires that the
firewall have an Application Layer Gateway (ALG) to figure
out the protocol and THEN to find the MIME type inside the
protocol envelope.
Personally, I agree with Henrik about selecting email as
the IPP mandatory notification method.
Cheers,
- Ira McDonald, consulting architect at Xerox and Sharp
High North Inc
-----Original Message-----
From: Zehler, Peter [mailto:Peter.Zehler@usa.xerox.com]
Sent: Wednesday, June 21, 2000 5:25 AM
To: henrik.holst@i-data.com; ipp@pwg.org; peter.ultved@i-data.com
Subject: RE: IPP> TES: Mandatory IPP notification agreement
Henrik,
From the May PWG/IPP meeting minutes:
"4.6 Mandatory Notification Method?
After further discussion about a possible mandatory notification
method, the group agreed that the INDP Notification method should
become mandatory."
As for going through firewalls, the Bake-Off (hopefully) will test that
specifically. Firewalls can be configured to allow specific traffic to
pass. Some filter only on a port number and others examine content. I
intend to have two firewall vendors at the Bake-Off with products that are
able to filter at least on the port number. I hope at least one will also
be able to examine the MIME type.
Pete
Peter Zehler
XEROX
Xerox Architecture Center
Email: Peter.Zehler@usa.xerox.com
Voice: (716) 265-8755
FAX: (716) 265-8792
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 139-05A
Webster NY, 14580-9701
-----Original Message-----
From: henrik.holst@i-data.com [mailto:henrik.holst@i-data.com]
Sent: Wednesday, June 21, 2000 3:53 AM
To: ipp@pwg.org; peter.ultved@i-data.com
Subject: Re: IPP> TES: Mandatory IPP notification agreement
Well it was my understanding that we didn't agree on a mandatory method.
And the INDP method
won't go through a firewall, so if you are searching for a mandatory method
I would say MAILTO.
Henrik
"Zehler, Peter" <Peter.Zehler@usa.xerox.com>@pwg.org on 20-06-2000 17:43:51
Sent by: owner-ipp@pwg.org
To: "IPP Discussion List (E-mail)" <IPP@pwg.org>
cc:
Subject: IPP> TES: Mandatory IPP notification agreement
All,
I am working the content planning for the IPP Bake-Off. I want to be sure
that there is PWG wide agreement on the notification issue.
It is my understanding that INDP is the mandated IPP notification method.
There were some minor updates that have been agreed to and we are awaiting
the final version of the document for PWG last call. The minor changes are
documented in the meeting minutes from May meeting of the PWG. This
upcoming INDP document will be the document that the notification section
of
the Bake-Off will use as a base.
Is this correct or did I misunderstand?
Pete
Peter Zehler
XEROX
Xerox Architecture Center
Email: Peter.Zehler@usa.xerox.com
Voice: (716) 265-8755
FAX: (716) 265-8792
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 139-05A
Webster NY, 14580-9701
This archive was generated by hypermail 2b29 : Wed Jun 21 2000 - 13:01:30 EDT