Semantic Model Mail Archive: RE: SM> Re: IPP> 4 significa

Semantic Model Mail Archive: RE: SM> Re: IPP> 4 significa

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

From: Harry Lewis (harryl@us.ibm.com)
Date: Sat Apr 19 2003 - 12:03:05 EDT

  • Next message: McDonald, Ira: "RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec"

    1. Help me out as to where PSI states this it is mandatory to support
    modification of a Document object after the job is submitted.
    2. I support healthy alignment with FSG and I've been pushing for a job
    ticket interface to PSI. It's just... every time I ask for a show of hands
    regarding actual support for PDL-override the response is always
    lackluster.
    ----------------------------------------------
    Harry Lewis
    IBM Printing Systems
    ----------------------------------------------

    "McDonald, Ira" <imcdonald@sharplabs.com>
    Sent by: owner-sm@pwg.org
    04/18/2003 12:38 PM
     
            To: Harry Lewis/Boulder/IBM@IBMUS, "Hastings, Tom N"
    <hastings@cp10.es.xerox.com>
            cc: ipp@pwg.org, ps@pwg.org, sm@pwg.org
            Subject: RE: SM> Re: IPP> 4 significant proposed increases
    in conformance requirements for the IPP Document object spec

    Hi Harry,

    (1) PSI has ALREADY made all of the equivalent WSDL methods REQUIRED.
    I'm merely suggesting equivalent functionality for the IPP Document
    object implementors. And yes it _is_ like IPPv2 - the Document
    object is the main thing missing from IPP/1.1. But this is just
    and extension. We're not mandating that all IPP/1.1 implementations
    support the Document object and operations.

    (2) The FSG expects to (using PAPI/1.0 API) convert any job ticket
    instructions to IPP job stream instructions. The job ticket support
    of PDL override is useless in the Free Standards Linux environment
    without the correspond IPP attributes.

    Cheers,
    - Ira

    -----Original Message-----
    From: Harry Lewis [mailto:harryl@us.ibm.com]
    Sent: Friday, April 18, 2003 12:16 PM
    To: Hastings, Tom N
    Cc: ipp@pwg.org; ps@pwg.org; sm@pwg.org
    Subject: SM> Re: IPP> 4 significant proposed increases in conformance
    requirements for the IPP Document object spec

    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@cp10.es.xerox.com>
    Sent by: owner-ipp@pwg.org
    04/17/2003 03:00 PM
            To: sm@pwg.org
            cc: ps@pwg.org, ipp@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



    This archive was generated by hypermail 2b29 : Sat Apr 19 2003 - 12:03:42 EDT