attachment

<!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.2800.1400" name=GENERATOR> <STYLE>@font-face { font-family: Tahoma; } @font-face { font-family: Impact; } @font-face { font-family: XeroxPeopleNet; } @font-face { font-family: sans-serif; } @page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P.MsoPlainText { FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New" } LI.MsoPlainText { FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New" } DIV.MsoPlainText { FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New" } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: "Times New Roman" } SPAN.EmailStyle18 { COLOR: navy; FONT-FAMILY: Arial } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=EN-US vLink=purple link=blue> <DIV>I agree with Harry and Pete on most things, and I will admit to not following how your argument below applies  to their objections (nor, indeed, many of your other undoubtedly logical relationships)</DIV> <DIV> </DIV> <DIV>Although having everything follow a grand scheme is desirable, the effect appears to introduce so much interdependency that everything requires that everything else be done, thereby defeating the ability to complete anything. Since PSI deals only with printers but needs alerts  done, why can it define just printer alerts (and perhaps general alerts)? Alerts for WIMS would be the combination of printer alerts, scanner alerts, fax alerts, resource alerts etc, as these become defined. Dropping the register for alerts capability because the only alerts we can currently support are printer related seems undesirable.</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>With respect to  "Does WIMS WG accept the need to model Resource?",  it is unclear to  me what other group  would do this. Although I would not put this on high priority, I would prefer not to loose Resource.  Again, since we may not at this time fully understand all the aspects of Resource,  can we not work with a skeleton model, filling it out later?</DIV> <DIV> </DIV> <DIV>I  understand the notion that the current semantic model is only for printers, and that elements belonging to  a non-printer part of an MFP  need to be in some other part of the semantic model. As such, forcing them into WIMS at this time may upset the future logical model if it cannot be remove from WIMS in favor of a reference to a more general semantic model at a later time.</DIV> <DIV> </DIV> <DIV>Indeed, the compromise forcing these cuts was in response to the understanding that we needed your skeleton imaging device model  filled out before we could use it, and that it was unclear when (and if) that would be done. But it seems that we need some interim way of handling references, realizing that they may change in  detail and completeness.</DIV> <DIV> </DIV> <DIV>Anyway, it would seem that, insofar as the schema are informational adjuncts to the spec, the changes you identify must also be reflected in the spec. I would, however, like to wait until the smoke clears before making those changes.</DIV> <DIV> </DIV> <DIV>Thanks for your continuing efforts.</DIV> <DIV> </DIV> <DIV>Bill Wagner</DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <DIV class=OutlookMessageHeader dir=ltr align=left> -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Wednesday, June 02, 2004 4:20 PM To: 'Zehler, Peter'; McDonald, Ira Cc: 'wbmm@pwg.org'; Wagner,William Subject: RE: WBMM> Re: Need quick decisions on schema changes </DIV> <DIV>Hi,</DIV> <DIV> </DIV> <DIV>For PSI to advance, the Events spec (psievents10) and the Events</DIV> <DIV>schema MUST be formally approved for addition to the next version</DIV> <DIV>of the Semantic Model.</DIV> <DIV> </DIV> <DIV>Because there is no such thing as a Resource or a _Subscription_</DIV> <DIV>defined in any standards-track IETF or PWG approved spec,</DIV> <DIV>there CANNOT be any Resource operations or events in WIMS.</DIV> <DIV> </DIV> <DIV>And more cogently, there CANNOT be any Subscription object</DIV> <DIV>defined in the Alert schema (so there is no source for the element</DIV> <DIV>bindings of most Alert types).  So RegisterForAlerts doesn't work.</DIV> <DIV> </DIV> <DIV>This just gets worse...</DIV> <DIV>----</DIV> <DIV> </DIV> <DIV>The PWG Semantic Model element PrinterOperationsSupported</DIV> <DIV>ONLY contains the base IPP/1.1 operations.  There is no obvious</DIV> <DIV>way that it could easily be extended to cover all PSI operations,</DIV> <DIV>WIMS operations, etc.</DIV> <DIV> </DIV> <DIV>And arguably, the PWG SM/1.0 Printer object should NOT be</DIV> <DIV>the source of any WIMS connection.  The abstract System or</DIV> <DIV>Service object in front of Printer should start WIMS connections.</DIV> <DIV> </DIV> <DIV>Near-term the WIMS Agent should NOT be conflated with Printer.</DIV> <DIV>----</DIV> <DIV>Cheers,</DIV> <DIV>- Ira</DIV> <DIV> </DIV> Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221  Grand Marais, MI  49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com <DIV class=OutlookMessageHeader dir=ltr align=left>-----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Wednesday, June 02, 2004 2:36 PM To: McDonald, Ira Cc: 'wbmm@pwg.org'; 'Wagner,William' Subject: RE: WBMM> Re: Need quick decisions on schema changes </DIV> <DIV class=Section1> Ira, Harry covered my views.  My inserts are only on 7 & 8.   <DIV> Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice:    (585) 265-8755 FAX:      (585) 422-7961 US Mail: Peter Zehler               Xerox Corp.               800 Phillips Rd.               M/S 128-25E               Webster NY, 14580-9701 </DIV>   -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Wednesday, June 02, 2004 1:57 PM To: McDonald, Ira Cc: 'wbmm@pwg.org'; 'Wagner,William' Subject: WBMM> Re: Need quick decisions on schema changes   Inserted... ---------------------------------------------- Harry Lewis Chairman - IEEE-ISTO Printer Working Group http://www.pwg.org IBM Printing Systems http://www.ibm.com/printers 303-924-5337 ---------------------------------------------- <TABLE class=MsoNormalTable style="MARGIN-LEFT: 0.5in; WIDTH: 100%" cellPadding=0 width="100%" border=0> <TBODY> <TR> <TD style="PADDING-RIGHT: 0.75pt; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; WIDTH: 39.98%; PADDING-TOP: 0.75pt" vAlign=top width="39%"> "McDonald, Ira" <imcdonald@sharplabs.com> 06/02/2004 11:47 AM </TD> <TD style="PADDING-RIGHT: 0.75pt; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; WIDTH: 58.98%; PADDING-TOP: 0.75pt" vAlign=top width="58%"> <TABLE class=MsoNormalTable style="WIDTH: 100%" cellPadding=0 width="100%" border=0> <TBODY> <TR> <TD style="PADDING-RIGHT: 0.75pt; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; PADDING-TOP: 0.75pt"> To</TD> <TD style="PADDING-RIGHT: 0.75pt; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; PADDING-TOP: 0.75pt" vAlign=top> "'wbmm@pwg.org'" <wbmm@pwg.org> </TD></TR> <TR> <TD style="PADDING-RIGHT: 0.75pt; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; PADDING-TOP: 0.75pt"> cc</TD> <TD style="PADDING-RIGHT: 0.75pt; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; PADDING-TOP: 0.75pt" vAlign=top> "'Wagner,William'" <WWagner@NetSilicon.com>, Harry Lewis/Boulder/IBM@IBMUS </TD></TR> <TR> <TD style="PADDING-RIGHT: 0.75pt; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; PADDING-TOP: 0.75pt"> Subject</TD> <TD style="PADDING-RIGHT: 0.75pt; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; PADDING-TOP: 0.75pt" vAlign=top> Need quick decisions on schema changes</TD></TR></TBODY></TABLE>   <TABLE class=MsoNormalTable cellPadding=0 border=0> <TBODY> <TR> <TD style="PADDING-RIGHT: 0.75pt; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; PADDING-TOP: 0.75pt" vAlign=top>  </TD> <TD style="PADDING-RIGHT: 0.75pt; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; PADDING-TOP: 0.75pt" vAlign=top>  </TD></TR></TBODY></TABLE> </TD></TR></TBODY></TABLE> Hi, PLEASE answer quickly with your opinions on edits below, so I can begin the edits needed in all of the WIMS schema after last week's PWG Vancouver meetings. Last week, we reduced the scope of the PWG Std Events spec and Events schema to Printer-only (Printer, Job, Document, and Subunit).  Fine, but... (1) Alerts schema - Should I delete 'AlertResource'?     - it depended on the now _deleted_ ResourceXxx events      in the Events schema and Resource object in the      (abandoned) Imaging System Model draft HL - Yes, for now... but we need to put these back in later (2) Alerts schema - Should I change 'NotifySourceState'    to delete 'Testing' and 'Down' from 'hrDeviceStatus'    in Host Resources MIB (RFC 2790)?     - this change will make support of coherent Printer      state harder to harmonize with HR MIB    - I think that it's a bug that Printer state in IPP/1.1      requires state reasons to report Down or Testing HL - No (3) Alerts schema - Should I rename 'NotifySourceState'    to 'NotifyPrinterState' and 'NotifySourceURI' to    'NotifyPrinterURI'?     - doing so effectively closes the future possibility      of multifunction alert support in WIMS HL - No! (4) Resource schema - Should we abandon this schema?     - last week's meeting seemed against adding any      new objects except in some future PWG MFP Model    - abandoning Resources seems foolish to me  HL -   Seems foolish to me too. Don't like the word abandon. Prefer "staging" (5) Schedule schema - Should I reorganize it into    the three Monitoring, Management, and Admin groups    of Actions?     - this seems worthwhile, as it describes WIMS levels      better HL - Yes (6) Schedule schema - Should I delete Resource actions?     - Does WIMS WG accept the need to model Resource? HL - No (Yes... but possibly at a later "stage") (7) Schedule schema - Should I import 'NotifyEvents' from    the Events schema?        - this looks better, but again loses Resources HL - Not sure... why does this loose Resources... because event schema requirments are being driven by PSI? Seems incorrect.             <PZ>I don't understand this one either</PZ> (8) Schedule schema - Should I add the elements for    Supported[Operations|Actions|Objects] here, so    that RegisterForManagement operation works?     - the WIMS operations won't appear in any generic      PWG Semantic Model element in the forseeable future HL - why do you say the WIMS ops won't appear in SM? Do you mean just the admin related Ops?             <PZ>This would seem to be a straight forward extension and could be added to the Schema easily, captured as a Semantic Model extension and picked up in the next version of the PWG Semantic Model spec</PZ>   Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221  Grand Marais, MI  49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com </DIV></BLOCKQUOTE></BODY></HTML>