attachment-0001

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=699333914-24022003><FONT face=Arial color=#0000ff 
size=2>Harry,</FONT></SPAN></DIV>
<DIV><SPAN class=699333914-24022003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=699333914-24022003><FONT face=Arial color=#0000ff size=2>I 
appreciate the comments.</FONT></SPAN></DIV>
<DIV><SPAN class=699333914-24022003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=699333914-24022003><FONT face=Arial color=#0000ff size=2>1. I 
would not necessarily exclude "the rest", but I&nbsp;suggest that 
we&nbsp;optimize the approach for the kind of operations that would be&nbsp;most 
important to a remote extra-enterprise&nbsp;monitor. Further, there is the 
"turf" issue. One of&nbsp;the most critical&nbsp;requirements of whatever we 
come up with is that enterprises will accept it. The local management 
facility&nbsp;probably will&nbsp;have no objection to the extra-enterprise 
entity doing accurate billing, providing supplies "just-in-time" and showing up 
to fix a problem promptly. The local management facility will probably 
object&nbsp;if the extra-enterprise monitor changes setup, trashes jobs, or in 
any other way interferes with the local people doing their job. I agree that 
there are some cases when more extensive control is desirable (e.g., a rental 
company shutting off a machine because of non-payment, or the case where there 
is no local management). Perhaps we may need to define a "level of control" 
parameter that is set when the capability is installed, that cannot be changed 
remotely, and that limits what the monitor can do.</FONT></SPAN></DIV>
<DIV><SPAN class=699333914-24022003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=699333914-24022003><FONT size=2><FONT face=Arial 
color=#0000ff>2. Your desire to expand the scope to include&nbsp; the semantics 
for device management&nbsp; is noted. I believe that you also agreed that the 
capability must be compatible with the existing equipment base.&nbsp; If this is 
the consensus in the group, then I would suggest partitioning the 
effort,&nbsp;probably among&nbsp;transport, coding and 
semantics.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=699333914-24022003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=699333914-24022003><FONT face=Arial color=#0000ff size=2>3. I 
agree with&nbsp;your general position on alignment with similar activities. We 
need to get the sense of the group on this point.</FONT></SPAN></DIV>
<DIV><SPAN class=699333914-24022003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=699333914-24022003><FONT face=Arial color=#0000ff size=2>4. The 
ability to traverse the firewalls is inherent on the basic definition of the 
activity. Considering Ira's input on the CIM effort, I think the question will 
boil down to:</FONT></SPAN></DIV>
<DIV><SPAN class=699333914-24022003>&nbsp;&nbsp;&nbsp; <FONT face=Arial 
color=#0000ff size=2>a. do we get a port assigned and disallow the use of any 
other port?</FONT></SPAN></DIV>
<DIV><SPAN class=699333914-24022003>&nbsp;&nbsp;&nbsp; <FONT face=Arial 
color=#0000ff size=2>b. do we get a port assigned but still allow the use of 
Port 80</FONT></SPAN></DIV>
<DIV><SPAN class=699333914-24022003>&nbsp;&nbsp;&nbsp; <FONT face=Arial 
color=#0000ff size=2>c. do we remain silent on the port 
number?</FONT></SPAN></DIV>
<DIV><SPAN class=699333914-24022003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=699333914-24022003><FONT face=Arial color=#0000ff size=2>I will 
list considerations with the set of issues.</FONT></SPAN></DIV>
<DIV><SPAN class=699333914-24022003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=699333914-24022003><FONT face=Arial color=#0000ff size=2>Best 
regards,</FONT></SPAN></DIV>
<DIV><SPAN class=699333914-24022003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=699333914-24022003><FONT face=Arial color=#0000ff size=2>Bill 
Wagner</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<P><FONT face=Arial size=2>William A. Wagner (Bill Wagner)</FONT> <BR><FONT 
face=Arial size=2>Director of Technology</FONT> <BR><FONT face=Arial 
size=2>Imaging Division</FONT> <BR><FONT face=Arial size=2>NETsilicon, 
Inc.</FONT> <BR><FONT face=Arial size=2>781-398-4588</FONT> </P>
<BLOCKQUOTE>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Harry Lewis 
  [mailto:harryl@us.ibm.com]<BR><B>Sent:</B> Sunday, February 23, 2003 12:57 
  AM<BR><B>To:</B> Wagner,William<BR><B>Cc:</B> 'Wbmm 
  (E-mail)<BR><B>Subject:</B> RE: WBMM&gt; RE: Scope and Starting 
  Point<BR><BR></FONT></DIV><BR><FONT face=sans-serif size=2>1.a. - I agree... 
  but I have a feeling I'm reading more into ("etc.") than you may. You've 
  listed usage, alerts, diagnostics, configuration, downloading resources, 
  downloading executables (presumably diagnostic or interrogative in nature) and 
  upgrading (remotely)... there seems to be very little remaining that is done 
  via SNMP today... so why not include "the rest" ... like taking the device 
  off-line, reading or writing the OpPanel, ... "ETC...".?</FONT> <BR><FONT 
  face=sans-serif size=2>1. b. - Yes, I've expressed several times that I 
  believe we should address the semantics for device management - just as we've 
  recently done for job submission and &nbsp;management and we should 
  specifically try to clean up some of the toxic waste we spilled in the status 
  area during the early MIB days ("magic decoder ring", "agent orange" ).</FONT> 
  <BR><BR><FONT face=sans-serif size=2>2. I think we should make ourselves aware 
  of existing or emerging standards in the area. I don't think we should force 
  alignment or compliance unless we can clearly articulate the benefit and 
  honestly feel there is a very good chance that alignment will result in 
  adoption. While the Printer MIB is probably one of the most useful standards 
  ever in terms of heterogeneous printer management, most of the pretzel twists 
  we encountered to align with a larger cause never really achieved the hoped 
  for result (my opinion). </FONT><BR><BR><FONT face=sans-serif size=2>I feel we 
  should leverage our own positive model and experience with the semantic model. 
  No one questions whether SM is the right thing to do. The SM springboards from 
  our most recent job protocol... IPP into the web environment and does 
  facilitate firewall scenarios I view WBMM as doing the same thing... 
  springboard off Printer, Finisher MIBs onto web protocols via a common 
  (device) semantic model. </FONT><BR><BR><FONT face=sans-serif size=2>3. We 
  need to nail this firewall discussion early. I do agree that we want to 
  facilitate solutions that can cross the firewall... similar to the way we've 
  done PSI. I hear others reacting to this requirement as if it is an 
  inappropriate goal. This will drag on and haunt us later if not put to rest. 
  &nbsp; </FONT><BR><BR><FONT face=sans-serif 
  size=2>---------------------------------------------- <BR>Harry Lewis <BR>IBM 
  Printing Systems <BR>---------------------------------------------- 
  </FONT><BR><BR><BR>
  <TABLE width="100%">
    <TBODY>
    <TR vAlign=top>
      <TD>
      <TD><FONT face=sans-serif size=1><B>"Wagner,William" 
        &lt;WWagner@NetSilicon.com&gt;</B></FONT> <BR><FONT face=sans-serif 
        size=1>Sent by: owner-wbmm@pwg.org</FONT> 
        <P><FONT face=sans-serif size=1>02/20/2003 03:03 PM</FONT> </P>
      <TD><FONT face=Arial size=1>&nbsp; &nbsp; &nbsp; &nbsp; </FONT><BR><FONT 
        face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; 
        &nbsp; &nbsp;"'Wbmm (E-mail)" &lt;wbmm@pwg.org&gt;</FONT> <BR><FONT 
        face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; 
        &nbsp; &nbsp;</FONT> <BR><FONT face=sans-serif size=1>&nbsp; &nbsp; 
        &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: WBMM&gt; RE: Scope 
        and Starting Point</FONT></TR></TBODY></TABLE><BR><BR><BR><FONT 
  size=2><TT><BR><BR>Bob Tailor had a very good suggestion. &nbsp;"..try to 
  identify the issues before [the conference call]<BR>so you might ask that 
  everyone post them to WBMM before the meeting. For "simple" issues, we may be 
  able to knock them off in email, saving our phone time for the more 
  significant/contentious issues."<BR><BR>I had intended that sort of thing in 
  asking for comments on the write-up (or any other comments that were felt to 
  be germane). But an explicit request may be more fruitful.<BR><BR>Please 
  forward your issues to the list!<BR><BR>Lets start with a few that I 
  see.<BR><BR>1. Basic purpose: I have defined it as access by an external agent 
  to imaging devices on an enterprise network, for the purpose of monitoring 
  usage and alerts, perhaps for doing maintenance tests and general 
  configuration, and perhaps for downloading files including executables, fonts, 
  upgrades, etc.<BR>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; a. 
  Do we have agreement on this?<BR>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; b. Is there a strong feeing that the scope must be expanded, and 
  if so, how?<BR><BR>2. Consideration of the approaches in the documents 
  referenced by Ira, Lee &nbsp;and Don (thank you all). Should we embrace, 
  ignore, or possibly extract some aspects from which ones?<BR>&nbsp;My 
  contention is:<BR>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; a. 
  as overall approaches, all seem to lack the concept of finessing 
  firewalls<BR>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; b. 
  approaches intended for managing/configuring networks miss the problems of an 
  external agent trying to manage devices on the network. The MIS people want 
  some inherent restrictions on what the external site can do, and in many 
  cases, want to be able to monitor messages being sent out to make sure that 
  there is nothing untoward.<BR>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; c. we may however, want to consider some other aspects of the other 
  approaches. Perhaps the coding or the notion of XML coded RPCs.<BR><BR>3. Is 
  there general agreement on the use of HTTP clients operating in a Browser-like 
  mode as the mechanism to finesse firewall?<BR><BR>Please feel free to add 
  issues!<BR><BR>Many thanks,<BR><BR>Bill 
  Wagner/NetSilicon<BR><BR><BR><BR>-----Original Message-----<BR>From: 
  TAYLOR,BOB (HP-Vancouver,ex1) [mailto:bobt@hp.com]<BR>Sent: Thursday, February 
  20, 2003 3:49 PM<BR>To: Wagner,William<BR>Subject: FW: WBMM&gt; RE: Scope and 
  Starting Point<BR><BR><BR>3/4 4-5 EST works for me. &nbsp;One suggestion: 
  Given that you only are<BR>allocating one hour, it might be good to try to 
  identify the issues before<BR>then, so you might ask that everyone post them 
  to WBMM before the meeting.<BR>For "simple" issues, we may be able to knock 
  them off in email, saving our<BR>phone time for the more 
  significant/contentious issues.<BR><BR>bt<BR><BR>-----Original 
  Message-----<BR>From: Wagner,William [mailto:WWagner@NetSilicon.com]<BR>Sent: 
  Wednesday, February 19, 2003 6:11 PM<BR>To: wbmm@pwg.org<BR>Subject: WBMM&gt; 
  RE: Scope and Starting Point<BR><BR><BR><BR><BR>Greetings:<BR><BR>I have 
  attached some thoughts on the use cases the WBMM should be<BR>addressing, and 
  taken a cut at defining a starting point. &nbsp;The document is<BR>posted 
  to:<BR>ftp://ftp.pwg.org/pub/pwg/wbmm/white/wbmm_Scope&amp;Start.pdf<BR><BR>I 
  would appreciate some feedback with the objective of finding common 
  ground<BR>within the working group. Would a conference &nbsp;call on 4 March, 
  4-5 PM EST be<BR>agreeable?<BR><BR><BR><BR>Bill 
Wagner<BR></TT></FONT><BR></BLOCKQUOTE></BODY></HTML>