attachment
<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=utf-8"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@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;}
/* 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.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@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-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi Ira,<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Thank you for your response. <o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Cambria","serif"'> Perhaps I misunderstand you on the first point. Although the Semantic Model fully identifies the form of an AvailableJobTicket, as far as I can see neither it nor the FaxIn draft indicates how AvailableJobTickets are communicated to the Service. The FaxIn draft indicates that </span><span style='font-family:"Cambria","serif"'>FaxInJobTickets are communicated via SetFaxInJobElements requests, but that seems unlikely. It also states that “There is no mechanism for an explicit FaxInJobTicket to be received with an incoming FaxInJob.</span>”. So it would appear that a FaxIn job ticket is derived from an AvailableFaxInJobTicket or the DefaultFaxInJob Ticket, and it would seem that SetFaxInServiceElements is the more likely. As is indicated in the FaxIn draft, there is a “<b><span style='background:yellow;mso-highlight:yellow'>Need a complete description (and diagram?) of FaxIn Job lifecycle and various InputChannel types applicable</span>”</b> . This would need to be done if FaxIn is to be included in SM3.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>With regard to your second point, my query about how to handle Cloud FaxIn was concerned with the rationale of modeling Cloud FaxIn Service, particularly since the User interface is just at the Administrator level. Unless you are suggesting that the IPP decision with regard to FaxIn cause it to be dropped from SM3 (in which case I agree that it should not be in the Cloud model), I think that making IPP binding of a specific service a necessary prerequisite to modeling that service is setting a new precedent that we may regret. It would of course make SM3 somewhat simpler. Actually, FaxIn might be one of the less likely Services to need an IPP binding, since none of the Basic User operations appear to be necessary.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Of course, if you are saying that a Cloud FaxIn Service has no conceivable application (as we agreed with respect to a Cloud Copy Service for example), that would be a good reason to not include it.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks, Bill Wagner<span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><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 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"'> cloud-bounces@pwg.org [mailto:cloud-bounces@pwg.org] <b>On Behalf Of </b>Ira McDonald<br><b>Sent:</b> Tuesday, September 16, 2014 4:19 PM<br><b>To:</b> Semantic Model 3.0 Workgroup discussion list; Ira McDonald<br><b>Cc:</b> cloud@pwg.org<br><b>Subject:</b> Re: [Cloud] [SM3] Cloud FaxIn Service<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><div><div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Hi Bill,<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>We *did* define in complete detail how a set of available job tickets are<br>configured on a FaxIn service and how they are selected - and all of <br>this is in SM schema and the most recent FaxIn draft.<o:p></o:p></p></div><p class=MsoNormal>BUT - I strongly urge that we *not* put FaxIn into Cloud Model, because<br>the IPP WG has decided (and written into their charter a year ago) that<o:p></o:p></p></div><p class=MsoNormal>they will *not* do an IPP FaxIn service - no protocol binding to satisfy the<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>PWG prototype requirement.<o:p></o:p></p></div><p class=MsoNormal>Cheers,<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>- Ira<o:p></o:p></p></div><div><p class=MsoNormal><br clear=all><o:p></o:p></p><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music / High North Inc<br><a href="http://sites.google.com/site/blueroofmusic" target="_blank"><span style='color:#3333FF'>http://sites.google.com/site/blueroofmusic</span></a><br><a href="http://sites.google.com/site/highnorthinc" target="_blank"><span style='color:#6600CC'>http://sites.google.com/site/highnorthinc</span></a><br>mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Winter 579 Park Place Saline, MI 48176 734-944-0094<br>Summer PO Box 221 Grand Marais, MI 49839 906-494-2434<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Tue, Sep 16, 2014 at 4:07 PM, William A Wagner <<a href="mailto:wamwagner@comcast.net" target="_blank">wamwagner@comcast.net</a>> wrote:<o:p></o:p></p><p class=MsoNormal>In working on the Cloud spec, we decided that Resource, Transform, and Copy<br>Services were not to be considered. EmailIn and Email Out services we to be<br>dropped from the Semantic Model entirely. That left Print, Scan, FaxOut and<br>FaxIn Cloud services that might involve connection to a 'local' service.<br><br><br><br>FaxIn remains an unusual service in that it does not involve an explicit<br>CreateJob or, indeed, any specific Job-related communication with a User. It<br>may involve creation of a user-specific FaxInAvailableJobTicket, which<br>defines how an incoming Fax is to be handled. In the MFD Model, I don't<br>think we ever defined how a FaxInAvailableJobTicket was provided to a FaxIn<br>Service. Conceptually, it could be either be via some out of band<br>management operation, or possible a SetFaxInJobElements or a<br>SetFaxInServiceElements operation. Presumably SetFaxInServiceElements makes<br>the most sense, understanding that there will typically be multiple<br>FaxInAvailableJobTickets with different Imaging Metrics.<br><br><br><br>The interface to a FaxIn Service is therefore most reasonably an<br>administrative operation.<br><br><br><br>The rationale for a Cloud FaxIn service is shaky but probably as valid as<br>for a Cloud FaxOut service: Fax Modems could be in the Cloud or 'Local";<br>incoming fax destinations can be local or in the cloud. Therefore, although<br>the User Client to Cloud Service connection would just be administrative,<br>incoming facsimile messages to a Cloud FaxIn Service may require creating a<br>Job that is sent to a local FaxIn Service (although it could be just a<br>print Service or a storage service). Incoming facsimile messages to a Local<br>FaxIn Service could require both notification and upload of the facsimile<br>message to a Cloud FaxIn Service, although such transfers could be out of<br>band from the model. Presently, we have not provided any mechanism for the<br>Proxy to create a job in the Cloud Service (do we want to?)<br><br><br><br>So.long story short, should we:<br><br>1. Drop FaxIn from the Cloud Model<br><br>2. Allow a Cloud FaxIn Service to create a Job from an incoming Fax,<br>and then relay the fax data to a Local FaxIn Service for printing and/or<br>local storage<br><br>3. Also allow a LocalFaxIn Service to create a Job from an incoming<br>Fax and relay the fax data to a Cloud FaxIn service for storage?<br><br><br><br>There are also some parallel questions for FaxOut. Should the Cloud<br>Model consider:<br><br>A. Just configurations where the Fax Modem is 'Local' (fax transmitted<br>and locally generated from locally scanned hardcopy and/or Digital Data<br>obtained by the local FaxOut (or Proxy) Service or Digital Data pulled from<br>the Cloud FaxOut Service.)<br><br>B. Also configurations where the Fax Modem is in the Cloud (fax<br>generated from uploaded locally scanned hardcopy and/or uploaded Digital<br>Data obtained by the local FaxOut or Proxy, or Digital Data otherwise<br>accessed by the Cloud FaxOut Service.<br><br><br><br>It might be noted that whatever we decide, FaxIn should be addressed in the<br>SM3 specification.<br><br><br><br>Many thanks for your consideration.<br><br><br><br><br><br><br><br>_______________________________________________<br>sm3 mailing list<br><a href="mailto:sm3@pwg.org">sm3@pwg.org</a><br><a href="https://www.pwg.org/mailman/listinfo/sm3" target="_blank">https://www.pwg.org/mailman/listinfo/sm3</a><o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>