SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec

SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec

Harry Lewis harryl at us.ibm.com
Fri Apr 18 13:16:11 EDT 2003


I'm afraid we are

1. Over complicating the Document Object 
  - This is really beginning to look like IPPv2
2. Risking lackluster adoption based on unnecessary mandatory operations

Look at the premise behind (2), below. "... users should be able to modify 
a document object after the job is submitted...". This might be something 
nice for some users but there are simpler alternatives (such as canceling 
the job and resubmitting it).... that don't require an architectural 
mandate. 

As for (4) guaranteeing pdl-override... I've always been opposed to the 
concept of pdl-override... it's premise being that we can't keep ourselves 
from generating Postscript with embedded production instructions and even 
if we could there is a mass of Postscript (still) being used for 
interchange. This was not true when me made the error of specifying 
pdl-override in IPP and it is less true today. Separating content from 
production instruction via the use of a job ticket has always been the 
goal. That goal is now within reach. I think, then, it is time to consider 
deprecating pdl-override...certainly not elevating the "feature" by 
mandating further complexity. 
---------------------------------------------- 
Harry Lewis 
IBM Printing Systems 
---------------------------------------------- 




"Hastings, Tom N" <hastings at cp10.es.xerox.com>
Sent by: owner-ipp at pwg.org
04/17/2003 03:00 PM
 
        To:     sm at pwg.org
        cc:     ps at pwg.org, ipp at pwg.org
        Subject:        IPP> 4 significant proposed increases in 
conformance requirements for    the IPP Document object spec


Attendees:  Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer,
Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?)

At today's PWG Semantic Model telecon we did a page by page review of the
IPP Document Object Spec in preparation for Last Call:

ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip

This mail note contains several significant changes in Printer conformance
requirements that we agreed to for the indicated reasons.  However, 
because
of their significance, we agreed to post these changes to the DL for a two
week comment period.  Objectsion and comments on these changes are due by
Friday, May 2, end of business.  Silence will be interpreted as approval, 
so
if you object, please send email.

The other less significant agreements will be posted in a separate mail 
note
as minutes.  We resolved all of the issues and did the page by page review
up to page 42 Table 7.  We will continue the page by page at another two
hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) 
with
the same version of the specification.  Same call-in number and HP webex.

Agreed to significant conformance requirements changes:


1. Change the Send-URI operation and the corresponding
"reference-uri-schemes-supported" (1setOf uriScheme) Printer Description
attribute from OPTIONAL to REQUIRED for a Printer to support.  We agreed
that a conforming implementation MAY have an empty list for the
"reference-uri-schemes-supported" Printer Description attribute.
 
Reason:  PSI requires this operation (and has no OPTIONAL attributes).
Optional operations are much less likely to get support by clients.  It is
best practice for an OPTIONAL extension specification (such as this spec) 
to
have no OPTIONAL operations, so that user clients will receive the same
level of service from all Printer implementations that support this
extension.


2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED
for a Printer to support.

Reason: This is the Document object spec and users should be able to 
modify
a Document object after the job is submitted.  Optional operations are 
much
less likely to get support by users clients.  It is best practice for an
OPTIONAL extension specification (such as this spec) to have no OPTIONAL
operations, so that user clients will receive the same level of service 
from
all Printer implementations that support this extension.


3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED 
for
a Printer to support.

Reason: To go along with the change in the conformance requirements for 
the
Set-Document-Attributes operation.  However, don't REQUIRE
Set-Job-Attributes, since most of the interesting attributes are document
attributes, not job attributes.


4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the
"pdl-overrides-supported" Printer Description attribute (REQUIRED in
[rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted'
values.  Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf
type2 keyword) Printer Description attribute.  The values indicate those 
Job
Template and Document Template attributes for which the Printer 
guarrantees
success in overriding the corresponding instruction in the PDL data.  The
values of this attribute returned in the Get-Printer-Attributes response 
MAY
be colored by the "document-format" operation attribute supplied by the
client in the request, if the Printer's guarrantee depends on the document
format.  A conforming Printer MAY return 'none' as the value. 

Reason:  The IPPFAX needs the ability for the Printer to indicate which 
Job
Template and Document Template attributes the Printer is able to guarantee
success in overriding the PDL.  Waiting for the Production Printing Set2
[ippsave] to be updated does meet the schedule for IPPFAX which is also
trying to go out to last call.  Also this extension is analoguous to our
addition of "job-mandatory-attributes" to give a finer granularity to
"ipp-attribute-fidelity" (boolean) operation attribute. 


Please send comments by Friday, May 2, 2003.

Thanks,
Tom


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/sm/attachments/20030418/fc1bc6f2/attachment-0001.html


More information about the Sm mailing list