attachment-0001

Any resemblance to the IETF process (or not) is of little significance in my opinion. I would prefer not to compare in the ultimate (updated) PWG process document... but if it helps our discussion, for now... ok. You clarifications about versioning are good. Thanks. Do you really mean to imply that a Draft Standard cannot bump version? I was not thinking of it this way. I disagree that we need two levels of interop. We should have further discussion on this from a wider audience. One more thought from me. The process, as written, pertains (and has been followed) well for the formation of new working groups (IFX, XP, SM...) but has not been followed well for what I would call "extension documents" (mainly IPP extensions). Is this just an enforcement problem or should the process actually be amended with possible streamlining for extensions (ex. jump right to Draft last call from Working Draft)? ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- <table width=100%> <tr valign=top> <td> <td>"Hastings, Tom N" <hastings@cp10.es.xerox.com> 01/14/2003 10:54 AM <td>                To:        Harry Lewis/Boulder/IBM@IBMUS, "Hastings, Tom N" <hastings@cp10.es.xerox.com>         cc:        Gail Songer <gsonger@peerless.com>, pwg@pwg.org, "Seeler, Rick" <rseeler@adobe.com>         Subject:        RE: PWG> PWG Proposed Standard versus PWG Draft Standard</table> Harry,   So you are suggesting that the PWG names and steps are the same as the IETF, which will help us all understand the PWG process better.  I think this is fine.  And thanks for updating the PWG Process Document.   So we still need a name for the various versions of documents that lead up to the Last Call.  I think that the current PWG process document uses the term "PWG Working Draft".  So the template that I was working on for IEEE-ISTO PWG standards should be for a "PWG Working Draft", not for a "PWG Proposed Standard" or a "PWG Draft Standard".  I can make a second template for the PWG Proposed Standard which just changes the few items from "PWG Working Draft" to "PWG Proposed Standard".  OK?   This terminology and PWG steps map nicely and has a similar sound to the IETF equivalents.  The equivalents to the "PWG Working Draft" is the IETF "INTERNET DRAFT".   So the complete PWG process is:   PWG Working Draft - many each with a distinguishing decimal version number (0.1, 0.2, 0.3 ... 0.9, 0.10, 0.11, 0.12 ...) leading up to Last Call (1), Last Call (2), or Last Call (3).   Last Call (1) + Vote -> Proposed Standard Version 1.0.  If it is revised, then repeat at this level with a new version number, either 1.1, or 2.0. Last Call (2) + Vote + Steering Committee -> Draft Standard Inherits the version number from the last Proposed Last Call (3) + Vote + SC + General Acceptance and Interop -> Standard  Inherits the version number from the last Proposed   And the comparison of the PWG Process with the IETF Process is: PWG Process -- IETF Equivalent --------------------     ---------------------- PWG Working Draft -- Internet Draft PWG Proposed Standard -- IETF Proposed Standard PWG Draft Standard -- IETF Draft Standard PWG Standard -- IETF Standard   and the Last Call requirements are the same for each step as well.   The one difference between the PWG process and the IETF process, is that you are only requiring interop for going from Draft standard to Standard.  I think this is a mistake, since one of the purposes of the interop is to fix the document.  So I'd suggest adding back interop to going to Draft Standard as well.  And that we do interop after a Proposed Standard is approved and decide whether to have another version of the Proposed Standard or whether we can go on to Draft standard.   Right?   Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Friday, January 10, 2003 14:29 To: Hastings, Tom N Cc: Gail Songer; pwg@pwg.org; Seeler, Rick Subject: Re: PWG> PWG Proposed Standard versus PWG Draft Standard 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 ---------------------------------------------- <table width=100%> <tr valign=top> <td width=2%> <td width=39%>"Hastings, Tom N" <hastings@cp10.es.xerox.com> Sent by: owner-pwg@pwg.org 12/11/2002 06:01 PM <td width=58%>               To:        pwg@pwg.org        cc:        Gail Songer <gsonger@peerless.com>, "Seeler, Rick" <rseeler@adobe.com>        Subject:        PWG> PWG Proposed Standard versus PWG Draft Standard</table> <tt> PWG, 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 (http://www.pwg.org/chair/pwg-process-990825.pdf) than the first process document described as: Review the Printer Working Group Standards Process document  (pdf) (http://www.pwg.org/chair/pwg-process-991021.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 Standard to a PWG Draft standard.  We thought that only one round of interoperability 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, then 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 the 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 testing. 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 successful: 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 together after we agree as to how many steps and Last Calls we want. Tom -----Original Message----- From: Gail Songer [mailto:gsonger@peerless.com] Sent: Monday, December 09, 2002 13:43 To: pwg-announce@pwg.org Subject: PWG-ANNOUNCE> IPPFax Working Group Last Call for "PDF Image-Streamable Format - PDF/is" and "IPPFAX/1.0 Protocol" to move to Proposed 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@pwg.org DL (to which you must be subscribed). All, 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:     ftp://ftp.pwg.org/pub/pwg/QUALDOCS/pwg-ifx-pdfis-P04-021122.doc     ftp://ftp.pwg.org/pub/pwg/QUALDOCS/pwg-ifx-pdfis-P04-021122.pdf     ftp://ftp.pwg.org/pub/pwg/QUALDOCS/pwg-ifx-ippfax-P13-021122.doc     ftp://ftp.pwg.org/pub/pwg/QUALDOCS/pwg-ifx-ippfax-P13-021122.pdf The Last Call notice follows: This is a formal request for final within the IPPFax Working Group in order to move two documents to Proposed Standard. These documents are "PDF Image-Streamable Format - PDF/is"  and the "IPPFAX/1.0 Protocol". These are 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          : ftp://ftp.pwg.org/pub/pwg/QUALDOCS/pwg-ifx-ippfax-P13-021122.pdf            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 increased 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 [ipp-get-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 for 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          : ftp://ftp.pwg.org/pub/pwg/QUALDOCS/pwg-ifx-pdfis-P04-021122.pdf            Pages             : 33            Date              : 22 Nov 2002 PDF/is is an image document format intended for use by, but not limited to, 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 [RFC1951]). 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 650.358.8875 </tt>