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: Hastings, Tom N (Tom.Hastings@xerox.com)
Date: Wed Mar 05 2008 - 15:59:34 EST

  • Next message: Ira McDonald: "Re: IPP> IPPv2 Statement Of Work Update [ISSUE: need to define what a "feature" is]"

    Ira,

    I agree that we should not revise any existing standard. However, I see
    no problem with a new standard profile that this IPPv2 project is
    developing saying that operation XYZ from standard mno is REQUIRED in
    order to conform to the profile that is being defined by the new
    standard, even if operation XYZ is OPTIONAL in standard mno.

    What's wrong with that?

    Tom

    -----Original Message-----
    From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org] On Behalf Of Ira
    McDonald
    Sent: Wednesday, March 05, 2008 11:15
    To: Hastings, Tom N; Ira McDonald
    Cc: Ron.Bergman@ricoh-usa.com; ipp@pwg.org
    Subject: Re: IPP> IPPv2 Statement Of Work Update [ISSUE: need to define
    what a "feature" is]

    Hi Tom,

    The PWG cannot change an IETF standard, EXCEPT through the formal
    IETF standards process (none of us are young enough to attempt this
    anymore).

    The fact that all the operations in IPP System Admin (RFC 3998) are
    OPTIONAL to implement (within that spec itself) is a *defect* that the
    IETF would have caught if anyone was watching, but the IETF published
    that spec years late just to close "old business".

    By contrast, the IPP Document Object (PWG 5100.5) has a good solid
    set of REQUIRED operations defined in section 13. Most PWG IPP specs
    are appropriately rigorous.

    Revising IETF or PWG IPP specs is out of the question - no manpower.

    In IETF and W3C parlance, a "feature" is a set of one or more Operations
    and any Attributes/Values required by those Operations.

    Going down to the level of the complete set of Attributes is not
    feasible.

    There's still a four-year-old action to register with IANA all of the
    IPP
    Operations and Attributes/Values in PWG IPP specs - none have ever
    been registered!

    For the admittedly deficient IETF IPP extension specs, I'd would support
    an effort to develop on a short list of Operations (per spec) that are
    REQUIRED by (one of) the IPP/2.x profiles.

    Cheers,
    - Ira

    PS - Agreeing on *which* IPP system admin operations should be
    REQUIRED is very likely to be a fruitless debate, but we can try.

    On Wed, Mar 5, 2008 at 1:18 PM, Hastings, Tom N <Tom.Hastings@xerox.com>
    wrote:
    > Ira,
    >
    > 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
    > OPTIONAL).
    >
    >
    > 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.
    >
    > Tom
    >
    > -----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
    > ONLY
    > 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
    > specs,
    > I'm opposed to doing so.
    >
    > The sole function of the IPP/2.x effort should be simply to encourage
    > more
    > widespread implementation of the many IPP extensions (a set of
    content
    > much larger than the entire original IPP/1.1 protocol). And to
    simplify
    > the
    > 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
    > PWG
    > 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.
    >
    > Cheers,
    > - Ira
    >
    > On Tue, Mar 4, 2008 at 7:44 PM, Hastings, Tom N
    <Tom.Hastings@xerox.com>
    > wrote:
    > > 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
    > or
    > > an option.
    > > * OBJ-3 All features are to be classified as Mandatory,
    > Conditionally
    > > Mandatory, or Optional.
    > >
    > > What is a "feature"? What is the level of granularity of a
    feature?
    > An
    > > 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
    > operation,
    > > an object, an attribute, or an attribute value?
    > >
    > > The PWG Semantic model lists all of the operations, objects,
    > attributes,
    > > and values (though spelled "funny"), along with the documents in
    > which
    > > 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.
    > >
    > >
    > >
    >
    ftp://ftp.pwg.org/pub/pwg/ipp/ippv2-docs/wd-ippv2-statement-of-work-2008
    > > 0221.pdf
    > > (.doc)
    > >
    > >
    > >
    > >
    >
    >
    >
    > --
    > Ira McDonald (Musician / Software Architect)
    > Chair - Linux Foundation Open Printing WG
    > Blue Roof Music/High North Inc
    > email: blueroofmusic@gmail.com
    > winter:
    > 579 Park Place Saline, MI 48176
    > 734-944-0094
    > summer:
    > PO Box 221 Grand Marais, MI 49839
    > 906-494-2434
    >

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


    This archive was generated by hypermail 2.1.4 : Wed Mar 05 2008 - 15:59:55 EST