Subject: IPP>Apparent conflicts clarification

From: Brendan Galten <[email-masked]>
Date: Wed, 14 Jan 98 12:02:03 -0800

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

Thanks,
Brendan Galten

Brendan Galten
RBI Software Systems
510-204-9980
[email-masked]

---

From: Scott Isaacson <[email-masked]>
Date: Wed, 14 Jan 1998 16:50:38 -0700

>>> Brendan Galten <[email-masked]> 01/14 1:02 PM >>>
 
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.

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

>RBI Software Systems

************************************************************
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: [email-masked]
web: http://www.novell.com
************************************************************