Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
I think this is a good debate, Like I said, I'm not sure my
suggestions were correct, but I think we need very precise
language in the document. Its not there now.
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 03/28/97 07:36
AM ---------------------------
ipp-owner @ pwg.org
03/27/97 03:07 PM
To: Roger K Debry/Boulder/IBM, ipp @ pwg.org at internet
cc:
Subject: Re: IPP>MOD - Attribute conformance
......snip ........
I would prefer that a certain set of common attributes be mandatory so
that we have don't have to deal with some of the complexity you
describe for these common attributes. I expect that we might want some
sort of common look and feel for the common stuff and it is hard to
support that if a client cannot depend on anything. I think that we are
taking generality too far when we can assume nothing about the world.
RKD> I agree with you. I also think there are a set
RKD> of attributes, priority being one that comes to
RKD> mind, upon which best-effort has no effect. That
RKD> is, if the printer does not support priority, and
RKD> a client specifies a priority in the job, I think
RKD> the job should not be rejected, no matter what
RKD> best-attribute says.
..... snip .....
I have the same comment again. In addition, we need to be careful
about adding a "null" value to mean that the attribute is unsupported.
I would prefer that the server either return no attribute 'sides', or
have some special result attribute that contains a list of attributes
'requested but not returned'.
RKD> I agree except in the case where (in this example) sides
RKK> is explicitly asked for in a Get Attributes request.
RKD? Maybe we return the text string unsupported?
..... snip .....
There are two issues here: a) the value is not supported and b) the
attribute is not supported.
If the value is not supported and best effort is requested, then we
need to define what best-effort means. Does the printer uses the
attribute's default value, or does it recognize some values and pick a
better one. Note: unsupported does not mean for all cases that the
printer is unaware of the meaning of a value. For simplicity, I would
prefer that the Printer use the attribute's default. Note, that
a syntax error may be recognizable as different from an unknown value
in this case.
If the attribute is not supported and best effort is requested, then
best effort means that the printer ignores the attribute. If an attribute
is unsupported, the Printer probably doesn't even know what it means
or what its syntax is.
RKD> I agree
..... snip .....
It doesn't seem like a protocol document should address what end-users
see.
RKD> But ... we need to understand what it means to support
RKD> an attribute. If what the end user sees (or does not see)
RKD> is an important element of what it means then we should
RKD> say it. If it's not, then we should say that support has
RKD> nothing to do with what an implementation shows an end user.
RKD> That is, we can't leave it up to interpretation of the
RKD> specification. We must be clear.
..... snip .....
I'm not sure if the IPP documents are contradictory. A client can be
totally ignorant of attribute if it never performs a GetAttributes or
GetJobs.
RKD> As it currently is written, it seems contradictory to me.
RKD> This just may be the result of the document not being
RKD> precise enough in this area. Conformance ought to be a
RKD> topic for the next model call.