I've also posted the minutes on the PWG server at:
ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-telecon-981202.docftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-telecon-981202.pdfftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-telecon-981202.txt
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
Tom Hastings
(310) 333-6413