Internet Printing Project Meeting Minutes May 20/21, 1998 Washington, DC The meeting started on May 20, 1998 at 11:00 AM led by Scott Isaacson. These minutes were compiled by Tom Hastings (with lots of help from Scott and Harry). The attendees were: Brian Batchelder - HP Ron Bergman - Dataproducts Lee Farrell - Canon Tom Hastings - Xerox Bob Herriott - SUN Mark Hodges - HP Henrik Holst - I-Data Scott Isaacson - Novell David Kellerman - Northlake David Kuntz - HP Greg LeClair - Epson Harry Lewis - IBM Printing Systems Jay Martin - Underscore Sandra Matts - HP Atsushi Uchino - Epson Don Wright - Lexmark Peter Zehler - Xerox 1 Agenda Scott Isaacson reviewed the agenda for the two days: Wednesday, 5/20: 11:00 AM - 11:30 PM Agenda fixing, progress of IPP in the IETF report, etc. 11:30 AM - 12:00 PM Bug fixes in current IPP/1.0 documentation (Scott, Bob) 1:30 PM - 2:30 PM Interoperability Testing (Pete Z.) 2:30 - 6:00 MIB Access (Scott) Thursday, 5/21: 8:30 - 12:00 Notification (Scott) 2 Progress of IPP in the IETF Still no positive word from Keith Moore, our area director, about the progress of IPP. A message to Carl-Uno indicated that the he was likely to ask for some minor fixes. One problem is that TLS is not yet an approved RFC, which IPP references. There was increasing consternation with the IESG taking so long with approving our specifications as RFCs. However, there was general agreement that implementation and interoperability testing should proceed, since IPP/1.0 is an approved PWG standard proposal. PWG Internet Printing Project - Minutes May 20-21, 1998 3 Bug fixes in current IPP/1.0 documentation The current IPP/1.0 documentation is defined by a suite of Internet- Drafts as submitted to the IESG: Requirements for an Internet Printing Protocol (104985 bytes) http://www.ietf.org/internet-drafts/draft-ietf-ipp-req-01.txt Internet Printing Protocol/1.0: Model and Semantics (435327 bytes) http://www.ietf.org/internet-drafts/draft-ietf-ipp-model-09.txt Mapping between LPD and IPP Protocols (52648 bytes) http://www.ietf.org/internet-drafts/draft-ietf-ipp-map-03.txt Internet Printing Protocol/1.0: Protocol Specification (75544 bytes) http://www.ietf.org/internet-drafts/draft-ietf-ipp-protocol-05.txt Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol (23639 bytes) http://www.ietf.org/internet-drafts/draft-ietf-ipp-rat-02.txt 3.1 Model Document changes ACTION ITEM (Scott): Make these changes while working with the RFC editor to turn the Model specification into an RFC: 3.1.1Clarify that the success status code doesn't mean job has printed A sentence will be added to clarify that the .Success. status code does not mean the print operation was entirely successful. It means that the request has been received, is valid and a job object was created. 3.1.2No further clarifications of the 'stopped' Printer state needed There was a question about whether or not the .Stopped. Printer State needs clarification. New wording, added since Portland, was agreed to be sufficient and no further changes are anticipated. 3.1.3Remove type4 keywords and use type3 keywords (and names) instead There was a question about the purpose and value of Type-4 keywords. Keyword types were explained, as follows: 1 - Must republish the standard to extend. Example - Job States. 2 - Extended or enhance with PWG approval. 3 - Extended or enhanced via registration (IANA) w/o PWG approval. 4 - Not registered. Only applicable to local administrative domains. Example of attributes using type 4 keywords: "media", "job-sheets", and "job-hold-until". They all have the syntax: (type4 keyword | name(MAX)). Because we also allow 'name' syntax, we decided it is best to eliminate the Type-4 enumeration from the specification and to change these three attributes to: (type3 keyword | name(MAX)). Administrators 2 PWG Internet Printing Project - Minutes May 20-21, 1998 may supply localized names within their own domains. So a system manager can only defined names, not keywords. It seems too difficult for a client to have to discover new keywords have been added by the system administrator and then obtain their localization (somehow) in different languages for display to the end-user. Instead, the 'name' attribute syntax will be clarified to indicate that the "name" exists for administrator to add values that are not supported by the implementation. See Bob Herriot's email of March 18 and 19 for a complete discussion. 3.1.4Order of "charset", "natural-language", and Target operation attributes There was a clarification about the order of operation attributes in IPP requests and responses. The "charset" attribute must come first followed by the "natural-language" attribute. For requests, the target attribute(s): "printer-uri", "job-uri", or "printer-uri followed by job-id" must come next. This ordering facilitates processing of the remaining operation attributes by the server. 3.1.5Clarify that the syntax of "printer-uri" and "job-uri" is 'uri' Clarify that the attribute syntax of "printer-uri" and "job-uri" is 'uri'. 3.1.6Clarify that the simplest PrintJob must include the target operation attributes An inconsistency was identified within the Operations attribute group of the PrintJob section in that the simplest operation is defined as the set of document content, "charset" and "natural-language" operation attributes. This section will be revised to include the target attribute(s). 3.1.7Clarify the notation for Mandatory and Optional in Section 15.3. The mandatory table in Section 15.3 is ambiguous. Tom proposed a clarification that, when talking about mandatory and optional, here, we are not defining the terms mandatory and optional, rather we are defining which things must be implemented and which things may be supplied. Tom.s clarifying text (as posted in previous e-mail) will be added. 3.1.8Keep 'uri' syntax and attribute names; don't change to 'url' syntax In Portland, we agreed to continue to use URI syntax name but note that these are really URL.s. Now, there is some question whether this is appropriate in light of some new RFC related to URI.s. ACTION ITEM (Bob Herriott): research and report. 3.1.9Redefine 'client-error-uri-too-long' to be 'client-error-too-long' There were questions about two, potentially redundant, client status error codes 1. client-error-request-uri-too-long 3 PWG Internet Printing Project - Minutes May 20-21, 1998 2. client-error-bad-request Do we need both? Which one do you use if URI is too long? Do they apply to all URI.s or just the "document-uri" attribute? Should .too long. apply to ANY attribute that is string-like? We decided that an error with semantics .Too Long. should be defined for any data type that is a variable number of octets with a maximum length. 3.1.10 ISSUE: Some text and name attributes are constrained to be shorter than MAX We further addressed the problem of string overrun in constrained resource implementations by proposing additional syntax types such as 'shortName', and 'shortText' which would be 63 and 127 bytes, respectively, for example). The goal is to allow the length syntax checking to be solely based on attribute syntax code, and not depend on which attribute is being supplied. To accomplish this goal will require the addition of at least one new attribute syntax. ACTION ITEM (Scott or Bob): Need a detailed proposal. 3.1.11 Reaffirmed that target attributes must be supplied in the request redundantly We agreed that target attributes should be redundantly carried inside the IPP operation as well as externally in the HTTP request header. This redundancy is necessary to keep the IPP MIME media type transport- independent. There was debate over the architectural soundness of this proposal, as it would prevent simple re-routing of the job to a new target based on information from the request header. Instead, to re- route, the embedded target must be learned from examination of the IPP stream. It also complicates test. Following discussion, there was strong opinion not to change anything so the decision to adopt this change (which had already been made - target attributes inside the operation) stands as is and test tools must deal with the situation as required. 3.1.12 Clarified that the target URI are absolute form Per above, suppose we have printer URI inside the operation, but also have it in the HTTP request header mapping. There is the issue of Absolute vs. Relative addressing of the target. Internal to the IPP operation, only Absolute URL.s apply. But, in the HTTP header, it might be Relative. We reiterated that the internal URI is mandatory but the server does not need to check it for routing. In fact, the HTTP request header URI, if present, takes precedence. The internal URI should reference the same URI as the one in the HTTP header (should not be garbage). The external URI may be Relative. 3.1.13 Clarify that the reference to RFC 1766 includes the ISO standards that it references Inside the model document, we talk about natural language syntax from RFC1766: 'en', 'fr', etc. But RFC1766 doesn.t give these values it just references two other ISO standards. We resolved clarify the reference 4 PWG Internet Printing Project - Minutes May 20-21, 1998 to RFC1766 as pertaining to syntax, and add a reference to the proper references for the actual values: [ISO 639] ISO 639:1988 (E/F) - Code for the representation of names of languages - The International Organization for Standardization, 1st edition, 1988 17 pages Prepared by ISO/TC 37 - Terminology (principles and coordination). [ISO 3166] ISO 3166:1988 (E/F) - Codes for the representation of names of countries - The International Organization for Standardization, 3rd edition, 1988-08-15. 3.2 Protocol Document changes ACTION ITEM (Bob): Make these changes while working with the RFC editor to turn the Model specification into an RFC: 3.2.1Change name from "Protocol" to "Encoding and Transport" Name should be changed from "Protocol" to "Encoding and Transport". 3.2.2Add "printer-uri" operation attribute to examples Add "printer-uri" operation attribute to examples to agree with the Model document. 3.2.3Change all attributes to lower case in examples Change some upper case to lower case to agree with the Model document. 3.2.4Change the reserved 'dictionary' attribute syntax to 'collection' Change the name of the reserved 34 attribute syntax code from 'dictionary' to 'collection'. 4 Providing MIB access through IPP The group reviewed the proposal to provide MIB access via IPP: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-mib-access-980505.pdf Scott's proposal for MIB access via IPP has had adequate time for review and the document, based on revision from feedback at meetings and the DL, and is presumed to be a full and fairly stable proposal. In Virginia, Scott introduced the notion of a Device Object to the IPP model. In IPP the Printer Object can be realized in an embedded device or a server which is "fronting" a device. An IPP Printer Object can support one or more device objects. Device objects are read only at this point. Any row, column, table or the whole MIB is accessible through this method. In addition, you can also access any single SNMP object in any MIB. This is achieved using the "requested-attributes" attribute in the Get-Printer-Attributes operation along with a new Optional "which- device" operational attribute. Scott's proposal listed the Finisher group as 19. It is actually 30, 31, 32, and 33 depending on which table in the Finisher MIB. 5 PWG Internet Printing Project - Minutes May 20-21, 1998 We asserted that an index need not always be an integer. It can be a String, OID, IPAddress, etc. In this case, the index is represented as the Decimal value of the sub-identifier (defined by SMI "sub- identifier" rules). There was discussion about whether we should allow access to non-leaf MIB OIDs or just implement a getNext concept. - as accommodated in TIPSIs approach to MIB OIDs. We concluded that getNext can be simulated using adding one more new group attribute: mib-arc-1.2.6...' and allowing the IPP front-end do getNext to the SNMP agent which generates the concatenated IPP response. You always get back individual attributes of the form: 'mib-1.2.6.' and the individual attribute value, not the group name. Examples of getting input tray 3 from hrDevice 10: OID - 'prt-att-8-12-3' gets 1.3.6.1.2.1.43.8.2.1.12.10.3 and is equivalent to: 'mib-1.3.6.1.2.1.43.8.2.1.12.10.3' Column - 'prt-col-8-12' gets all: 1.3.6.1.2.1.43.8.2.12.10.* and is equivalent to: 'mib-arc-1.3.6.1.2.1.43.8.2.12.10' Row - 'prt-row-8-3' gets all: 1.3.6.1.2.1.43.8.2.1.*.10.3 Table - 'prt-tab-8' gets all: 1.3.6.1.2.1.43.8.2.1.*.10.* MIB - 'prt-all' gets all: 1.3.6.1.2.1.43.*.2.1.*.10.* If the client omits the "which-device" operation attribute, the IPP Printer object assumes that it's the first device in order of how they would be found in the Printer object's "devices-supported" attribute. 4.1 Issues 4.1.1Which MIB group names are required if implementing MIB access? General (including private) MIB solution vs. specific to the Printer MIB or both. We decided that access to the Printer MIB would be mandatory (if the IPP Printer supports access to MIBs via IPP). but general access beyond this would be optional since you may not have a private MIB or want to allow access via IPP. So if an IPP Printer object supports MIB access at all, it shall support at least: 'prt-att-.', 'prt-col-.', 'prt-row-.', 'prt-tab-.', and 'prt-all'. Support of 'mib-.', and 'mib- arc-.' is OPTIONAL. 4.1.2Add a "device-type" Printer Attribute? If a printer supports multiple devices you can query and determine which device. What if the devices are multifunction? Do we need a tag that identifies it as a scanner, copier etc? Since we were not aware of a scanner or fax MIB, we agreed not to add a "device-type" attribute at this time. We can add it later when needed when we would also add additional group attribute names, such as 'scn-.' and 'fax-.'. ACTION ITEM (Tom): Update the document with the above agreements and finish the appendix which has the mapping to IPP attribute syntaxes for each object in the Printer MIB. Note: If new IPP attribute syntax(es) 6 PWG Internet Printing Project - Minutes May 20-21, 1998 are introduced for shorter text and names, then those should be used in this Appendix. 5 IPP TEST The week of May 18 was supposed to be a concerted interoperability test. Some testing took place but there was still a lot of debugging going on at this stage. It was found that, while interop testing over the internet is much preferred over a "lug-and-chug" bakeoff, we *do* need people to attend their perspective stations and devices during pair-wise testing. To address this, Peter will solicit a list of contacts and their phone numbers and a readiness and sign-up scheme will be developed. Basic or Digest authentication seems to really need to be tested. Has anyone tried chunking? Peter Zehler reported that Xerox is preparing to release their free IPP client for use in testing. This will provide GUI access to attributes, will support Printer URI's, Job ID's... all IPP operations. It will also support Digest and Basic authentication. Xerox is also planning to release a conformance test suite to the PWG that uses this text client and tests the Mandatory operations, including error conditions. 6 Summary document for IPP Model Scott is trying to build a simplified overview of the IPP model document. Ron Bergman gave him a summary that he had done. 7 IPP Notification Proposal This effort introduces the ability to subscribe to printing events. There are job event groups and printer event groups. A client can subscribe to event groups when submitting a job. Job events apply to that job and Printer events apply only when that job is active (pending, processing, or processing-stopped). When the job completes the subscription is automatically removed. A client can also subscribe and unsubscribe independently of any job submission using two new Subscribe and Unsubscribe operations. The Job Submission Subscription should be simple. The Subscribe/Unsubscribe can be more complicated. There was general agreement on the above approach. However, there were a large number of issues raised as Scott went through the short proposals as listed below. Proposals can be found at: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-event-notification- proposal.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-event-notification- proposal.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-very-short- 980515.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-very-short- 980515.pdf 7 PWG Internet Printing Project - Minutes May 20-21, 1998 ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-printer- 980515.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-printer- 980515.pdf http://www.ietf.org/internet-drafts/draft-ietf-ipp-not-01.txt These issues came from the review of "IPP Event Notifications (Very Short)" (May 15, 1998, Version 0.1) and "Printer Subscriptions for IPP" (May 15, 1998, Version 0.1) and "Event notifications for the IPP print protocol [and JMP]" (May 12, 1998, Version 0.05). It was noted that "Very Short" and "Printer Subscriptions" were two summary-oriented proposals that covered the general concepts proposed in the "Full" document. "Very Short" covered Job Submission Subscriptions, i.e., additional operation attributes supplied in the existing IPP/1.0 job create operations. "Printer Subscriptions" covered new operations for Job Independent Subscriptions. However, it was also noted that the "Very Short" document was not just a summary, but both a summary and in some cases a subset proposal of "Full". There was agreement on the benefit of having a summary specifications for all of our standards, which describes the highlights in a small number of pages. Such a summary should be developed first. Such a summary should be maintained as a summary of the detailed specification as it evolves. The following are in the form of issues that came up during the discussion. Each issue is followed by a proposal that seems to captures some consensus or support from the attendees. Where there was no discussion or not enough discussion to reach a consensus, "TBD" is indicated. 7.1 GENERAL/COMMON ISSUES The following issues apply to both Job Submission Subscriptions and Job Independent Subscriptions: ISSUE 1: Should we allow for subscribing by both Job Submitting End Users as well as other clients (such as server based applications)? Proposal: Yes. Very Short can continue to evolve into an even simpler mechanism by which Job Submitting clients subscribe to both Job and Printer events. The "Printer Subscriptions" (or "Job Independent Subscriptions") document can evolve into the mechanism by which non-job submitting clients subscribe. Job Submission subscriptions should be very simple and "easy". Job Independent subscriptions can be more complex and "hard". ISSUE 2: How do we factor and group events for ease of subscription? Proposal: There are several dimensions across which events can be factored. For example - Events can be divided into Printer Events and Job Events. - Events can be divided into Errors, Warnings, and Reports. 8 PWG Internet Printing Project - Minutes May 20-21, 1998 - Events can be divided by Frequency (more frequent events and less frequent events). - Events can be divided by an encompassing hierarchy (start with 'job-completed', add a small set of just a few events (such as 'job-aborted' and 'job-canceled'), a larger set of those events plus more events (such as printer events), and then all events). The Very Short document proposed 12 Event Groups: Printer Errors, Printer Warnings, Printer Reports, Job Errors, Job Warnings, and Job Reports (broken into several smaller event groups). It sounds like there still might be some concern over this grouping. Other proposals that show partitioning into event groups via these other dimensions are welcome. ISSUE 3: Short proposed 12 event groups for 15 events. Do event groups really buy anything? Proposal: Yes. Implementors can add events (registered or private) to standard event groups without impacting existing clients. ISSUE 4: Full proposed that a subscription was a multi-valued set of collections. Can we simplify that to just one rather than possibly more than one, so that the event groups supplied apply to all supplied URIs (notification-recipients and delivery methods)? Proposal: Yes. ISSUE 5: Should we keep the fact that for each event there is a fixed (predefined in the spec) set of attributes unique to that event that comes back in the event report? Proposal: Yes. However, the table of fixed event report attributes for Job events in Full can be simplified from 4 columns down to 2 columns. ISSUE 6: Should we fix the content format of the event report to the delivery method? Proposal: Yes. ISSUE 7: Should we hardcode (specify in the spec) which attributes are mandatory in the event report based on the delivery method? Proposal: Yes. The mandatory attributes in the event report would be different if the delivery method is email vs. if the delivery method is TCP socket for example. ISSUE 8: Should we hardcode the event report mandatory attributes based on the way in which the subscription was made (that is Job Submission or Job Independent subscription)? Proposal: No. Base the event report on the delivery method, not on the subscription type. ISSUE 9: Should we allow an event to be in multiple event groups? Proposal: Yes. ISSUE 10: Should we hardcode the attributes in the event report based on the event group (i.e., accounting 'job-completed' vs. job progress 'job- completed'? 9 PWG Internet Printing Project - Minutes May 20-21, 1998 Proposal: TBD. ISSUE 11: Is the set of attributes to return in the event report as defined in the tables in the Full proposal complete? Proposal: Yes, unless Bob H. can prove otherwise. ISSUE 12: Which delivery methods (uriScheme) are defined for use in the Printer object's "notify-recipients-supported" attribute? Proposal: Very Short proposes 'mailto': a message via email to the specified email address. The "text/plain" content format is used for this delivery method. 'ipp-tcp-socket': an IPP notification via a TCP/IP socket that is opened by the Printer object or notification service on the IP address specified in the URI using the specified port using the "host:port" HTTP convention. For example: ipp-tcpip-socket:13.240.120.138:6000 The "application/ipp" content format is used for this delivery method. 'snmpv1': a notification as an SNMPv1 trap to the host specified as the address in the URI. 'snmpv2': a notification as an SNMPv2 inform to the host specified as the address in the URI. 'snmpv3': a notification as an SNMPv3 inform to the host specified as the address in the URI. 'sense-datagram': a UDP data gram that is opened by the Printer object or notification service on the IP address specified in the URI using the specified port using the "host:port" HTTP convention. The SENSE UDP content format is used for this delivery method. In addition, add: 'ipp-datagram': a UDP data gram that is opened by the Printer object or notification service on the IP address specified in the URI using the specified port using the "host:port" HTTP convention. The "application/ipp" content format is used for this delivery method. The idea here is to A) use a standard delivery method scheme if it is already registered (http:, mailto: ) and B) register new delivery method schemes as needed here (ipp-tcp-socket:, snmpv3:, etc.). Also new delivery method schemes can have parameters, such as /no-of-retries=n, /time-to-live=m, etc., as described in the registration specification of the notification delivery method scheme that we send to IANA. ISSUE 13: If we use the /parameters mechanism in the delivery method scheme (instead of IPP attributes), how can a client determine which parameters and parameter values are supported by an IPP Printer object for a particular delivery method scheme? Proposal: Ignore this issue for now. ISSUE 14: Which delivery methods are MANDATORY to support? Proposal: 'ipp-tcp-socket' and 'ipp-datagram'. 10 PWG Internet Printing Project - Minutes May 20-21, 1998 ISSUE 15: Once a subscription is made, should we allow subscriptions to be queried so that a client can find out what they are subscribed to? Proposal: For Job Submission Subscriptions: yes; for Job Independent Subscriptions: No. ISSUE 16: Should we continue to try and combine the IPP event model and the Printer MIB alert model and the JMP Alert model? Proposal: Yes ISSUE 17: Should we define an "acknowledgement" mechanism for each delivery method? Proposal: No. If the delivery method is guaranteed delivery, then the event report will be guaranteed delivery (for example TCP connection). If the delivery method is inherently "best effort" we should not go ahead and define acknowledgement semantics on top of it (for example UDP). If we want ack'ed UDP, we should use some already existing mechanism (UDP RPC, snmpv2, snmpv3, or sense-datagrams for example). Therefore, IPP defines most of the event report, however, there might be additional delivery-method-specific info that is supplied to the notification recipient that they can use for acknowledgement or other delivery method specific protocol actions. ISSUE 18: What is the format of the timestamp in the event report? Is it in "seconds" relative to the Printer object's "printer-up-time" attribute (which is just the number of seconds that that Printer object has been up), or do we want to mandate that it be a standard string format representing absolute time (GMT/UTC)? Proposal: Since absolute time is optional in IPP, we can not mandate that all event reports contain an absolute time stamp (GMT/UTC). If the Printer object supports absolute time, this attribute should be made available in the event report. What about "printer-up-time" seconds? Only supply this attribute if the event report format is "application/ipp" (intended for machine consumption - meaningless for humans). ISSUE 19: Do we want a Mixed Format for event reports? Proposal: No for now. We can add 'multi-part/alternative' back in sometime later. ISSUE 20: Make sure that "printer-uri" and "job-uri" and "job-id" are included in the event report where applicable. Proposal: OK. ISSUE 21: Can the attributes in the event report depend on the delivery method? Proposal: yes. ISSUE 22: Add the IPP/1.0 "job-state-message" and "printer-state- message" text attributes to the Job and Printer event reports, respectively? Proposal: Ok 11 PWG Internet Printing Project - Minutes May 20-21, 1998 ISSUE 23: Add the IPP/1.0 "job-state" attribute to Job event reports? Proposal: Ok ISSUE 24: Add IPP/1.0 "number-of-documents" attribute to Job event reports? Proposal: TBD ISSUE 25: Add a new IPP "copies-completed" attribute to Job event reports? Proposal: TBD ISSUE 26: Add the 6 PWG Job Monitoring progress attributes: "output- bin, "sheet-completed-copy-number", "sheet-completed-document-number", "job-collation-type", "impressions-interpreted", and "impressions- completed-current-copy" attributes as IPP Job Description attributes and to Job event reports? Proposal: TBD ISSUE 27: What if we come across printer events that are not in the Printer MIB? Proposal: Add to the Printer MIB alerts, don't just define new IPP Printer events. So need to add to the Printer MIB: the 'printer-is- accepting-jobs' and 'printer-is-not-accepting-jobs' event alert codes. ISSUE 28: Do we need two new Printer attributes "notify-event-groups- supported (1setOf type2 keyword)" and "notify-recipients-supported (1setOf uriScheme)"? Proposal: Yes. The rest of the issues are divided into two groups: Job Submission subscriptions and Job Independent Subscriptions 7.2 JOB SUBMISSION SUBSCRIPTION ISSUES The following issues apply only to Job Submission Subscriptions: ISSUE 29: Should we even allow Job Submission Subscriptions to A) specify the events/event groups of interest or B) hardcode the set of events that are subscribed to? Proposal: TBD. ISSUE 30: If the above choice is B), then what is the set of events/event groups to which a job submission subscription is automatically subscribed? Proposal: Job Completion events and Printer Errors ISSUE 31: Should we hardcode or limit the set of event groups for the 'mailto" delivery method in a Job Submission Subscription (so that other event groups would apply to any other delivery methods also supplied? Proposal: Yes. Which events is TBD, probably just the 'job-completion' event group ('job-completed', 'job-aborted', and 'job-canceled' events), and maybe also 'printer-errors'. 12 PWG Internet Printing Project - Minutes May 20-21, 1998 ISSUE 32: Full proposed that a single subscription was a "collection" of event group names, recipients, content type, charset, natural language, and requested attributes. In the Job Submission case, can this be simplified? Proposal: Yes. If we choose A above, then a subscription is two multi- valued attributes (but not parallel values): "notify-event-groups" and "notify-recipients" (list of delivery-scheme/recipient) values. If we choose B above, then a subscription can be just the "notify-recipients" attribute. The charset and language we can get out of the operation attributes, and/or e-mail restrictions. We can also simplify and eliminate the feature that a client can specify a list of arbitrary attributes to include in the event report. If we hardcode the content type to the delivery method, then we can get rid of the "content-type" specifier attribute. This simplification (A or B) makes the whole idea of "collections" go away! 7.3 JOB INDEPENDENT SUBSCRIPTION ISSUES The following issues apply only to Job Independent Subscriptions: ISSUE 33: Should we allow for multiple subscriptions per Subscribe operation? Proposal: No, therefore we get rid of the "collection" idea. A subscribing client can perform multiple Subscript operations in order to make multiple subscriptions. ISSUE 34: Full proposed that a single subscription was a "collection" of event group names, recipients, content type, charset, natural language, and requested attributes. In the Job Independent case, can this be simplified? Proposal: Yes. A subscription can be just the list of recipients and the event groups of interest for all of those recipients . The charset and language we can get out of the operation attributes. We can also simplify and eliminate the feature that a client can specify a list of arbitrary attributes to include in the event report. If we hardcode the content type to the delivery method, then we can get rid of the "content-type" specifier attribute. This simplification makes the whole idea of "collections" go away since the two attributes supplied by the subscribing client just become operation attributes ("notify-event- groups", and "notify-recipients"); there is no need for a collection. ISSUE 35: Should we allow for some sort of "lease" (time to live) concept in the subscription in order to help solve the "stale" subscription problem and to remove an administrative burden of performing cleanup of "stale" subscriptions? That is, if the client does not resubscribe in a specified amount of time, the subscription is automatically unsubscribed? Proposal: Yes. ISSUE 36: Should we have one operation that subscribes and unsubscribes? 13 PWG Internet Printing Project - Minutes May 20-21, 1998 Proposal: No, need to make sure that the intent of the subscription client is independent of the state of the IPP Printer, i.e., that the Subscript and Unsubscribe operations are idempotent. ISSUE 37: Should we have one operation that both subscribes and refreshes the lease? Proposal: TBD ISSUE 38: Should we allow the client or the Printer to pick the subscription ID? Proposal: Printer. ISSUE 39: Should we allow for an "Unsubscribe ALL" feature in some operation? Proposal: Yes. ISSUE 40: Is unsubscribing a non-existent subscription an error, warning, or success? Proposal: Warning. ISSUE 41: Should we allow only a single unsubscribe or ALL in a single Unsubscribe operation? Proposal: Yes ISSUE 42: Should we allow for a Change or Modify Subscription? Proposal: No. ISSUE 43: What happens when a subscribe fails because the Printer is full of subscriptions? Does it matter if it is Job Submission Subscription or a Job Independent Subscription (that is, is one higher priority than the other)? Proposal: Add an error message to either type of subscription that says "Sorry full, can not subscribe at this time." This should apply equally to both types of subscription - no priority in either case. ISSUE 44: Should we define subscription service events? Such as: "subscription-about-to-expire", "subscription-expired", "are-you-alive", notification Proposal: Probably. ISSUE 45: Do these subscription service events just happen because some entity is subscribed or does the entity explicitly have to subscribe to these events? Proposal: automatic, or is this whole issue out of scope of basic IPP subscription semantics? 14