Semantic Model Mail Archive: RE: SM> Dead-on-arrival proposa

RE: SM> Dead-on-arrival proposal from "IPP Document Object Spec a vailable for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)"

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Thu Apr 10 2003 - 11:59:48 EDT

  • Next message: don@lexmark.com: "RE: SM> Dead-on-arrival proposal from "IPP Document Object Spec a vailable for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)""

    Don,
     
    I think that you hit on the criteria that the file is intended for human
    use, not automatic machine use. So how about the idea that a human
    installer and/or administrator can go and fetch the flat file at any time.
    If the site isn't available, the human will have to try again later.
     
    Also I think that the scemas are only for human consumption. The URL is
    used as an ID to indicate version.
     
    Tom

    -----Original Message-----
    From: Harry Lewis [mailto:harryl@us.ibm.com]
    Sent: Wednesday, April 09, 2003 15:46
    To: don@lexmark.com
    Cc: ps@pwg.org; sm@pwg.org
    Subject: Re: SM> Dead-on-arrival proposal from "IPP Document Object Spec
    available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)"

    We touched on this earlier in the year in the context of SM schemas. We
    backed off when we backed off the design point where devices would hit the
    server real-time. If we're drifting back in that direction, we'll have to
    develop our requirements in terms of bandwidth, QOS, and look for
    commercial solutions and determine how to fund this via ISTO PWG. I do think
    it should be feasible to find a commercial solution that meets our needs at
    an affordable price.

    I agree with Don that we can't expect a volunteer member to bear this
    responsibility!
    ----------------------------------------------
    Harry Lewis
    IBM Printing Systems
    ----------------------------------------------

            don@lexmark.com
    Sent by: owner-sm@pwg.org

    04/09/2003 02:07 PM

            
            To: sm@pwg.org, ps@pwg.org
            cc:
            Subject: SM> Dead-on-arrival proposal from "IPP Document
    Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2
    EDT)"

    In regards to issue 4 and some background preceding it:

    ----------------
    The values of the "document-format" and their corresponding
    "document-format-version" values will be kept in a flat text file on the
    PWG
    server for use by the PWG and CIP4. Implementers and implementations will
    be able to access this file at any time (at CD writing time, install time,
    vendor update time, and/or at power-up time, etc.). New values will be
    added to the flat file by its Maintainer after sending to the PWG list for
    a
    two week review whenever they are registered with or standardized by some
    recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4
    buy-in to use the same flat file (which will require an additional field
    for
    the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format
    for
    the file. The URL is:
     ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should
    the URL be for the flat file? What is the formatting conventions for the
    flat file. Is it a PWG Schema of sorts?
    ----------------

    I CANNOT SUPPORT USING THE PWG SERVER BY ANYTHING OTHER THAN HUMAN
    BEINGS!!!!!

    Any proposal that endorses or proposes access by machines "at install time"
    or "at power-up time" is simply not workable unless some other company
    wants to support what will become multiple machines with giant bandwidth
    pipes to the internet to support millions of printers and other devices.

    I suggest you find another solution.

    *******************************************
    Don Wright don@lexmark.com

    Chair, IEEE SA Standards Board
    Member, IEEE-ISTO Board of Directors
    f.wright@ieee.org / f.wright@computer.org

    Director, Alliances and Standards
    Lexmark International
    740 New Circle Rd C14/082-3
    Lexington, Ky 40550
    859-825-4808 (phone) 603-963-8352 (fax)
    *******************************************

    ---------------------- Forwarded by Don Wright/Lex/Lexmark on 04/09/2003
    04:01 PM ---------------------------

    "Hastings, Tom N" <hastings@cp10.es.xerox.com>@pwg.org on 04/09/2003
    07:54:04 AM

    Sent by: owner-ps@pwg.org

    To: sm@pwg.org
    cc: ps@pwg.org
    Subject: PS> IPP Document Object Spec available for Thursday, April 10,
          SM Tel econ, 10-11 PDT (1-2 EDT)

    I've finished the editing on the IPP Document Object Spec and have down
    loaded it to:

    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353
    KB
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB

    This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2
    EDT).

    Sorry for the short notice, but the editing took way more time than I
    thought.

    Version 0.9, 7 April 2003, agreements from the April 3 telecon:
    1. Added "document-charset" (charset),
    "document-digital-signature" (type2 keyword), "document-format-version"
    (text(127)), and "document-natural-language" (naturalLanguage) Operation
    and
    Document Description attributes and corresponding "xxx-default" and
    "xxx-supported" Printer Description attributes.
    2. Changed the "document-natural-language" member attribute of
    "document-format-details" (1setOf collection) operation attribute to be
    1setOf, but kept the top level "document-natural-language" Operation
    attribute as single-valued.
    3. Added Summary Table 2 of new Operation/Document Description
    attributes.
    4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms.
    5. Deleted the "document-id-uri" Operation attribute no longer
    needed by PSI.
    6. Changed "ipp-attribute-fidelity" so it doesn't affect
    operation attributes, so it is the same as in [RFC2911].
    7. Clarified the operation attributes supplied at the Job Level
    in Print-Job and Print-URI versus Create-Job by introducing the "p"
    notation
    in Table 7.
    8. Added columns to Table 7 to show the corresponding Document
    Description attributes and the "xxx-default" and "xxx-supported" Printer
    Description attributes.
    9. Clarified that all of the new Operation attributes are
    hints, except "document-charset" and "document-format" and that the client
    can turn them into Must Honor by supplying their keyword attribute names in
    the "job-mandatory-attributes Operation attribute.
    10. Add the unique lang prefix from the Printer MIB to all
    "document-format-version" values, so that they can all be in a single flat
    list for the Printer's "document-format-version-supported" Printer
    Description attribute.

    There are four issues embedded in the document and a 5th from Dennis (see
    below):

    6.1.1 document-charset (charset)
    ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it
    CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document
    formats?

    If the Printer supports this "document-digital-signature" Operation
    attribute and the value supplied by the client, the Printer MUST verify the
    signature according to the rule for that signature format. If the
    signature
    does not verify, then the Printer MUST either (1) ignore the signature or
    (2) put the job on hold and wait for human intervention, depending on
    implementation. The Printer gives no additional indication to the client.
    ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold
    the
    correct behavior for the Printer if the digital signature doesn't verify?

    This Printer behavior is backwards compatible with a Printer that doesn't
    support the "digital-signature" attribute. However, if the Printer
    supports
    the "job-mandatory-attributes" attribute (see section 8.1.2) and the client
    supplies the "job-mandatory-attribute" Operation attribute with the
    'digital-signature' keyword value, then the Printer MUST reject the job if
    the "digital-signature" attribute is supplied with a value that isn't
    supported by the Printer (or the Printer doesn't support the
    "digital-signature" attribute at all). Thus the client can force the
    Printer to reject a signed document for a signature technology that the
    Printer does not support. ISSUE 03: What if the digital signature is
    supported, but the signature fails verification by the Printer when
    "job-mandatory-attributes" identifies 'document-digital-signature'?

    The values of the "document-format" and their corresponding
    "document-format-version" values will be kept in a flat text file on the
    PWG
    server for use by the PWG and CIP4. Implementers and implementations will
    be able to access this file at any time (at CD writing time, install time,
    vendor update time, and/or at power-up time, etc.). New values will be
    added to the flat file by its Maintainer after sending to the PWG list for
    a
    two week review whenever they are registered with or standardized by some
    recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4
    buy-in to use the same flat file (which will require an additional field
    for
    the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format
    for
    the file. The URL is:
     ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should
    the URL be for the flat file? What is the formatting conventions for the
    flat file. Is it a PWG Schema of sorts?

    and here is ISSUE 05 from Dennis Carney:

    - I brought this up on the call, but I'll mention it again, since I'm not
    sure whether it was resolved. You sell a printer. You happen to have
    found out that some specific thing goes wrong when a user uses Powerpoint
    2000 on Windows NT 4.0, such that your printer always messes up the
    printout. How do you specify this in document-format-details-implemented?
    And a much simpler issue on these same lines: why would *anyone*, ever,
    return any values for the document-creator-application-name-implemented or
    document-creator-application-version-implemented member attributes--why
    would anyone want to try to list all applications they support? Similarly
    for the two "os" member attributes--I might know I don't provide special
    drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a
    PDF file, *can* print to me from Macintosh. Even if there *were* some OSes
    I wanted to say I don't support (which seems doubtful), I have to do this
    by listing all *other* OSes? I guess in summary: I can see the use for the
    5th-8th member attributes of document-format-details-implemented, but not
    for the 1st-4th.

    Tom



    This archive was generated by hypermail 2b29 : Thu Apr 10 2003 - 12:00:11 EDT