Semantic Model Mail Archive: RE: SM> ACT - IPP "-actual

Semantic Model Mail Archive: RE: SM> ACT - IPP "-actual

RE: SM> ACT - IPP "-actual" attributes downloaded, version 0.1 [m y comments]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Nov 06 2002 - 20:40:27 EST

  • Next message: Dennis Carney: "RE: SM> ACT - IPP "-actual" attributes downloaded, version 0.1 [m y comments]"

    Dennis,

    See my comments below (all supporting the -actual concept and just
    clarifying what the Printer MUST and SHOULD return for different
    situations).

    Tom

    -----Original Message-----
    From: Dennis Carney [mailto:dcarney@us.ibm.com]
    Sent: Thursday, October 31, 2002 16:04
    To: Hastings, Tom N; sm@pwg.org
    Subject: RE: SM> ACT - IPP "-actual" attributes downloaded, version 0.1
    [m y comments]

    Tom,

    Thanks for bringing these up. In response to your 4 points:

    1. I believe the "-actual" concept should be extended to Document Template
    attributes. This means that for every Document Template attribute, there
    is a corresponding "-actual" Document Description attribute that reports on
    the actual value of that attribute for that document. The question of
    which "-actual" attributes are Job Description attributes and which are
    Document Description attributes, then, is answered in the Document Object
    spec, in Table 6 (Draft 0.4). Of course, if we go with this proposal, I
    need to make the extension of the concept to the Document Template
    attributes clear in the "-actual" attributes document.

    TH> Sounds good to extend to the Document object spec. I'll include in the
    next update of the Document object spec, unless the SM face-to-face agrees
    otherwise.

    2. We came to a conclusion, I believe, on this in the teleconference today.
    We decided that any design for how to make the actual value of the
    "document-format" attribute available to the client would be discussed in
    the Document Object spec. There will be no "document-format-actual"
    attribute in the "-actual" attributes spec.

    TH> So to the Document object spec, I'll add a "document-format-actual"
    (documentFormat) as a Document Description attribute. Its clearly single
    valued. And an implementation populates it with the value that is actually
    detected by the Printer for that document. For the moment, we won't have a
    corresponding "document-format-actual" Job Description attribute which would
    raise the question of whether to make it multi-valued or not.

    I'll include in the next update of the Document object spec, unless the SM
    face-to-face agrees otherwise.

    3. I tried to cover this topic in section 3.2, which reads:
       3.2 Relationship between "-actual" attributes and Job Template
       attributes

       A very important point about the new "-actual" attributes is that
       support for them is not in any way tied to the support for the
       corresponding Job Template attributes. For example, a Printer that does
       not support PDL override will not support the "copies" Job Template
       attribute either. However, that same Printer SHOULD support the
       "copies-actual" attribute if the Printer knows how many copies printed
       for a job.
       Similarly, the "-actual" attribute's existence is not in any way tied to
       the existence of the Job Template attribute on the job creation request.
       Whether or not a number of copies was requested, the Printer SHOULD
       report on how many copies actually printed if the value is known.
    Does this satisfy you?

    TH> Not quite. The confusion is caused by including PDL override (which I
    assume you mean that the Printer supports "pdl-override" = 'attempted') in
    the discussion. Whether or not a Printer supports PDL override, and whether
    not a Printer supports the "copies" Job Template attribute, just as long as
    the Printer at least supports a copies instruction in the PDL, the Printer
    SHOULD support "copies-actual". Also there is confusion about the support
    of -actual attributes in general versus the support of a particular
    "xxx-actual" attribute. And lets be clear that we are talking about support
    by the Printer.

    How about replacing section 3.2 with:

    A very important point about the Printer support of a particular
    "xxx-actual" Job Description attribute is that such support is tied neither
    (1) to the support for the corresponding "xxx" Job Template attributes nor
    (2) whether the Printer attempts to override the PDL for that "xxx" Job
    Template attribute (see "pdl-overrides" in [RFC2911 section 4.4.28). For
    example, a Printer that does not support the "copies" Job Template
    attribute, but does support a copies instruction in the PDL, SHOULD support
    the "copies-actual" Job Description attribute in order to indicate the
    actual number of copies produced by the Printer. Similarly, a Printer that
    supports the "copies" Job Template attribute SHOULD support the
    "copies-actual" Job Description attribute whether or not the Printer
    attempts to override the copies instruction in the PDL data when the client
    supplies the "copies" Job Template attribute. Some Printers MAY support the
    "copies" Job Template attribute and a PDL copies instruction resulting in
    the product of the two values. Such an implementation SHOULD also support
    the "copies-actual" Job Description attribute.

    Or a much briefer equivalent would be:
    A Printer SHOULD support a particular "xxx-actual" Job Description attribute
    if the Printer supports either the "xxx" Job Template attribute and/or a
    corresponding instruction in the PDL. For Printers that support both,
    support of the corresponding "xxx-actual" Job Description attribute SHOULD
    be independent of whether or not the Printer attempts to override the PDL
    for that Job Template attribute (see "pdl-overrides" in [RFC2911 section
    4.4.28).

    In fact, this second alternative could replace section 4, Conformance
    Requirements (for printers) and simply delete section 3.2. Especially,
    because Section 4 is only saying OPTIONAL, rather than RECOMMENDED, which
    contradicts section 3.2.

    4. I believe Printers should fill in the values as soon as they have some
    strong confidence they know them. I do not believe that in general, the "
    -default" attributes necessarily have a strong shot at being right. I feel
    strongly that we should not make any rules except to say that the Printer
    should not return a value unless it thinks that value is correct--this is
    not a guarantee of correctness, but a guarantee that the Printer honestly
    *thinks* it is correct. I know that if we went with your proposal, if I
    wrote a monitoring app, I would be hesitant to use the value, since it
    would too often result in me giving bad information to the user.
    By the way, counting on 'pending' or 'pending-held' being the only states
    where information is not "final" is wrong. Once a job starts processing,
    it might take significant time before the Printer determines a final value.
    I don't believe that an "-actual" value can be considered final until the
    job enters a completion state (completed, canceled, or aborted), as I say
    in section 3.1.

    TH> I'm convinced that filling in with the "xxx-default" value would be
    sufficiently mis-leading to not be a good idea BEFORE the Printer has
    discovered that the PDL doesn't contain the corresponding instruction.
    However, after the Printer has discovered that the PDL doesn't have the
    instruction either, the Printer MUST populate the "xxx-actual" with its
    "xxx-default" value. So the specification needs to say what the Printer
    MUST return between the time the Printer receives a Job with an "xxx" Job
    Template attribute omitted and when the Printer discovers that the PDL
    either (1) has a value for the attribute or (2) does not have a value for
    the attribute, so that the Printer sets the "xxx-actual" value from its
    "xxx-default" value.

    Dennis

     

                          "Hastings, Tom N"

                          <hastings@cp10.es To: sm@pwg.org, Dennis
    Carney/Boulder/IBM@IBMUS
                          .xerox.com> cc: ipp@pwg.org

                                                   Subject: RE: SM> ACT - IPP
    "-actual" attributes downloaded, version 0.1 [m y comments]
                          10/31/02 10:59 AM

     

     

    Dennis,

    Good concept and good writeup.

    I have a few detailed issues/suggestions:

    1. Interaction with Document objects

    Another reason for more than one value at the job level might be that
    different documents have different values.

    On the other hand, for the Document object, won't we want to have -actual
    for the Document Description attributes too? If so, which -actual
    attributes would be Job Description attributes and which would be Document
    Description? media-actual would be a Document Description attribute and
    job-priority-actual would be a Job Description attribute.

    2. Even though "document-format" isn't a Job Template (or a Document
    Template) attribute, I think that for a file sniffing Printer, having a
    "document-format-actual" (which has to be multi-valued since a
    multi-document job could be sniffed to different values).

    And for the Document object it would be a Document Description attribute.

    3. A printer that doesn't support a Job Template attribute, say,
    resolution,
    but does in the PDL, could have a resolution-actual attribute, right? This
    case needs to be indicated.

    4. ISSUE: If a job is submitted with none or few Job Templates supplied,
    does the Printer fill in the remaining -actual with its default value?
    When? Can it supply the default values for these immediately, before it
    has
    processed the PDL? And then change the value if the PDL has a
    specification
    for that attribute? I suggest yes, and then clients know that -actual
    values when the job is 'pending' or 'pending-held' are subject to change.

    Tom



    This archive was generated by hypermail 2b29 : Wed Nov 06 2002 - 20:40:52 EST