This is getting lengthy, so I've added numbers in [] to each section
which may help during the telecon.
[1] In all the mail since the Internet Draft has been published, I haven't
noticed one reference to sections or lines. We have to be working more
closely with the specification if we are ever to finish.
Roger,
[2] What section is your suggested text to replace?
Currently in the Internet-Draft, conformance with respect to
attributes is discussed in two places:
1. Pages 8-9, lines 251-292.
2. Pages 20-21, lines 691-718 for the Print operation.
3. I couldn't find anything for the Get Attributes and Get Jobs operations
with respect to an explicity requested attribute that the Printer doesn't
implement so I suggest that your text go there. Perhaps that is what you
intended.
At 10:24 04/09/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
>
>-----------
>I've drafted a new section on conformance as it applies to attributes.
>Comments please.....
>
>IPP conforming implementations must do the following with respect to
>attributes:
>
>In response to a query (Get_Attributes or Get_jobs) an IPP Printer
>
>- shall respond with all available supported values for each attribute
> if the attribute is supported by the Printer. Support for some attributes
> is mandatory. Available means that the Printer can actually determine what
> the attribute value is. For example, printer-state would be unavailable
> when a Printer is driving a legacy output device which has no capability
> of reporting its current state.
[3] Instead of the term "available", "unavailable", "supported", I suggest
"implemented" for attributes and attribute groups
and the term "supported" for values of implemented attributes. In DPA,
available has to do with the current situation ready/not ready, not with
implementation.
[4] To keep the terminology simple, there are cases where an implementation
implements an attribute, but the instance of the printer doesn't. For
example, if the software implements the finishing attribute, but the
particular Printer instance doesn't have any finishing equipment, I think
it is simpler to say that that Printer instance doesn't implement the
finishing attribute. So that for that Printer instance the behavior
is indistinguishable from another implementation that never implemented
the finishing attribute for any Printer instance.
[5] When an implementation doesn't know the value, DPA, IPP, and most SNMP MIBs
have been using the value "unknown". I suggest that IPP continue this.
[6] The current document uses the term "supplied", not "specified" for what
a client passes in a request. Specifications specify, clients supply.
[7] Because of extensibiity, I don't think that there is any need to consider
the case of an implementation recognizing an attribute that it doesn't
implement. An implementation either implements an attribute or it doesn't.
[8] Also I would suggest using a similar approach that was used for the Print
operation (see lines 691-718), namely to consider each case separately.
[9] So I would rewrite the above section and add it to the end of
section 4.2.3 as:
When a Printer receives a Get Attributes Request to a Job URL or a Printer URL,
the Printer shall either accept the request or reject the request.
The only reasons for rejecting the request shall be access control or a
syntactically mal-formed request. A Printer shall not reject a request
because the request contains an attribute or attribute group that is not
implemented. Such an unimplemented attribute might be an attribute in this
specification that is (1) not mandatory for conformance, (2) a registered
(type 2) attribute that extends the speification, or (3) a private
attribute that extends the specification.
There are the following cases to consider with respect to each
attribute:
- The client supplies an attribute and it is an attribute implemented by
that instance of the Printer. The Printer shall return all current
values of the requested job attribute for a Job URL or all supported values
of the requested printer attribute for a Printer URL.
- The client supplies an attribute group and it is an attribute group
implemented by that instance of the Printer. The Printer shall return all
current values of the implementd job attributes in the group for a Job URL
or all supported values of the implemented printer attributes in that group
for a Printer URL.
- The client supplies an attribute or an attribute group, but it is an
attribute or attribute group that is not implemented by that instance of
the Printer. The Printer shall return no attribute and value for that
attribute and shall return the status code:
some-requested-attributes-not-implemented.
[10] The conformance for the Get Jobs operation to be added to the end of
section 4.2.4 is a repeat of the above for the text that applies to
the Job URL only.
>
>- shall respond with an empty value for each attribute that it recognizes,
> but which is unavailable.
>
> Issue: The notion of unavailable here is meant to handle cases
> where an IPP Printer is driving a legacy device which has no
> ability to report any information about itself upstream. Should
> there be an attribute value of "unavailable" to better indicate
> this condition?
[11] I think we should continue the IPP (and DPA and SNMP) terminology of
returning an "unknown" value for such an implemented attribute.
[12] Also I have been trying to stamp out attributes with empty values, since
they are not user-friendly. Programmers are confortable with empty, but
not ordinary users.
>
>
>- shall respond with an empty value for each attribute that it does not
> recognize.
>
> Issue: Should there be an attribute value of "unsupported" to
> better indicate this?
[13] Again, I think that it is simpler not to make a distinction between
(1) recognized, but unimplemented, and (2) unrecognized. So just return
no attribute at all and the status code:
some-requested-attributes-not-implemented
[14] Did you mean to replace the lines 696-718 with the following?
>
>In response to a Print request, if the best-effort attribute is set to
>substitute-as-needed, an IPP Printer
>
> Issue: The following assumes best-effort as currently defined
> in the model document. best-effort would be a mandatory attribute.
>
>- shall use the specified attribute value in the print operation if the
> attribute and the specified value are supported.
[15] I suggest:
attribute is implemented and the specified value(s) are supported.
>
>- shall ignore the attribute if the attribute is supported but the specificed
> value is not
>
> Issue: Should a return code indicate that the attribute was
> ignored because an unsupported value was specified?
[16] Yes, add the following:
and shall return the status code: some-requested-values-substituted
[17] And I agree with Scott that there no need to return the attributes or the
values that were substituted. The client can query the Printer to see
ALL attributes supported. This is a simplification from ISO DPA.
[18] However, I believe that the Printer must actually change the value to
the one substituted, so that a subsequent query will show the actual
value. This is not too difficult and will help the implementation as well,
since it won't have to treat this attribute specially down-stream. So add
the following sentence:
The Printer shall change the value to the default value for that
attribute, so that subsequent Get Attribute requests will return the
substituted value.
>
>- shall ignore the attribute if the attribute is not supported.
[19] Slight improvement:
- shall ignore the attirubte if the attribute is not implemented for the
Job object.
>
> Issue: Should a return code indicate that the attribute was ignored
> because it is unsupported?
[20] Yes, add the following:
and shall return the statue code: some-attributes-ignored.
[21] Also add the following sentence:
The Printer shall not add the unsupported attribute to the Job Object.
A subsequent Get Attributes request to this Job object shall not return
the ignored unimplemented job attribute.
>
>
>
>
>In response to a Print request, if the best-effort attribute is set to
>do-not-substitute, an IPP Printer
>
>- shall use the specified attribute value in the print operation if the
> attribute and the specified value are supported.
[22] Slightly better:
- shall use the specified attribute value in the Print operation if the
specified attribute is implemented and the specified value(s) are (all)
supported.
>
>- shall reject the print job if the attribute is supported but the specified
> value is not.
[23] Slightly better:
- shall reject the print job if the attribute is implemented but any of the
supplied value(s) are not supported on this Printer
>
> Issue: Should a return code indicate that the job was rejected
> because an unsupported attribute value was specified?
[24] Yes, add the following:
and shall return the status codes: operation rejected,
some-attributes-values-unsupported
>
>- shall reject the print job is the attribute is not supported.
>
> Issue: Should a return code indicate that the job was rejected
> because an unsupported attribute was specified?
[25] Yes, add the following:
and shall return the status codes: operation rejected,
some-attributes-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?
[26] Good issue. Since the Printer URL is not being sent as an attribute,
but as an operation parameter, it isn't a required attribute.
It would be best that if we have any other attributes that are required to be
supplied, that we make them be input parameters of the operation. Then
the syntax of the abstract model enforces the required information to be
supplied.
[27] Perhaps the Job Owner group of attributes in 5.3.2 should be passed
as input parameters in the protocol: job-originating-user,
job-originating-host, user-locale, (and I think we agreed to move job-name
back to a group that is set by client).
>
>In response to a Query, an IPP client shall not fail for any attributes or
>values for those attributes which are returned. The client need not use any
>returned attributes in subsequent operations. IPP clients should provide a
>means for displaying any returned attributes and values to an end user.
>
> Issue: Bob Herriot had suggested that the protocol should not
> say anything about what a client presents to an end user. If
> others agree, then perhaps this is just an implementation guideline.
> However, I think it is important to note.
[28] I think that we had resolution on this later. The IPP standard shouldn't
say what the client must do to the user interface. But the IPP standard
must have some operational conformance requirements on the client.
[29] For example, the client shall ignore any attributes that it doesn't
implement, rather than refusing to interoperate with the Printer.
The current text in section 1.1.1 says:
1.1.1 Client Considerations
IPP clients shall support all operations, objects, and attributes as defined
in this document. However, there is no conformance requirements placed on
the user interfaces provided by IPP clients or their applications. For
example, one application might not allow an end user to submit multiple
documents per job, while another does. One application might first query a
Printer object in order to supply a graphical user interface (GUI) dialogue
box with current supported and default values whereas a different
application might not. A conforming client may choose to ignore any
adornment tags it does not understand.
[30] I think that the title should be changed to Client Conformance Requirements
[31] Same for 1.1.2 to Server Conformance Requirements.
[32] I also think that the last sentence should be strengthened to:
A conforming client shall ignore any adornment tags it does not implement.
Else we can't register and add adornment tags in the future as extensions.
Have a good telecon. I hope these comments help move the discussion along
and get explicit agreements of text to add/change in the document.
Tom