PWG> PWG Proposed Standard versus PWG Draft Standard

PWG> PWG Proposed Standard versus PWG Draft Standard

PWG> PWG Proposed Standard versus PWG Draft Standard

Harry Lewis harryl at
Fri Jan 10 17:28:36 EST 2003

I don't think it is healthy to relate our process steps to IETF. This is 
an unfortunate artifact. I re-read and feel the doc is pretty clear. 
Last Call (1) + Vote -> Proposed Standard
Last Call (2) + Vote + Steering Committee -> Draft Standard
Last Call (3) + Vote + SC + General Acceptance and Interop -> Standard
I'm sure there is room for clean-up. I will try to remove references to 
IETF and add clarification where necessary and repost the document
Harry Lewis 
IBM Printing Systems 

"Hastings, Tom N" <hastings at>
Sent by: owner-pwg at
12/11/2002 06:01 PM
        To:     pwg at
        cc:     Gail Songer <gsonger at>, "Seeler, Rick" 
<rseeler at>
        Subject:        PWG> PWG Proposed Standard versus PWG Draft 


Our PWG Process document needs some work.  There is confusion about the
different steps in the PWG standards process.  Dennis Carney and I re-read
the current process document, available as .pdf from the Chair's page. 

In fact, the Tab at the top of the Chair's page gets you to a different
version of the process document
than the first process document described as:
Review the Printer Working Group Standards Process document  (pdf) 
The latter fixes typos in the former with revision marks.  The latter
attempts to map the PWG documents to the IETF documents by saying:

PWG working group charter is equivalent to an IETF working group charter.
PWG Proposed Standard maps to an initial IETF Internet Draft
PWG Draft Standard maps to an IETF RFC Proposed Standard.
PWG Standard maps to an IETF RFC Draft Standard. 
There is no PWG equivalent to the IETF Standard.

The intent of the PWG process was to skip one of the hurdles that the IETF
has.  So the first Last Call would be to transition a PWG Proposed 
to a PWG Draft standard.  We thought that only one round of 
tests were necessary (though more could be held) after reaching PWG Draft
Standard status in order to transition to PWG Standard. 

However, reading the text of the process document (sections 3.3, 3.4, and
3.5) and the table at the end, Dennis and I agree that it isn't very clear
whether the Last Call is needed to get to a Proposed Standard.   If so, 
the predecessor to a Proposed Standard is a series of "PWG Working Drafts"
(not versions of a PWG Proposed Standard), according to section 3.3 and 
Table at the end.  And then another Last Call to get to a Draft Standard.
And a third Last Call to get to a PWG Standard.  If so, then we would have
the same number of stages in the PWG and the IETF.  If we did, what do we
call the versions of the document before the first Last Call?  These would
correspond to what the IETF calls Internet-Drafts.

The current 5100.1, .2, and .3 say PWG Draft Standard, because they have
gone through their first Last Call, but have not had interoperability

The Media Standard is silent, so the Media standard looks like it is a PWG
Standard, though no interoperability tests have taken place. 

Anyway, the IPPFAX and PDF/is documents are ready for a Last Call.  We're
just not sure what to call the specifications before the Last Call is
PWG Working Drafts to become a PWG Proposed Standard
or versions of a PWG Proposed Standard to become a PWG Draft Standard.

Several people ought to take over the PWG Process document and work 
after we agree as to how many steps and Last Calls we want.


-----Original Message-----
From: Gail Songer [mailto:gsonger at]
Sent: Monday, December 09, 2002 13:43
To: pwg-announce at
Subject: PWG-ANNOUNCE> IPPFax Working Group Last Call for "PDF
Image-Streamable Format - PDF/is" and "IPPFAX/1.0 Protocol" to move to

The last "Last Call" incorrectly requested that the two documents in
question be moved to DRAFT.  They instead should be moved to PROPOSED.

The modified "Last Call" is attached.


Do NOT send comments by a Reply-All to this email.  Instead, send comments
to the ifx at DL (to which you must be subscribed).


This is a working group Last Call to move the specifications "PDF
Image-Streamable Format - PDF/is" and "IPPFAX/1.0 Protocol" to Proposed.

PDF and Word versions of the drafts are posted at the pwg web site as:

The Last Call notice follows:

This is a formal request for final within the IPPFax Working Group in 
to move two documents to Proposed Standard. These documents are "PDF
Image-Streamable Format - PDF/is"  and the "IPPFAX/1.0 Protocol". These 
IPP Working Group products, which have been discussed since early 2001. It
is the intent, once all comments have been address, to progress these
documents to Proposed Standard.

Last Calls are for a minimum of 2 weeks. The period for the Working Group
comments will close on Dec 20, 2002(US Pacific time reference).

The relevant documents are:

             Title             : IPPFAX/1.0 Protocol
             Author(s)         : Thomas N. Hastings, Ira McDonald, Paul
Moore, Gail Songer, John Pulera, Rick Seeler
             Filename          :
             Pages             : 69
             Date              : 22 Nov 2002

IPPFAX is used to provide a synchronous, reliable exchange of image
Documents between clients and servers.  The primary use envisaged of this
protocol is to provide a synchronous image transmission service for the
Internet.  Contrast this with the Internet FAX protocol specified in
[RFC2305] and [RFC2532] that uses the SMTP mail protocol as a transport.

The IPPFAX/1.0 protocol is a specialization of the IPP/1.1 [RFC2911],
[RFC2910] protocol supporting a subset of the IPP operations with 
conformance requirements in some cases, some restrictions in other cases,
and some additional REQUIRED attributes.  The IPPFAX Protocol uses the
'ippfax' URL scheme (instead of the 'ipp' URL scheme) in all its
operations.  Most of the new attributes defined in this document MAY be
supported by IPP Printers as OPTIONAL extensions to IPP as well.  In
addition, IPPFAX/1.0 REQUIRES the support of the IPP Event Notification
mechanism [ipp-ntfy] using the 'ippget' Pull Delivery Method

An IPPFAX Printer object is called a Receiver.  A Receiver MUST support at
least the PDF/is S Profile as specified in [ifx-pdfis] which is defined 
the 'application/pdf' document format MIME type .  A Print System MAY be
configured to support both the IPPFAX and IPP protocols concurrently, but
each protocol requires separate Printer objects with distinct URLs.

             Title             : PDF Image-Streamable Format - PDF/is
             Author(s)         : Rick Seeler
             Filename          :
             Pages             : 33
             Date              : 22 Nov 2002

PDF/is is an image document format intended for use by, but not limited 
the IPPFAX protocol, which is used to provide a synchronous, reliable
exchange of image Documents between Senders and Receivers. PDF/is makes
reference to the PDF 1.4 Reference [pdf], which describes the PDF
representation of image data specified by the ITU-T Recommendations for
black-and-white facsimile (see [T.4], [T.6]), the ISO/IEC Specifications
for Digital Compression and Coding of Continuous-Tone Still Images (see
[jpeg]), and Lossy/Lossless Coding of Bi-Level Images (see [jbig2]), and
the general purpose Flate compression methods (see [RFC1950] and

PDF/is is an image-only, streamable, subset specification of PDF 1.4 [pdf]
and, as such, follows all of the specification requirements of PDF.

Gail Songer
Peerless Systems Corp

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Pwg mailing list