IPP> Comments on MIB access document
Paul Moore <paulmo@microsoft.com> Fri, 17 July 1998 01:48 UTC
Delivery-Date: Thu, 16 Jul 1998 21:48:33 -0400
Return-Path: ipp-owner@pwg.org
Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA24961 for <ietf-archive@ietf.org>; Thu, 16 Jul 1998 21:48:32 -0400 (EDT)
Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA24188 for <ietf-archive@cnri.reston.va.us>; Thu, 16 Jul 1998 21:48:26 -0400 (EDT)
Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA29197 for <ietf-archive@cnri.reston.va.us>; Thu, 16 Jul 1998 21:48:07 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Jul 1998 21:40:36 -0400
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA28607 for ipp-outgoing; Thu, 16 Jul 1998 21:34:45 -0400 (EDT)
Message-ID: <CB6657D3A5E0D111A97700805FFE6587BF6EA5@red-msg-51.dns.microsoft.com>
From: Paul Moore <paulmo@microsoft.com>
To: "'ipp@pwg.org'" <ipp@pwg.org>
Subject: IPP> Comments on MIB access document
Date: Thu, 16 Jul 1998 18:34:27 -0700
X-Mailer: Internet Mail Service (5.5.2328.0)
Sender: owner-ipp@pwg.org
This document proposed many extremely significant changes to IPP. They are so radical that I do not thing that they can be accepted simply as an optional extension to 1.0. Many of the issue it tries to solve are very valid - but this is not the right way to address them. 1. The current model is very strong on hiding the physical details of fanning out. The only thing exposed is a logical printer - the fact that this may represent multiple devices is deliberatly not exposed. This proposal turns this 180 degrees and explicitly exposes this. No comment on whether this is good or bad - I merely point out that this is a BIG change to slip in via an optional extension for accessing MIBs. Note that this is done for some non-MIB attributes as well. 2. The device is described as being an 'object'. This challenges the whole concept of an object in IPP. Everywhere else an Object can receive operations and has a URI; the device does neither. Having said that, a model that does expose 'devices' and 'objects' but that does not represent such a fundamental construct (device) as a object seems very strange. 3. This scheme introduces a structured namespace. No comment on whether this is good or bad - I merely point out that this is a BIG change from the flat list in the main model. 4. The printer MIB is given a special place in this scheme. What about the job mib or the finisher mib. 5. The MIB query is optional but is overloaded on the get attributes operation. I cannot find out if a printer supports it without trying and failing. Normally such big pieces of functionality would be a separate operation. 6. What is the relationship between the information I obtain via the MIb query and the data I obtain via the other queries? Will the result of querying the job mib be the same as the result of doing a getjobs? What about printer-status and the MIB status? 7. If I dont say what device I want it will go to the 'first' one. What does first mean? Is it guaranteed to be the same always? How do I support intelligent pools (If I send a PS file there is a choice of two printers, if I send PCL there is a choice of 4. Only 2 printers are available for large jobs, but if i send a small job there is a choice of 4). What should the device list return? What happens if a device is turned off? 8. You state that for non-printer MIB things you dont have to say what the device is because this is implicit in the OID. There is a level shift here. The devices enumerated by the proposed IPP device list is not the same as the device list in each printer. A printer will have a printer device, a disk, some RAM, etc. 9. You do not say what must happen if I send a valid query but the result is empty. I.e. read the alert table.
- IPP> Comments on MIB access document Paul Moore
- Re: IPP> Comments on MIB access document Tom Hastings
- RE: IPP> Comments on MIB access document Paul Moore