IPP> DIR - Re: Compiled list of directory schema issues; Comments

IPP> DIR - Re: Compiled list of directory schema issues; Comments

IPP> DIR - Re: Compiled list of directory schema issues; Comments

Carl-Uno Manros cmanros at cp10.es.xerox.com
Wed Jan 29 20:31:42 EST 1997


Roger,


some comments on your comments.


Carl-Uno  CBM>


At 06:10 AM 1/27/97 PST, you wrote:
>Epilogue: Roger K deBry
>email: rdebry at us.ibm.com
>phone: 1-303-772-2479
>
>1) LDAP question:  Is it possible to use LDAP entries as an **example**?


CBM> I don't think so. We could produce a separate informational RFC though.


>2) Objective vs. Subjective attributes: Keith makes a good suggestion to
>     get customer input.  However, I'm on the side of objective attributes. I
>     personally find measures like "high", "medium", and "low" as useless.


CBM> I though originally that we could get away with some subjective 
CBM> attributes in directory, but thinking about the I18N impacts, I
CBM> think I am now leaning more towards only using objective ones.


>3)  Cost-per-page issue:   I believe that it is of utmost importance to put
>things
>      in the directory schema  that help an end user make a selection easily,
>      **without** requiring him or her to poll every printer that might be
>used!  If
>      we can't agree on the details then I think we absolutely need a
field in
>the
>      directory which is an unformatted user text string. Then as an
>administrator
>      I can put in things that will be useful to my users -- even if the
>architecture
>     doesn't provide what I need.  Then when I browse the directory, I
might get
>     something like "This is an expensive printer - only use it for final
>presentation
>     slides. Drafts should be done on printer xyz", or the like.


CBM> See my comment above. The I18N requirements however would seem to 
CBM> discourage the use of plain text, and if we want to give a price
CBM> per copy, we also need to add information about the currency.
>
>4) Media-ready issue: I agree, but can't seem to get any consensus on the
real
>     issue underlying this one which was what is the printer intended for.
>Every day
>     I use printers to do tranparencies. I may not be guaranteed that they
are
>loaded,
>     but I'd sure like to know which printers are set up, normally use
for, or
>established
>     by the operator to print them.  Maybe this is another example of the
need
>for a
>     free text entry to describe the printer.


CBM> I think we have beaten this one to death by now. I suggest that we
CBM> indicate what media you expect the printer to normally support.
CBM> Again, avoid free text. If free text, put it on a Web page (which might
CBM> have links to other language versions if required), and give the URL 
CBM> in the directory entry.


>6) Driver/Installer: I'd sure like to see something in the directory that
told
>me if there
>     was even a place to get drivers.  Let the Printer provide the
details, but
>let me
>     know that it is even a possibility when I am searching the directory!
>
>9) Security: We need the directory to say something about the security
>mechanisms
>     of the printer.  For example, if a printer requires all users to have a
>password or
>     to have an account set up prior to use, or to own a digital certificate,
>or ..., I'd like to
>    know that before I spend much time talking to the Printer. Maybe some
>configurations
>    won't even allow a user to query the Printer without passing some
security
>mechanism.
>


CBM> My earlier suggestion was to just indicate whether the printer can be
CBM> used without any security restrictions or not. If it uses ANY kind of
CBM> security, give a URL reference to a place where the required security
CBM> options are explained (I am sure that there are too many options for 
CBM> them to be listed in the directory).



---
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com




More information about the Ipp mailing list