Subject: Re[2]: IPP>MOD - conformance

From: [email-masked] (Bill Wagner)
Date: Wed, 9 Apr 1997 14:23:47 -0400

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

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

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: Randy Turner <[email-masked]>
Date: Wed, 09 Apr 1997 14:10:08 -0700

>      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

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