attachment
<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Ira,<div><br><div><div>On Mar 21, 2014, at 3:02 PM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>> wrote:</div><blockquote type="cite"><div dir="ltr"><div><div><div><div><div>Hi,<br><br></div>I don't like "destination-uri-ready" at all. It doesn't scale. It doesn't add any<br></div>visible utility. It's actively a bad idea for IPP Everywhere as a pervasive<br>
</div>print protocol.<br></div></div></div></blockquote></div><div><br></div><div><div>The "destination-uri-ready" attribute would *not* be used for Print since there we specify destination with "printer-uri" and potentially "output-device", and there we already have an "output-device-supported" attribute that clients can use for fan-out services.</div></div><div><br></div><div>However, for Scan, FaxOut, etc. where the destination is not specified by the "printer-uri" attribute, it would give clients and way to tell the Client about site-configured destinations, beyond the simple "you can scan to email" kinds of things the current "destination-uri-schemes-supported" attribute provides. There is also precedent for such an attribute - JPS2 defines a similar "save-location-supported (1setOf uri)" attribute for Job save.</div><div><br></div><div>I am specifically thinking of Pete's workflow environment where the Scan service might need to submit scanned documents to a local service - by having an attribute that lists local bookmarks/presets the Client can present this as a choice to the user beyond entering a URL or email address. And it allows for implementation-specific things in the case of HTTP, since there you might want something other than a bare PUT of the document images.</div></div><div><br></div><div>So, let's say we define "destination-uri-ready" as follows:</div><div><br></div><div> destination-uri-ready (1setOf collection)</div><div> destination-is-directory (boolean) [true if the URI refers to a directory; Client adds /name to the end]</div><div> destination-name (name(MAX)) [localized name of URI]</div><div> destination-uri (uri) [destination-uri that can be included in job creation request]</div><div><br></div><div>And a Scan service reports:</div><div><br></div><div> destination-uri-schemes-supported = "ftp", "http", "https", "ipp", "ipps", "mailto", "smb"</div><div> destination-uri-ready =</div><div> { destination-is-directory=true destination-name="Archive" destination="<a href="http://storage.example.com/archives/">http://storage.example.com/archives/</a>" },</div><div> { destination-name="OCR and Email" destination="<a href="ipps://ocr.example.com/ipp/ocr+email">ipps://ocr.example.com/ipp/ocr+email</a>" },</div><div> { destination-name="OCR and Archive" destination="<a href="https://storage.example.com/ocr">https://storage.example.com/ocr</a>" }</div><div><br></div><div>The Client would then allow the user to enter a URI and/or email address, or pick from one of the three "ready" destinations that have been configured on the Scan service. It specifically would *not* be used as an address book of all local email addresses - that's what LDAP is for. Instead, it is about Client discovery of local receiving services with implementation-specific configuration of those services by a local owner/operator/administrator.</div><div><br></div><div>....</div><div><br></div><div>The other attribute I proposed was "document-uri-ready", which would be applicable to Print, EmailOut, and FaxOut, and could be a lightweight way to expose document resources provided by the service or by other local services, such as cover pages, brochures, and other standard content that has been configured on the service.</div><div><br></div><div>I am less enthusiastic about this attribute because practical applications of print-by-reference tend to be tightly controlled/managed in integrated solutions that have already "solved" this particular discovery problem. That said, the same kind of solution could be defined if there is interest...</div><div><br></div><div><span style="font-family: 'Andale Mono'; orphans: 2; text-align: -webkit-auto; widows: 2;">_________________________________________________________</span></div><div><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; font-family: 'Andale Mono'; border-spacing: 0px;"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</div>
<br></div></body></html>