Hi Tom,
I agree with you that we can raise OPTIONAL operations (from source
standards) to REQUIRED in an IPP/2.x profile.
I hoped to avoid this, but it seems necessary - or system admin, in
particular, is meaningless.
Now to see if many IPP implementations all chose the same operations
(ah, I see a pig flying...).
Cheers,
- Ira
On Wed, Mar 5, 2008 at 3:59 PM, Hastings, Tom N <Tom.Hastings at xerox.com> wrote:
> 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 at pwg.org [mailto:owner-ipp at pwg.org] On Behalf Of Ira
> McDonald
> Sent: Wednesday, March 05, 2008 11:15
> To: Hastings, Tom N; Ira McDonald
> Cc: Ron.Bergman at ricoh-usa.com; ipp at 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 at 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 at gmail.com]
> > Sent: Tuesday, March 04, 2008 19:42
> > To: Hastings, Tom N; Ira McDonald
> > Cc: Ron.Bergman at ricoh-usa.com; ipp at 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 at 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 at pwg.org [mailto:owner-ipp at pwg.org] On Behalf Of
> > > Ron.Bergman at ricoh-usa.com> > > Sent: Thursday, February 21, 2008 09:56
> > > To: ipp at 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 at 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 at 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 at gmail.com
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 49839
906-494-2434