IPP> Unsupported 'requested-attributes' quest

IPP> Unsupported 'requested-attributes' quest

IPP> Unsupported 'requested-attributes' quest

Hastings, Tom N hastings at cp10.es.xerox.com
Tue Oct 6 11:36:33 EDT 1998


I think we are all in agreement here.  What is confusing is seemingly two
contradictory things about our encoding:

1. A separate value tag is associated with each value.
2. The value tag comes before the attribute-name keyword.

However, because each successive value of a multi-valued attribute has an
attribute-name keyword of zero length, a separate value tag is really
associated with each separate attribute value.

Tom

-----Original Message-----
From: henrik.holst at i-data.com [mailto:henrik.holst at i-data.com]
Sent: Tuesday, October 06, 1998 01:53
To: ipp at pwg.org
Subject: Re: IPP> Unsupported 'requested-attributes' quest





See my comments under,

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


I don't understand your concern about the language, because the values of
the 'requested-attributes' is of the type 1setOfKeyword. A value with a
'keyword' type must
be in en-us language and ascii character set. In the above example the
response would
in details looks like,

value-tag=1setOfKeyword
name-length=0x0014
name='requested-attributes'
value-length=0x000c
value='printer-info'
value-tag=1setOfKeyword
name-length=0x0000
value-length=0x0010
value='printer-location'

/HOLST




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