Directory Entry Schema

Directory Entry Schema

Directory Entry Schema

rdebry at us1.ibm.com rdebry at us1.ibm.com
Tue Nov 19 11:08:10 EST 1996


Classification:
Prologue:
Epilogue:


---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/19/96 08:37
AM ---------------------------


        ipp-owner @ pwg.org
        11/18/96 09:46 PM




To: ipp @ pwg.org at internet
cc:
Subject: Directory Entry Schema


>>Keith Carter and I met and we want to run the following issues by the
>>team:


>>We want to have a Location attribute. We propose that this should be a "
>>a free form string that can contain any site specific location information."
>>How should filtered searches work on values of this attribute?


Scott, I assume that you are talking about adding the existing printer location
attribute (section 6.4.2) to the directory schema, not inventing a new
attribute.
Perhaps we could recommend that attribute values, although being free-form text,
be written as dotted values, e.g. Provo.Building3.floor2, that way installation
specific filtering (e.g. find all printers in building3) could perhaps be done
more easily.


>>We want to introduce a new attribute callled Print Quality. "This indicates
>>a somewhat subjective evaluation of the overall printing quality: "high",
>>"medium", or "low"  "  ISSUE:  Does this subsume the need for Resolution
>>and Speed?


Again I assume that you are adding the existing print qualities supported
attribute to the directory schema, not inventing a new attribute. I think
that quality is an attribute that can often be orthogonal to speed and
resolution. For example, some printers reduce the qulaity by putting down
less toner while still printing at the same speed and resolution.


>>We want to introduce a new attribute called Cost.  "This indicates a
>>somewhat subjective evaluation of the overall cost of printing at this
>>printer: "high", "medium", or "low".   "  ISSUE: Is this a good thing or not?


This makes sense to me when in an intranet environment where controlling costs
would be important.  In an internet environment where I might be paying for a
print job at Kinkos, for example, I think we might want some alternative
schemes.
One idea might be to allow a print job to be sumbitted with a "bid" attribute.
The bid attribute says "don't print this, but tell me what it will cost to print
this job".


In an intranet environment would we want more granularity than high-medium-low?
For example, let an installation define the number of "chits" required to print
on any given printer, then put this number in the cost attribute. Thus if I had
a templare for printing color foils, it might cost 10 "chits", while printing
two-up on a high speed fanfold printer costs 1 "chit". Chits don't necesarily
have to relate to exact costs, but can provide a relative cost. We'd probably
want to associate these with templates, since cost is a funcntion of the media,
n-up, use of color, and so on.


>>We propose a Fonts Supported attribute which is the same as the
>>fonts-supported attribute in the Printer object.  ISSUE: Do you agree that
>>this should be in the directory entry.  Some studies have shown that
>>users want to search for printers based on this attribute.


Could there be some way of indicating some "standard" font sets rather than
enumerate the entire list in the printer (including fonts that could be
downloaded transparently from a server)? Would a lagre enterprise want to
have installation defined "sets"?


>>If we keep Maximum Speed should it be moved to "high, med low"??


>>We propose a P1284 Device ID not a plug and play Id -- the plug and play
>>id can be created from this.  ISSUE: Does this subsume the need for
Make, Model, and Type??


************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson at novell.com
W: http://www.novell.com
************************************************************



More information about the Ipp mailing list