attachment-0002
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><base href="x-msg://1516/"><style><!--
/* Font Definitions */
@font-face
{font-family:Cambria;
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Andale Mono";}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-family:"Cambria","serif";color:#1F497D'>Interesting arguments on both sides… although I am not quite sure about the “</span><span style='font-family:"Cambria","serif"'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Cambria","serif"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Cambria","serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Cambria","serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Cambria","serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Cambria","serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Cambria","serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Cambria","serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Cambria","serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Cambria","serif";color:#1F497D'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Cambria","serif";color:#1F497D'>Bill Wagner<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> mfd-bounces@pwg.org [mailto:mfd-bounces@pwg.org] <b>On Behalf Of </b>Michael Sweet<br><b>Sent:</b> Wednesday, July 03, 2013 4:13 PM<br><b>To:</b> ptykodi@tykodi.com<br><b>Cc:</b> mfd@pwg.org; 'Manchala, Daniel'<br><b>Subject:</b> Re: [MFD] Meeting Minutes: IEEE/ISTO - PWG/Semantic Model Working Group, 1 July 2013<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Paul,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On 2013-07-03, at 3:26 PM, Paul Tykodi <<a href="mailto:ptykodi@tykodi.com">ptykodi@tykodi.com</a>> wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p class=MsoNormal><span style='color:black'>...</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> 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</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> 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.”</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Yeah, old politics from before the PWG became part of the IEEE-ISTO...<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> 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.</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>(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?)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal><span style='font-family:"Andale Mono";color:black'>_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal><br>-- <br>This message has been scanned for viruses and <br>dangerous content by <a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is <br>believed to be clean. <o:p></o:p></p></div><br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.
</body></html>