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>