IPP Mail Archive: IPP> RE: IFX> Updated JOBX spec for Wed

IPP Mail Archive: IPP> RE: IFX> Updated JOBX spec for Wed

IPP> RE: IFX> Updated JOBX spec for Wed, June 4, 1-3 PM PDT (4-6 PM ED T) teleco n (10 ISSUES)

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Tue Jun 03 2003 - 10:47:32 EDT

  • Next message: Hastings, Tom N: "IPP> RE: IFX> Updated JOBX spec for Wed, June 4, 1-3 PM PDT (4-6 PM ED T) teleco n (10 ISSUES)"

    Hi Tom

    But we're NOT requiring that the IPPFAX Sender send content that
    doesn't require scaling. Read the IPPFAX spec. We permit SMALL
    scale to fit (without any truncation) between iso-a4 and na-latter.

    Your argument is based on a false premise. IPPFAX DOES require
    scaling for the letter media sizes.

    Cheers,
    - Ira

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Monday, June 02, 2003 1:42 PM
    To: McDonald, Ira; Hastings, Tom N; ipp@pwg.org
    Subject: RE: IFX> Updated JOBX spec for Wed, June 4, 1-3 PM PDT (4-6 PM
    ED T) teleco n (10 ISSUES)

    Ira,

    I agree with most of your comments. However, I have push back on the
    following 2 comments C and D:

      C) Comment on ISSUE 07:

      The Printer MUST scale to support our (nearly equal) choice media size.
      The Printer MUST NOT truncate (for IPPFAX). Your issue is invalid.

    REQUIRING an IPPFAX Receiver (or any IPP Printer) that supports one of the
    new choice "media" keywords to scale, seems to be a high burden on the
    Printer and for little gain.

    If the choice keywords are restricted to be for sizes that are close
    together, such as na_letter and iso_a4 (or iso_b4 and jis_b4) and we follow
    the existing FAX practice of the Sender formatting document content so that
    it fits on either size, then the Printer doesn't have to scale.

    Only if the Printer chooses to scale MUST the Printer do so with isomorphic
    scaling to preserve the aspect ratio.

    This is an important ISSUE for the IPPFAX WG to discuss for use with PDF/is
    (where scaling may not be a burden).

    But for general use with any PDL, requiring scaling seems to be a high
    burden.

    I think that we also went wild in the telecon with the suggestion that a
    choice keyword value could have quite disparate sizes, such as A4 and B4,
    where scaling would be necessary in order to be useful. I think allowing
    such disparate sizes would be a serious mistake and undermine the
    interoperability for the really important use cases of very similar sizes.

      D) Comment on ISSUE 09:

      No - in IETF and W3C terms we are NOT "revising" or "updating" 5100.4.
      We are "obsoleting" 5100.4 (much stronger than "deprecating"). The
      previous text of 5100.4 will be abandoned. An implementation CANNOT
      claim conformance to a non-standards-track former document. The
      future Candidate Standard 5100.4 will define DIFFERENT attributes with
      fundamentally DIFFERENT semantics. That is NOT "revision" in the
      terms of any of your cited standards bodies.

      That is exactly why the soon-to-be-published RFC of Printer MIB v2
      will state that it "obsoletes" the Printer MIB v1 (RFC 1759), because
      there are actual semantic differences (corrections) between some of
      the common attributes in the two MIBs.

    Our goals are the same, its just the terminology. Also you are missing my
    point that the IETF never *revise* an RFC, they just publish a new RFC with
    a new number, and then say whether that new RFC updates or obsoletes the
    older RFC.

    But other standards bodies, like ANSI, ISO, IEEE, etc, actually revise their
    existing standards keeping the *same* number. When the revision is
    approved they just change the year that is part of the designation.

    That is why I think that the PWG is revising IEEE-ISTO Trial Use
    5100.4:2001. We'll have an appendix that indicates that we've removed
    "document-overrides" and replaced "page-overrides" with "overrides". Also
    we can say in that Appendix that "pages-per-subset" has been moved to
    [ippjobx].

    Tom

    -----Original Message-----
    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Monday, June 02, 2003 09:06
    To: 'Hastings, Tom N'; ipp@pwg.org
    Subject: RE: IFX> Updated JOBX spec for Wed, June 4, 1-3 PM PDT (4-6 PM
    ED T) teleco n (10 ISSUES)

    Hi Tom,

    I made this comment before, but I see it got lost in the latest version.

    A) Comment on ISSUE 02 and ISSUE 03:

    The correct name of "output-device-requested-supported" should be
    "output-device-supported". Both "-requested" and "-assigned" are
    suffixes (just like "charset-configured"). We have "charset-supported",
    not "charset-configured-supported".

    Please remember that "output-device-supported" has always been needed
    for the existing "output-device-assigned" Job attribute. It is the
    list of "friendly" device names (not URLs, unfortunately) that the
    IPP Printer object supports.

    The future IPP Device object (output of the WBMM project and Semantic
    Model extensions) should have a KEY Device Description attribute called
    "device-name" (to disambiguate the locality of reference), which MUST
    be one of values of the "output-device-supported" attribute.

    B) Comment on ISSUE 05:

    The datatype of "pages-per-subset-supported" MUST NOT be changed from
    a previous version (PWG Trial Use 5100.4) unless the NAMES of these
    attributes (BOTH "pages-per-subset" and "pages-per-subset-supported")
    are also changed.

    If the datatype OR the semantics change, then the old attribute MUST
    be abandoned and replaced with a new attribute with a new name.

    C) Comment on ISSUE 07:

    The Printer MUST scale to support our (nearly equal) choice media size.
    The Printer MUST NOT truncate (for IPPFAX). Your issue is invalid.

    D) Comment on ISSUE 09:

    No - in IETF and W3C terms we are NOT "revising" or "updating" 5100.4.
    We are "obsoleting" 5100.4 (much stronger than "deprecating"). The
    previous text of 5100.4 will be abandoned. An implementation CANNOT
    claim conformance to a non-standards-track former document. The
    future Candidate Standard 5100.4 will define DIFFERENT attributes with
    fundamentally DIFFERENT semantics. That is NOT "revision" in the
    terms of any of your cited standards bodies.

    That is exactly why the soon-to-be-published RFC of Printer MIB v2
    will state that it "obsoletes" the Printer MIB v1 (RFC 1759), because
    there are actual semantic differences (corrections) between some of
    the common attributes in the two MIBs.

    Cheers,
    - Ira

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Monday, June 02, 2003 2:28 AM
    To: ipp@pwg.org
    Cc: ifx@pwg.org
    Subject: IFX> Updated JOBX spec for Wed, June 4, 1-3 PM PDT (4-6 PM EDT)
    teleco n (10 ISSUES)

    I've uploaded the updated version of the Job Extension spec for review
    Wednesday, 1-3 PM PDT (4-6 PM EDT):

    ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030530.pdf.zip
    (572KB)
    ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030530.doc.zip
    (125KB)
    ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030530-rev.pdf
    (262KB)
    ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030530-rev.doc.zip
    (142KB)

    Please send any comments to the ipp@pwg.org DL only!

    > Rick Seeler has invited you to a MeetingPlace voice conference.
    >
    > Date/Time: June 04, 2003, 01:00 PM America/Los_Angeles
    > Meeting ID: 123123
    > Password:
    > Frequency: Once
    >
    > MeetingPlace Phone Numbers:
    > Local: 408-536-9900

    Here is the webex info -

    Name: IFX
    Date: 6/4/2003
    Time: 1:00PM, (GMT -07:00) Pacific Time, USA & Canada (DayLight Time)
    Meeting Number: 29378444 Meeting Password: pwgifx

    Here are the changes from the last version we reviewed at the May 28
    telecon:

    Version 0.3, 30 May 2003:
    Agreements reaches at the May 28, 2003 telecon:
            1. Moved the Close-Job operation to the futures specification.
            2. Added the "pages-per-subset" Job Template from [pwg5100.4].
    See Appendix B section 17 for the minor differences.
            3. Added the terms: "Best Effort, Finished Document, Page, Page
    Subset, and Sheet.
            4. Clarified the conformance relationships between "xxx"
    Operation attributes and their corresponding "xxx-default" and
    "xxx-supported" Printer attributes.
            5. Added rationale for each missing "xxx-default" and
    "xxx-supported" attribute.
            6. Added 'errors-detected' and 'warnings-detected'
    "job-state-reasons" values.
            7. Added the new 'choice_iso_a4_210x297mm_na_letter_8.5x11in'
    "media" attribute value which is a choice of two approximately equal media.
            8. Added the requirements for choice media keyword values for
    inclusion in a revision of the PWG IEEE-ISTO 5101.1.
            9. Changed the "document-format-implemented" member attribute
    from 1setOf mimeMediaType to mimeMediaType since it is the key attribute
    value.
            10. Added another "document-format-implemented" example.
            11. Updated the IANA section to agree with the additions.

    The following 10 issues are highlighted in the document:

    ISSUE 01: OK that the "job-mandatory-attributes" Operation attribute has
    nothing to do with guaranteeing (that the attribute will supersede the PDL),
    but only with whether the Printer will accept the job with unsupported
    attributes requested - TNH

    ISSUE 02: From DMC: It seems like it might be possible, for certain
    implementations, to have a default output-device. The problem is that
    normally the "xxx-default" is REQUIRED [TH: not for operation attributes, so
    we say a Printer MAY support the "output-device-default"], whereas my idea
    would be more to allow a Printer to advertise a default only if it matched
    its actual implementation.

    3.1.3.1 Why there is no "output-device-requested-default" attribute
    ISSUE 02 (repeat): From DMC: Should we add an
    "output-device-requested-default" Printer Description attribute that a
    Printer MAY support when it supports the "output-device-requested" Operation
    attribute?

    ISSUE 03: (Thought up while writing up the reason for no default):
    [rfc2911] does have the concept of attribute coloring that causes the values
    of Printer attributes to depend on the "document-format". Thus, we could
    have "document-format-version-default" whose value depends on the value of
    the "document-format". Do we want to have
    "document-format-version-default", which, if supported, the Printer MUST
    color the value depending on the "document-format" Operation attribute
    supplied in the Get-Printer-Attributes request?

    All part of ISSUE 04:
    If the client supplies more integer values for the "pages-per-subset"
    attribute than the Printer supports, the Printer MUST treat the remaining
    values as Unsupported Attribute values as follows (see [rfc2911] section
    3.1.7):
                    If the client supplies the "attribute-fidelity" Operation
    attribute with a 'false' value (see section 3.1.1) or omits the attribute
    altogether, the Printer MUST (1) otherwise accept the Job, (2) return the
    'successful-ok-attributes-ignored-or-substituted' status code, and (3)
    return in the Unsupported Attribute Group the additional values not
    supported.
                    If the client supplies either the "attribute-fidelity"
    Operation attribute with a 'true' value or the "job-mandatory-attributes"
    Operation attribute with the 'pages-per-subset' keyword value (see section
    3.1.2), the Printer MUST reject the job.
    ISSUE 04: PWG 5100.4 was silent on whether a Printer MUST support any
    number of integer values for "pages-per-subset" or whether the number was
    implementation dependent. Is supporting only a single value considered a
    conforming implementation so that the above error handling is sufficient?

    ISSUE 05: PWG 5100.4 had the "pages-per-subset-supported" attribute
    specified as a boolean. MUST a Printer support any number of integer values
    for the "pages-per-subset" (1setOf integer(1:MAX)) Job Template attribute?
    If supporting a maximum number, even as low as '1', is considered
    conforming, should we change the attribute syntax of the
    "pages-per-subset-supported" to integer(1:MAX) to indicate the maximum
    number of values supported by the Printer? Or is it sufficient for the
    Printer to return in the Unsupported Attributes group the remaining values
    of the "pages-per-subset" (integer(1:MAX)) attribute that aren't supported?

    ISSUE 06: What about the maximum number of pages in a Page Subset? MUST a
    Printer support any number up to MAX in any Page Subset?

    Part of ISSUE 07:
      The Printer MAY scale the image to fit, but any scaling MUST be isomorphic
    scaling and without image content loss.
    ISSUE 07: Why even allow the Printer to scale? Lets simplify this choice
    concept to sizes that are approximately the same, such as A4 and na-letter,
    rather than allowing a choice, of, say, A4 or A3 which would require
    scaling. That makes interoperability more difficult.

    ISSUE 08: Who needs the "document-format-details-implemented" attribute?
    Does PSI? We assume yes. However, if PSI does support Capabilities, then
    we shouldn't define "document-format-details-implemented" in this spec,
    since "document-format-details-implemented" is a poor man's capability
    mechanism. ACTION ITEM (Tom): Ask PSI whether they intend to use
    "document-format-details-implemented"? If not, should
    "document-format-details-implemented" be moved to the IPP Futures document,
    or just deleted and wait for someone to request it?

    Document Color Separation (DCS), version 2.0. ISSUE 10: Need a reference

    All part of ISSUE 09:
    [pwg5100.4]
            Herriot, R., Ocke, K., "Internet Printing Protocol (IPP): Override
    Attributes for Documents and Pages", IEEE-ISTO 5100.4-2001, February 7,
    2001, ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.4.pdf. - being obsoleted
    by (1) a new Page Overrides specification which removes the
    "document-overrides" Job Template attribute and Operation attribute in favor
    of using the Document Object [ippdoc] and (2) this specification [ippjobx]
    definition of "pages-per-subset" Job Template attribute.

    ISSUE 09: The IETF process never revises an RFC, but just updates or
    obsoletes one with another RFC. On the other hand most other standards
    organizations, such as ANSI, ISO, (IEEE?), and POSIX, require that standards
    be reviewed and if necessary be "revised". I think that we are "revising"
    PWG IEEE-ISTO 5100.4, not "obsoleting" it. This is just a terminology
    question.
            The second paragraph of the PWG process section 4.2 says:
                            "Working Drafts and Candidate Standards correspond
    to a specific version of the Standard they are defining. Unless the working
    group is engaged in an effort to revise an existing PWG Standard, the
    Working Drafts and Candidate Standards are always defining PWG Standard
    Version 1.0."
            and section 4.4.1 says:
                            "Although the maturity level will not appear on PWG
    Candidate Standards or PWG Standards, if a Candidate Standard needs to be
    revised, any resulting PWG Working Drafts will have a maturity level
    indicated on their title page."



    This archive was generated by hypermail 2b29 : Tue Jun 03 2003 - 10:52:02 EDT