[MFD] Re: MFD Schema updated [keep Email services]

[MFD] Re: MFD Schema updated [keep Email services]

[MFD] Re: MFD Schema updated [keep Email services]

Ira McDonald blueroofmusic at gmail.com
Tue Jul 21 17:51:59 UTC 2009


Hi Bill,

Without commenting on specific products, both of the
following basic services are of interest to Samsung:

EmailIn
- analogous to basic Scan (i.e., Scan-to-File).

- uses a default Job Ticket (configured on Service)
  plus attributes in received email header to accept
  any attached document (any format) and store it
  (in local/remote directory or even specific filename).

EmailOut
- also analogous to basic Scan

- may be invoked from local device Console or a
  workflow Job Ticket received by Email or HTTP.

- uses a default Job Ticket (configured on Service)
   plus LDAP user schema attributes (for Job Owner)
   to mail any document (local on System or by URI
   reference) to a list of recipients (similar to PSTN
   Fax fanout to multiple recipients).

NOTE - This basic service EmailIn is NOT the same
as Print with an email input channel or FaxIn (limited
to image formats).  In particular, EmailIn does NOT
print the received document.

Hope this helps clarify.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: 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 Mon, Jul 20, 2009 at 4:04 PM, William Wagner<wamwagner at comcast.net> wrote:
> Ira,
>
> I would like further clarification what EmailIn and EmailOut. You indicate
> that they are used "in the composed services ScanToEmail and
> TransformToEmail", which appear to be compound services composed of the MFD
> Scan and MFD Transform Services concatenated with one of the Email Services.
>
> I don't mean to discourage inclusion of something that exists, but it would
> seem that the Email "services" used in this way are just transports rather
> than full services, in much the same way as the various types of fax
> services can use phone lines, SMTP, or other protocols as transports.
> Similarly, printers often have the ability to pull messages from a email
> server using POP3 or IMAP4, which are regarded as transport protocols in
> this context, although I guess in your view they would be (part of) EmailIn
> services.
>
> Unless you are thinking of a full email service whereby users can actually
> compose and receive emails on their MFP (which I don't think is a common MFD
> capability), I am having trouble viewing what I think in practice is an
> EMail server supporting SMTP and POP3 and/or IMAP4 as an MFD service.
>
> Perhaps it would help me understand how to deal with EmailIn and EmailOut if
> you could show how these services should be represented in  the Service
> Interfaces document (Figure 1 in the current MFP Overall document).
>
> Thanks,
>
> Bill Wagner
>
>
> -----Original Message-----
> From: mfd-bounces at pwg.org [mailto:mfd-bounces at pwg.org] On Behalf Of Ira
> McDonald
> Sent: Monday, July 20, 2009 2:11 PM
> To: Zehler, Peter; Ira McDonald
> Cc: mfd at pwg.org
> Subject: Re: [MFD] Re: MFD Schema updated [keep Email services]
>
> Hi Pete,
>
> Thanks!
>
> Cheers,
> - Ira
>
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Blue Roof Music/High North Inc
> email: 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 Mon, Jul 20, 2009 at 2:08 PM, Zehler, Peter<Peter.Zehler at xerox.com>
> wrote:
>> Ira,
>> I will add them back in before posting the updated schema to the MFD site.
>> Pete
>>
>> Peter Zehler
>>
>> Xerox Research Center Webster
>> Email: Peter.Zehler at Xerox.com
>> Voice: (585) 265-8755
>> FAX: (585) 265-7441
>> US Mail: Peter Zehler
>> Xerox Corp.
>> 800 Phillips Rd.
>> M/S 128-25E
>> Webster NY, 14580-9701
>>
>>
>> -----Original Message-----
>> From: mfd-bounces at pwg.org [mailto:mfd-bounces at pwg.org] On Behalf Of Ira
> McDonald
>> Sent: Monday, July 20, 2009 2:00 PM
>> To: Zehler, Peter; Ira McDonald
>> Cc: mfd at pwg.org
>> Subject: [MFD] Re: MFD Schema updated [keep Email services]
>>
>> Hi Pete,
>>
>> The services Email<In/Out> in the PWG Job Monitoring MIB
>> (RFC 2707) were for first class Email services - NOT for the
>> separate Fax service (SMTP transport or otherwise).
>>
>> The Samsung prototype of Counter MIB had an EmailOut
>> service used by the composed services ScanToEmail and
>> TransformToEmail - it supported *all*  document formats
>> - NOT just image formats like Fax.
>>
>> Samsung intends to use EmailOut (and probably EmailIn)
>> in PWG Counter MIB implementations.
>>
>> Samsung would to keep Email<In/Out> as distinct basic
>> MFD services in the XML schema and model, please.
>>
>> Cheers,
>> - Ira
>>
>> Ira McDonald (Musician / Software Architect)
>> Chair - Linux Foundation Open Printing WG
>> Blue Roof Music/High North Inc
>> email: 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 Mon, Jul 20, 2009 at 1:27 PM, Zehler, Peter<Peter.Zehler at xerox.com>
> wrote:
>>> My comments are inline below.
>>>
>>> Peter Zehler
>>>
>>>
>>> -----Original Message-----
>>> From: William Wagner [mailto:wamwagner at comcast.net]
>>> Sent: Thursday, July 16, 2009 4:48 PM
>>> Subject: RE: MFD Schema updated
>>>
>>> ...snip...
>>>
>>> 5. EmailIn and EmailOut are listed as services in the Schema, but I
>>> don't
>>> recall discussing what they are, and they did not appear on Figure 1 -
>>> MFD
>>> Services with Primary Interfaces when we first worked up that diagram.
>>> What
>>> are these services? We have described  them as facsimile services using
>>> email (but not IETF fax, which does use SMTP). And if they are fax
>>> services,
>>> calling them email certainly causes confusion. And what is distinctive
>>> about
>>> such services so that we cannot collapse them into FaxIn and FaxOut, as
>>> we
>>> did will all of the other facsimile services?
>>> <PZ>My assumption is that these have been collapsed into the Fax
>>> services and are simply vestigial code.  I will remove them in the next
>>> version of the schema.  We can add them back in if there is a need for
>>> them I am overlooking.</PZ>
>>>
>>> I would appreciate some comments and clarifications.
>>>
>>> Thanks,
>>>
>>> Bill Wagner
>>>
>>>
>>> -----Original Message-----
>>> From: Ira McDonald [mailto:blueroofmusic at gmail.com]
>>> Sent: Wednesday, July 15, 2009 4:45 PM
>>> To: Zehler, Peter; Ira McDonald; mfd at pwg.org
>>> Cc: William Wagner
>>> Subject: Re: MFD Schema updated
>>>
>>> Hi Pete,                                        Wednesday (15 July 2009)
>>>
>>> Here are my comments on 10 July SM/2.0 schema:
>>>
>>> (1) I like the generalization of Printer[Status/Description] elements
>>>    reflected in PwgDeprecated.xsd
>>>    - I agree with Bill that there may yet be more to generalize
>>>    - Note this boils down to applying IPP to MFD services - Good Thing
>>>
>>> (2) I like the rework of System
>>>
>>> (3) I like the rework of NaturalLanguage and Charset
>>>    - IETF just approved RFC 4646bis, so a new RFC reference this fall
>>>
>>> (4) In SubunitStates please capitalize (for consistency):
>>>    coverOpen/Closed, interlockOpen/Closed, and other
>>>
>>> (5) In SubunitStatus type definition and numerous other places in schema
>>>    - SPY has jumbled XML comments randomly out-of-line
>>>
>>> (6) StorageDataEncryption should be StorageDataEncryptionIsEnabled,
>>>    since it's a boolean not an enum (w/ default to false)
>>>    - see lines 59 to 65 in Subunits.xsd
>>>
>>> (7) MediaPathStatus should include SheetsCompleted like
>>>    ScanMediaPathStatus (though the property's not in Printer MIB)
>>>    - What are the semantics?
>>>    - Are these Lifetime or PowerOn counters?
>>>
>>> (8) FinisherSupply (from Finisher MIB) and
>>>    MarkerSupply (from Printer MIB) should probably be combined into
>>>    ImagingSupply
>>>    - in recent MIB walks, many manufacturers list FinisherSupply stuff
>>>      in prtMarkerSuppliesTable (where types like 'staple' are defined)
>>>    - the advantage of using the common table (among others) is that
>>>      Finisher supplies show up in HP WJA and other fleet mgmt tools
>>>
>>> (9) I like the current ImagingJob and ImagingJobTicket classes
>>>
>>> Cheers,
>>> - Ira
>>>
>>> Ira McDonald (Musician / Software Architect)
>>> Chair - Linux Foundation Open Printing WG
>>> Blue Roof Music/High North Inc
>>> email: 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 Fri, Jul 10, 2009 at 2:13 PM, Zehler, Peter<Peter.Zehler at xerox.com>
>>> wrote:
>>>> I updated the MFD site with the schema version I last sent to you.
>>>>
>>>> Peter Zehler
>>>>
>>>> Xerox Research Center Webster
>>>> Email: Peter.Zehler at Xerox.com
>>>> Voice: (585) 265-8755
>>>> FAX: (585) 265-7441
>>>> US Mail: Peter Zehler
>>>> Xerox Corp.
>>>> 800 Phillips Rd.
>>>> M/S 128-25E
>>>> Webster NY, 14580-9701
>>>>
>>>>
>>>
>>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>> _______________________________________________
>> mfd mailing list
>> mfd at pwg.org
>> https://www.pwg.org/mailman/listinfo/mfd
>>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> mfd mailing list
> mfd at pwg.org
> https://www.pwg.org/mailman/listinfo/mfd
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




More information about the mfd mailing list