attachment
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Smith,<div class=""><br class=""><blockquote type="cite" class="">On Nov 5, 2014, at 1:30 PM, Kennedy, Smith (Wireless Architect) <<a href="mailto:smith.kennedy@hp.com" class="">smith.kennedy@hp.com</a>> wrote:<br class=""><br class="">Hi Mike,<br class=""><br class="">Would consideration at this level for access control / permissions be needed?<br class=""></blockquote><div class=""><br class=""></div>The way I'm wording it for IPP INFRA is to require AAA (or IAA if you adopt the IDS acronym) to be the same for both IPP and HTTP/HTTPS:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">Infrastructure Printers that provide storage and hosting of static resources MUST support the HTTP DELETE, GET, and PUT request methods [RFC7230] for the given URI prefix, MUST support the HTTP "If-Unmodified-Since" header [RFC7232], and MUST authenticate DELETE and PUT requests using the same scheme and authority/realm as the IPP URI. That is, if the Infrastructure Printer uses HTTP Basic authentication for the "Example" realm, any DELETE or PUT requests to the "printer-static-resource-directory-uri" URI MUST also use HTTP Basic authentication for the "Example" realm.</div></blockquote><div class=""><br class=""></div><div class="">I'm not sure if we can make the same normative requirements in the abstract Semantic Model...</div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class=""><br class="">Smith<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On 2014-11-04, at 8:57 PM, Michael Sweet <<a href="mailto:msweet@apple.com" class="">msweet@apple.com</a>> wrote:<br class=""><br class="">All,<br class=""><br class="">OK, so based on the discussions in today's joint IPP/Cloud sessions I'd like to propose the following new Semantic Model ServiceDescription elements (IPP Printer Description attributes in parenthesis):<br class=""><br class="">- ServiceStaticResourceDirectoryUri ("printer-static-resource-directory-uri (uri)") - directory URI for HTTP PUT requests (to create resources) and HTTP DELETE requests (to cancel resources)<br class=""><br class="">- ServiceStaticResourceKOctetsReady ("printer-static-resource-k-octets-ready (integer(0:MAX))") - Available storage capacity in K octets (1024 octets).<br class=""><br class="">- ServiceStaticResourceKOctetsSupported ("printer-static-resource-k-octets-supported (integer(0:MAX))") - Maximum storage capacity in K octets (1024 octets).<br class=""><br class="">Resources are created using HTTP PUT requests and canceled using HTTP DELETE requests. Doing a PUT to "ServiceStaticResourceDirectoryUri/filename.ext" does the equivalent of the CreateResource (formerly DeleteResource) operation with the following elements:<br class=""><br class="">ResourceCategory=Static<br class="">ResourceCreatorUserName=<HTTP authenticated user name><br class="">ResourceName=<path component of URI without leading slash><br class="">ResourceType=<mapped from Content-Type - Image, ICCProfile, or *MessageCatalog*><br class="">ResourceFormat=<Content-Type value><br class="">*ResourceUri*=<URI of PUT><br class=""><br class="">(*foo* is a new value or element)<br class=""><br class="">If the PUT request includes the conditional request header If-Unmodified-Since, then the service does an atomic combination of a CancelResource (formerly DeleteResource) followed by a CreateResource if the destination resource is older than the specified date.<br class=""><br class="">Doing a DELETE to "ServiceStaticResourceDirectoryUri/filename.ext" does the equivalent of the CancelResource operation for the matching ResourceUri.<br class=""><br class="">Thoughts?<br class=""><br class="">_________________________________________________________<br class="">Michael Sweet, Senior Printing System Engineer, PWG Chair<br class=""><br class="">_______________________________________________<br class="">ipp mailing list<br class=""><a href="mailto:ipp@pwg.org" class="">ipp@pwg.org</a><br class="">https://www.pwg.org/mailman/listinfo/ipp<br class=""></blockquote><br class=""></blockquote><br class=""><div class="">_________________________________________________________<br class="">Michael Sweet, Senior Printing System Engineer, PWG Chair<br class=""></div><br class=""></div></body></html>