[Cloud] [SM3] Cloud FaxIn Service

[Cloud] [SM3] Cloud FaxIn Service

Ira McDonald blueroofmusic at gmail.com
Tue Sep 16 20:19:09 UTC 2014

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.

- 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
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>

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20140916/946cc533/attachment.html>

More information about the cloud mailing list