attachment-0001

I can make Noon EDT on 8/16 in place of the regular schedule which would have fallen on Noon EDT 8/17. ---------------------------------------------- Harry Lewis IBM STSM Chairman - IEEE-ISTO Printer Working Group http://www.pwg.org IBM Printing Systems http://www.ibm.com/printers 303-924-5337 ---------------------------------------------- <table width=100%> <tr valign=top> <td width=40%>wamwagner@comcast.net Sent by: owner-wims@pwg.org 08/09/2005 10:33 PM <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right>To</div> <td>"McDonald, Ira" <imcdonald@sharplabs.com>, "'wims@pwg.org'" <wims@pwg.org> <tr valign=top> <td> <div align=right>cc</div> <td> <tr valign=top> <td> <div align=right>Subject</div> <td>WIMS> Requirements for WIMS Protocol- Next Conference Call</table> <table> <tr valign=top> <td> <td></table> </table> Thank you Ira.   I will incorporate these into the existing document sometime before next Monday and post the document. In the meantime, please review Ira's changes.   There will be no WIMS conference call Wednesday 10 August. I propose a call for noon EDT on Tuesday 16 August. If you have comments on the WIMS protocol document and are not able to participate in a conference call at that time, please email an alternate day and time to the list and we will try to accomodate.   Thanks.   Bill Wagner, Chairman, WIMS       -------------- Original message -------------- > Hi folks, Tuesday (9 August 2005) > > Below are updates for the WIMS Protocol spec, per our discussion at last > week's WIMS telecon: > > (a) global edits (invalid references); > > (b) updates to section 11.1 'Normative References'; > > (c) updates to section 11.2 'Informative References'; > > (d) full text of section 3 'Requirements'. > > 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 > ------------------------------------------------------------------------ > > > [global edits] > > * Replace norm! ative references to [SOAP1.2-0] (which is an informative > document) with [SOAP1.2-1] (which is a normative document). > > * Replace [IPP-ADM] with [RFC3998] (which is normative for our admin > action semantics). > > * Replace [IPP-NOT] with [RFC3995] (which is normative for Subscription > and Alert object semantics). > > ------------------------------------------------------------------------ > > > [add to section 11.1 'Normative References'] > > [ISO10175] ISO. "Information Technology - Document Printing Application > (DPA) Part 1: Abstract Service Definition and Procedures", > ISO 10175, May 1995. > > [RFC2790] S. Waldbusser, P. Grillo. "Host Resources MIB v2", RFC 2790, > March 2000. > > [RFC3231] D. Levi, J. Schoenwaelder, "Definitions of Managed Objects for > Scheduling Management Operations", RFC 3231, January 2002.! > > [RFC3380] Hastings, Herriot, Kugler, Lewis. "Intern et Printing Protocol > (IPP): Job and Printer Set Operations", RFC 3380, September > 2002. > > [RFC3986] Berners-Lee, Fielding, Masinter. "Uniform Resource Identifier > (URI): Generic Syntax", RFC 3986, January 2005. > > [RFC3995] Herriot, Hastings. "Internet Printing Protocol (IPP): Event > Notifications and Subscriptions", RFC 3995, March 2005. > > [RFC3998] Kugler, Lewis, Hastings. "Internet Printing Protocol (IPP): > Job and Printer Administrative Operations", RFC 3998, March > 2005. > > [SOAP1.2-1] Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques > Moreau, Henrik Frystyk Nielsen. "SOAP Version 1.2 Part 1: > Messaging Framework", W3C Recommendation, June 2003. > > [SOAP1.2-2] Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques > Moreau, Henrik Frystyk Nielsen. "SOAP Version 1.2 Part 2: > Adjuncts", W3C Recommendation, ! June 2003. > > ------------------------------------------------------------------------ > > > [delete from section 11.1 'Normative References'] > > [RFC1759] - (obsoleted by RFC 3805) > > [RFC2396] - (obsoleted by RFC 3986) > > [SOAP1.2-0] - (because it's marked INFORMATIVE only by W3C) > > > ------------------------------------------------------------------------ > > > [add to section 11.2 'Informative References'] > > [RFC1759] R. Smith, F. Wright, T. Hastings, S. Zilles, J. Gyllenskog, > "Printer MIB", RFC 1759, March 1995. (obsoleted by RFC 3805) > > [SOAP1.2-0] Box, Ehnebuske, Kakivaya, Layman, Mendelsohn, Nielsen, > Thatte, Winer, "SOAP Version 1.2 Part 0: Primer", W3C > Recommendation, June 2003. > > ------------------------------------------------------------------------ > >! ; > [delete from section 11.2 'Informative References'] > ; > [IPP-ADM] (obsoleted by RFC 3998 - normative for admin actions) > > [IPP-NOT] (obsoleted by RFC 3995 - normative for Alert/Subscripion) > > [ISO10175] (normative for Resource object semantics in model) > > [RFC2732] (obsoleted by RFC 3986 - IPv6 literal address format) > > [RFC2790] (normative for Alert, Printer MIB, and Print Views schema) > > [RFC3231] (normative for Schedule object semantics in model) > > [RFC3380] (normative for SetElements operation semantics) > > [SOAP1.2-1] (normative for WIMS Protocol binding to SOAP/1.2) > > [SOAP1.2-2] (normative for WIMS Protocol binding to SOAP/1.2) > > ------------------------------------------------------------------------ > > [replace existing section 3 entirely with] > > 3. Requirements > > 3.1 Rationale for WIMS Protocol > > The ISO, I! ETF, and PWG standards for the printing industry define: > > (a) A rationale for an abstract model of printing (to support alternate > encodings and protocols) in section 3 of the IETF IPP Rationale > [RFC2568] which led to the later development of the PWG Semantic > Model/1.0 [PWG5105.1]. > > (b) A set of design goals for status monitoring in a printing protocol > in section 3.1.3 'Viewing the status and capabilities of a printer' > (for End User), section 3.2.1 'Alerting' (for Operator), and section > 3.3 'Administrator' (the bullet requirement to 'administrate billing > or other charge-back mechanisms') of the IETF IPP Design Goals > [RFC2567]. > > (c) An abstract model of a Print Service in section 2.1 of IETF IPP/1.1 > [RFC2911]. > > (d) A set of multifunction Service types for Imaging Systems in the > 'JmJobServiceTypesTC' textual convention in! section 4 of the IETF > Job Monitoring MIB [RFC2707]. > > (e) An abstract model of a multifunction Job in section 2 of the IETF > Job Monitoring MIB [RFC2707]. > > (f) An abstract model of a Print Job in section 2.2 of IETF IPP/1.1 > [RFC2911]. > > (g) A set of abstract Print Job counter attributes in section 4.3.18 of > IETF IPP/1.1 [RFC2911], section 3.8 of PWG IPP Production Printing > Attributes [PWG5100.3], section 5.1 of PWG IPP Job Extensions > [PWG5100.7], and section 4 of the IETF Job Monitoring MIB [RFC2707]. > > (h) An abstract model of a Print Device in section 2.2 of the IETF > Printer MIB v2 [RFC3805]. > > (i) A set of abstract Print Device counter attributes in section 6 of > the IETF Printer MIB v2 [RFC3805]. > > (j) An abstract model of a printing Resource in section 6.3.7 and > section 9.8 of ISO Document Printing Application (DPA) [ISO10175]. > > > Over the p! ast decade, network printers have evolved into multifunction > Imaging Systems. In order to support monitoring, maintenance, and > administration of these Imaging Systems, this document defines: > > (1) New abstract Agent, Device, Manager, Resource, Service, Subunit, and > System objects with Status and Description element groups, as a > framework extension to the PWG Semantic Model/1.0 [PWG5105.1]. > > (2) New abstract Report and Schedule objects to support the delayed > execution of monitoring, management, and administration actions, as > a framework extension to the PWG Semantic Model/1.0 [PWG5105.1]. > > (3) New abstract Alert and Subscription objects to support notifications > for events from monitored objects, as a framework extension to the > PWG Semantic Model/1.0 [PWG5105.1]. > > (4) Two sets of abstract operations (i.e., Agent Interface and Manager &! gt; Interface) to support monitoring, management, and administration, as > a framework extension to the PWG Semantic Model/1.0 [PWG5105.1]. > > (5) A set of conformance requirements for implementation of these new > abstract objects, operations, and actions. > > > 3.2 Use Models for WIMS Protocol > > 3.2.1 Service Providers - Monitoring and Billing > > Outside service providers may lease and maintain imaging software and > imaging equipment in remote customer enterprise networks (in different > administrative domains). > > Note: Typically monitoring proxies within customer enterprise networks > are required for scalability of this use model. However, the deployment > of monitoring proxies and of security credentials is outside the scope > of this document. > > (1) To support basic usage billing, outside service providers > may read System counters from imaging systems (e.g., every month). > > (2) To support detailed usage billing, outside service providers > may read Service and Subunit counters from imaging systems (e.g., > every month). > > (3) To support reordering of supplies, outside service providers > may read System and Subunit counters from imaging systems (e.g., > every week). > > (4) To support preventive maintenance, outside service providers > may read System counters from imaging systems (e.g., every week) and > may subscribe to System, Service, and Subunit events. > > (5) To support downtime guarantees, outside service providers > may read System, Service, and Subunit counters from imaging systems, > especially for configuration changes, critical alerts, and > allocation errors (e.g., every 15 minutes). > > > 3.2.2 System Administrators - Network Management > > Network System administrators configure a! nd manage Services and Subunits > on imaging systems in local e nterprise networks. > > (1) To support basic configuration, network system administrators > may read System elements from imaging systems for configuration > checkpoints (e.g., every month). > > (2) To support detailed configuration, network system administrators > may read Service, Device, Subunit, and Resource elements from > imaging systems for configuration checkpoints (e.g., every month). > > (3) To support configuration updates, network system administrators > may write System, Service, Device, Subunit, and Resource elements on > imaging systems (e.g., as needed). > > (4) To support usage and access policies, network system administrators > may change enable and disable System, Service, Device, and Subunit > elements on imaging systems (e.g., as needed) and may subscribe to > System, Service, Device, and Subunit events. > > (5) To support! preventive maintenance, network system administrators > may read System counters from imaging systems (e.g., every week). > > (6) To support emergency maintenance, network system administrators > may read System, Service, and Subunit counters from imaging systems, > especially for configuration changes, critical alerts, and > allocation errors (e.g., every 15 minutes) and may subscribe to > System, Service, and Subunit events. > > > 3.2.3 Network Applications - Accounting > > Network accounting applications monitor Services and Jobs on imaging > systems in local enterprise networks. > > (1) To support basic accounting, a network accounting application > may read System counters from imaging systems (e.g., every month). > > (2) To support detailed accounting, a network accounting application > may read Service counters from imaging systems (e.! g., every week). > > (3) To support user accounting, a n etwork accounting application > may read Service, Job, and Document counters from imaging systems > (e.g., every minute) and may subscribe to Service, Job, and Document > events. > > > 3.3 Design Requirements for WIMS Protocol > > (1) The WIMS Protocol design MUST follow the naming conventions and > element structuring requirements defined in the PWG Semantic > Model/1.0 [PWG-5105.1], including group and element containment, > counter datatype, and counter precision requirements. > > (2) The WIMS Protocol design MUST support mappings to multiple transport > protocols (e.g., TCP or UDP) (see sections 3.2.1 and 3.2.2). > > (3) The WIMS Protocol design MUST support mappings to multiple session > protocols (e.g., HTTP, SMTP, or BEEP) (see sections 3.2.1 and > 3.2.2). > > (4) The WIMS Protocol design MUST support mappings to multiple security! > protocols (e.g., TLS or S/MIME) (see sections 3.2.1 and 3.2.2). > > (5) The WIMS Protocol design MUST support mappings to multiple > management protocols (e.g., OASIS WSDM or IETF SNMP) and multiple > data modelling languages (e.g., XML Schema or SNMP SMIv2) (see > section 3.2.1). > > (6) The WIMS Protocol design MUST support Schedule objects > corresponding to the schedTable element defined in IETF Schedule MIB > [RFC3231] (see all use models in section 3.2). > > (7) The WIMS Protocol design MUST support Report objects for reporting > results and status for delayed actions specified in Schedule objects > (see all use models in section 3.2). > > (8) The WIMS Protocol design MUST support Subscription objects > corresponding to the Subscription object defined in IETF IPP Event > Notifications [RFC3995] (see all use models in section 3.2). > > (9) The WIMS Protocol design MUST support Alert objects &g t; corresponding to the Notification object defined in IETF IPP Event > Notifications [RFC3995] and the printerV2Alert SNMP trap defined in > IETF Printer MIB v2 [RFC3805] (see all use models in section 3.2). > > (10) The WIMS Protocol design MUST support Agent and Manager objects > corresponding to management agent and management station endpoints > in the WIMS Protocol and other network management protocols. > (see all use models in section 3.2). > > (11) The WIMS Protocol design MUST support System objects corresponding > to the System group defined in IETF Host Resources MIB v2 [RFC2790] > (see all use models in section 3.2). > > (12) The WIMS Protocol design MUST support Service objects corresponding > to the Printer object defined in IETF IPP/1.1 [RFC2911] (see all use > models in section 3.2). > > (13) The WIMS Protocol design MUST support Device obje! cts corresponding > to the Printer device defined in IETF Printer MIB v2 [RFC3805] (see > all use models in section 3.2). > > (14) The WIMS Protocol design MUST support Subunit objects corresponding > to the Printer device subunits defined in IETF Printer MIB v2 > [RFC3805] (see all use models in section 3.2). > > (15) The WIMS Protocol design SHOULD support Resource objects > corresponding to the Resource object defined in ISO Document > Printing Application [ISO10175] (see section 3.2.2). > > (16) The WIMS Protocol design MUST support explicit counter persistence > corresponding to 'prtMarkerLifeCount' and 'prtMarkerPowerOnCount' > in IETF Printer MIB v2 [RFC3805] (see section 3.2.3). > > (17) The WIMS Protocol design MUST support both standard and vendor > extensions that define new interfaces, operations, actions, objects, > or elements (see sect! ion 3.2.2). > > ---------------------------------------- --------------------------------