attachment

<html><body> <DIV>Thank you Ira.</DIV> <DIV> </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> </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 time to the list and we will try to accomodate.</DIV> <DIV> </DIV> <DIV>Thanks.</DIV> <DIV> </DIV> <DIV>Bill Wagner, Chairman, WIMS</DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">-------------- 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 normative 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'] &gt ; > [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, IETF, 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 past 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 > 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 and 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 objects 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 section 3.2.2). > > ---------------------------------------- -------------------------------- </BLOCKQUOTE></body></html>