Answer to issue 1.18
An IPP object MAY return requested attributes that are unsupported in Group
2 in Get-Printer-Attributes, Get-Jobs, and Get-Job-Attributes responses, but
a client cannot depend on it.
Add the following sentence:
The response NEED NOT contain the "requested-attributes" operation attribute
with any supplied values (attribute keywords) that were requested by the
client but are not supported by the IPP object.
to MOD 3.2.5.2 Get-Printer-Attributes response, 3.2.6.2 Get-Jobs response,
and 3.3.4.2 Get-Job-Attributes response:
Group 2: Unsupported Attributes
This is a set of Operation attributes supplied by the client (in the
request) that are not supported by the Printer object or that conflict with
one another (see sections 3.2.1.2 and 16).
Add a statement to the IIG that the client cannot depend on getting
unsupported attributes returned in the Unsupported Attributes group of
Get-Xxxx responses that the client requested, but are not supported by the
IPP object. However, such unsupported requested attributes will not be
returned in the Job Attributes or Printer Attributes group (since they are
unsupported).
-----Original Message-----
From: Carl Kugler [mailto:kugler@us.ibm.com]
Sent: Monday, October 05, 1998 08:17
To: ipp@pwg.org
Subject: Re: IPP> Unsupported 'requested-attributes' quest
> My opinion is that the second proposal must be the right solution
> I.e.
> >attr-tag=value-tag-keyword
> >attr-name='requested-attributes'
> >attr-value='printer-info'
> >attr-value='printer-location'
>
> Then we have a consistent. When the requested attribute is
> 'requested-attributes'
> and the values e.g are 'printer-info' and 'printer-location', then I
think,
> the IPP Printer should return the value it doesn't support. The same
> behavior as other
> attribute with unsupported attributes.
>
> /HOLST
>
In general, I agree that this is the right solution. However, I'm concerned
about the example given. I don't know what language it's in, but in IPP the
syntax tag is applies to an individual attribute value, not a whole
attribute. So it should be rewritten as
attr-name='requested-attributes'
value-tag=keyword
attr-value='printer-info'
value-tag=keyword
attr-value='printer-location'
>
>
>
> In Savannah we agreed that in the operations get-job-attributes, get-jobs,
> and get-printer-attributes, if the 'requested-attributes' attribute
> contains values specifying attributes not supported by the printer, the
> printer SHALL return status code
> 'successful-ok-ignored-or-substituted-attributes' and MAY return these
> attributes in the 'unsupported-attributes' group. My question is, if the
> printer chooses to list the attributes as unsupported in the response,
> which of the following formats should it use (suppose the printer doesn't
> support 'printer-info' and 'printer-location'):
>
> attr-tag=value-tag-unsupported
> attr-name='printer-info'
> attr-value=NULL
>
> attr-tag=value-tag-unsupported
> attr-name='printer-location'
> attr-value=NULL
>
> - or -
>
> attr-tag=value-tag-keyword
> attr-name='requested-attributes'
> attr-value='printer-info'
> attr-value='printer-location'
>
>
> -Hugo
>
>
>
>
>
>
-----
See the original message at http://www.egroups.com/list/ipp/?start=4550
-- Free e-mail group hosting at http://www.eGroups.com/