IPP Mail Archive: RE: IPP> REQ - Input for IPP discussion in

IPP Mail Archive: RE: IPP> REQ - Input for IPP discussion in

RE: IPP> REQ - Input for IPP discussion in PWG [Does IPP meet its goals document?]

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Tue Mar 06 2001 - 21:10:47 EST

  • Next message: Internet-Drafts@ietf.org: "IPP> I-D ACTION:draft-ietf-ipp-notify-get-02.txt"

    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