[Cloud] [SM3] Cloud FaxIn Service

[Cloud] [SM3] Cloud FaxIn Service

[Cloud] [SM3] Cloud FaxIn Service

Michael Sweet msweet at apple.com
Wed Sep 17 15:43:52 UTC 2014


My $0.02 CAD - Cloud FaxIn is out-of-scope, not only because of prototyping but because remote management is out of scope already (as Bill points out) and any local-to-Cloud push of incoming faxes sure looks a lot like a regular client-to-Cloud interaction that we don't need to be involved in...


On Sep 16, 2014, at 4:19 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:

> Hi Bill,
> 
> We *did* define in complete detail how a set of available job tickets are
> configured on a FaxIn service and how they are selected - and all of 
> this is in SM schema and the most recent FaxIn draft.
> 
> BUT - I strongly urge that we *not* put FaxIn into Cloud Model, because
> the IPP WG has decided (and written into their charter a year ago) that
> they will *not* do an IPP FaxIn service - no protocol binding to satisfy the
> PWG prototype requirement.
> 
> Cheers,
> - Ira
> 
> 
> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto: blueroofmusic at gmail.com
> Winter  579 Park Place  Saline, MI  48176  734-944-0094
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
> 
> 
> On Tue, Sep 16, 2014 at 4:07 PM, William A Wagner <wamwagner at comcast.net> wrote:
> In working on the Cloud spec, we decided that Resource, Transform, and Copy
> Services were not to be considered.  EmailIn and Email Out services we to be
> dropped from the Semantic Model entirely. That left Print, Scan, FaxOut and
> FaxIn Cloud services that might involve connection to a 'local' service.
> 
> 
> 
> FaxIn remains an unusual service in that it does not involve an explicit
> CreateJob or, indeed, any specific Job-related communication with a User. It
> may involve creation of a user-specific FaxInAvailableJobTicket, which
> defines how an incoming Fax is to be handled. In the MFD Model, I don't
> think we ever defined how a  FaxInAvailableJobTicket was provided to a FaxIn
> Service. Conceptually, it could be either be via some out of band
> management operation, or possible a SetFaxInJobElements or a
> SetFaxInServiceElements operation. Presumably SetFaxInServiceElements makes
> the most sense, understanding that there will typically be multiple
> FaxInAvailableJobTickets with different Imaging Metrics.
> 
> 
> 
> The interface to a FaxIn Service  is therefore most reasonably an
> administrative operation.
> 
> 
> 
> The rationale for a Cloud FaxIn service is shaky but probably as valid as
> for a Cloud FaxOut service: Fax Modems could be in the Cloud or 'Local";
> incoming fax destinations can be local or in the cloud. Therefore, although
> the User Client to Cloud Service connection would just be administrative,
> incoming facsimile messages to a Cloud FaxIn Service may require creating a
> Job that is sent to a local FaxIn  Service (although it could be just a
> print Service or a storage service). Incoming facsimile messages to a Local
> FaxIn Service could require both notification and upload of the facsimile
> message to a Cloud FaxIn Service, although such transfers could be out of
> band from the model. Presently, we have not provided any mechanism for the
> Proxy to create a job in the Cloud Service (do we want to?)
> 
> 
> 
> So.long story short, should we:
> 
> 1.       Drop FaxIn from the Cloud Model
> 
> 2.       Allow a Cloud FaxIn Service to create a Job from an incoming Fax,
> and then relay the fax data to a Local FaxIn Service for printing and/or
> local storage
> 
> 3.       Also allow a LocalFaxIn Service to create a Job from an incoming
> Fax and relay the fax data to a Cloud FaxIn service for storage?
> 
> 
> 
> There are  also some  parallel  questions for FaxOut.  Should the Cloud
> Model consider:
> 
> A.      Just configurations where the Fax Modem is 'Local' (fax transmitted
> and locally generated from locally scanned hardcopy and/or  Digital Data
> obtained by the local FaxOut  (or Proxy) Service or Digital Data pulled from
> the Cloud FaxOut Service.)
> 
> B.      Also configurations where the Fax Modem is in the Cloud (fax
> generated from uploaded locally scanned hardcopy and/or uploaded  Digital
> Data obtained by the local FaxOut  or Proxy, or Digital Data otherwise
> accessed by the Cloud FaxOut Service.
> 
> 
> 
> It might be noted that whatever we decide, FaxIn should be addressed in the
> SM3 specification.
> 
> 
> 
> Many thanks for your consideration.
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> sm3 mailing list
> sm3 at pwg.org
> https://www.pwg.org/mailman/listinfo/sm3
> 
> _______________________________________________
> cloud mailing list
> cloud at pwg.org
> https://www.pwg.org/mailman/listinfo/cloud

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20140917/5c676f16/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4881 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/cloud/attachments/20140917/5c676f16/attachment.p7s>


More information about the cloud mailing list