BIll,
I checked the process document and non-voting members do indeed count towards quorum for last call. See section 8.1 (bold/italic text highlights the important bits):
8.1 Last Call
Last Call represents a final opportunity for issues to be raised against a document. During this period all PWG members are encouraged to review the final working draft for both technical and editorial content and to provide comments to the Working Group. The Working Group Chair announces a Last Call on a document with rough consensus of the Working Group. Last Calls are posted to all members of the PWG via the PWG-ANNOUNCE mailing list. The Last Call period may vary, based upon the content, complexity, holidays, or other circumstances, but must be at least 16 full working days (minimum 22 calendar days). A working day is a normal business day and is considered to end at 10 PM USPST (Los Angeles, CA, USA). For any document transitioning to Candidate Standard or Standard, Last Call must either conclude at, or span a PWG Plenary meeting with an overview of the draft or standards document and a review of any current detailed issues and their resolutions. If less than 30 percent of the PWG membership have commented, participated, or communicated that they have no comments for a given document during Last Call, the Last Call period is automatically extended until that threshold is met. Within a reasonable period of time following closure of Last Call, all issues raised during Last Call must be either resolved or rejected as follows:
• ⎯ Resolved - Document updated to reflect the resolution
• ⎯ Rejected - No change required in the document
All issues and their resolution from the most recent Last Call must be published in the Formal Approval announcement.
According to section 2.1, a non-voting member is still a member and can participate in everything except voting and serving as an officer of the PWG, so if it is OK with you I'd like to include these items in the last call comments for IPP Everywhere.
Thanks!
On Aug 21, 2012, at 2:30 PM, William A Wagner <wamwagner at comcast.net> wrote:
> As requested, I am outlining some of the differences between the IPP Everywhere Use Cases and the revised Cloud Use Cases. First, since the general position has been that, as a nonvoting member, my comments do not count toward the quorum, I make these observations on IPP Everywhere vs. Cloud “Use Cases” as comments on the conference call rather than last call comments on the document. Second, I am noting the divergence of the two use cases from the same original set not as critical comments on the IPP Everywhere Use Cases, but to indicate the legitimate differences in how one looks at these cases. I can think of no reason why the two sets of use cases must be the same in style, form or specifics, provided that they are realistic and useful in developing requirements. Further, I believe it is valid to conclude that a requirement evolving from a Use Case need not be addressed in thesolutions, provided that a reason for the omission is given. However, in that there were some issues that came up in addressing the IPP Everywhere use cases that had also been addressed in the Cloud Use Cases, I offer this summary.
>> With that preface, I would note that the original Use Cases included both concise statements of cases where a specific feature would be used (which I would call Use Cases), and narratives giving a more or less plausible situation (perhaps better called scenarios). The IPP Everywhere spec gives specific use cases under “Select Printer” , but reverts to more of a scenario approach for the “Print” section. I see no problem with this approach although I admit a bias toward stating scenarios, with the requirements developed from the scenarios breaking out the details (e.g., specific criteria used for selection).
>> One line of thinking in the Cloud discussion was that requirements were to be developed to address use cases (or scenarios) and the design was to be developed to satisfy the requirements. Therefore, it seemed inappropriate to describe the Use Cases in terms of the elements of the model design. So the Cloud scenarios were rephrased in terms of the basic elements…the User (or more specifically, the potential Job Originator), the physical printer and the stuff in between (primarily the Cloud , the big black box in the sky). I do not suggest this as a comment on the IPP Everywhere specification, just as the thoughts that are reflected in the Cloud Rationale section.
>> With regard to specific changes in the Cloud vs IPP Everywhere versions of what was initially the same use case:
>> 1. If Common Preconditions in Cloud were important, it was felt that they should be itemized and presented as a distinct section. Once they were made more obvious, they were variously considered to be wrongly stated, obvious, or more appropriately stated in the requirements section. We are not sure what we will do with them.
> 2. Objections to the Common Preconditions also stemmed from the confusion of the term “Visible”. Even in IPP Everywhere, it is sort of contradictory to say “the Printer must be Visible to the Client in order to be selected, either directly or through an intermediate Service” when “Visible” is defined as the ability to communicate directly. The other confusion developed from the definition’s referring to the “ability” to communicate, suggesting that at some time under some conditions the connection could exist while the normal sense of the word suggests that the connection does exist.
> 3. Print a Document – no significant difference. Original statement specifying some relationship of user to printer was considered confusing and was removed. Comments on validating were considered perhaps part of requirements or solution.
> 4. Print by Reference. – same comments as Print a Document
> 5. Print a Photo/Print Using Loaded Media. – Titles diverged some time ago. Preconditions were considered more requirements.
> 6. Check printing – Cloud sought to clarify that this did not involve sending a “form template” to the printer. Also, to include an obvious Cloud scenario, the application is Cloud Based (not necessary for IPP Everywhere). I suggest that, in the IPP Everywhere text, Client sends the “document data containing the checks” might be confusing, since check usually refers to the printed media.
> 7. Print with Special Formatting was dropped from Cloud as not representing a sufficiently distinct set of requirements.
> 8. The original Prescription print case in Cloud was changed to a photoprint involving selection on the basis of geographic location and print to someone other than the job originator. The prescription case seemed too loaded with HIPAA problems.
> 9. Print and Select was changed to avoid reference to ‘FollowMe®” (a registered trademark of Ringdale)
> 10. Print to a Service – aside from some minor clarification, no change.
> 11. Job Cancel…that is canceling a job request after it has been submitted and accepted was taken as a use case rather than an exception. This may be more appropriate for Cloud since the Cloud model does require intermediaries between the job originator and the printer.
> 12. Exceptions: Main change was identifying the exception but not the actions to be taken, under the premise that the way the system reacts is to be indicated under Requirements and how it does this is to be in the Model.
>> I would note that Pete indicated that there are User use cases (rather than just Job Originator use cases) that have not been covered and may be added, but that is a Cloud problem.
>> Aside from things that have already been noted in yesterday’s call, I do not think that the divergence in how the use cases are presented represents a problem. But perhaps some of the wording (such as the treatment of “Print and Select”) may be of interest when addressing similar issues in IPP Everywhere.
> Thanks,
> Bill Wagner
>> Thanks,
>>>>> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean. _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20120823/0dd2c581/attachment-0001.html>