Reminder of our IPPGET telecon today, in a little more than an hour.
If we finish IPPGET, we can discuss John Pulera's updated UIF spec (see
announcement attached at the end).
Also it is more important to update the IFX spec for next Friday's (11/9)
telecon or update the IPPGET and possibly the IPP Notification spec?
I'll try to get these all done next week, but which should come first?
Thanks,
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Monday, October 29, 2001 12:33
To: ipp (E-mail); IPP FAX DL (E-mail)
Subject: IFX> IPP/IPPFAX telecon: IPPGET, Fri, Nov 2 and 9, 1-3PM EST
(10-12 PS T)
Since IPPGET is also an IPP Event Notification Delivery method, the first of
the two telecons is for IPP and IPPFAX WG folks:
Friday, Nov 2 and 9, 10-12 AM PDT (1-3 PM EDT)
Phone: 1(712) 884-1555, (Xerox folks: 8*596-5170), passcode: 654970
The agenda for Friday, Nov 2, will be the IPPGET Event Notification Delivery
Method. We'll decide at the end of that telecon what the agenda will be for
the next telecon the following Friday (November 9).
The IPPFAX WG spent most of the meeting last week (10/24) on the IPPFAX
Protocol document and finished reviewing it. We discussed the changes that
John had made to the UIF document, but did not review those changes
thoroughly. We did not address the IPP IPPGET Event Delivery Method
document at all. We agreed to have two telecons, to address IPPGET and
updated UIF and IPPFAX Protocol documents as well.
Here is the mail that I sent out before the IPP FAX WG meeting. Since then
there has been a lot of good email discussion about resolving issues 1 and
2.
We did discuss ISSUE 01 (adding Event Wait Mode) to Job Creation operations
at the meeting. The sentiment was against. I'll send out a separate email
message on that discussion.
The current favored resolution to ISSUE 02 (IPPGET URL) on the DL would
probably best require editing the IPP Event Notification Spec itself (which
is still in the IESG queue) to add the "notify-put-method" (type2 keyword)
Subscription Template attribute for pull methods which goes along with the
"notify-recipient-uri" (uri) Subscription Template attribute for push
methods. A Subscription object MUST have one or the other, but not both.
Please send any comments on the agenda or the issues to both DLs.
Thanks,
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Friday, October 19, 2001 03:37
To: ipp (E-mail); IPP FAX DL (E-mail)
Subject: IFX> NOT - IPPGET Delivery Method down-loaded - REQUIRED for
IPPFAX
I've posted the updated IPPGET Event Notification Delivery Method that is
REQUIRED for IPPFAX:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-011017.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-011017.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-011017-rev.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-011017-rev.doc
The -rev version show the revisions since the July 17, 2001 version.
It has all of the agreements reached at the August 1, IPP FAX meeting in
Toronto and the subsequent 3 telecon, August 11, 14, and 17. See the
telecon and meeting notes for the list of the changes.
I'll send a .txt I-D later Friday. Please send any comments to the mailing
list. We'll also review at the IPPFAX WG meeting, next Wednesday, October
24 in San Antonio.
There are two issues:
ISSUE 01: Although we agreed to extend Job Creation operations to
support Event Wait Mode, it seems to be an unnecessary complication, since
the Printer MUST keep events for at least 15 seconds. So OK NOT to add the
"notify-wait" (boolean) operation attribute to Job Creation operations and
NOT have to have Job Creation responses return Event Notification Groups (in
addition to returning Subscription Attribute Groups).
ISSUE 02: How unique do we need the "notify-recipient-uri" (uri)
URL now that the Printer doesn't use anything but the scheme in the URL to
match on?
Here are the major changes:
1. Removed the "notify-recipients-uri" operation attribute from
Get-Notifications, so no URI matching.
2. Changed "notify-subscription-id" (integer(1:MAX)) to
"notify-subscription-ids" (1setOf integer(1:MAX)); the client MUST supply
with at least one value. Printer MUST support multiple-values.
3. Added "notify-sequence-numbers" (1setOf integer(1:MAX)) to be parallel
and be a floor to the Event Notifications sequence numbers returned. The
client SHOULD supply. Printer MUST support multiple-values.
4. In Event Wait Mode, each response is a full IPP response.
5. Moved "notify-get-interval" back to the operations attributes group in
the response.
6. Added 'successful-ok-events-complete to indicate that there will be no
more events for this Subscription object.
7. The Printer MUST support Event Wait Mode.
8. The client can end Event Wait Mode (without closing the connection) by
sending "notify-wait" = 'false' any time. The Printer can end Event Wait
Mode (without closing the connection) by returning "notify-get-internal"
operation attribute any time (including immediately).
9. Changed the lower limit for "ippget-event-life" from 1 to 15 seconds and
recommend 60 seconds to agree with the PWG Job Monitoring MIB (RFC 2707).
Thanks,
Tom
-----Original Message-----
From: John Pulera [mailto:jpulera@minolta-mil.com]
Sent: Tuesday, October 30, 2001 16:55
To: IPP-Fax Group
Subject: IFX> UIF spec has been updated: 'uif-spec-08'
I've updated the UIF spec to contain modifications suggested by Tom Hastings
and Robert Buckley since the last IPP-FAX face-to-face.
changes from version 0.7 to 0.8 noted:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-08-rev.doc
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-08-rev.pdf
clean:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-08.doc
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-08.pdf
There is still one outstanding issue:
-- Is it still OK for a Sender to describe UIF Profile S or F TIFF data
using the "image/tiff" MIME subtype since UIF Profile S relies on several
TIFF-FX extensions which require the use of two TIFF fields not recognized
by TIFF 6 (namely, the GlobalParametersIFD and TIFF-FXExtensions fields)
John Pulera
------------------------------------
John Pulera
jpulera@minolta-mil.com
Minolta Systems Laboratory
111 Innovation Dr., Ste 200
Irvine, CA 92612
(949)737-4520 x348
This archive was generated by hypermail 2b29 : Fri Nov 02 2001 - 11:43:13 EST