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 <jkm at underscore.com> 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
--
Randy Turner
Network Architect
Sharp Laboratories of America
rturner at sharplabs.com