Really Ira, it was not my intent to criticize any of the significant effort
you have put and are putting into PWG activities. I fully appreciate the
significant contributions you have made. I have simply suggested that a
single unified statement of requirements for the MFD model effort may be
more efficient and might better allow a coherent statement of the need for,
intent of and bounds on the MFD Model. I pose this thought to the MFD
working group and will cheerfully abide by the consensus of the group. If
there are "process" problems in doing this, perhaps the SC will allow some
bending of the rules as it obviously has in forgoing the need for a separate
requirements document in other cases.
I am sorry that you find the requirements update statement confusing. It was
a direct quote from Process document. Perhaps there is justification for
updating/clarifying the Process document?
And I am sorry of you felt I was attacking the Power Model. Actually, I
think it is a good model and a good document. I was just responding to your
observation that it underwent significant changes from the first draft, and
I thought that the sequence specified in the Process document, including the
generation of an PWG approved requirements document, may have addressed many
of the issues that required those changes before the first draft was
I am aware that you personally have written ALL of the Requirement sections
and specs in the PWG for the last five years. And although I appreciate that
your efforts have facilitated getting those specs done, I think this fact in
itself is disturbing.
From: Ira McDonald [mailto:blueroofmusic at gmail.com]
Sent: Wednesday, October 28, 2009 4:33 PM
To: William Wagner
Cc: Zehler, Peter; mfd at pwg.org
Subject: Re: [MFD] Issue for MFD teleconference Thursday 10/29?
Your reply is confusing.
The only way that "Requirements may be updated during
development..." in an external document is the entire PWG
(minimum 6 months, usually more than a year) - that's worse
for timeliness than an embedded Requirements section.
And I find your attack on Power Model for not having a first
Power Management Requirements document rather out of
I personally have written ALL of the Requirement sections
and specs in the PWG since PSI (last 5 years).
Before I ever proposed the first Power Model sketch in June,
I evaluated four vendor private MIBs (publicly available ones),
DMTF CIM (and their extensive Power Profile), ACPI, IEEE
1621, and three large user scenarios within Samsung (not
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
579 Park Place Saline, MI 48176
PO Box 221 Grand Marais, MI 49839
On Wed, Oct 28, 2009 at 2:33 PM, William Wagner <wamwagner at comcast.net>
>> This discussion is more appropriate to the SC list.
>> But note that the "Process" document states that "Requirements may be
> updated during the development of the standard, as they become clearer.",
> the process addresses the potential issue of "stale" (or more likely,
> incompletely considered) requirements. But what it also does is discourage
> generating solutions to problems perceived but not clearly delineated.
>> I agree that the "stawman" approach of generating a spec draft, getting
> comments, and writing the requirements later is often more expeditious,
> it can go awry for more complicated projects.
>> Although I threatened to unilaterally generate a Power Management spec, I
> really would have preferred doing a good requirements analysis of Power
> Management before you submitted your first draft of solutions.(But perhaps
> we would not have had much participation, as the results of the survey
>> Bill Wagner
>> -----Original Message-----
> From: Ira McDonald [mailto:blueroofmusic at gmail.com]
> Sent: Wednesday, October 28, 2009 1:40 PM
> To: Zehler, Peter; Ira McDonald
> Cc: William Wagner; mfd at pwg.org> Subject: Re: [MFD] Issue for MFD teleconference Thursday 10/29?
>> Hi Pete,
>> I agree that we can administratively improve the visibility
> of our free-standing Requirements specs.
>> But I still think the "last year's news" effect of a static external
> Requirements spec is a real downside.
>> In the Power Management Model, there has been repeated
> update of Requirements in both Use Cases and Design
> Requirements sections.
>> And relevant Use Cases are important and evolving, by their
> very nature.
> - Ira
>> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Blue Roof Music/High North Inc
> email: blueroofmusic at gmail.com> winter:
> 579 Park Place Saline, MI 48176
> PO Box 221 Grand Marais, MI 49839
>>>> On Wed, Oct 28, 2009 at 1:22 PM, Zehler, Peter <Peter.Zehler at xerox.com>
>> If we do go with a free standing requirements document it certainly will
> be visible from the MFD page as is the Scan Service requirements document.
> There is a link of the main PWG page for informational documents. Based
> its contents it could use a bit of updating. Once that is addressed the
> informational documents should be just as visible as the standards.
>>>>>> Peter Zehler
>>>> Xerox Research Center Webster
>> Email: Peter.Zehler at Xerox.com>> Voice: (585) 265-8755
>> FAX: (585) 265-7441
>> US Mail: Peter Zehler
>> Xerox Corp.
>> 800 Phillips Rd.
>> M/S 128-25E
>> Webster NY, 14580-9701
>>>> -----Original Message-----
>> From: mfd-bounces at pwg.org [mailto:mfd-bounces at pwg.org] On Behalf Of Ira
>> Sent: Wednesday, October 28, 2009 12:11 PM
>> To: William Wagner; Ira McDonald
>> Cc: mfd at pwg.org>> Subject: Re: [MFD] Issue for MFD teleconference Thursday 10/29?
>>>> One important downside of a free-standing requirements
>> document (as we did for PSI) is that it has to be published
>> as PWG Informational (NOT standards-track), though it
>> still has to go through the PWG Last Call and PWG Formal
>> Vote process.
>>>> Unfortunately, the PWG Informational status makes it
>> invisible (it doesn't show on the PWG Standards list).
>>>> That's pretty much why we abandoned doing free-standing
>> requirements documents after the PSI project.
>> - Ira
>>>> Ira McDonald (Musician / Software Architect)
>> Chair - Linux Foundation Open Printing WG
>> Blue Roof Music/High North Inc
>> email: blueroofmusic at gmail.com>> winter:
>> 579 Park Place Saline, MI 48176
>> PO Box 221 Grand Marais, MI 49839
>>>>>>>> On Tue, Oct 27, 2009 at 8:11 PM, William Wagner <wamwagner at comcast.net>
>>> At the face to face, it was indentified that the MFD "Overall" document
>>> needed " Requirements" section.
>>>>>>>>>>>> The PWG process document says "Prior to completion of the first Working
>>> Draft, a clear statement of requirements for the standard to be produced
>>> required. A requirements statement documents the best effort collection
>>> known requirements on a particular protocol, interface, procedure or
>>> convention. The requirements statement is important as it leads to a
>>> common understanding of the goals, provides a guide for developing the
>>> standard, and can be used as a final test to measure the completeness of
>>> resulting specification. ..."
>>>>>>>>>>>> In practice, the Requirements document has reverted to being a section
>>> the spec draft. And one such section exists in the Scan and Resource
>>> standards. However, I suggest that, in place of including a rather
>>> Requirements section in each Service spec, the Overall Spec and the
>>> spec, we do a separate but meaningful Requirements document for the set
>>> MFD Service and supporting documents.
>>>>>>>>>>>> I think a separate single Requirements document would not only be more
>>> efficient, but it would help readers understand why we are taking a much
>>> implemented device type and Services that have been around for many
>>> and creating new and very involved model descriptions. I think a
>>> requirements document would indeed allow a "common understanding of the
>>> goals, provide a guide for developing the standard, and [a reference] to
>>> measure the completeness of the resulting specification."
>>>>>>>>>>>> I call the existing Requirements sections minimal since they consist of
>>> Rationale, Out of Scope, and Model Mapping Conventions. The '
>>> section takes the form " There is clear need to do this", which appears
>>> rather circular. 'Out of Scope' is useful in providing bounds, but does
>>> really help understanding what is in scope. " Model Mapping Conventions"
>>> does not really appear to be a main aspect of requirements.
>>>>>>>>>>>> The process document is unclear on whether "Requirements" should be "
>>> Requirements for" (i.e. why it is needed, Rational, Use Cases) or "
>>> Requirements of" (operational requirements, what must be addressed,
>>> constraints, need for conformity with, and out of scope). In the case
>>> the MFD Service documents, the requirements should not necessarily
>>> the requirements for or of the Service but rather the requirements for
>>> of a model of the service consistent with an overall structure (I
> think... but
>>> I too need some help in clearly stating why the modeling is necessary.)
>>>>>>>>>>>> So, I propose a separate Requirements document and would like some help
>>> really define the need for a consistent modeling of MFD services. So
>>> the best I can find is in the charter "Currently service, device, and
>>> management and job submission protocols for these network MFDs are
>>> fragmented and proprietary. " Along with this would be some
>>> the models (be representable in XML? be consistent with IPP? Be
>>> with existing products?)...Pete and Ira seem to have a handle on this
>>> suspect that having a clear written statement may have limited the
>>> continuous evolution that we have been experiencing.
>>>>>>>>>>>> Of course, if no one is interested, I can just copy the standard stuff
>>> have in the other specs and get this puppy rolling.
>>>>>>>>>>>> Bill Wagner
>>>>>>>>>>>> From: mfd-bounces at pwg.org [mailto:mfd-bounces at pwg.org] On Behalf Of
>>> Sent: Tuesday, October 27, 2009 7:18 AM
>>> To: mfd at pwg.org>>> Subject: [MFD] MFD teleconference Thursday10/29 at 3:00 PM EDT (12:00 PM
>>>>>>>>>>>> As agreed at the recent face to face meeting there will be an MFD
>>> call at 3:00 PM EDT (12:00 PM PDT) Thursday October 29. The focus of
>>> meeting is the Copy specification that was not covered at the meeting.
>>> same document will be used.
>>>>>>>>>>>>>>>>>> The meeting is held in accord with the PWG Intellectual Property Policy.
>>>>>>>>>>>> Note the NEW Teleconference number and access code are now used.
>>>>>> Please contact me if you do not have the new number and pass code.
>>>>>>>>>>>> Call-in toll-free number (US/Canada): 1-866-469-3239
>>>>>> Call-in toll number (US/Canada): 1-650-429-3300
>>>>>> Call-in toll number (US/Canada): 1-408-856-9570
>>>>>>>>>>>> Attendee access code: (by request only, please contact me if you do not
>>>>>> 1. Identify Minute Taker
>>>>>> 2. Approval of minutes from last meeting
>>>>>>>>> 3. Agenda bashing
>>>>>> 4. Resolve PrinterResolution representation (PrintServiceCapabilities)
>>>>>> 5. Discuss Media, MediaType and MediaCol representation in
>>> <service>DocumentProcessing and IPP/WS-Print mapping
>>>>>> 6. Discuss Copy Service Semantic Model and Service Interface- Interim
>>>>>> (also available is the "-rev" version as well as the ".doc" format for
>>>>>> 7. Next steps
>>>>>>>>>>>> Click Here to Join Live Meeting
>>>>>>>>>>>>>>>>>>>>>>>> Peter Zehler
>>>>>> Xerox Research Center Webster
>>> Email: Peter.Zehler at Xerox.com>>> Voice: (585) 265-8755
>>> FAX: (585) 265-7441
>>> US Mail: Peter Zehler
>>> Xerox Corp.
>>> 800 Phillips Rd.
>>> M/S 128-25E
>>> Webster NY, 14580-9701
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>> mfd mailing list
>>>mfd at pwg.org>>>https://www.pwg.org/mailman/listinfo/mfd>>>>>>>>>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>> mfd mailing list
>>mfd at pwg.org>>https://www.pwg.org/mailman/listinfo/mfd>>>>
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.