Subject: IPP>Comments on Operations Attributes

From: Roger K Debry <[email-masked]>
Date: Thu, 20 Nov 1997 11:21:32 -0500

I have read through the comments posted by Tom, Bob, and Scott
and have the following comments:

In general, I think that the proposal is a good one, and I appreciate
the work done by Tom, Bob and Scott to clarify the handling of
operation attributes.

Section 2.2:  Do we need to get to the level of detail suggested
in this paragraph in reporting errors?  Why isn't it adequate to
simply say "syntax error"?   Don't these errors fall into the same
category as paragraph 2.4, i.e. invalid length looks like a
development time error, not an end user run-time.

It seems that if code is buggy or there is a serious problem in
generating or parsing the request stream, that more than one
error of this type might occur. If we take this to its ultimate
conclusion, we could get carried away with a very sophisticated
error reporting scheme, listing all errors that coccured and where
in the request stream they occured. I don't think we want to do this,
so I'd just settle for "Syntax error" and leave it at that.

Sections 2.3 and 2.4: Same comments as above.

Section 2.5:  The sentence "An unsupported attribute is either
one that is not in the Model document or that is in the Model document
but is not required to be supported" is troublesome. One could argue
from this sentence that a supported attribute is therefore one that is
in the Model document and mandatory. Clearly this is not true.
Aren't implemented optional attributes "supported"?

Doesn't supported have to do with what I implement, not what is
in the document?  For example, I can implement my own attributes
as extensions to the standard, are these then unsupported according
to the rules stated here?  Also, using the logic implied by the sentence
in 2.5, if I implement an optional attribute, even though it is in the model
document, it is unsupported. Is that what you mean?

Section 2.6: I'm somewhat concerned over the statement made in
this section that validation depends upon the specification of the
attribute. We ought to strive for a common rule, it would make
the model much cleaner and I would expect therefore the
processing would be simpler. Certainly there would be fewer
opportunities for misreading or misinterpreting the spec.

Section 4.1: What does the comment "after copies-collated-supported"
gets removed mean?  I know Bob had argued against this in the past,
but we lose an important attribute of some devices if we take this out.

Section 4.2: attributes-natural-languages seems to be the ONLY
attribute in this entire set that has a different rule. Why?  I don't
understand the reasoning behind this. If the Printer supports
French only, and I send it English text attributes, is that okay?

on the other hand, job-name and document-name say that any
correct value is "supported", but that the server should reject
unsupported values. These two things seem contradictory. How
do I get an unsupported value to reject??? Why would this case
be different from attribute-natural-language which has the same
rule for defining which values are supported?

Section 4.3: Which-document-format attribute name does not
match the model document, which lists this simply as
document-format.  If the client says "Give me the following printer
attributes for document-format=IPDS and the printer doesn't
support IPDS, why is the rule accept and ignore?  What does
ignore mean - not respond? Send back the listed attributes for
some other (maybe the default) document-format? Either of these
would be incorrect as far as the client was concerned.

This comment applies to which-jobs and my-jobs as well.  If I
say send me job attributes for "queued", which is not a valid
value, the paper suggests that the printer accept and ignore.
Again, what does this mean? Do I respond with "completed"
jobs instead?  Not respond at all? Seems very strange to me!

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

---

From: Tom Hastings <[email-masked]>
Date: Thu, 20 Nov 1997 16:53:34 PST

Roger,

Thanks for making these comments.  See replies below.  We'll incorporate
them into the updated version that we were assigned as an action item
at the 11/19 telecon.

Tom

>the work done by Tom, Bob and Scott to clarify the handling of

Thanks

>Sections 2.3 and 2.4: Same comments as above.

Good point.  We agreed on the telcon yesterday to combine
'client-error-keyword-or-value-too-long' with
'client-error-wrong-length-value' into
'client-error-incorrect-length'.  So your suggestion is to combine
all of the developer errors into one: 'client-error-syntax-error'.

So your suggestion is to go even further and fold
'client-error-keyword-or-value-too-long',
'client-error-wrong-length-value',
'client-error-attributes-groups-out-of-order', and
'client-error-missing-required-operation-attributes' 
into one error:  'client-error-syntax-error'.

Sounds good to me.

>document, it is unsupported. Is that what you mean?

Good point.  We were trying to indicate that "unsupported" covered 
several situations, but we didn't do a very good job.

The easied fix is just to delete the incorrect definition of "unsupported":

  An unsupported attribute is either one that is not in the Model document 
  or that is in the Model document but is not required to be supported.

>opportunities for misreading or misinterpreting the spec.

While I agree that it would be better to have a consistent rule,
when we did the analysis, we couldn't come up with such a rule.

There are some attributes, such as "attributes-char-set", that the
recipient cannot just ignore an unsupported value.  The recipient cannot
do anything with a value that it doesn't understand.  If I send you
'text' and 'name' attributes in ShiftJIS and you do not understand
that charset, you will not be able to do what I ask.  Same for
"document-format".  If you are a PCL printer and I send you a PostScript
document, it doesn't do me any good for you to ignore my values and
print it as PCL.

On the other hand, if I ask you for just my jobs, but you can only return
all jobs, it isn't too bad if you return all jobs and tell me that you
are ignoring the "my-jobs" attribute.  It seems better than returning
an error and not returing any jobs.  I can either ignore your entire
response or present all of the results to my user.

Same with "attribute-natural-language".  If I tell you that my name is
in Navajo and I would like your messages to be in Navajo, but you don't
support Navajo, I'd rather get messages in your default language and
still be able to print, than having the request rejected completely.
(as long as you support the charset that I use).

>but we lose an important attribute of some devices if we take this out.

We need to discuss this.  The statement is because the validation of
copies is against either the "copies-supported" or the
"copies-collated-supported" attribute, depending on whether documents are
being collated
with a job (A, B, A, B, ... vs. A, A, ... B, B, ...) or not.  So for
this one case, the validation algorightm is not just compare "xxx" with
"xxx-supported".

But we need to talk, since the "copies-collated-supported" is probably talking
about collating sheets within a single document copy using an output bin
collator, not collating document copies within a job.  We can see that the 
number of copies that an output bing collator has, might place an upperbound 
on the number of collated copies.  But, since IPP doesn't currently have an 
attribute for controlling collation of sheets within a document copy, we 
wonder whether we really need "copies-collated-supported"?

Lets discuss off-line and bring in something for the WG Last call.

>French only, and I send it English text attributes, is that okay?

Yes is it ok.  Either you may understand French too in order to read the
messages that I return, or the status codes that come back are sufficient 
for you to understand, since your client has to localize the status codes 
to French anyway.

Also, we need to improve the presentation, since you are mis-lead by it
into thinking that attributes-natural-languages is the only "forgiving"
attribute.  The following attributes are also "forgiving", in that the
Printer MUST ignore values it doesn't support:

Forgiving attributes:
4.2:
"attributes-natural-language"
"requested-attributes"

4.3:
"document-natural-language"
"job-k-octets"
"job-impressions"
"job-media-sheets"
"message"
"which-document-format"
"which-jobs"
"my-jobs"
any unknown attributes

Unforgiving attributes:
4.2:
"attributes-charset"
"document-uri"
"job-id"
"document-format"
4.3:
"compression"

So we have 5 unforgiving attributes vs. 11 forgiving attributes.

I don't see a way to come up with a single way to handle them
without making them all unforgiving or to add "ipp-attriute-fidelity"
control to the 11 forgiving ones (which is added complexity).  But the 
5 unforgiving ones MUST always be unforgiving.

>rule for defining which values are supported?

To make the table simple, we lumped bad syntax in with unsupported.
So a "job-name" that was too long or the wrong attribute syntax, was
lumped into "unsupported".  That is too confusing, so we'll change
the table.  In fact, it was so confusing, that I erroneously changed
"attributes-natural-language" from reject to accept always. The entry
should have been "reject", and yet we really want to indicate that
"attributes-natural-langauge" is one of the forgiving operation attributes
that SHALL accept any (syntactically legal) value, whether supported or not.

>document-format.  

True.  We had meant to suggest that the Get-Attributes (on a Printer)
change the name of the "document-format" operation attribute to
"which-document-format", to follow the principle that we ageed on the
IPP 11/19 telecon, that we can't use the same name for an Operation
attribute that is different in semantics from the Job Template attribute.

>If the client says "Give me the following printer

We suggest that the Printer does return the attributes for the
default printer and also return the "which-document-format" attribute
that is being ignored with its value.  So the client gets the warning
"successful-ok-ignored-or-substituted-attributes" status code.

ISSUE:  Perhaps this is a debatable point.  The alternative would be
to change the "which-document-attribute" into an unforgiving Operation
attribute, so that it would reject the requeset for an unsupported
value of the "which-document-format".  The client must then query
the printer and try again, or leave out the "which-document-attribute"
and get the Printer's default document-format.

The current Model document is silent on what to return when the
"document-format" requested is not supported, though it hints that
the Printer would return for the default document format in the second
paragraph of 3.2.5.1 "document-format".

We are suggesting the principle that for attributes that the client
need not supply, so that the IPP object uses a default, that the
IPP object use that same default for forgiving attributes when the
supplied value is unsupported.  This helps interworking with future minor 
versions that add additional values to forgiving Operation attributes.

>jobs instead?  Not respond at all? Seems very strange to me!

When an IPP object ignores an attribute it behaves as if the attribute
had NOT been supplied, i.e., the IPP object uses its default behavior.
Section 3.2.6.2 says if the client omits the "which-jobs" attribute, the
Printer SHALL assume 'not-completed'.  So we are proposing to extend that
behavior to an unsupported value.

---

From: Tom Hastings <[email-masked]>
Date: Mon, 24 Nov 1997 11:46:51 PST

>the work done by Tom, Bob and Scott to clarify the handling of

snip...

>would be incorrect as far as the client was concerned.

After thinking about this some more, I'd like to make the following
proposal:

1. Rename "document-format" to "which-document-format" as agreed to on
the 11/19 telecon, not to use the same name for an Operation attribute
as for a Job Template attribute when the semantics are different.

2. Clarify that the "which-document-format" Operation attribute is
MANDATORY for a Printer object to support (so clients can always supply).

3. Clarify that the Printer object SHALL return the
'client-error-document-format-not-supported' status code, if the supplied
document format is
not supported (so that the client isn't mislead).

4. Continue recommending that a client SHOULD supply it, else they get
the results for the Printer's default which may be 'application/octet-stream'
which is the "or" of the supported values of the several document formats 
that are auto-sensed.

5. Change what support of the "which-document-format" means.  Instead of
requiring Printer objects to validate only for the specified document
format, which not many current system do, require the Printer object
to return the supported values that correspond to the validation that it
performs on the create operations:

  If the Printer validates according to the document-format supplied in
  the create, then the Printer SHALL also return values that are applicable
  only to the document format requested in the Get-Attributes operation.

  However, if the Printer oject is not that sophiscated (most aren't yet),
then
  the Printer returns the attributes for the union of document formats that
  it supports.

In other words, if a client queries the Printer, the client can find
all values that the Printer will accept in a create operation with
"ipp-attribte-fidelity" 'true' when the client supplies the same 
"document-format" value in the create as it supplies in the 
"which-document-format" in the Get-Attributes operation.

snip...

Tom