[Cloud] [SM3] Cloud FaxIn Service

[Cloud] [SM3] Cloud FaxIn Service

William A Wagner wamwagner at comcast.net
Wed Sep 17 18:33:20 UTC 2014



I understand your reasoning but  wonder about: 

1.       FaxIn where the modem is in the Cloud (and therefore setting
AvailableFaxInJobTicket via the modeled Cloud Service management interface
is valid), but the fax is printed out on as associated Local FaxIn Service.

2.       FaxOut where the modem is in the Cloud but input includes scanned
copy provided by a Local FaxOut service.

It would seem that both of these cases span.

Bill Wagner


From: Michael Sweet [mailto:msweet at apple.com] 
Sent: Wednesday, September 17, 2014 1:49 PM
To: William A Wagner
Cc: Ira McDonald; cloud at pwg.org; Semantic Model 3.0 Workgroup discussion
Subject: Re: [Cloud] [SM3] Cloud FaxIn Service




The Cloud Service Management Operations are directed to the Cloud service
and only manage the Cloud service.  We don't relay them through the Proxy to
the Local service and have no way to do so in the current model - all out of
scope for a long time.  Similarly, there is no way to remotely manage the
Proxy - out of scope.


All client-initiated job-based services that span between the Cloud and
Local services are in scope for the Cloud Imaging Requirements and Model:


- FaxIn does not span and jobs are not client-initiated.  It should be out
of scope.


- FaxOut MAY span and has client-initiated jobs.  Cloud-based FaxOut through
a Local service should be in scope.  Purely Cloud FaxOut (with the fax modem
in the cloud too) is the same as SM FaxOut and should be out of scope.
Similarly, FaxOut from the Local Device should be out of scope since either
a) the Cloud isn't involved or b) it *is* involved in some way, but not
using the interface in this document.


- Print spans and has client-initiated jobs.  It should be in scope.


- Resource does not span and has no jobs.  It should be out of scope.


- Scan spans and has client-initiated jobs.  If should be in scope.


- Transform does not span.  It should be out of scope.




On Sep 17, 2014, at 1:23 PM, William A Wagner <wamwagner at comcast.net> wrote:



Actually, I believe at your suggestion, we did add
<x-msg://30/#_Toc397612068>  Cloud Service Management Operations. 46 to the
Model, including the SetServiceElements operation that (I suggest) defines
incomming facsimile  handling.  However, I do get the sense that there is no
interest in including FaxIn so unless someone suggestst that it is
desirable, I will eliminate it.  We are, of course, rethinking things we had
settled some time ago. Any other Services we should drop? What about
CloudFaxOut? CloudScan?



Bill Wagner





From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Michael Sweet
Sent: Wednesday, September 17, 2014 11:44 AM
To: Ira McDonald
Cc: cloud at pwg.org; Semantic Model 3.0 Workgroup discussion list
Subject: Re: [Cloud] [SM3] Cloud FaxIn Service


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.


- 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


cloud mailing list
cloud at pwg.org


Michael Sweet, Senior Printing System Engineer, PWG Chair



Michael Sweet, Senior Printing System Engineer, PWG Chair


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20140917/f4b3219b/attachment.html>

More information about the cloud mailing list