Subject: IPP>MOD - Conformance

From: Roger K Debry <[email-masked]>
Date: Mon, 21 Apr 1997 15:46:21 -0400

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

Following is update to the conformance white paper.  This reflects Tom's email
and discussion in last week's IPP telecon.
Comments please ....

IPP Conformance White Paper

This paper does not discuss where conformance should go in the
model document. Personally, I prefer to see conformance
described all together in one section, rather than spread
throughout the document. As an implementor it seems easier to be
model document.  Personally, I prefer to see conformance
sure that I've got a conforming application if the requirements
are all stated in one place.

IPP conforming implementations must do the following with respect
to attributes:

In response to a Get_Attributes or Get_Jobs operation

o If the client supplies an attribute and it is an attribute
    implemented by the Printer, the Printer shall respond with all
    currently supported values for that attribute.  If the value
    of an implemented attribute is unknown for some reason, the
    Printer shall respond with the value "unknown".

    Note: this requires an encoding of "unknown" for each
    attribute syntax.

o If the client supplies an attribute and it is an attribute not
   implemented by the Printer, the Printer shall respond with the
   value of "unsupported" for that attribute.

   Note: this requires an encoding of "unsupported" for each
  attribute syntax.

o If the client supplies an attribute group that is implemented
    by the Printer, the Printer shall respond with all currently
    supported values for each implemented attribute in the group.
    It shall not respond for unimplemented attributes in the
    group. If the value of an attribute is unknown for some
    reason, the Printer shall respond with the value "unknown" for
    that attribute.

In response to a Print request, if a job or document attribute is
supplied and the best-effort attribute is set to
substitute-as-needed, an IPP Printer

Note: The following assumes best-effort as currently defined
in the model  document.

o shall use the supplied attribute value in the print operation
    if the attribute is implemented in the Printer and the
    specified value is supported.

o shall change the attribute value to the default value for the
    supplied attribute if the attribute is implemented but the
    supplied value is not supported. A return code will indicate
    that the job was accepted with attribute substitution.  A
    subsequent query of the supplied attribute should return the
    substituted value.

o shall ignore the attribute if the attribute is not
    implemented. A return code will indicate that the job was
    accepted with some attributes ignored. The Printer shall not
    add the unimplemented attributes to the created job object. A
    subsesquent Get-attributes operation will not return the
    ignored unimplemented attributes.

In response to a Print request, if the best-effort attribute is
set to do-not-substitute, an IPP Printer

o shall use the supplied attribute value in the print operation
      if the attribute is implemented and the supplied value is
      supported.

o shall reject the print job if the attribute is implemented but
    the supplied value is not. A return code will indicate that
    the job was rejected because a supplied attribute value is
    unsupported.

o shall reject the print job if a supplied attribute is not
    implemented. Aeturn code will indicate that the job was
    rejected because a supplied attribute is not implemented.

Sending a Query or Print request, an IPP client need not specify
any attributes.

Issue: Are there any attributes that are mandatory for a
client to set in a Print request?

In response to a Query, an IPP client may ignore any attributes
that it does not implement.

---

From: [email-masked] (Robert Herriot)
Date: Tue, 22 Apr 1997 16:02:29 -0700

I agree with you rules below with the following suggestions and additions.
This reply got longer than I initially expected.

First, we need to define the terms "supported", "implements", and "default"
more carefully.

The text should indicate that a value is "supported" for an attribute
"XXX" if it is member of the set of values for the Printer attribute
"supportedXXX".  If a value is not supported, that does not make a
statement about whether the Printer implements the value. That is,
a Printer may implement values that someone (e.g. an administrator)
has decided a Printer will not support.

NOTE: the model group is still debating the name of "supportedXXX",
versus "XXXsupported" versus "XXX-supported", etc.

A printer implements an attribute if that attribute is in the list of
attributes that the Printer knows about.  A Printer may have behavior
that corresponds to the value of some attribute, but if the Printer
doesn't know about the attribute name, it doesn't implement it.  For
example, if a printer prints one-sided only but does not know about the
attribute "sides", it does not implement "sides" even though it prints
one-sided jobs. I would hope that most Printers would implement "sides",
even for one-sided Printer, but the same reasoning applies to the 
attribute "foo".

If a printer implements an attribute, but that attribute contains
no values (e.g. an Administrator didn't initialize it), what does
the Printer return as its value? "unknown", empty set, or does
every attribute has at least some reasonable value that can never
be empty (for IPP attributes, the model document defines such
a default value)?  

The text should also define what the Printer's default value is. For
attribute "XXX" the Printer's "defaultXXX" attribute contains the
default value.  If the printer doesn't implement "defaultXXX", the
default value is the first value of "supportedXXX". If neither
"supportedXXX" nor "defaultXXX" are defined, the printer does not 
implement the attribute, so the explicit default is moot.

Your text also omits a whole set of rules, namely what happens during
job submission when the job doesn't contain an attribute. The missing
rules are:

  o shall use the Printer's default attribute value in the print operation
      if the Printer implements an attribute which the job does not specify.
      If a client queries the job, subsequently, such attributes shall
      be included with the job, as if the client had included them with
      the original job submission.

  o shall use the default behavior (according to the IPP model document)
      for the attribute in the print operation if the Printer doesn't
      implement the attribute and the job does not specify the attribute
      and the IPP model document does specify the attribute. If a client 
      queries the job, subsequently, such attributes shall not be included
      with the job.

  o shall use the default behavior (according to the Printer)
      for the attribute in the print operation if the Printer doesn't
      implement the attribute and the job does not specify the attribute
      and the IPP model document does not specify the attribute. If a client 
      queries the job, subsequently, such attributes shall not be included
      with the job.

  o shall use the supplied attribute value in the print operation
      if the Printer implements the specified attribute and supports
      the specified value.
>     subsequent query of the supplied attribute should return the

ISSUE: what is the rule if the attribute's default value is "unknown"?
It that the same as the attribute not being implemented.

  o shall change the attribute value to the default value for the
      supplied attribute if the Printer implements the specified 
      attribute but does not support the specified value. A return 
      code shall indicate that the Printer accepted the job 
      with attribute substitution.  A subsequent query of the 
      aforementioned attribute should return the substituted value.
>     ignored unimplemented attributes.

ISSUE: what sort of return code is used when several of the return
code clauses get invoked?

   o shall ignore the attribute if the Printer does not implement
     it.  ...

Note: an alternative approach to the above case, is for the job to
    keep the attribute with a value of "unsupported".  This makes
    it easier for a client to query a job and see the attributes
    that were ignored.

>     the job was rejected because a supplied attribute value is

Keep the language of "supported" for values rather than the implicit
"implemented" here.  Suggested wording:
  o shall reject the print job if the Printer implements the 
    specified attribute but does not support the specified value.

> that it does not implement.

We probably shouldn't prescribe the behavior of a client. What we
should say is:

   A Query may return attributes and values which a client does not
   implement.

This warns the implementor to be ready to receive unexpected attributes
and value, but leaves the implementer free to handle such attributes
and values in whatever way the implementor chooses. This does not
prohibit bad solutions, such as abnormal termination of the client.

---

From: Tom Hastings <[email-masked]>
Date: Wed, 23 Apr 1997 11:49:17 PDT

Roger,

Looks good.

A few minor editorial comments.

Tom

>are all stated in one place.

I agree that there are two approaches:  
1. Put conformance in one place
2. Put conformance as part of the description of each operation.

A possible win-win, is to list in a single section on conformance references
to each section that has conformance requirments.

For example the general conformance section could have:

A conforming Printer shall:

1. Implement the following operation according to the conformance 
requirements for accepting and responding to these operations as 
specified in the indicated sections:

  4.2.1 Print operation
  4.2.2 Cancel-Job operation
  4.2.3 Get-Attributes operation
  4.2.4 Get-Jobs operation

2. Implement the mandatory attributes according to the conformance
requirements as specified in the indicated sections:

  5.x.y

If the list of mandatory attributes is too long, we may not want to list
them in the general conformance section, but just refer to where they
are indicated as mandatory.   Since I think that it is important to have
with each attribute (in some compact notation) and indication of whether
the attribute is mandatory or not.  If it is real simple to specify
mandatory, then put it in parens in the header, along with the data type.
For the non-mandatory, don't put anything in the header, assuming that
most are non-mandatory or are conditionally mandatory.

Then the table of contents gives the reader a real 40 thousand foot view
of the attributes and which are mandatory.  I've done this with the
IETF Job Monitoring MIB and its real simple and keeps the document short.

We also need a Conformance section for the client and it should have the
same form:

A conforming client shall:

1. not refuse to interwork with a conforming Printer, even if the Printer 
returns additional attributes or values in any operation than are in this 
version of the specification, as long as the Printer conforms to the 
implementation of such extensions.

BTW, MS-WORD allows you to make the above list using cross references
to headers, so that the section number and the text is kept up to date 
automatically.   You have to include the section number and the 
header text in the selections.

>    subsequent query of the supplied attribute should return the

In the second to last sentence, we should specify the return codes by
name, there should be an acceptance status code and an indication of the
substitution, and we need a shall, and no passive voice. How about:

  The Printer shall return the status codes: job-accepted, and: 
  some-attribute-values-substituted

This last sentence needs a shall, not a should, ok?
Also needs to be re-written to avoid the passive voice and specify which
operation the query is and what a conforming Printer must do.  I suggest:

  A Printer shall return the substituted value as the value of the attribute
  in a subsequent Get-Attributes or Get-Jobs operation for the submitted job.

>    ignored unimplemented attributes.

Need to specify the return code.  How about for the second sentence:

  A Printer shall return the status codes: job-accepted, and: 
  some-attributes-ignored

For the last sentence how about:

  A Printer shall not return the ignored attributes in a subsequent 
  Get-Attributes or Get-Jobs operation for the submitted job.

>    the job was rejected because a supplied attribute value is

For the last sentence how about:

  A Printer shall return the status codes: job-rejected, and: 
  some-attribute-values-are-not-supported

>    rejected because a supplied attribute is not implemented.

For the last sentence how about:

  A Printer shall return the status codes: job-rejected, and: 
  some-attributes-are-not-implemented

>client to set in a Print request?

Yes, and they should be listed in the General conformance section
for client conformance (as well as in the description of the operation).

>that it does not implement.

True, but we need a stronger conformance for a client, that prohibits
the client from refusing to interoperate with the (conforming) Printer
that is returning extensions.

Also true for a response to a Print operation, not just a query.

---

From: Tom Hastings <[email-masked]>
Date: Thu, 24 Apr 1997 18:33:05 PDT

I agree with these comments and have some minor comments on a few.

Some of my earlier comments are on the same areas, and these are not
repeated here.

Tom

>Return-Path: <[email-masked]>
>Date: Tue, 22 Apr 1997 16:02:29 PDT
>From: [email-masked] (Robert Herriot)
>To: [email-masked], [email-masked]
>Subject: Re: IPP>MOD - Conformance
>X-Sun-Charset: US-ASCII
>Sender: [email-masked]
>

I agree. We need to put these terms in a terminology section.
I happen to like putting such a section up front, so that the reader
reads them first.

We also need to add "default behavior" to the terminology section.

>has decided a Printer will not support.

So we will talk about attributes being implemented, and values being
supported, but NOT attributes being supported and values being implemented,
correct?

Also I think we need to point out this subtle fact that an administrator
may restrict a Printer to not supporting a value that has actually been
implemented by the Printer.

>versus "XXXsupported" versus "XXX-supported", etc.

I happen to like XXX-supported, since I think of the "tag" as being
subordinate to the attribute.  Also I like the syntax being the
same.  Though I could support some other character between XXX and supported,
since - is also allowed inside XXX.

>even for one-sided Printer, but the same reasoning applies to the 

I agree.

>be empty (for IPP attributes, the model document defines such

I'm a fan of not having empty attributes.  Furthermore, I suggest that
the Printer shall prevent the administrator from setting an XXX-supported
attribute to no values.  I suggest that we pick one of
for the model document for all the XXX-supported attributes:

1. The Printer shall supply a value, even if the administrator has not
set the XXX-supported attribute.  In other words, the implementation shall
return one of the standard or registered values as a built-in default value
for each of the XXX-supported attributes, so that no XXX-supported attribute 
shall be able to have no values.

2. The Printer shall supply the 'uninitialized' value, if the adminstrator
has not set the XXX-supported attribute.

I prefer 1, since it is simpler and means that the system does something
useful out of the box, in spite of the system administrator.

>implement the attribute, so the explicit default is moot.

I agree with Roger,

If we allow the first value to be the default, why not use just that
mechanism to specify the default and not have two ways for a Printer
to indicate the default value?

Alternatively, require the XXX-default and make no statement about the
first value.  That will make it clearer about default values, though
it means more attributes, and complicates a client application. But I see
no advantage to have two ways, especially if it might reduce interoperability,
and complicates the spec and the implementation of clients and Printers.

I prefer the first alternative, since it is simpler and has less attributes.

>      queries the job, subsequently, such attributes shall not be included

I agree with adding these rules.

>      if the Printer implements the specified attribute and supports

I'm a big fan of the active voice.

>It that the same as the attribute not being implemented.

No.  I suggest that we require that a conforming Printer shall not
have a default value of "unknown".  Lets suppose that there is a hardware
device that allows the operator to set simplex vs. duples locally at the
console (and supports setting sides by the PDL), but that doesn't allow
the software to query the output device for the current setting.  A conforming
Printer (front for this output device) shall support the sides attribute 
and furthermore, the Printer shall have a default value for the sides
attribute.  In order to implement such a default value, the Printer would have
to always send the default value for the sides attribute ahead of each
job to the output device.  But that is the only way to get reproducible
results!

We need to explicitly forbid the unknown value for a default and explain
what a conforming Printer that is a front for the output device shall do
with such an output device.

>      aforementioned attribute should return the substituted value.

I think the last line should be a shall, not a should.

>code clauses get invoked?

If we are stuck with only one return code, we need some sort of precedance
for when there are more than one.  I hope we can to better than only
having one.

>    it easier for a client to query a job and see the attributes

Interesting idea. Lets list this as an issue.

>    specified attribute but does not support the specified value.

Good.

>prohibit bad solutions, such as abnormal termination of the client.

I claim we need to write conformance requirements for clients as well
as Printers, and we can at least say something like:

  a client shall not perform an abnormal termination upon receiving 
  an attribute or a value in a response from a Printer, that the client 
  did not implement or support.