attachment-0002
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><base href="x-msg://348/"><style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Impact;
panose-1:2 11 8 6 3 9 2 5 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:322317163;
mso-list-type:hybrid;
mso-list-template-ids:-1799831018 460482930 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;}
@list l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple style='word-wrap: break-word;-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'><div class=WordSection1><p class=MsoNormal><span style='font-size:14.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The revived interest is most encouraging. One concern I have with PWG going off and defining a Cloud Printing model (that may be unjustified) is that we may not fully understand cloud printing aspects beyond the printing, part of the “gap” that Randy refers to. Another is wondering who would implement a PWG model…or perhaps the model would just be intended to illustrate some ideas that other implementations could adopt. By all means, if there is interest and personnel, lets proceed with the model that Pete has identified (and perhaps it is more practical to do an IPP binding directly without doing the abstract model first.)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:14.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:14.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>But, from what I understood of our objective, I thought that the suggestion from Ranga Raj was very good, particularly to the extent that Celstream, as an Cloud Printing implementer, could provide much of the information about current solutions and problem areas...and perhaps about the “gaps”. His suggestion, which to an extent is consistent with our print ticket mapping effort, was:<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>We look at the Cloud Imaging Workflow and current solutions being offered today - current CISPs are tending to be proprietary silos in most cases <o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Evaluate what components in the workflow and deployment use cases that are most likely to benefit from a standardization effort from PWG and re-order the sequence of standards being released for adoption (not that I am stating that the current sequence may not be right)<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>This would enable CISPs (we are one of them) to consider PWG standards adoption in our roadmap, especially in areas with maximum pain points or to tackle interoperability aspects. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:14.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:14.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>At any rate, I strongly suggest that we do complete our existing effort with print tickets since they are a contribution to both the PWG model and something that could be adopted by existing implementations.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:14.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:14.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Bill Wagner<o:p></o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> cloud-bounces@pwg.org [mailto:cloud-bounces@pwg.org] <b>On Behalf Of </b>Randy Turner<br><b>Sent:</b> Tuesday, December 13, 2011 12:03 PM<br><b>To:</b> cloud@pwg.org<br><b>Subject:</b> Re: [Cloud] Cloud Print binding to IPP<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Hi Pete,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I think it's great to see this initiative…my fundamental question regarding cloud print has been identifying really where the differences are between network printing in an enterprise, and a cloud print model, and then just gap filling.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Microsoft Windows Servers (specifically the print server capability) has always had the ability to store queues on a server and deliver jobs to "known" (or "registered") printers -- and to your point about being able to fan-in / fan-out, you can (in theory) string together print servers that print to print servers that eventually hold queues to actual physical devices.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>All of the print job semantic model applies to cloud printing, I don't think we need to re-visit anything -- it seems to me that's it's only a problem of registration…and possibly security, but existing systems may have a model for this as well.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I guess what I'm curious about is identifying the "gap" between network printing on an enterprise and cloud printing -- my hunch is the gap isn't much. We're just moving the print server to the internet, and scaling the fan-in problem (but that's an infrastructure problem, not a printing problem)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>R.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Dec 13, 2011, at 5:33 AM, Zehler, Peter wrote:<o:p></o:p></p></div><p class=MsoNormal><br><br><o:p></o:p></p><div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>All,<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>I would like to see an IPP binding for Cloud printing. I see a significant advantage to an IPP based solution given the maturity of the protocol and the industry wide support. I experimented with a cloud based print service back in 2009. I based my experiments on a WS-Print binding but an IPP binding would also work. I switched the binding from WS-Print to PWG SM and included it in v1.160 of the PWG SM Schema. It is easier for me to write Schema than IPP and easier to display. It is not difficult to move between the two mappings. The issues I did not address include an environment agnostic registration and a common security model. <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>For clarity I will refer to the Cloud based Printers as Queues and the devices as Printers even though in the IPP model they are both implementation of IPP Printers. In v1.160 of the PWG Semantic Model Schema I included two files (i.e., PwgCloudPrintQueue.wsdl and PwgCloudPrintQueueMsg.xsd) that have some of the operations fleshed out a bit. (I dropped a couple things moving from WS-Print to PWG SM.)<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>I had a couple of assumptions going in.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>I believe that Queues and Printers contain Jobs and are stateful. There is an association between the Jobs in a Queue and the Jobs being printed on a Printer. A mapping between them should be maintained on both sides and carried explicitly in the protocol. I do not believe we should be implementing “remote markers” where Jobs only reside in the Cloud. It should be possible for either side to use IPP operations to query the state of the Printer/Queue and their Jobs.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>I believe it is a requirement that the Cloud Print model must support both Fan Out and Fan In. In other words it should be possible for a single Cloud Queue to act as a proxy for other Cloud Queues. This will allow a Printer to interact with a single Cloud Queue but still service jobs in multiple Cloud Queues. Taking this approach allows you to do things such as set different default behaviors for Queues that all map to the same Printer. (The User does not need a Job Ticket since the intent is associated with the various Queues.) This approach also allows you to enforce different capabilities for different users. Users have permission to use specific Queues. The Queues could prohibit color printing or limit the size of a Job. <span class=apple-converted-space> </span><br> It should also be possible for one Printer to interact with a Queue and forward Jobs to other Printers. For example a Printer in an enterprises DMZ could forward jobs to internal Printers or a software only Printer could front end legacy devices (i.e., proxy).<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>The way I broke the processing of Cloud Jobs up was; Check for Work, Lock the Job, Update the Job Status, Retrieve the Document(s), and Finish the Job. I also had another group of things that include; synchronization of Printer and Job state, Firewall Traversal, Moving from Poll Driven to Event Driven, and Eventing.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Check for work:<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>The Printer should be event driven when processing Jobs. See below for a discussion on eventing. The printer should query the Queue for available work. <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>The Operation IsThereAnyWork <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><<a href="http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1036">http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1036</a>><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>is used by the Printer to ask a Queue to see if any work is available. The request contains a list of DestinationServiceUuids (i.e. printer-uuid) where the Jobs will be printed. The response will have a list of work entries. Each entry contains the SourceServiceUuid, DestinationServiceUuid (missing in schema) and a list of Job ids. I used a UUID instead of an ID but as long as the source Queue is identified either would work.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Lock the Job:<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Once a Printer has determined the job it will process, it sends a DeQueuePrintJob operation<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><<a href="http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1035">http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1035</a>><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> to the Queue. This operates a little differently than CreateJob in that the Printer Job identifier needs to be reserved until the operation succeeds. If the operation fails or times out the identifier and any allocated resources are discarded. The request includes the identifiers for the source and destination Queue/Printer and Jobs. The response contains the number of documents in the job as well as some job information such as the job name and owner. Although not included a JobTicket should be passed in the response as well. The payload of the response should closely match a CreateJob operation. We may also want to consider passing a JobTicket by reference which IPP does not permit at this time.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Update the Job Status:<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Event notifications are used to keep the state of the Job, Document and Service updated. I used WS-Eventing but an IPP notification method can be substituted. See eventing discussion below.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Retrieve the Document:<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>The Printer retrieves the documents to process using the Retrieve Document operation<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><<a href="http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1038">http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1038</a>>. <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>The request identified the source Service, Job and Document number. The response includes the document number and a flag to indicate if it is the last document. Other information such as a Document Ticket or the DocumentFormat can also be included. Since the Printer does not know if the document will be pushed or pulled it must be ready to accept a DocumentUri or Document Content in the response. I used MTOM but IPP already has an acceptable encoding. It is most efficient to use print by reference whenever possible. <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Finish the Job:<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Once the Job has been printed the final update of the Job is done. Note that events are used to handle updates as the Job is being processed. The CompleteDequeuePrintJob operation<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><<a href="http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1034">http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1034</a>><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>request contains the Source and destination Queue/Printer and Jobs and the details of the Destination Job. Included is The JobState, any JobStateReasons, DateTimeAtCompletion and the ImpressionsCompleted. The PrintJobReceipt can also be included.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Synchronize Printer/Queue state,<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Synchronize Job state,<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Moving from Polling to Event Driven<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Firewall traversal<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Eventing:<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>This nice thing about outbound (i.e., Printer to Queue) eventing in a Cloud environment is that no event subscription needs to be sent. The Printer knows the Queue is interested in Printer and Job events. Either a well-known listener port can be used or the location can be part of registration. Since the Printer knows which jobs came from the Cloud it can filter the Job events. Whenever a Printer is initialized a printer state event should be sent to its registered Queues. If the content of the event is insufficient then a one way message that looks like a GetPrinterAttributes operation response could be used.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>In order to move from a poll model to an event driven model we need a mechanism to traverse the firewall. I originally used a hacked together HTTP trickle protocol. A standardized protocol such as XMPP can be used instead. The PWG can create PWG specific stanzas that map to existing IPP operations such as GetPrinterAttributes, GetJobs or GetJobAttributes. A new stanza would be needed to let the Printer know it’s time to send an IsThereAnyWork operation to a Queue.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Registration:<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>I did not do anything with registration other than put in a place holder. The RegisterPrinter operation<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><<a href="http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1037">http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1037</a>><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>request contains some Printer information such as the identifier for the Queue and the Printer. It was not clear to me if the existence of a Queue is a prerequisite or a result of the operation. The Printer information would also include the PrinterCapabilities that we recently defined in the Job Ticket work. This contains the defaults, capabilities and document generation information. I included some “Agent” information. I assumed there would be some security information exchanged so I just put a placeholder there. <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Comments?<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Impact","sans-serif";color:navy'>Peter Zehler</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><br><br></span><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:navy'>Xerox Research Center Webster<br></span><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'>Email:<span class=apple-converted-space> </span></span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><a href="mailto:Peter.Zehler@Xerox.com"><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Peter.Zehler@Xerox.com</span></a><span style='color:#1F497D'><br></span></span><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'>Voice: (585) 265-8755</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><br></span><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'>FAX: (585) 265-7441</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><br></span><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'>US Mail: Peter Zehler</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><br></span><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'>Xerox Corp.</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><br></span><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'>800 Phillips Rd.</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><br></span><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'>M/S 128-25E</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><br></span><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'>Webster NY, 14580-9701</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><p class=MsoNormal><span style='font-size:13.5pt;font-family:"Helvetica","sans-serif"'><br>--<span class=apple-converted-space> </span><br>This message has been scanned for viruses and<span class=apple-converted-space> </span><br>dangerous content by<span class=apple-converted-space> </span><a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is<span class=apple-converted-space> </span><br>believed to be clean. _______________________________________________<br>cloud mailing list<br><a href="mailto:cloud@pwg.org">cloud@pwg.org</a><br><a href="https://www.pwg.org/mailman/listinfo/cloud">https://www.pwg.org/mailman/listinfo/cloud</a><o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal><br>-- <br>This message has been scanned for viruses and <br>dangerous content by <a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is <br>believed to be clean. <o:p></o:p></p></div><br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.
</body></html>