IPP>MOD - conformance

IPP>MOD - conformance

IPP>MOD - conformance

Bill Wagner bwagner at digprod.com
Wed Apr 9 14:23:47 EDT 1997

     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 <jkm at underscore.com> at Internet
Date:    4/9/97 1:46 PM


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


More information about the Ipp mailing list