Bill,
I agree that secure retrieval of printed FaxIn document via PIN is not a
basic FaxIn use case. I prefer to defer this type of workflow to a
document specifically on MFD workflows.
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
From: mfd-bounces at pwg.org [mailto:mfd-bounces at pwg.org] On Behalf Of
William Wagner
Sent: Wednesday, August 10, 2011 5:21 PM
To: mfd at pwg.org
Subject: RE: [MFD] Why FaxIn should NOT add the PrintService attributes
OK, that seems consistent with what we have been doing. I would suggest
that this is a case where a scenario narrative would be useful. If
secure retrieval of printed FaxIn document via PIN is a desired basic
FaxIn use case (and I am not sure that it is), the components and steps
necessary to achieve it should be outlined. Conceivably, if there are
more of this sort of multiple-service application which are not obvious
as simple applications of a service but do not require the complexity of
a workflow solution, perhaps they could be addressed in a separate MFD
document?
Thanks,
Bill W.
From: Ira McDonald [mailto:blueroofmusic at gmail.com]
Sent: Wednesday, August 10, 2011 3:58 PM
To: William Wagner; Ira McDonald
Cc: Zehler, Peter; Nancy.Chen at okidata.com; mfd at pwg.org;
mfd-bounces at pwg.org
Subject: Re: [MFD] Why FaxIn should NOT add the PrintService attributes
Hi,
For PIN printing, the destination of the FaxIn must be an electronic
document or a user's electronic mailbox under access control.
As a *separate* job, the end user has to walk up and start
a secure print job. There is no support for *any* DestinationURI
in any PWG MFD service to have a job ticket or other metadata
associated with it.
Fancy printing is NOT the use case of classic fax - just best
effort with the local PrintService's default job ticket is fine.
Real workflow is intentionally out-of-scope in PWG Semantic Model
(at least until SM/3.0 starts up as a project).
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Chair - TCG Embedded Systems Hardcopy SWG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>
mailto:blueroofmusic at gmail.com
Christmas through April:
579 Park Place Saline, MI 48176
734-944-0094
May to Christmas:
PO Box 221 Grand Marais, MI 49839
906-494-2434
On Wed, Aug 10, 2011 at 2:43 PM, William Wagner <wamwagner at comcast.net>
wrote:
I thought that the available job ticket just related to FaxIn processing
(including the destination). The default job ticket for the destination
printer would define print processing. I don't recall that we had
available job ticket capability for printers (do we?). At any rate, the
path for communication the PIN code to the printer (and the intended
recipient) is not clear.
Thanks.
Bill Wagner
From: mfd-bounces at pwg.org [mailto:mfd-bounces at pwg.org] On Behalf Of
Zehler, Peter
Sent: Wednesday, August 10, 2011 2:06 PM
To: Nancy.Chen at okidata.com; Ira McDonald
Cc: mfd at pwg.org; mfd-bounces at pwg.org
Subject: RE: [MFD] Why FaxIn should NOT add the PrintService attributes
This can be accomplished via the AvailableJobTicket, its FaxInMetrics
and FaxInJobTicket, and a properly configured Printer pointed to by
DestinationUri.
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com
Voice: (585) 265-8755 <tel:%28585%29%20265-8755>
FAX: (585) 265-7441 <tel:%28585%29%20265-7441>
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701
From: Nancy.Chen at okidata.com [mailto:Nancy.Chen at okidata.com]
Sent: Wednesday, August 10, 2011 1:33 PM
To: Ira McDonald
Cc: Ira McDonald; mfd at pwg.org; mfd-bounces at pwg.org; Zehler, Peter
Subject: Re: [MFD] Why FaxIn should NOT add the PrintService attributes
How can secure retrieval of printed FaxIn document via PIN be supported
this way? I remember somebody mentioned before in one of our meetings
that this feature is desired. Just won't be supported?
-Nancy
Ira McDonald <blueroofmusic at gmail.com>
Sent by: mfd-bounces at pwg.org
08/10/2011 11:57 AM
To
"Zehler, Peter" <Peter.Zehler at xerox.com>, Ira McDonald
<blueroofmusic at gmail.com>, mfd at pwg.org
cc
Subject
[MFD] Why FaxIn should NOT add the PrintService attributes
Hi Pete,
Originally, we had some boolean to say "and by the way print"
for FaxIn (and EmailIn, presumably) - no longer in the schema.
Then we decided instead to tread print as just another destination.
And treating it that way let's the hardcopy for the FaxIn document
happen easily off-box (e.g., on a printer nearer the user).
I strongly favor no extra privilege/details for the print destination of
FaxIn - just a URI that points to some PrintService that prints with
the configured defaults.
Otherwise FaxIn-to-Print becomes more of a true compound
service - very undesirable.
WDYT?
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Chair - TCG Embedded Systems Hardcopy SWG
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
Christmas through April:
579 Park Place Saline, MI 48176
734-944-0094
May to Christmas:
PO Box 221 Grand Marais, MI 49839
906-494-2434
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
mfd mailing list
mfd at pwg.orghttps://www.pwg.org/mailman/listinfo/mfd
--
This message has been scanned for viruses and
dangerous content by MailScanner <http://www.mailscanner.info/> , and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner <http://www.mailscanner.info/> , and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20110811/2fa0fcf1/attachment-0001.html>