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
At 08:21 11/20/1997 PST, Roger K Debry wrote:
>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.
Thanks
>>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.
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.
>>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?
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.
>>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.
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).
>>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.
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.
>>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?
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.
>>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?
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.
>>Section 4.3: Which-document-format attribute name does not
>match the model document, which lists this simply as
>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
>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.
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.
>>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!
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.
>>>>Roger K deBry
>Senior Technical Staff Member
>Architecture and Technology
>IBM Printing Systems
>email: rdebry at us.ibm.com>phone: 1-303-924-4080
>>