I would prefer a more static approach to the directory service
attributes for IPP. Use the directory service to get a relatively
good approximation for the type of printing service you want, then
communicate directly with the service for any other really
dynamic information like "media currently installed" or "fonts
currently available" etc.
Randy
rdebry@us.ibm.com wrote:
>
> Classification:
> Prologue:
> Epilogue: Roger K deBry
> Senior Techncial Staff Member
> Architecture and Technology
> IBM Printing Systems
> email: rdebry@us.ibm.com
> phone: 1-303-772-2479
>
> Response to Scott ...
> ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/23/97 07:01
> AM ---------------------------
>
> Scott_Isaacson @ novell.com
> 01/22/97 07:30 PM
>
> > 1) Is the cost per page tied to the media it is printed on?
> > Do we define some standard for determining the cost
> > of a page.
> >
> > answer: I believe that we need to allow the people setting
> > up and running IPP printers to decide how they want to
> > charge for printing, and be able to show an end user
> > what the cost per page is. This will certainly depend on
> > media, but may also depend on use of color, and other
> > printer options.
>
> SAI> Do you envision a "cost-per-page" attribute that is set to some
> SAI> value like "$0.32" or some set of attributes that are queried and
> SAI> evaluated and some cost per page number is generated?
> SAI> If you envision the later then I say that this is beyond the scope
> SAI> of IPP
>
> RKD> I envision a cost-per-page attribute that is set when printer
> RKD is configured.
>
> > 2) Is information that is as variable as media-ready stored
> > in the name service?
> >
> >
> > answer: The name service needs to be able to tell a user that
> > a printer is normally set up to print on various media, such as
> > transparencies. If a printer has three input trays and one of
> > those trays is supposed to have tranparencies in it, then I should
> > put this in the name-service to help users find a printer that prints
> > transparencies. However, the name service probably should not
> > be updated everytime the transparency tray empties, or if a rogue
> > user swaps the transparency tray for another media type.
>
> SAI> I agree that the name service should NOT have relatively dynamic
> SAI> attributes. media-ready should not be in the directory. However,
> SAI> I don't agree that we should put what a tray is supposed to have
> SAI> in the directory. What is a standard letter tray supposed to have?
> SAI> All media types that fit letter size???
>
> RKD> If you don't do this, how can I ask the question "Can I print
> RKD> tranparencies on this printer?" On the shared printers we use
> RKD> around here one tray is often set up with transparencies in it.
> RKD> It would be nice if I knew at least that an adminsitrator/operator
> RKD> had configured the printer this way. Otherwise, my only recourse
> RKD> is to walk down the hallway and look at the printer.
>
> > 5) How do you determine the notification methods supported
> > by the printer? What is the set of notification methods
> > for IPP?
> >
> > answer: We need a "notification-methods" attribute.
>
> <SAI> I disagree. I thought that we decided the methods would be
> <SAI> embedded in the URL scheme: mailto:..., http:...., etc.
>
> RKD> Scott, I don't understand your answer. Could you clarify.
-- Randy Turner