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/