Randy,
You've expressed my position perfectly. Many thanks.
...jay
----- Begin Included Message -----
Date: Wed, 09 Apr 1997 14:10:08 -0700
From: Randy Turner <rturner at sharplabs.com>
To: Bill Wagner <bwagner at digprod.com>
CC: ipp at pwg.org
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 <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
----- End Included Message -----