Sorry that I could not participate in yesterday's call. I'd really like to
have some explanation (in terms of user scenarios) that help me to understand
the rationale behind these discussions. I have a few comments, which follow:
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/22/97 01:20
PM ---------------------------
ipp-owner @ pwg.org
01/22/97 01:09 PM
To: ipp @ pwg.org@internet
cc:
Subject: IPP> MOD - 1/21 Minutes
Scott Isaacson wrote:
We will introduce a new attribute called "associated-devices". This
will be a multi-valued attribute that can take on the "names" of associated
devices that may or may not speak IPP or associated server components
which may or may not speak IPP. The "names" of these associated
devices/printers/Printers can be from almost any name space. If they
speak IPP then they will be Printer object URLs which could then be used
as the target for IPP operations (such as getting the state of that Printer).
For other names, the values in this attribute are basically just string that
can be used (hopefully) using some other access protocol or service to
query that device directly. We will not get into the rat hole of trying to
define the access protocol for the name along with that name. An
example might be a server providing service behind a Printer object.
However, behind it (from the end user's point of view) are some network
attached printers. Then names in the "associated-devices" could be
enough information to use SNMP Printer MIB queries to get the device
state.
<<RKD>> If this is indeed required, which I am not personally convinced
<<RKD>> of, then I think that an administrator, when configuring the
<<RKD>> system, ought to be able to say that associated devices are
<<RKD>> truly invisible to the protocol! We set up groups of printers
<<RKD>> specifically to hide the individual printers from the end user.
<<RKD>> I'd like to allow this to continue to be so. Can someone paint
<<RKD>> me the scenario where an end user needs to know about associated
<<RKD>> devices?