Interesting arguments on both sides. although I am not quite sure about the
"consensus that we need to define a hardcopy document object and its
supporting elements and semantics." except perhaps in the context of the
"AddHardcopyDocument" operation. I agree with Mike's earlier observation
that the current definition of this operation is insufficient for use as a
copy function. I suspect that it is also inadequate for use in FaxOut and
EmailOut.
Although I respect Pete's opinions, I am unconvinced that a Copy function
(with an enhanced AddHardcopyDocument) cannot be reasonably modeled as a
print function (which is not to say I am certain that it can.) My
understanding of the model is that it represents neither the actual
implementation nor the User interface..rather it provides a model for the
Client - Service interface. Users can and will still think in terms of Copy
vs Print.
As to some of the specific restrictions AddHardcopyDocument puts on the
actual implementation of the scan, such as requiring that the scan be done
before print start (probably reasonable for fax), these may be clear with
Pete's in depth knowledge of the schema but is not obvious to many of us.
The arguments relative to count, particularly if charging for copy prints
is different than for print prints, may be more significant. The model must
accommodate the peculiarities of marketing and sales, even if they are
illogical. But I have no knowledge of pricing structures. Still, it might be
generally true that pricing for prints depends upon original document
source.printing local documents is a different price than printing remotely
access documents. in which case adding scanned documents as a source should
not be a problem.
I appreciate Pete's taking the time to provide his inputs, but as far as I
know, he has been the only one to raise objections to an approach that we
have been pursuing in SM, Cloud and IPP for some time. I am not sure that
Pete will continue to provide his insight and suggest that others provide
their input on this promptly, since we have already proceeded with the
specifications.
Thanks,
Bill Wagner
From: mfd-bounces at pwg.org [mailto:mfd-bounces at pwg.org] On Behalf Of Michael
Sweet
Sent: Wednesday, July 03, 2013 4:13 PM
To: ptykodi at tykodi.com
Cc: mfd at pwg.org; 'Manchala, Daniel'
Subject: Re: [MFD] Meeting Minutes: IEEE/ISTO - PWG/Semantic Model Working
Group, 1 July 2013
Paul,
On 2013-07-03, at 3:26 PM, Paul Tykodi <ptykodi at tykodi.com> wrote:
...
The "Printer Working Group" industry consortium is not an IETF working
group, and the IETF does not recognize the Printer Working Group as a
standards-setting body. This document is being published solely to provide
information to the Internet community regarding a MIB that might be
deployed in the marketplace. Publication of this document as an RFC is not
an endorsement of this MIB."
Yeah, old politics from before the PWG became part of the IEEE-ISTO...
I think that Pete makes a good observation in his point #1 that as an
IEEE-ISTO standards body, the PWG does need to consider carefully the
potential deprecation of an existing PWG standard in favor of handling the
same task in a totally new way rather than a deprecation due to the
publishing of a new updated version of a specification that obsoletes the
previous version.
But we also should not keep standards around longer than they are useful.
We have obsoleted standards before, and if we are successful in doing SM 2.0
we will be obsoleting a LOT of specs in the SM/MFD space. Standards change.
What we shouldn't do is make any assumptions about the validity of our
positions - right now I think we have consensus that we need to define a
hardcopy document object and its supporting elements and semantics. Once
that is done we can update the Scan, FaxOut, EmailOut, Print, and Copy
models to use it, and *then* make a decision about whether Copy is its own
service or a function of Print.
(the other aspect is work for IDS: how to define and query policies for MFDs
tailored to MFD functions, and does Copy need to be separate for proper
AAA?)
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20130703/60489680/attachment-0002.html>