I agree with Carl-Uno that the IPP documents (Model, Protocol, Notification,
Printer Install Extension, Job and Printer Set Operations, Production
Printing, and Administrative Set2 operations) have generally met the
requirements in the Goals document (RFC 2567).
However, it would be good to list which features meet each requirement.
Doing such a feature tracking is part of the usual testing that requirements
are met. Here are some additional comments though:
1. It was good that IPP lists attributes for a directory schema in its
Appendix. However, the discovery that is described in Scenario 11.3 sounds
like it is beyond what current LDAP and SLP can do even with our schema. In
Scenario 11.4 the User needs to find a print shop that is open, that is near
me, and that can print color transparencies.
2. The whole discussion about Discovery also brings up whether IPP is
suffering in the competition of print protocols, because it doesn't have
profiles that reference other open standards for discovery. Such profiles
could be:
a. the Internet between Enterprises
b. within an Enterprise
c. unmanaged small networks for SOHO and home.
Defining such Profiles is the essence of the "IPP Complete" proposal that
has been made on the DL for a complete end-to-end solution. Such Profiles
would NOT need to define additional protocols, but just reference existing
ones and specify which options are required.
3. On page 6 is the discussion about IPP Client talking to Servers and to
Printers. It does not clearly state whether those IPP Clients can be
servers or not. Thus the discussion about whether IPP/1.1 plus IPP
Notification meets the needs of a Server to Device Protocol needs to be had.
4. Page 8, line 319, Section 3.1.9 Viewing the status and capabilities of a
printer, has:
- supported media, commonly paper, by size and type
The proposal to add a Media object with a filtered query operation (and
other operations) would be needed to meet this requirement. We agreed that
if we supported a Media Resource, we should do it as a separate object with
its own set of operations, not as a general Resource object.
5. Page 11, Section 3.3 Administrator, has:
Minimally, the administrator must also have the tools, programs,
utilities and supporting protocols available to be able to:
create an instance of a printer
create, edit and maintain the list of authorized
end-users
create, edit and maintain the list of authorized
operators
create, edit and maintain the list of authorized
administrators
We have not defined any operations and/or attributes for authorization; only
authentication. The only thing we have defined is the
client-error-not-authorized (0x0403) error status code.
6. Page 16, line 661-663, and 673, Section 5.1 PRINTER DISCOVERY, has:
- whether or not payment is required for printing (outside the scope of IPP)
- maximum job size (spool size) (outside the scope of IPP)
- telephone number
Presumably, the attributes are discoverable, but the mechanism is outside
IPP? We could add such IPP Printer Description attributes.
7. Page 50, line 1809, Section 11.22 END TO END SCENARIO - ACROSS
ENTERPRISES, has:
job-name = memo-to-Don-Wright
We should have had a "job-recipient-name" Operation Attribute, rather than
the sender and recipient having to have a convention of using the "job-name"
for the recipient.
Comments?
Tom
> -----Original Message-----
> From: Manros, Carl-Uno B
> Sent: Tuesday, March 06, 2001 15:07
> To: 'pwg-ipp@pwg.org'; 'pwg@pwg.org'
> Cc: Hastings, Tom N; Zehler, Peter; Herriot, Robert
> Subject: Input for IPP discussion in PWG
>
> Hi,
>
> I just quickly went over the RFC 2567 - Design Goals for an Internet
> Printing Protocol document to see if we had covered what we intended at
> the beginning of the project.
>
> I think we have done a pretty good job of covering the original
> requirements and goals.
>
> A few comments:
>
> 1) We did not design a feature in IPP itself to do printer discovery, but
> by providing schemas for SLP and LDAP I think we have done the right thing
> in this area.
>
> 2) In scenario 10.9 we are talking about supporting payments for print
> jobs being sent to a print service provider. We have not covered this
> explicitly, but I assume that an implementer can combine IPP with one of
> the existing methods for payment over the web, without too much extra
> integration work, and as far as I am aware, we cannot identify a really
> standardized, non-proprietary way of making payments over the Internet
> yet.
>
> 3) We still have a need for more security surrounding print-by-reference,
> but the work that has recently been started in the IETF TLS WG on
> delegation looks like it will provide a solution for that when finished
> (after the subject got dropped in the IETF AAA WG last year).
>
> There might be some further things in the detailed scenarios that I have
> overlooked...
>
> There are certainly also a number of other lessons learned from the
> combined IETF/PWG work on this project, which I think you are all familiar
> with, but I will leave that up to the meeting to discuss.
>
> Regards,
>
> Carl-Uno
>
> Carl-Uno Manros
> Manager, Print Services
> Xerox Architecture Center - Xerox Corporation
> 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
> Phone +1-310-333 8273, Fax +1-310-333 5514
> Email: manros@cp10.es.xerox.com
>
>
-----Original Message-----
From: don@lexmark.com [mailto:don@lexmark.com]
Sent: Thursday, February 15, 2001 14:03
To: ipp@pwg.org
Subject: IPP> Tampa IPP Agenda Item
I would like to have an item on the Tampa Agenda where we go through the
original Goals document and look at what was included there and assess if we
have achieved that goal with the IPP documents already complete or in one of
the
ones currently under development / review. I believe this could take a
couple
of hours and I would be willing to lead this discussion. I believe this
will
help us assess the completion status of the overall project and identify
work
that needs to be done if any.
**********************************************
* Don Wright don@lexmark.com *
* Chair, Printer Working Group *
* Chair, IEEE MSC *
* *
* Director, Strategic & Technical Alliances *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 859-232-4808 (phone) 859-232-6740 (fax) *
**********************************************
This archive was generated by hypermail 2b29 : Tue Mar 06 2001 - 20:26:23 EST