Subject: Re: IPP>MOD - conformance [for Friday's 4/18 telecon]

From: Tom Hastings <[email-masked]>
Date: Fri, 18 Apr 1997 03:07:11 PDT

Here are some comments on the suggestions for conformance which is on the
agenda for Friday 4/18 Model telecon.  I'm sorry, but I will be unable
to attend, due to travel.

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: [email-masked]
>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

---

From: Roger K Debry <[email-masked]>
Date: Fri, 18 Apr 1997 15:37:32 -0400

Classification:
Prologue:
Epilogue: Roger K deBry

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.

RKD> I agree.

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.

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

RKD> I Agree

- 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"?

RKD> Okay

RKD> Okay

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.
[15] I suggest:
RKD> Okay

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.

RKD> I agree

RKD> Okay

[19] Slight improvement:
RKD> Okay

RKD> Okay

RKD> Okay

[22] Slightly better:

[23] Slightly better:

RKD> Okay

RKD> Okay

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

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.

Tom

---

From: Tom Hastings <[email-masked]>
Date: Sun, 20 Apr 1997 17:53:24 PDT

At 12:37 04/18/97 PDT, Roger K Debry wrote:

...

>RKD> this information back to the IPP layer? If so, I agree.

I think that we should clarify that 'unknown' covers this case.

...

>RKD> Not sure what this applies to in my text???

You used the word "recognize" as distinct from supported.  I feel that
there is no need for a Printer to return two different error codes for
attributes: one for attributes it recognizes, but doesn't support,
versus attributes it doesn't recognized and doesn't support.

For example, an implementation might recognize all attributes in the
standard, but not support all of them.  But another implementation might
not recognize all of them and so would return the unsupported error.
And both implementations would return the unsupported error when a new
registered attribute is supplied by a client.

...

>RKD> than a value of "unsupported"?

Actually, I agree with you that it would be much better for the user to see 
which attributes aren't supported and shouldn't be too much harder to support.  
And having an "unsupported" value come back with any of our attributes
would be a simple way to do it for our "ASCII" approach.  It isn't so easy
for binary approaches, such as ASN.1 because the syntax for every value
as to include a CHOICE "unsupported".

>RKD> than leaving x out of the list of responses.

Again, I agree that it would be much better for the user to see which
attributes aren't supported and shouldn't be too much harder to implement.  

A sub-issue would be when an implementation doesn't support all attributes
in a requested group.  I would assume that the implementation would NOT
need to return the unsupported attributes in the group with a value of
"unsupported".  Also when a new attribute is registered, the registration
would specify which group the attribute belongs, so we would have future
attributes belonging to groups that older implementations wouldn't
know about.