IPP> IPP Bake-Off 3 issue 4

IPP> IPP Bake-Off 3 issue 4

IPP> IPP Bake-Off 3 issue 4

Harry Lewis/Boulder/IBM harryl at us.ibm.com
Mon Oct 30 12:46:41 EST 2000


I agree with Carl. I don't think the goal (or result) of interop testing 
should be to loosen the spec because of diverse findings. This does not 
yield interoperability! Diverse interpretations are a sign of an area (of 
the spec) that may have been unclear, unnecessarily complex or simply not 
needed. 

This is a case of mismatched redundant information. I think either ....
a. Forcing the information to match
b. Removing the redundancy
... would be helpful... but not just throwing our hands up and allowing 
any combination to be considered valid. 
 
---------------------------------------------- 
Harry Lewis 
IBM Printing Systems 
---------------------------------------------- 




Carl Kugler/Boulder/IBM at IBMUS
Sent by: owner-ipp at pwg.org
10/30/2000 09:44 AM

 
        To:     "Hastings, Tom N" <hastings at cp10.es.xerox.com>
        cc:     ipp at pwg.org
        Subject:        RE: IPP> IPP Bake-Off 3 issue 4



To be really anal ytical, the spec still only allows D:

<<<<<<<<<<<<<
3.1.7 Unsupported Attributes
...
A Printer object MUST include an Unsupported Attributes group in a 
response
if the status code is one of the following:
'successful-ok-ignored-or-substituted-attributes',
'successful-ok-conflicting-attributes',
'client-error-attributes-or-values-not-supported' or
'client-error-conflicting-attributes'.
>>>>>>>>>>>>

My opinion is that specifying four or more ways to accomplish the same
thing just complicates matters and makes implementation more confusing.
Back at bakeoff 1, the spec only allowed D.  I admit that I was one of
those who implemented it wrong for bakeoff 1.  But when the spec was
loosened up, I still got it wrong and ended up in camp A.  IBM is 
currently
shipping three different implementations of "requested-attributes".  I
don't consider this a good thing.

     -Carl


"Hastings, Tom N" <hastings at cp10.es.xerox.com> on 10/27/2000 06:36:07 PM

To:   Carl Kugler/Boulder/IBM at IBMUS, ipp at pwg.org
cc:
Subject:  RE: IPP> IPP Bake-Off 3 issue 4



I agree with Carl that the current standard only allows C and D.  But 
since
so many implementations did A and since the client gets back the supported
attributes anyway, whether or not the unsupported requested attributes are
returned or not seems less important to the client.

However, I disagree with Carl that we should tighten up the standard to
allow only D.  That is the way the standard was written for the first Bake
Off and we agreed to allow C.

So the current standards allows C and D.  Since requesting unsupported
attributes isn't really going to cause the client to get unexpected 
results
(since the client will be looking at the supported returned attributes
anyway), I favor adding A as allowed.  And we may as well allow B as well.
No matter which of the 4 ways the Printer is written, the client doesn't
have any extra work to work with all 4 ways:

Until we add OPTIONAL operation attributes or OPTIONAL operation attribute
values to the Get-Printer-Attributes operation, there is not much need for
the client to look at the Unsupported Attribute group returned by the
Printer at all.  (Currently the only other attribute that a Printer could
return in the Unsupported Attributes Group is "document-format" with an
unsupported document format that the client requested).

So the client merely treats success (0) and
Successful-attribute-or-value-ignored (1) status codes the same and then
looks at the Printer Attributes Group returned.

Lets here from others...

Tom

-----Original Message-----
From: Carl Kugler/Boulder/IBM [mailto:kugler at us.ibm.com]
Sent: Friday, October 27, 2000 13:44
To: ipp at pwg.org
Subject: Re: IPP> IPP Bake-Off 3 issue 4


"Zehler, Peter" <Peter.Zehler at u...> wrote:
> All,
>
> BO3-4: For get-printer-attributes operation submitted with an 
unsupported
> "requested-attributes" value what is the return code and should an
> unsupported attributes group be returned containing the
requested-attributes
> attribute and the unsupported value.  There are four possibilities of
status
> code and unsupported attribute:
>    A)   successful-ok/no attributes
>    B)   successful-ok/unsupported requested-attributes returned
>    C)   Successful-attribute-or-value-ignored/ no attributes
>    D)    Successful-attribute-or-value-ignored/ unsupported
> requested-attributes returned
>         The standard currently allows A, C, D.  Should the standard
> be relaxed to include C.
>
I'm not sure I follow you here!

Looks to me like the spec currently allows only C or D:
<<<<<
13.1.4.12 client-error-attributes-or-values-not-supported (0x040B)
...
For any operation where a client requests attributes (such as a Get-Jobs,
Get-Printer-Attributes, or Get-Job-Attributes operation), if the IPP 
object
does not support one or more of the requested attributes, the IPP object
simply ignores the unsupported requested attributes and processes the
request as if they had not been supplied, rather than returning this 
status
code.  In this case, the IPP object MUST return the
'successful-ok-ignored-or-substituted-attributes' status code and MAY
return the unsupported attributes as values of the "requested-attributes"
in the Unsupported Attributes Group (see section 13.1.2.2).
>>>>>
Choice D would simplify the spec, since there wouldn't need to be any
special exception for "requested-attributes";  it would be treated the 
same
as any other attribute.  However, "requested-attributes" seems to be
confusing to implement, since I have seen implementations all over the map
on this.  I have even seen some imaginative responses that don't fall into
any of the above possibilities (but not at the bakeoff).  Maybe we should
settle on D, the simplest one to specify, then put a big chapter in the
Implementer's Guide explaining the details.

     -Carl

> The implementations at the Bake-Off supported were
> A-11, B-1, C-3, D-0
>         Proposed Resolution: Allow all combinations
>
>








More information about the Ipp mailing list