IPP Mail Archive: RE: IPP> IPPv2 Statement Of Work Update [ISSUE: need to define what a "feature" is]

RE: IPP> IPPv2 Statement Of Work Update [ISSUE: need to define what a "feature" is]

From: Ron.Bergman@ricoh-usa.com
Date: Wed Mar 05 2008 - 14:41:32 EST

  • Next message: Hastings, Tom N: "RE: IPP> IPPv2 Statement Of Work Update [ISSUE: need to define what a "feature" is]"

    Hi Tom,

    You have a good point which we need to consider. Also, note that the
    Notifications (RFC3995), ippget (RFC3996), and the Document Object (5100.5)
    do have required operations. Only the Set Operations (RFC3380) and the
    Admin Operations (RFC3998) list just optional operations.

    I don't know if we will need to dig deeper than the operations if do decide
    to make some of the Set and Admin operations required. The attributes and
    values may not need to be addressed. This will certainly be investigated
    in the very near future.


                 "Hastings, Tom N"
                 OX.COM> To
                                           "Ira McDonald"
                 03/05/2008 10:18 <blueroofmusic@gmail.com>
                 AM cc
                                           RE: IPP> IPPv2 Statement Of Work
                                           Update [ISSUE: need to define what
                                           a "feature" is]


    The problem that I have with your view that the IPPv2 Profiles just
    lists IPP Standards is that most of the additional IPP standards define
    additional operations, attributes, and values which are all OPTIONAL to
    support. In other words, they are just shopping lists of operations or
    attributes (and attribute values).

    For example, here is the abstract from RFC 3998: Job and Printer
    Administrative Operations:

    This document specifies the following 16 additional OPTIONAL system
    administration operations for use with the Internet Printing
    Protocol/1.1 (IPP) [RFC2910, RFC2911], plus a few associated attributes,
    values, and status codes and using the IPP Printer object to manage
    printer fan-out and fan-in.

    As another example, here is the abstract from IEEE-ISTO PWG 5100.7-2003:
    Standard for The Internet Printing Protocol (IPP): Job Extensions

    Abstract: This IPP specification extends the Job semantics of the IPP
    Model and Semantics [rfc2911] object model. This specification defines
    some new Operation attributes for use in Job Creation and Document
    Creation operations. The Printer copies these Operation attributes to
    the corresponding Job Description attributes, which the clients may
    query. The Document Creation Operation attributes describe the Document
    Content and permit the Printer to reject requests that it cannot process
    correctly. Some corresponding "xxx-default" and "xxx-supported" Printer
    attributes are defined. This specification defines some Job Template
    attributes that apply to a multi-document Job as a whole and the
    "output-device" Job Template attribute that can apply to Documents and
    to Sheets as well as Jobs. This specification also defines some
    additional values for the "job-state-reasons" Job Description attribute.
    Each of the attributes defined in this specification are independent of
    each other and are OPTIONAL for a Printer to support.

    All of the attributes defined are OPTIONAL for a Printer to support!

    My recollection is that most of the extension IPP standards are like
    this. Thus I think it would really help if each profile listed the
    operations and attributes (any maybe attribute values) that are
    MANDATORY, CONDITIONALLY MANDATORY (with their condition), and

    Back to my comment on the Statement of Work:

    The ISSUE with the Statement of Work is to agree on what the undefined
    term: "feature". One interpretation (mine) is that each operation is a
    "feature" and each attribute is a "feature". Whether an attribute value
    is also a feature needs to be clarified. Without such an agreement on
    what the term "feature" is, I think that people will have widely
    differing understandings on what the IPPv2 project is about.

    BTW, I like the idea of the IPPv2 project NOT trying to re-write,
    clarify, or augment, the published standards. I'm just questioning the
    value of having a profile that points to set of IPP standards where each
    IPP standard just contains a list of operations or attributes that are
    all OPTIONAL.


    -----Original Message-----
    From: Ira McDonald [mailto:blueroofmusic@gmail.com]
    Sent: Tuesday, March 04, 2008 19:42
    To: Hastings, Tom N; Ira McDonald
    Cc: Ron.Bergman@ricoh-usa.com; ipp@pwg.org
    Subject: Re: IPP> IPPv2 Statement Of Work Update

    Hi Tom,

    My two cents - these profiles (i.e., version 2.0, 2.1, 2.2, etc.) should
    make whole IPP standards specs (IETF or PWG) mandatory, conditionally
    mandatory, or optional.

    Although there has been speculation that individual operations (but NOT
    attributes) might be raised in requirements level from their original
    I'm opposed to doing so.

    The sole function of the IPP/2.x effort should be simply to encourage
    widespread implementation of the many IPP extensions (a set of content
    much larger than the entire original IPP/1.1 protocol). And to simplify
    description of such higher implementation functionality for end users.

    Changing specific requirements levels *within* particular IPP specs is a
    slippery slope that would destroy the IPP/2.x effort (and violate the
    Process/2.0 rules).

    Bear in mind that the PWG Process/2.0 is much more rigorous than past
    PWG practice. Actual prototypes are REQUIRED before a document can
    even enter PWG Last Call, much less be adopted. It remains to be seen
    if this can be achieved for IPP/2.x.

    - Ira

    On Tue, Mar 4, 2008 at 7:44 PM, Hastings, Tom N <Tom.Hastings@xerox.com>
    > The statement of work says:
    > * OBJ-1 Include a reference to all IPP Standards Track documents,
    > starting from version 1.1.
    > * OBJ-2 All current IPP features are to be included as a requirement
    > an option.
    > * OBJ-3 All features are to be classified as Mandatory,
    > Mandatory, or Optional.
    > What is a "feature"? What is the level of granularity of a feature?
    > operation, an object, an attribute, or an attribute value?
    > In other words, at what level of detail will the "Mandatory",
    > "Conditionally Mandatory" or "Optional" be specified at: an
    > an object, an attribute, or an attribute value?
    > The PWG Semantic model lists all of the operations, objects,
    > and values (though spelled "funny"), along with the documents in
    > they are defined, if that is a help is compiling a profile template.
    > Tom
    > -----Original Message-----
    > From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org] On Behalf Of
    > Ron.Bergman@ricoh-usa.com
    > Sent: Thursday, February 21, 2008 09:56
    > To: ipp@pwg.org
    > Subject: IPP> IPPv2 Statement Of Work Update
    > The IPPv2 Charter has been converted into a Statement of Work.
    > Send any comments to the mail list.
    > 0221.pdf
    > (.doc)

    Ira McDonald (Musician / Software Architect)
    Chair - Linux Foundation Open Printing WG
    Blue Roof Music/High North Inc
    email: blueroofmusic@gmail.com
      579 Park Place  Saline, MI  48176
      PO Box 221  Grand Marais, MI 49839

    This archive was generated by hypermail 2.1.4 : Wed Mar 05 2008 - 14:41:51 EST