Subject: IPP>MOD - Attribute conformance

From: Roger K Debry <[email-masked]>
Date: Thu, 27 Mar 1997 16:25:02 -0500

Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

I have found the section on conformance, as it relates to attributes,
 to be confusing.   I've tried to reason out what I think conformance
means.  If this sounds reasonable then perhaps we can use some
of the following text to clarify conformance in section 1.1 of the
model document. Please let me know your thoughts on the
following.  What I've suggested may not be correct, but I think we
have to be this specific.

Attributes are conditionally mandatory. This means the following:
(The attribute sides will be used as an example)

If a Printer does not provide a feature that a given attribute
controls, then

In response to a general query (all or an attribute group) the
Printer should respond with any attributes it does not
support.  For example, if jobTemplate is specified in a Get
Attributes request, and the Printer only supports simplex
printing, then it should return the attribute keyword sides
with the attribute value 1-sided. However, it need not
send back anything for sides.

In response to a specific query for an unsupported attribute,
the Printer should return the attribute keyword with an
appropriate value. For example, if Sides is requested in a
Get attributes request, and the Printer only supports simplex
printing, then it should respond with sides = 1-sided. However,
it may respond with sides = null value, since if it is really
unsupported it will not know what value to respond with.

In response to a print request including a non-supported
attribute, the Printer must recognize the attribute as one
that it does not support (this would have to include syntax
errors or private extensions not supported) and honor the
print request ONLY if the best-effort attribute is set to
substitute-as-needed (this implies that best-effort is either
a mandatory attribute, or always defaults to do-not-
substitute).  In our example, a duplex job sent to a simplex
printer would not print unless substitute-as-needed is
indicated.

When a print request is rejected because of an
unsupported attribute, the Printer must be able to indicate
which attribute(s) in the request were not supported and
therefore caused the failure. In our example, if a duplex job
is sent to a simplex printer, and the print request is rejected, the
response must say sides=duplex not supported.

In response to a general query, a client should provide end
users with some mechanism to see and select all attributes
returned by the Printer.  However, a client need not provide
the end user with visibility of any attributes.

When submitting a print request, the client need not explicity
specify any attributes, thus taking the Printer defaults.
For example, it might always default sides to be either
1-sided or take the Printer default. From this point of view,
it is probably correct to say that a client need not support
any attributes. This is contradictory to the current model doc.

---

From: [email-masked] (Robert Herriot)
Date: Thu, 27 Mar 1997 14:02:03 -0800

I have made several comments below. 

> From [email-masked] Thu Mar 27 13:29:17 1997
> 

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.

> send back anything for sides.

I think that I have a different notion of 'support'.  If the printer
knows about 'sides' but only supports '1-sided', then I believe that
the printer supports the attribute 'sides'.   In this case, I believe
that the printer SHALL always return 'sides' in the case.
> unsupported it will not know what value to respond with.

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

> printer would not print unless substitute-as-needed is

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.
> the end user with visibility of any attributes.

It doesn't seem like a protocol document should address what end-users
see.

> any attributes. This is contradictory to the current model doc.
The sentence 'it might always default sides to be either 1-sided or take the 
Printer default.' suggests two defaulting mechanisms. There is only
one, namely on the Printer side. The IPP documents don't specify how a
client decides to set or not to set attributes.

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.

---

From: Roger K Debry <[email-masked]>
Date: Fri, 28 Mar 1997 09:57:38 -0500

Classification:
Prologue:
Epilogue: Roger K deBry

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@internet
cc:
Subject: Re: IPP>MOD - Attribute conformance

 ......snip ........

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

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

RKD> I agree

..... snip .....

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

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.

---

From: JK Martin <[email-masked]>
Date: Fri, 28 Mar 1997 20:20:23 -0500 (EST)

Roger,

> RKD> I also think there are a set

Hmmm.  This makes me think that each and every attribute specification
will need to have a clause (or section, or whatever) that addresses
"best-effort ramifications" so that an implementor knows *exactly*
what to expect.

	...jay