Subj: Brief Minutes of IPP Telecon, Dec 2, 1998 From: Tom Hastings Date: 12/03/1998 File: ipp-telecon-981202.doc Attendees: Maulik Desai, Tom Hastings, Bob Herriot, Swen Johnson, Harry Lewis, Carl-Uno Manros, Ira McDonald, Hugo Parra, Richard Shockey, Pete Zehler Agenda: 1. IETF43 plans, week of 12/7 2. IPP San Diego plans, 12/16 and 12/17 3. SLP printer template 4. IPP Bakeoff interoperability testing 5. FAX over IPP discussion 1 IETF43, Orlando, week of 12/7 The IPP Meeting will be Wednesday, 12/9, 9-11:30AM The topics will be: 1. Briefly summarize the IPP/1.0 documents forwarded to the IESG for publication as Informational RFCs 2. IFAX 3. Security Richard Shockey has sent out invitations to the IFAX folks to join the IPP meeting. There is no IETF charter for "real-time" FAX. IFAX is store and forward over SMTP. But IPP looks like it meets 95% of the requirements for real-time FAX over the Internet. Keith Moore, has been supportive of using IPP for real-time FAX. We will wait to see if the Area Directors want a charter update or not. The IFAX group will meet Thursday, 12/10, 9-11:30AM 2 IPP San Diego plans, 12/16 and 12/17 The agenda for San Diego will be: 1. IPP Implementer's Guide, Carl-Uno Manros 2. IFAX, Thursday, Richard Shockey notification will be handled as part of this topic, Tom Hastings 3. testing - what goes into the test plan, Peter Zehler 4. Security - Randy Turner 5. Extensions - Tom Hastings 3 SLP printer template We did not have time to cover this topic. Ira McDonald will send out an updated version based on the comments from the Tucson meeting. We will not discuss SLP templates at the San Diego meeting, but will handle the template on the mailing list. 1 4 IPP Bakeoff interoperability testing Novell will host the bake-off, probably the week of March 8, 1999. The IETF meeting is the following week, and Brain Share is the week after that. Hugo Parra and Peter Zehler will firm up plans and announce to the list. Peter will send out an early ping to judge the interest level. There may be a limit of attendees to around 50. We agreed to an earlier cutoff on signing up for attendance of Feb 1, 1999, based on our experience with the September bakeoff. Peter will produce an updated test plan. 5 FAX over IPP Most of the telecon was brainstorming using IPP for real-time FAX. In Richard Shockey's words, IPP/1.0 has 95% of the features needed for FAX already. For example: 1. immediate feed back whether the data was properly received or not 2. ability to query the device for its capabilities 3. the ability to handle TIFF and TIFF/FX as a document format 4. ability to poll for job printed The following issues were raised: 5.1 IPP server relays a job to a FAX dial-up or SMTP mail address Need a way for the client to pass a phone number (a complete E164) or an e-mail address in a job submission. Then the IPP server relays the job to the specified FAX number or SMTP mail address. The group preferred adding a Job Template attribute(s) which can be queried, rather than adding a parameter to a URL. 5.2 Does the client and/or the server convert to TIFF/FX? Whose job is it to convert a document to TIFF/FX, the client's or the server's? Or does it depend. Do we have to extend IPP for both scenarios? The client can query the IPP Printer object (server) to determine which document formats it will accept. If the server accepts only TIFF/FX, then the client must convert to TIFF/FX and insert water marks. If the server supports other formats, then the server converts those formats to TIFF/FX and adds the water marks (but would we'd need to add an attribute from the client to indicate its contents?). 5.3 Is watermarking required for every page or just the first page U.S. Law only requires watermarking on the first page, but most implementations watermark all pages. Is there a European law requiring watermarking on all pages? However, if current practice is to watermark all pages, IPP FAX should probably also. 2 5.4 Should watermarking be 128 character CSID or VCARD? Should the current FAX practice of a 128 character CSID be used, or the newer, more general VCARD, which is an electronic business card? 5.5 How does an IPP server indicate which phone numbers it supports? How does an IPP server that accepts an IPP print job and dials a PSTN line to send a FAX, indicate which document formats it will accept and convert to TIFF/FX (or whatever is necessary)? If the IPP server is only a front end for FAX 5.6 Need additional job status when relaying jobs Need better job status feed back when jobs are relayed. When the server is finished relaying the job to another IPP server, FAX machine, or mail server, the job isn't really completed. Should its state remain in 'processing' until the job is printed at its final destination or should the job transition to 'completed' as soon as the job is relayed? This is a general problem for IPP, not just when the server is acting as an outbound gateway to FAX or e-mail. For example, IPP gatewaying to an LPD print system. It may be considerable time before the job is printed on the LPD print system. One possibility is adding more job-state-reasons to indicate the status, such as 'completed-relaying'. SMTP is a relaying protocol and has the concept of last hop with notification (RDN and MDN). The IPP notification proposal being developed may also help and should take into account relaying scenarios. 5.7 How does an IPP server map phone numbers to a remote IPP server? It was pointed out that an IPP server that only makes a phone call, is not as useful or cost-effective as one that takes the long distance phone number and maps it to a remote IPP server that is just a local phone call away from the number. Then it uses the Internet to relay the job to another IPP Printer that in turn places the phone call. There is some work on "rules-based" IP Service. We discuss whether the client should consult a directory service first, or should send the job to the IPP Printer that does whatever it wants to support the supplied phone number, including rejecting the job. At the IETF43 meeting on Tuesday 17:00 - 18:00, there is a BOF, called TPC.INT, on E164 Resolution to IP Service which is dealing with this problem. There is also a Gateway location BOF, called IPTEL, on Thursday, 15:30 - 17:30. The above issues and others will be discussed at the IETF43 IPP meeting, Wednesday, December 9, 9:00 - 11:30. 3 4