Hi Tom,
Some comments below, preceded by 'ira>'.
Cheers,
- Ira McDonald
High North Inc
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Tuesday, March 06, 2001 5:25 PM
To: ipp (E-mail)
Subject: RE: IPP> REQ - Input for IPP discussion in PWG [Does IPP meet
its goals document?]
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.
ira> The above is an absurd requirement which cannot possibly be
satisfied. For a variety of reasons, finding physical geographic
proximity is impossible with current IETF standardized protocols
(although a HUMAN BEING could read a description attribute and
make some judgment of such geographic proximity).
--->
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.
ira> While I like (and support) the idea of an 'IPP Complete' document,
I think this is a dubious stretching of the charter of the IPP WG.
It could just as easily be written as an 'individual contribution'
(if anyone had the time and money to do so).
--->
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.
ira> Huh? The IPP charter is NOT for Device Mgmt and the IPP WG
has generally rejected efforts to define Device Mgmt via IPP.
--->
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.
ira> I agree that it would be nice to define an IPP Media object
(with specific management operations, for suitable authentication),
but I also think it's more appropriate as an 'individual contribution'.
--->
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.
ira> WAY out of reasonable scope. The IETF isn't going to allow
the IPP WG to start managing authorized users and permissions
using IPP operations. Delete this inappropriate requirement.
Much of the AAA stuff is still in the 'long term research' mode
in the sister IRTF (Internet Research Task Force). In half
a dozen IETF 'standards track' protocols there are mechanisms
for authenticating and managing authorized users, but the IPP
application layer protocol is the _wrong_ place.
--->
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.
ira> Again, explicitly part of the charter of the IRTF AAAarch WG.
Not suitable as IPP attributes. What is 'telephone number'?
Whose telephone number, for what?
--->
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.
ira> Yes, but a 'job-recipient-name' attribute has to have clear and
unambiguous semantics. Is that a user name in some network realm?
Does it have to be 'visible' in an LDAP accessible directory? (I
hope not, we can't tie IPP to the availability of LDAP.) I think
'job-recipient-name' is only really interesting in the context of
a comprehensive extension for 'distribution jobs', which is _not_
in the IPP WG charter.
--->
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 - 21:17:18 EST