To IPP WG,
I've extracted from the IPPFAX telecon notes the part of the IPPFAX telecon
that dealt with IPPGET and have copied it.
Please send any comments to the IPP DL.
Thanks,
Tom
-----Original Message-----
From: Hastings, Tom N
Sent: Monday, August 20, 2001 18:17
To: IPP FAX DL (E-mail)
Subject: Notes on the IFX and IPPGET part of the IPPFAX telecon, Friday,
Aug 17
I've separated the notes about the UIF part and the IFX part of our IPPFAX
telecon, Friday, August 17, since the former will be sent to the Internet
FAX WG (ietf-fax@img.org), but the IFX notes will not. The added IPPGET
issue 48 about URI matching was also raised and agreed and will be
distributed to the IPP DL separately as well.
Please send any comments about the notes to the mailing list.
Agenda:
10-11 AM - Address the Internet FAX WG concerns about UIF and the Adobe IPR
issues with TIFF/FX.
11-12 AM - continue with IFX issues 43, 45-47. Any IPPGET Issues.
Attendees: John Pulera (Minolta Labs), Marty Joel (Netreon), Ira McDonald
(High North), Rob Buckley (Xerox), Peter Zehler (Xerox), Tom Hastings
(Xerox), Gail Songer (Netreon).
Summary of the IFX Part:
... agreements deleted ...
****The following IPPGET ISSUE 48 will be copied to the IPP DL as well****
ISSUE 48: How will the Receiving User get notified of an IPP FAX Job
completion?
AGREED> We reconfirmed that IPPGET is not a suitable method for use with
Per-Job Subscription objects for notifying Receiving Users. IPPGET requires
that each user do something every time the Printer is started in order to
receive notifications. So we reconfirmed removing the uri matching function
from the IPPGET Get-Notifications operation, even though we realized that
there is no easy way for a client on a Receiver to search all Per-Job
Subscription Objects using Get-Subscriptions. First such a client would
have to poll using a Get-Jobs operation and see what new jobs had arrived
since the last poll. Then it would have to do a Get-Subscriptions for each
new job requesting the "notify-recipient-uri" attribute and match it.
If the IPPGET Delivery Method is used on a Receiver to notify Receiving
Users, it should be done by an operator application that creates a
Per-Printer Subscription object that subscribes to 'job-completed' events
for all Jobs. See agreement under ISSUE 49 (below) for further discussion
about possible ways a Receiver can notify Receiving Users.
The following affects the IPPFAX Protocol spec, not the IPPGET spec:
ISSUE 49: Should we have an attribute that is similar which is to notify
the recipient (person) of the arrival of the document? The URI could be
'mailto', 'tel'. For the former, the IPPFAX Receiver sends an unsolicited
email message saying that a document has been printed. The latter makes a
phone call to announce that the document has been printed. This attribute
does not require the recipient to have done anything ahead of time and does
not require the recipient to be registered in any system. It is what a
secretary typically does today when a FAX is received at a group FAX.
AGREED> Instead of adding a Job Template attribute to allow the client to
control the delivery of notification to Receiving Users, we agreed to simply
add a Printer Description attribute that is a boolean that indicates whether
or not the Receiver is currently configured to notify Receiving Users when
an IPPFAX Job completes, so that the Sender doesn't have to also worry about
notifying the Receiving User about the IPPFAX Job causing annoying duplicate
notifications for the Receiver User. If the Receiver isn't notifying
Receiving Users, then the Sender could notify Receiving Users either:
a. by adding another Subscription Object with a push method, such as
'mailto' or 'indp' (if supported) to the Job Creation operation with the
Receiving User as the "notify-recipient-uri", or
b. by sending an email message to the Receiving User (before or after the
job completes, depending on the wishes of the Sending User).
The IMPLEMENTATION DEFINED methods for the Receiver to notify Receiving Uses
of completed IPPFAX Jobs include:
1. Each Printer URI is for a separate user. Each Printer object has a
configured Per-Printer Subscription object or equivalent that is subscribed
to 'job-completed' events and uses a supported Event Notification Delivery
Method to deliver the notification to the configured user.
2. Each Printer object has a pre-allocated Per-Printer Subscription Object
that is subscribed to 'job-completed' events and that an operator
application uses to examine Job attributes, such as any fields in the Job's
"ippfax-receiving-user-vcard" operation/Job Description attribute and/or the
"printer-uri" and automatically notify the Receiving User by email,
telephone, or pager.
3. An operator/secretary launches an application that creates a Per-Printer
Subscription object that notifies the operator/secretary by some supported
Delivery Method (ippget, indp, or mailto).
4. That application could examine Job attributes, such as any fields in the
Job's "ippfax-receiving-user-vcard" operation/Job Description attribute
and/or the "printer-uri" and automatically notify the Receiving User by
email, telephone, or pager.
5. That application could access a central data base or directory for the
Receiving User as indicated in the "ippfax-receiving-user-vcard" and use the
method indicated there.
6. A person sits next to the Receiver and reads the start page and delivers
the documents to the Receiving User.
etc.
Please send any comments to the IPP DL.
Thanks,
Tom
This archive was generated by hypermail 2b29 : Mon Aug 20 2001 - 21:27:44 EDT