IPP Mail Archive: RE: IPP> Unsupported 'requested-attributes' quest [Issue 1.18]

IPP Mail Archive: RE: IPP> Unsupported 'requested-attributes' quest [Issue 1.18]

RE: IPP> Unsupported 'requested-attributes' quest [Issue 1.18]

Hastings, Tom N (hastings@cp10.es.xerox.com)
Mon, 5 Oct 1998 16:17:32 -0700

I agree with Henrik that it is Hugo's second alternative that is more
consistent with returning Operation attributes with values that are not
supported. Here is the text that I am putting into the Issues List for
Issue 1.18. How does this seem as the actual text to be put into MOD?

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 Get-Printer-Attributes response, Get-Jobs response,
and 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 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

-----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
> the IPP Printer should return the value it doesn't support. The same
> behavior as other
> attribute with unsupported attributes.

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


> 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/