attachment
<div dir="ltr"><div><div><div><div><div>Hi Bill,<br><br></div>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.<br><br></div>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<br></div>they will *not* do an IPP FaxIn service - no protocol binding to satisfy the<br></div><div>PWG prototype requirement.<br><br></div>Cheers,<br></div>- Ira<br><br></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">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 style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</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<br><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div></div></div>
<br><div class="gmail_quote">On Tue, Sep 16, 2014 at 4:07 PM, William A Wagner <span dir="ltr"><<a href="mailto:wamwagner@comcast.net" target="_blank">wamwagner@comcast.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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><br>
</blockquote></div><br></div>