IPP Mail Archive: RE: IPP> Misplaced attributes [suggested c

IPP Mail Archive: RE: IPP> Misplaced attributes [suggested c

RE: IPP> Misplaced attributes [suggested clarifications to the II G]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Mar 14 2001 - 17:01:55 EST

  • Next message: Manros, Carl-Uno B: "IPP> ADM - Are we ready to start thinking about wrapping up the IPP WG in the foreseeable future?"

    I agree with Carl and Ira, that "C" is the proper action for a Printer that
    receives an Operation attribute that was sent in error in the Job Attributes
    group (Group 2) where Job Template attributes are supposed to be. The
    example was where the client sent an "ipp-attribute-fidelity" attribute with
    a 'true' value as a Job Template attribute, instead of as an Operation
    attribute in the Operation Attributes group. The client MUST treat the
    "ipp-attribute-fidelity" as an unsupported Job Template attribute, returning
    it in the Unsupported Attributes group, and since there was no
    "ipp-attribute-fidelity" attribute submitted as an operation attribute in
    the Operation Attributes group, assume the default of 'false', accept the
    job, and return the status code of
    'successful-ok-ignored-or-substituted-attributes' (0x0001) status code.

    However, we might want to clarify the IIG a little. The following section
    could be mis-interpreted that the Printer is supposed to detect when a
    client mis-places an Operation attribute and sends it in as a Job Template
    attribute in the Job Attribute group. In other words, is an attribute an
    Operation attribute because it is defined to be an Operation attribute or
    because the client supplied the attribute in the Operation Attributes group
    in a request? I think we are agreeing to the latter interpretation.
    However, the following section is pretty clear that the intent of the
    section was to be talking about the Printer processing the attributes in the
    Operation attribute group in a request (but some clarifications could be
    added as I have indicated below):

    3.1.2.1.4.3 Validate the presence of a single occurrence of required
    Operation attributes

    Client requests and IPP object responses contain Operation attributes that
    [RFC2911] Section 3 requires to be present. Attributes within a group may
    be in any order, except for the ordering of target, charset, and natural
    languages attributes. These attributes MUST be first, and MUST be supplied
    in the following order: charset, natural language, and then target. An IPP
    object verifies that the attributes that Section 4 requires to be supplied
    by the client have been supplied in the request (attributes without an * in
    the following tables). An asterisk (*) indicates groups and Operation
    attributes that the client may omit in a request or an IPP object may omit
    in a response.
     
    If an IPP object receives a request with required attributes missing or
    repeated from a group or in the wrong position, the behavior of the IPP
    object is IMPLEMENTATION DEPENDENT. Some of the possible implementations
    are:

     - REJECTS the request and RETURNS the 'client-error-bad-request' status
    code

     - accepts the request and uses the first occurrence of the attribute no
    matter where it is

     - accepts the request and uses the last occurrence of the attribute no
    matter where it is

     - accept the request and assume some default value for the missing
    attribute

    Therefore, client MUST send conforming requests, if they want to receive the
    same behavior from all IPP object implementations. For example, it is an
    error for the "attributes-charset" or "attributes-natural-language"
    attribute to be omitted in any operation request, or for an Operation
    attribute to be supplied in a Job Template group or a Job Template attribute
    to be supplied in an Operation Attribute group in a create request. It is
    also an error to supply the "attributes-charset" attribute twice.

    Since these kinds of attribute errors are most likely to be detected by a
    client developer rather than by a customer, the IPP object NEED NOT return
    an indication of which attribute was in error in either the Unsupported
    Attributes group or the Status Message. Also, the IPP object NEED NOT find
    all attribute errors before returning this error.

    TH> So clarify the beginning of the second sentence in the first paragraph
    above to be:

    Attributes within the Operation Attributes group (Group 1) in a request ...

    TH> and the first sentence of the second paragraph above to be:

    If an IPP object receives a request with required attributes missing,
    repeated, or in the wrong position in the Operation Attributes group (Group
    1), ...

    TH> Further on in the IIG:

    3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied

    The Printer object checks to see if the client supplied an
    "ipp-attribute-fidelity" Operation attribute. If the attribute is not
    supplied by the client, the IPP object assumes that the value is 'false'.

    TH> So clarify the first sentence by adding "in the Operation Attributes
    group (Group 1) in the request" to the end.
     

    Later on:

    3.1.2.3 Algorithm for job validation

    ...

     If an IPP object doesn't recognize/support a Job Template attribute, i.e.,
    there is no corresponding Printer object "xxx-supported" attribute, the IPP
    object treats the attribute as an unknown or unsupported attribute (see the
    last row in the table below).

    ...

    Note: whether the request is accepted or rejected is determined by the value
    of the "ipp-attribute-fidelity" attribute in a subsequent step, so that all
    Job Template attribute supplied are examined and all unsupported attributes
    and/or values are copied to the Unsupported Attributes response group.

    TH> So replace "ipp-attribute-fidelity" attribute with
    "ipp-attribute-fidelity" Operation attribute.

    ...

    3.1.2.3.2 Decide whether to REJECT the request

    If there were any unsupported Job Template attributes or
    unsupported/conflicting Job Template attribute values and the client
    supplied the "ipp-attribute-fidelity" attribute with the 'true' value, the
    Printer object REJECTS the request and return the status code:

    TH> We should add "Operation" and "in the Operation Attributes group (Group
    1) in the request" so that it reads:

    If there were any unsupported Job Template attributes or
    unsupported/conflicting Job Template attribute values and the client
    supplied the "ipp-attribute-fidelity" Operation attribute with the 'true'
    value in the Operation Attributes group (Group 1) in the request, the
    Printer object REJECTS the request and return the status code:

    Comments?

    Tom

    -----Original Message-----
    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Wednesday, March 14, 2001 12:16
    To: 'Carl Kugler'; ipp@pwg.org
    Subject: RE: IPP> Misplaced attributes

    Hi Carl,

    I agree with you.

    Cheers,
    - Ira McDonald, consulting architect at Sharp and Xerox
      High North Inc

    -----Original Message-----
    From: Carl Kugler [mailto:kugler@us.ibm.com]
    Sent: Wednesday, March 14, 2001 11:46 AM
    To: ipp@pwg.org
    Subject: Re: IPP> Misplaced attributes

    P.S. Choice "C" is in accordance with the steps and error checks in IIG
    section 3.1.2 "Suggested Operation Processing Steps for IPP Objects".

         - Carl

    ---------------------- Forwarded by Carl Kugler/Boulder/IBM on 03/14/2001
    12:40 PM ---------------------------

    From: Carl Kugler on 03/14/2001 12:36 PM

    To: ipp@pwg.org
    cc:
    From: Carl Kugler/Boulder/IBM@IBMUS
    Subject: Re: IPP> Misplaced attributes

    I think choice "C" is the only conforming implementation. Quoting from
    MOD:

       Because of extensibility, any IPP object might receive a request that
         contains new or unknown attributes or values for which it has no
         support. In such cases, the IPP object processes what it can and
         returns the unsupported attributes in the response. The Unsupported
         Attribute group is defined for all operation responses for returning
         unsupported attributes that the client supplied in the request.

    Any request attribute in the Job attributes group is, by definition, a Job
    Template attribute. Support for Job Template attributes by a Printer
    object is OPTIONAL. If the client does not supply a boolean operation
    attribute named "ipp-attribute-fidelity" with value 'true', and a Printer
    does not support a client supplied Job Template attribute, the Printer MUST
    ignore it.

         -Carl

    "Zehler, Peter" <PZehler@c...> wrote:
    > All,
    > I have had some internal discussions around an issue I would like to
    resolve
    > across the IPP WG.
    >
    > ISSUE: An IPP Client sends a print request with the
    > "ipp-attribute-fidelity" attribute containing a value of 'true'. The
    client
    > also supplies the job template attribute "sides" with a value of
    > 'two-sided-long-edge'. The IPP Printer does not support two sided
    printing.
    > The IPP Client software generates the request but put the
    > "ipp-attribute-fidelity" in the job attributes group instead of the
    > operational attributes group. What should the Printer do?
    >
    > A) Reject the request with 'client-error-bad-request' since
    > "ipp-attribute-fidelity" is in the wrong group.
    >
    > B) Reject the job because the printer does not support two sided
    > printing. The IPP Printer would accept "ipp-attribute-fidelity" even
    though
    > it is in the wrong group. The printer would return a
    > "client-error-attributes-or-values-not-supported' error and return the
    > "side" attribute and value in the unsupported attribute group.
    >
    > C) Accept the job and print it substituting 'one-sided'. The IPP
    Printer
    > uses the defaulted value (i.e. 'false' ) for "ipp-attribute-fidelity"
    since
    > it was not an operational attribute. The return code would be
    > 'successful-ok-ignored-or-substituted-attributes' and the "sides" and
    > "ipp-attribute-fidelity" would be returned as unsupported attributes.
    (i.e.
    > "ipp-attribute-fidelity" is not a supported job template attribute)
    >
    >
    > As an IPP Printer implementer I would chose C. The response informs the
    > client that it is in error. The Printer is forgiving and the job is
    > printed. The extensibility of IPP is maintained.
    >
    > The Implementer's guide with need to be updated to provide a
    recommendation
    > on how to handle "misplaced" attributes. There is currently a clause
    that
    > lumps "misplaced" attributes with missing or duplicate attributes.
    (section
    > 3.1.2.1.4.3)
    >
    > Pete
    >
    > By the way my email address has changed from Peter.Zehler@u... to
    > pzehler@c...
    >
    > Peter Zehler
    > XEROX
    > Xerox Architecture Center
    > Email: PZehler@c...
    > Voice: (716) 265-8755
    > FAX: (716) 265-8792
    > US Mail: Peter Zehler
    > Xerox Corp.
    > 800 Phillips Rd.
    > M/S 139-05A
    > Webster NY, 14580-9701



    This archive was generated by hypermail 2b29 : Wed Mar 14 2001 - 17:03:13 EST