IPP Mail Archive: Re: IPP>Apparent conflicts clarification

Re: IPP>Apparent conflicts clarification

Scott Isaacson (SISAACSON@novell.com)
Wed, 14 Jan 1998 16:50:38 -0700

>>> Brendan Galten <bgalten@rbi.com> 01/14 1:02 PM >>>
> There are a couple of items that I was hoping somebody could clarify for
> me. The first is an apparent conflict between the protocol and model
> documents. Here is a synopsis:
> On page 133 of the model document, in section 15.3.3.1 is the
> paragraph:
>
> "If an IPP object receives a request with (1) required
> attribute groups missing, or
> (2) the attributes groups are out of order, or (3) the groups
> are repeated, the IPP
> object REJECTS the request and RETURNS the
> 'client-error-bad-request' status code."
>
> However, the protocol document states on page 5 that:
>
> A receiver of a request SHALL be able to process as equivalent
> empty attribute
> groups:
>
> a) an xxx-attributes-tag with an empty
>xxx-attribute-sequence,
>
> b) an expected but missing xxx-attributes-tag.
>
>
>Perhaps I am not reading the documents correctly, but case "b" in the
>protocol rule appears to conflict with case "1" in the model rule.
>Please let me know if and how I am interpreting this incorrectly.

Notice that case 1) in the Model Document describes a "required" (or
expected) group that is missing. A required group coming from the client is
one that contains a MANDATORY (for a client to supply) attribute. The
protocol document defines what "missing" means: it is either case a) (a
tag but no attributes) or b) (no tag and therefore no attributes). So, in
either case if a required group (a group containing a MANDATORY to supply
attribute) is missing (not there at all or there but empty) then a
'client-error-bad-request' status code is returned. I don't see a conflict.

> Also, on page 130 of the model document note 3 states:
>
> "The Unsupported Attributes Group is present only if the client
>included some
> Operation and/or Job Template attributes that the printer
>doesn't support whether
> a success or an error return."

>It would seem that the "error return" case would contain either 0 or a
>subset of all Unsupported Attributes. Either an error case can occur
>before any or all Unsupported Attributes were found. The question is, is
>there any significance to the Unsupported Attributes list that is
>returned given that the list could be incomplete? Should the only
>attribute in the list be the offending attribute, if found? If an
>unrecoverable error occurred then there is no way to complete the list.
>Perhaps, if my thinking is correct, note 3 could exclude Unsupported
>Attributes in the error case.
> Again please let me know if my understanding of the document is
>correct. Any help would be appreciated.

If the response status code is any error other than
'client-error-attributes-or-values-not-supported', then the requester can
assume that the IPP object did not get to processing Job Template attributes
against what is supported and so a subsequent request that fixed any other
problem might still have one or more unsupported attributes. If the
response is 'client-error-attributes-or-values-not-supported', the client
can still only be sure that the returned list of unsupported attributes is
only some not necessarily all unsupported attributes. We used to have a
statement like "if any unsupported attribute is returned then all SHOULD be
returned", but we never had a SHALL. I think that now, that statement is
not explicit but is actually embodied in the steps outlined in section 15.3.
If the response status code is one of the "successful status-ok-but-xxx"
cases, the list of unsupported attributes can be assumed to be the full set
since the successful status code indicates that all validation and all
checks have been done and the IPP object thinks that it can do what it is
being asked to do. There still might be errors, but they would not affect
what is or is not supported.

Short answer: a list of unsupported attributes returned (on an error status
code) is not guaranteed to be the full set of unsupported attributes.

> Thanks,
>Brendan Galten
>
>Brendan Galten
>RBI Software Systems
>510-204-9980
>bgalten@rbi.com

************************************************************
Scott A. Isaacson
Corporate Architect
Novell Inc., M/S PRV-C-121
122 E 1700 S, Provo, UT 84606
voice: (801) 861-7366, (800) 453-1267 x17366
fax: (801) 861-2517
email: sisaacson@novell.com
web: http://www.novell.com
************************************************************