attachment

<html><body>
<DIV>Thank you Ira.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I will incorporate these into the existing document sometime before next Monday and post the document. In the meantime, please review Ira's changes.</DIV>
<DIV>&nbsp;</DIV>
<DIV>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&nbsp;time to&nbsp;the list and we will try to accomodate.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Bill Wagner, Chairman, WIMS</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">-------------- Original message -------------- <BR><BR>&gt; Hi folks, Tuesday (9 August 2005) <BR>&gt; <BR>&gt; Below are updates for the WIMS Protocol spec, per our discussion at last <BR>&gt; week's WIMS telecon: <BR>&gt; <BR>&gt; (a) global edits (invalid references); <BR>&gt; <BR>&gt; (b) updates to section 11.1 'Normative References'; <BR>&gt; <BR>&gt; (c) updates to section 11.2 'Informative References'; <BR>&gt; <BR>&gt; (d) full text of section 3 'Requirements'. <BR>&gt; <BR>&gt; Cheers, <BR>&gt; - Ira <BR>&gt; <BR>&gt; <BR>&gt; Ira McDonald (Musician / Software Architect) <BR>&gt; Blue Roof Music / High North Inc <BR>&gt; PO Box 221 Grand Marais, MI 49839 <BR>&gt; phone: +1-906-494-2434 <BR>&gt; email: imcdonald@sharplabs.com <BR>&gt; ------------------------------------------------------------------------ <BR>&gt; <BR>&gt; <BR>&gt; [global edits] <BR>&gt; <BR>&gt; * Replace normative references to [SOAP1.2-0] (which is an informative <BR>&gt; document) with [SOAP1.2-1] (which is a normative document). <BR>&gt; <BR>&gt; * Replace [IPP-ADM] with [RFC3998] (which is normative for our admin <BR>&gt; action semantics). <BR>&gt; <BR>&gt; * Replace [IPP-NOT] with [RFC3995] (which is normative for Subscription <BR>&gt; and Alert object semantics). <BR>&gt; <BR>&gt; ------------------------------------------------------------------------ <BR>&gt; <BR>&gt; <BR>&gt; [add to section 11.1 'Normative References'] <BR>&gt; <BR>&gt; [ISO10175] ISO. "Information Technology - Document Printing Application <BR>&gt; (DPA) Part 1: Abstract Service Definition and Procedures", <BR>&gt; ISO 10175, May 1995. <BR>&gt; <BR>&gt; [RFC2790] S. Waldbusser, P. Grillo. "Host Resources MIB v2", RFC 2790, <BR>&gt; March 2000. <BR>&gt; <BR>&gt; [RFC3231] D. Levi, J. Schoenwaelder, "Definitions of Managed Objects for <BR>&gt; Scheduling Management Operations", RFC 3231, January 2002. <BR>&gt; <BR>&gt; [RFC3380] Hastings, Herriot, Kugler, Lewis. "Intern

et Printing Protocol <BR>&gt; (IPP): Job and Printer Set Operations", RFC 3380, September <BR>&gt; 2002. <BR>&gt; <BR>&gt; [RFC3986] Berners-Lee, Fielding, Masinter. "Uniform Resource Identifier <BR>&gt; (URI): Generic Syntax", RFC 3986, January 2005. <BR>&gt; <BR>&gt; [RFC3995] Herriot, Hastings. "Internet Printing Protocol (IPP): Event <BR>&gt; Notifications and Subscriptions", RFC 3995, March 2005. <BR>&gt; <BR>&gt; [RFC3998] Kugler, Lewis, Hastings. "Internet Printing Protocol (IPP): <BR>&gt; Job and Printer Administrative Operations", RFC 3998, March <BR>&gt; 2005. <BR>&gt; <BR>&gt; [SOAP1.2-1] Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques <BR>&gt; Moreau, Henrik Frystyk Nielsen. "SOAP Version 1.2 Part 1: <BR>&gt; Messaging Framework", W3C Recommendation, June 2003. <BR>&gt; <BR>&gt; [SOAP1.2-2] Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques <BR>&gt; Moreau, Henrik Frystyk Nielsen. "SOAP Version 1.2 Part 2: <BR>&gt; Adjuncts", W3C Recommendation, June 2003. <BR>&gt; <BR>&gt; ------------------------------------------------------------------------ <BR>&gt; <BR>&gt; <BR>&gt; [delete from section 11.1 'Normative References'] <BR>&gt; <BR>&gt; [RFC1759] - (obsoleted by RFC 3805) <BR>&gt; <BR>&gt; [RFC2396] - (obsoleted by RFC 3986) <BR>&gt; <BR>&gt; [SOAP1.2-0] - (because it's marked INFORMATIVE only by W3C) <BR>&gt; <BR>&gt; <BR>&gt; ------------------------------------------------------------------------ <BR>&gt; <BR>&gt; <BR>&gt; [add to section 11.2 'Informative References'] <BR>&gt; <BR>&gt; [RFC1759] R. Smith, F. Wright, T. Hastings, S. Zilles, J. Gyllenskog, <BR>&gt; "Printer MIB", RFC 1759, March 1995. (obsoleted by RFC 3805) <BR>&gt; <BR>&gt; [SOAP1.2-0] Box, Ehnebuske, Kakivaya, Layman, Mendelsohn, Nielsen, <BR>&gt; Thatte, Winer, "SOAP Version 1.2 Part 0: Primer", W3C <BR>&gt; Recommendation, June 2003. <BR>&gt; <BR>&gt; ------------------------------------------------------------------------ <BR>&gt; <BR>&gt; <BR>&gt; [delete from section 11.2 'Informative References'] <BR>&gt

; <BR>&gt; [IPP-ADM] (obsoleted by RFC 3998 - normative for admin actions) <BR>&gt; <BR>&gt; [IPP-NOT] (obsoleted by RFC 3995 - normative for Alert/Subscripion) <BR>&gt; <BR>&gt; [ISO10175] (normative for Resource object semantics in model) <BR>&gt; <BR>&gt; [RFC2732] (obsoleted by RFC 3986 - IPv6 literal address format) <BR>&gt; <BR>&gt; [RFC2790] (normative for Alert, Printer MIB, and Print Views schema) <BR>&gt; <BR>&gt; [RFC3231] (normative for Schedule object semantics in model) <BR>&gt; <BR>&gt; [RFC3380] (normative for SetElements operation semantics) <BR>&gt; <BR>&gt; [SOAP1.2-1] (normative for WIMS Protocol binding to SOAP/1.2) <BR>&gt; <BR>&gt; [SOAP1.2-2] (normative for WIMS Protocol binding to SOAP/1.2) <BR>&gt; <BR>&gt; ------------------------------------------------------------------------ <BR>&gt; <BR>&gt; [replace existing section 3 entirely with] <BR>&gt; <BR>&gt; 3. Requirements <BR>&gt; <BR>&gt; 3.1 Rationale for WIMS Protocol <BR>&gt; <BR>&gt; The ISO, IETF, and PWG standards for the printing industry define: <BR>&gt; <BR>&gt; (a) A rationale for an abstract model of printing (to support alternate <BR>&gt; encodings and protocols) in section 3 of the IETF IPP Rationale <BR>&gt; [RFC2568] which led to the later development of the PWG Semantic <BR>&gt; Model/1.0 [PWG5105.1]. <BR>&gt; <BR>&gt; (b) A set of design goals for status monitoring in a printing protocol <BR>&gt; in section 3.1.3 'Viewing the status and capabilities of a printer' <BR>&gt; (for End User), section 3.2.1 'Alerting' (for Operator), and section <BR>&gt; 3.3 'Administrator' (the bullet requirement to 'administrate billing <BR>&gt; or other charge-back mechanisms') of the IETF IPP Design Goals <BR>&gt; [RFC2567]. <BR>&gt; <BR>&gt; (c) An abstract model of a Print Service in section 2.1 of IETF IPP/1.1 <BR>&gt; [RFC2911]. <BR>&gt; <BR>&gt; (d) A set of multifunction Service types for Imaging Systems in the <BR>&gt; 'JmJobServiceTypesTC' textual convention in section 4 of the IETF <BR>&gt; Job Monitoring MIB [RFC2707]. <BR>&gt;

 <BR>&gt; (e) An abstract model of a multifunction Job in section 2 of the IETF <BR>&gt; Job Monitoring MIB [RFC2707]. <BR>&gt; <BR>&gt; (f) An abstract model of a Print Job in section 2.2 of IETF IPP/1.1 <BR>&gt; [RFC2911]. <BR>&gt; <BR>&gt; (g) A set of abstract Print Job counter attributes in section 4.3.18 of <BR>&gt; IETF IPP/1.1 [RFC2911], section 3.8 of PWG IPP Production Printing <BR>&gt; Attributes [PWG5100.3], section 5.1 of PWG IPP Job Extensions <BR>&gt; [PWG5100.7], and section 4 of the IETF Job Monitoring MIB [RFC2707]. <BR>&gt; <BR>&gt; (h) An abstract model of a Print Device in section 2.2 of the IETF <BR>&gt; Printer MIB v2 [RFC3805]. <BR>&gt; <BR>&gt; (i) A set of abstract Print Device counter attributes in section 6 of <BR>&gt; the IETF Printer MIB v2 [RFC3805]. <BR>&gt; <BR>&gt; (j) An abstract model of a printing Resource in section 6.3.7 and <BR>&gt; section 9.8 of ISO Document Printing Application (DPA) [ISO10175]. <BR>&gt; <BR>&gt; <BR>&gt; Over the past decade, network printers have evolved into multifunction <BR>&gt; Imaging Systems. In order to support monitoring, maintenance, and <BR>&gt; administration of these Imaging Systems, this document defines: <BR>&gt; <BR>&gt; (1) New abstract Agent, Device, Manager, Resource, Service, Subunit, and <BR>&gt; System objects with Status and Description element groups, as a <BR>&gt; framework extension to the PWG Semantic Model/1.0 [PWG5105.1]. <BR>&gt; <BR>&gt; (2) New abstract Report and Schedule objects to support the delayed <BR>&gt; execution of monitoring, management, and administration actions, as <BR>&gt; a framework extension to the PWG Semantic Model/1.0 [PWG5105.1]. <BR>&gt; <BR>&gt; (3) New abstract Alert and Subscription objects to support notifications <BR>&gt; for events from monitored objects, as a framework extension to the <BR>&gt; PWG Semantic Model/1.0 [PWG5105.1]. <BR>&gt; <BR>&gt; (4) Two sets of abstract operations (i.e., Agent Interface and Manager <BR>&gt; Interface) to support monitoring, management, and administration, 

as <BR>&gt; a framework extension to the PWG Semantic Model/1.0 [PWG5105.1]. <BR>&gt; <BR>&gt; (5) A set of conformance requirements for implementation of these new <BR>&gt; abstract objects, operations, and actions. <BR>&gt; <BR>&gt; <BR>&gt; 3.2 Use Models for WIMS Protocol <BR>&gt; <BR>&gt; 3.2.1 Service Providers - Monitoring and Billing <BR>&gt; <BR>&gt; Outside service providers may lease and maintain imaging software and <BR>&gt; imaging equipment in remote customer enterprise networks (in different <BR>&gt; administrative domains). <BR>&gt; <BR>&gt; Note: Typically monitoring proxies within customer enterprise networks <BR>&gt; are required for scalability of this use model. However, the deployment <BR>&gt; of monitoring proxies and of security credentials is outside the scope <BR>&gt; of this document. <BR>&gt; <BR>&gt; (1) To support basic usage billing, outside service providers <BR>&gt; may read System counters from imaging systems (e.g., every month). <BR>&gt; <BR>&gt; (2) To support detailed usage billing, outside service providers <BR>&gt; may read Service and Subunit counters from imaging systems (e.g., <BR>&gt; every month). <BR>&gt; <BR>&gt; (3) To support reordering of supplies, outside service providers <BR>&gt; may read System and Subunit counters from imaging systems (e.g., <BR>&gt; every week). <BR>&gt; <BR>&gt; (4) To support preventive maintenance, outside service providers <BR>&gt; may read System counters from imaging systems (e.g., every week) and <BR>&gt; may subscribe to System, Service, and Subunit events. <BR>&gt; <BR>&gt; (5) To support downtime guarantees, outside service providers <BR>&gt; may read System, Service, and Subunit counters from imaging systems, <BR>&gt; especially for configuration changes, critical alerts, and <BR>&gt; allocation errors (e.g., every 15 minutes). <BR>&gt; <BR>&gt; <BR>&gt; 3.2.2 System Administrators - Network Management <BR>&gt; <BR>&gt; Network System administrators configure and manage Services and Subunits <BR>&gt; on imaging systems in local e

nterprise networks. <BR>&gt; <BR>&gt; (1) To support basic configuration, network system administrators <BR>&gt; may read System elements from imaging systems for configuration <BR>&gt; checkpoints (e.g., every month). <BR>&gt; <BR>&gt; (2) To support detailed configuration, network system administrators <BR>&gt; may read Service, Device, Subunit, and Resource elements from <BR>&gt; imaging systems for configuration checkpoints (e.g., every month). <BR>&gt; <BR>&gt; (3) To support configuration updates, network system administrators <BR>&gt; may write System, Service, Device, Subunit, and Resource elements on <BR>&gt; imaging systems (e.g., as needed). <BR>&gt; <BR>&gt; (4) To support usage and access policies, network system administrators <BR>&gt; may change enable and disable System, Service, Device, and Subunit <BR>&gt; elements on imaging systems (e.g., as needed) and may subscribe to <BR>&gt; System, Service, Device, and Subunit events. <BR>&gt; <BR>&gt; (5) To support preventive maintenance, network system administrators <BR>&gt; may read System counters from imaging systems (e.g., every week). <BR>&gt; <BR>&gt; (6) To support emergency maintenance, network system administrators <BR>&gt; may read System, Service, and Subunit counters from imaging systems, <BR>&gt; especially for configuration changes, critical alerts, and <BR>&gt; allocation errors (e.g., every 15 minutes) and may subscribe to <BR>&gt; System, Service, and Subunit events. <BR>&gt; <BR>&gt; <BR>&gt; 3.2.3 Network Applications - Accounting <BR>&gt; <BR>&gt; Network accounting applications monitor Services and Jobs on imaging <BR>&gt; systems in local enterprise networks. <BR>&gt; <BR>&gt; (1) To support basic accounting, a network accounting application <BR>&gt; may read System counters from imaging systems (e.g., every month). <BR>&gt; <BR>&gt; (2) To support detailed accounting, a network accounting application <BR>&gt; may read Service counters from imaging systems (e.g., every week). <BR>&gt; <BR>&gt; (3) To support user accounting, a n

etwork accounting application <BR>&gt; may read Service, Job, and Document counters from imaging systems <BR>&gt; (e.g., every minute) and may subscribe to Service, Job, and Document <BR>&gt; events. <BR>&gt; <BR>&gt; <BR>&gt; 3.3 Design Requirements for WIMS Protocol <BR>&gt; <BR>&gt; (1) The WIMS Protocol design MUST follow the naming conventions and <BR>&gt; element structuring requirements defined in the PWG Semantic <BR>&gt; Model/1.0 [PWG-5105.1], including group and element containment, <BR>&gt; counter datatype, and counter precision requirements. <BR>&gt; <BR>&gt; (2) The WIMS Protocol design MUST support mappings to multiple transport <BR>&gt; protocols (e.g., TCP or UDP) (see sections 3.2.1 and 3.2.2). <BR>&gt; <BR>&gt; (3) The WIMS Protocol design MUST support mappings to multiple session <BR>&gt; protocols (e.g., HTTP, SMTP, or BEEP) (see sections 3.2.1 and <BR>&gt; 3.2.2). <BR>&gt; <BR>&gt; (4) The WIMS Protocol design MUST support mappings to multiple security <BR>&gt; protocols (e.g., TLS or S/MIME) (see sections 3.2.1 and 3.2.2). <BR>&gt; <BR>&gt; (5) The WIMS Protocol design MUST support mappings to multiple <BR>&gt; management protocols (e.g., OASIS WSDM or IETF SNMP) and multiple <BR>&gt; data modelling languages (e.g., XML Schema or SNMP SMIv2) (see <BR>&gt; section 3.2.1). <BR>&gt; <BR>&gt; (6) The WIMS Protocol design MUST support Schedule objects <BR>&gt; corresponding to the schedTable element defined in IETF Schedule MIB <BR>&gt; [RFC3231] (see all use models in section 3.2). <BR>&gt; <BR>&gt; (7) The WIMS Protocol design MUST support Report objects for reporting <BR>&gt; results and status for delayed actions specified in Schedule objects <BR>&gt; (see all use models in section 3.2). <BR>&gt; <BR>&gt; (8) The WIMS Protocol design MUST support Subscription objects <BR>&gt; corresponding to the Subscription object defined in IETF IPP Event <BR>&gt; Notifications [RFC3995] (see all use models in section 3.2). <BR>&gt; <BR>&gt; (9) The WIMS Protocol design MUST support Alert objects <BR>&g

t; corresponding to the Notification object defined in IETF IPP Event <BR>&gt; Notifications [RFC3995] and the printerV2Alert SNMP trap defined in <BR>&gt; IETF Printer MIB v2 [RFC3805] (see all use models in section 3.2). <BR>&gt; <BR>&gt; (10) The WIMS Protocol design MUST support Agent and Manager objects <BR>&gt; corresponding to management agent and management station endpoints <BR>&gt; in the WIMS Protocol and other network management protocols. <BR>&gt; (see all use models in section 3.2). <BR>&gt; <BR>&gt; (11) The WIMS Protocol design MUST support System objects corresponding <BR>&gt; to the System group defined in IETF Host Resources MIB v2 [RFC2790] <BR>&gt; (see all use models in section 3.2). <BR>&gt; <BR>&gt; (12) The WIMS Protocol design MUST support Service objects corresponding <BR>&gt; to the Printer object defined in IETF IPP/1.1 [RFC2911] (see all use <BR>&gt; models in section 3.2). <BR>&gt; <BR>&gt; (13) The WIMS Protocol design MUST support Device objects corresponding <BR>&gt; to the Printer device defined in IETF Printer MIB v2 [RFC3805] (see <BR>&gt; all use models in section 3.2). <BR>&gt; <BR>&gt; (14) The WIMS Protocol design MUST support Subunit objects corresponding <BR>&gt; to the Printer device subunits defined in IETF Printer MIB v2 <BR>&gt; [RFC3805] (see all use models in section 3.2). <BR>&gt; <BR>&gt; (15) The WIMS Protocol design SHOULD support Resource objects <BR>&gt; corresponding to the Resource object defined in ISO Document <BR>&gt; Printing Application [ISO10175] (see section 3.2.2). <BR>&gt; <BR>&gt; (16) The WIMS Protocol design MUST support explicit counter persistence <BR>&gt; corresponding to 'prtMarkerLifeCount' and 'prtMarkerPowerOnCount' <BR>&gt; in IETF Printer MIB v2 [RFC3805] (see section 3.2.3). <BR>&gt; <BR>&gt; (17) The WIMS Protocol design MUST support both standard and vendor <BR>&gt; extensions that define new interfaces, operations, actions, objects, <BR>&gt; or elements (see section 3.2.2). <BR>&gt; <BR>&gt; ----------------------------------------

-------------------------------- </BLOCKQUOTE></body></html>