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

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

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

Hastings, Tom N hastings at cp10.es.xerox.com
Mon Oct 5 19:17:32 EDT 1998


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 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 at us.ibm.com]
Sent: Monday, October 05, 1998 08:17
To: ipp at 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/



More information about the Ipp mailing list