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