Subject: IPP> MOD - Closure on status codes

From: [email-masked]
Date: Tue, 29 Apr 1997 09:19:10 -0500

The purpose of this note is to attain agreement on the documentation of
  status codes in the Model document.

  Based on the discussion at the MOD telecon on 4/25 and Bob Herriot's
  protocol document, I propose that the Model document describe status
  codes using generic terms (e.g. bad-request) instead of specific values
  (e.g. "400").  A protocol document can then use the descriptions of the
  status codes and map these descriptions to specific status code values
  and messages for a protocol like Bob did in his protocol document.  With
  this approach, protocol implementations of IPP should behave
  consistently.

  Here is an example of what we can put in the Model document:

  4.4.2.1 bad-request

  The request could not be understood by the IPP Printer due to
  malformed syntax.  The IPP application should not repeat the
  request without modifications.

  In the case of Bob's protocol document, bad-request maps to "400".

  If we agree, then I will modify my previous note on status codes and
  resend for your review.  If anyone has another idea, please put it on
  the table so we can close this matter.

  Thanks,

  Keith

---

From: Scott Isaacson <[email-masked]>
Date: Tue, 29 Apr 1997 09:09:44 -0600

I fully endorse Keith's suggestion to NOT put numeric codes in the Model
document and just use keywords which can then be mapped to codes in the
protocol document.   I hope we all agree on this so that Keith can do the
rewrite as he has proposed. 

I missed the last model telecon and I have not seen any minutes?  Did anyone
take minutes or plan to distribute them.

Scott

>>> <[email-masked]> 04/29 8:19 AM >>>

  4.4.2.1 bad-request

  Thanks,

  Keith

---

From: Patrick Powell <[email-masked]>
Date: Tue, 29 Apr 1997 17:12:09 -0700 (PDT)

I think that there is a fine dividing line between the notion of the
error code,  and details of the actual format of the error codes.
Having seen what happens when there is ambiguity,  I think that putting
the error codes and their meaning as close as possible to the model
is a good idea.  Note that this format/intent/meaning then becomes
'transportation protocol independent'.

Patrick Powell