Elliott,
Scenario 2 is indeed the same as Scenario 1, just with a more severe constraint. This is based on a real case and I recorded it before Ira's objection to using port 80. But indeed, at this site NOTHING got out of this enterprise except browser traffic though a proxy server... no DNS server communication , no NTP , no FTP, nada.
Having been though this at various places. Asking if they would allow a printer that talks to an external server, without adding more restrictions, will get a very quick NO. I agree that we need to collect more information, but some of the additional provisions that some pretty critical sites appear to accept are:
1. use of the browser infrastructure, including proxy support and (in some cases) authentication with, no firewall changes
2. use of encryption (in some cases) - non use of encryption (so that message can be monitored) in other cases
3. client contacts limited number of defined and checked out server sites
4. no Java, and limited remote programmability of the clients
5. the client (in the case of a proxy servicing multiple legacy printers) can only monitor predefined devices, as established at installation/configuration
6. naturally, confidence in the company that has the external server.
7. no communication of IP addresses, any network characteristics, names, etc
8. no modification of any parameter that will affect operation of the imaging device (although a disable by the owner of the device was accepted, but only with authentication/ encryption)
I am inclined to agree to "not start with a fundamental requirement that everything Printer MIB can do can also be done
by WBMM." But I suspect that others will demand this, and go beyond it. That brings up the idea of unalterable levels of accessibility which, I think, must be feature.
I suspect that much of the contention on semantics is a question of ....semantics.. English type. I think that this needs to be discussed and the proponents might want to be a little more illustrative in their requirement.
Hopefully, we can get some more comments in. The XMLCONF information that Lee referenced is interesting and has some stuff we should consider. But the basic premise is different. XMLCONF is MIS people configuring network infrastructure devices. WBMM is non enterprise people getting access to information on networked imaging devices. Among other things, the MIS people, who often do not have responsibility for the imaging devices anyway, are now potential antagonists rather than participants.
Bill Wagner
-----Original Message-----
From: ElliottBradshaw@oaktech.com [mailto:ElliottBradshaw@oaktech.com]
Sent: Wednesday, February 26, 2003 3:47 PM
To: Wagner,William
Cc: owner-wbmm@pwg.org; 'Wbmm (E-mail)
Subject: Re: WBMM> Scope and Starting Point Conference call
Bill,
I think your document is a good start. The scenarios are more or less
described at the right level for this discussion. I am confused, however,
about the difference between Scenarios 1 and 2. Aren't they both part of
the same story?
The firewall issue is, of course, critical. Whatever we do has to be
acceptable to the majority of IT groups, and we should test that. Maybe we
should each ask our local IT folks whether they would allow a printer that
automatically talks to an external server, and whether their answer depends
on the selection of port #, type of data traffic, etc. If we find major
resistance to the idea, then we should stop. This is the issue that drives
the HTTP questions, and I can't imagine any non-HTTP scheme that would be
acceptable.
With regard to SNMP compatibility, my sense is you have picked up on the
most useful scenarios for the the Printer MIB. I think WBMM should align
with Printer MIB wherever it makes sense, but I would not start with a
fundamental requirement that everything Printer MIB can do can also be done
by WBMM. We may end up re-implementing some pretty rarely used functions,
and we can always add them in later.
I'm not sure I follow the discussion of semantics, but we do want a scheme
that provides interoperability. That means we have to describe the actual
encoding of each operation. So, I think that does mean we do need to nail
the basic semantics. It seems reasonable to do this using SM, although
this is not a fundamental requirement if some other approach solves the
problem.
Control over allowed operations will be important. I can imagine an IT
department that allows alerts but not file transfers, and certainly not the
more operational actions like going on or offline, if we decide to include
them. We should treat this as a primary requirement, with questions of
granularity, grouping, etc. to come later.
See you (?) at the teleconference...
Elliott
------------------------------------------
Elliott Bradshaw
Director, Software Engineering
Oak Technology Imaging Group
781 638-7534
"Wagner,Willia
m" To: "'Wbmm (E-mail)" <wbmm@pwg.org>
<WWagner@NetSi cc:
licon.com> Subject: WBMM> Scope and Starting Point
Sent by: Conference call
owner-wbmm@pwg
.org
02/24/2003
03:06 PM
Greetings:
I have received several messages indicating that 4 March 4-5 PM EST (1-2
PST) would be a good time for a conference call. There were also some
suggestions that we establish a list of issues and try to get as many
issues a possible resolved before the conference call. There has been some
discussion of issues in the message I sent on Friday, and I solicit more
comments. I will come up with a preliminary list of issues with discussion
and an agenda later this week, and an updated agenda next Monday. Please
forward your concerns and issues to the list or to me for inclusion.
This is a simple telephone conference call. Parameters are:
Time: 4:00 PM 4 March 2003
Call-in US: 1-877-628-1350
Call-in International: 1-712-421-1160
Participant Identification number: 415259
Best regards,
Bill Wagner/NetSilicon, a Digi International Company
This archive was generated by hypermail 2b29 : Wed Feb 26 2003 - 18:37:24 EST