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 at sharplabs.com]
Sent: Wednesday, March 14, 2001 12:16
To: 'Carl Kugler'; ipp at 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 at us.ibm.com]
Sent: Wednesday, March 14, 2001 11:46 AM
To: ipp at 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 at pwg.org
cc:
From: Carl Kugler/Boulder/IBM at 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 at 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 at u... to
>pzehler at c...>> Peter Zehler
> XEROX
> Xerox Architecture Center
> Email: PZehler at 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