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
Tom, sorry that you will not be in on the call today.
Here are my thoughts on your comments:
[2] What section is your suggested text to replace?
RKD> Haven't thought about this. Will consider your
RKD> suggestion.
[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.
RKD> I agree.
[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.
RKD> I agree.
[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.
RKD> Does this cover the case where the device may support an
RKD> attribute, such as finishing, but has no means for passing
RKD> this information back to the IPP layer? If so, I agree.
[6] The current document uses the term "supplied", not "specified" for what
a client passes in a request. Specifications specify, clients supply.
RKD> Okay.
[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.
RKD> Not sure what this applies to in my text???
[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.
RKD> I Agree
[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.
RKD> But I assume the Printer still returns data for
RKD> supported attributes. Is this approach better (easier)
RKD> than a value of "unsupported"?
[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.
RKD> Okay
[11] I think we should continue the IPP (and DPA and SNMP) terminology of
returning an "unknown" value for such an implemented attribute.
RKD> Okay
[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.
RKD> I agree
[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
RKD> I would prefer a value of "unsupported". Going back to your point
RKD> in [12], not returning an attribute at all seems a bit like returning
RKD> an empty list. If an end user requests (in a list of attributes)
RKD> attribute x, wouldn't a value of unspupported be easier to understand
RKD> than leaving x out of the list of responses.
[14] Did you mean to replace the lines 696-718 with the following?
RKD> Yes, or something similar.
>>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.
RKD> Okay
>>- 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
RKD> Okay, by the way Keith Carter has defined this in his proposal
RKD> for status codes.
[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.
RKD> I agree
[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.
RKD> Okay
>>- 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.
RKD> Okay
>> 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.
RKD> Okay
[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.
RKD> Okay
>>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
RKD> Okay
>>- 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
RKD> Okay
>>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.
RKD> I agree that the standard should not dictate the user interface. But
RKD> I maintain that we might want to mention this as an implementation
RKD> consideration. It seems to me the only way that a client can make
RKD> server-specific extensions visible to an end user.
[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.
RKD> I don't think that this paragraph is very clear -- one of the reasons
RKD> that I tried to write down some additional prose on the subject. My
RKD> final analysis was that the client is not bound to do anything at all
RKD> except not fail if it sees attributes it doesn't 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