Looks good.
A few minor editorial comments.
Tom
At 12:46 04/21/97 PDT, Roger K Debry wrote:
>Classification:
>Prologue:
>Epilogue: Roger K deBry
>Senior Techncial Staff Member
>Architecture and Technology
>IBM Printing Systems
>email: rdebry@us.ibm.com
>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.
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.
>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.
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.
>
>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.
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.
>
>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.
For the last sentence how about:
A Printer shall return the status codes: job-rejected, and:
some-attribute-values-are-not-supported
>
>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.
For the last sentence how about:
A Printer shall return the status codes: job-rejected, and:
some-attributes-are-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?
Yes, and they should be listed in the General conformance section
for client conformance (as well as in the description of the operation).
>
>In response to a Query, an IPP client may ignore any attributes
>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.
>
>