Subject: IPP>MOD - conformance

From: Roger K Debry <[email-masked]>
Date: Wed, 9 Apr 1997 13:24:00 -0400

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

-----------
I've drafted a new section on conformance as it applies to attributes.
Comments please.....

IPP conforming implementations must do the following with respect to
attributes:

In response to a query (Get_Attributes or Get_jobs) an IPP Printer

- shall respond with all available supported values for each attribute
  if the attribute is supported by the Printer. Support for some attributes
  is mandatory. Available means that the Printer can actually determine what
  the attribute value is. For example, printer-state would be unavailable
  when a Printer is driving a legacy output device which has no capability
  of reporting its current state.

- shall respond with an empty value for each attribute that it recognizes,
   but which is unavailable.

         Issue: The notion of unavailable here is meant to handle cases
         where an IPP Printer is driving a legacy device which has no
         ability to report any information about itself upstream. Should
         there be an attribute value of "unavailable" to better indicate
         this condition?

- shall respond with an empty value for each attribute that it does not
   recognize.

        Issue: Should there be an attribute value of "unsupported" to
        better indicate this?

In response to a Print request, if the best-effort attribute is set to
substitute-as-needed, an IPP Printer

        Issue: The following assumes best-effort as currently defined
        in the model document.  best-effort would be a mandatory attribute.

- shall use the specified attribute value in the print operation if the
  attribute and the specified value are supported.

- shall ignore the attribute if the attribute is supported but the specificed
  value is not

        Issue: Should a return code indicate that the attribute was
        ignored because an unsupported  value was specified?

- shall ignore the attribute if the attribute is not supported.

        Issue: Should a return code indicate that the attribute was ignored
        because it is unsupported?

In response to a Print request, if the best-effort attribute is set to
do-not-substitute, an IPP Printer

- shall use the specified attribute value in the print operation if the
  attribute and the specified value are supported.

- shall reject the print job if the attribute is supported but the specified
  value is not.

        Issue: Should a return code indicate that the job was rejected
        because an unsupported attribute value was specified?

- shall reject the print job is the attribute is not supported.

        Issue: Should a return code indicate that the job was rejected
        because an unsupported attribute was specified?

Sending a Query or Print request, an IPP client need not specify any
attributes.

 Issue: Are there any attributes that are mandatory for a client to
 set in a Print request?

In response to a Query, an IPP client shall not fail for any attributes or
values for those attributes which are returned. The client need not use any
returned attributes in subsequent operations. IPP clients should provide a
means for displaying any returned attributes and values to an end user.

         Issue: Bob Herriot had suggested that the protocol should not
        say anything about what a client presents to an end user. If
        others agree, then perhaps this is just an implementation guideline.
        However, I think it is important to note.

---

From: JK Martin <[email-masked]>
Date: Wed, 9 Apr 1997 13:46:17 -0400 (EDT)

Roger,

>         However, I think it is important to note.

I agree with Bob.  Dictating, or even suggesting, how a client should
respond with the data it receives from a server should be considered
out-of-scope.  It's not even clear that it's worthy of being put in
an appendix of the spec, since the function of the client is completely
up to the designers.

Discussions of how a IPP client might be designed (and what the target
functionality could/should be) would be interesting on one of the PWG
mailing lists.  However, suggesting that a client should do this-and-that
with respect to IPP protocol responses is not a good idea, IMHO.

	...jay

---

From: JK Martin <[email-masked]>
Date: Thu, 10 Apr 1997 11:14:33 -0400 (EDT)

Randy,

You've expressed my position perfectly.  Many thanks.

	...jay

----- Begin Included Message -----

>From [email-masked] Wed Apr  9 17:23 EDT 1997
Date: Wed, 09 Apr 1997 14:10:08 -0700
From: Randy Turner <[email-masked]>
To: Bill Wagner <[email-masked]>
CC: [email-masked]
Subject: Re: IPP>MOD - conformance

Bill Wagner wrote:
> 
>      Although I agree with Jay and Bob in principle, it brings up an
>      interesting point.
> 
>      My understanding is that there are two phases of the IPP project which
>      may be sequential or concurrent. One is providing an internet printing
>      capability that does not require any modification of or addition to
>      extant clients. The other is providing a full featured IPP printing
>      capability; this appears to require a client activity. It is unclear
>      at the moment if these two phases are to be addressed in one pass, if
>      there is to be one standard or two, or if indeed the former phase
>      needs a formal standard.
> 
>      However, if one agrees that some aspect of IPP will need a custom
>      client, and if standards track requires compatibility demonstrations,
>      then the basic definition of a client that utilizes the features of
>      the protocol must be identified somewhere.

I think (hope) Jay meant to say that we shouldn't dictate how clients
translate IPP responses into end-user interaction. What we DO need to
absolutely spec is how clients deal with responses, operationally
speaking, whether exposed to the user or hidden in the internal
workings of the implementation.  Operational specification in this
context refers to the overall operational state of the client after
receiving protocol responses from a server. This is basically just
ensuring that both client and server can expect to be running the same
protocol state machine.

When I say translating IPP responses into user-interaction, we
shouldn't say statements like "When a error 301 is received to a
particular request, the client application should exit with a 301 error
code, removing any windows or UI controls that were created."

Basically we need to completely spec. out the interactions between
clients and servers, not with clients and end-users. I'm not sure about
"administrative framework" issues with regards to configuration of
servers. We may need to have a "Practical Considerations" section with
examples of how to do this, but my gut says that even this would be
purely informative and not a conformance issue with regards to IPP.

Randy

> 
>      Bill Wagner, DPI
> 
> ______________________________ Reply Separator _________________________________
> Subject: Re: IPP>MOD - conformance
> Author:  JK Martin <[email-masked]> at Internet
> Date:    4/9/97 1:46 PM
> 
> Roger,
> 

-- 
Randy Turner
Network Architect
Sharp Laboratories of America
[email-masked]

----- End Included Message -----