Subject: RE: IPP> IPPv2 Statement Of Work Update

From: "Hastings, Tom N" <[email-masked]>
Date: Tue, 4 Mar 2008 16:44:57 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, February 21, 2008 09:56
To: [email-masked]
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)

---

From: "Ira McDonald" <[email-masked]>
Date: Tue, 4 Mar 2008 22:42:24 -0500

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

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

---

From: "Hastings, Tom N" <[email-masked]>
Date: Wed, 5 Mar 2008 10:18:02 -0800

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:[email-masked]] 
Sent: Tuesday, March 04, 2008 19:42
To: Hastings, Tom N; Ira McDonald
Cc: [email-masked]; [email-masked]
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).

Cheers,
- Ira

---

From: [email-masked]
Date: Wed, 5 Mar 2008 11:41:32 -0800

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.

Ron

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

                                                                           

Ira,

Tom

-----Original Message-----
From: Ira McDonald [mailto:[email-masked]]
Sent: Tuesday, March 04, 2008 19:42
To: Hastings, Tom N; Ira McDonald
Cc: [email-masked]; [email-masked]
Subject: Re: IPP> IPPv2 Statement Of Work Update

Hi Tom,

Cheers,
- Ira

---

From: "Ira McDonald" <[email-masked]>
Date: Wed, 5 Mar 2008 14:15:10 -0500

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.

---

From: "Hastings, Tom N" <[email-masked]>
Date: Wed, 5 Mar 2008 12:59:34 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of Ira
McDonald
Sent: Wednesday, March 05, 2008 11:15
To: Hastings, Tom N; Ira McDonald
Cc: [email-masked]; [email-masked]
Subject: Re: IPP> IPPv2 Statement Of Work Update [ISSUE: need to define
what a "feature" is]

Hi Tom,

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!

Cheers,
- Ira

On Wed, Mar 5, 2008 at 1:18 PM, Hastings, Tom N <[email-masked]>
wrote:
>  >  *  OBJ-2 All current IPP features are to be included as a
requirement
>  or
>  >  What is a "feature"?  What is the level of granularity of a
feature?
>  An

---

From: "Ira McDonald" <[email-masked]>
Date: Wed, 5 Mar 2008 19:42:13 -0500

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